Latest Entries »

Temporal Motivation Theory

I was recently asked if it was ok to do the Sprint Retro on Sprint Planning day…

The answer depends on context. Many teams find it most efficient to do all the Scrum events on 1 day e.g. Review/Retro/Planning. If that is agreed up-front as part of teams normal cadence that is fine. However if the Sprint has been extended by half a day to accommodate the Retro, for example the Retro is planned for a Friday afternoon (on a Mon-Fri sprint) and it is moved to Monday morning, then this is a ScrumBut anti-pattern. (We do Scrum but we do the Retro on Planning day by extending the print by half a day):

This is a good round-up on not extending Sprints:

Another view from a more traditional PM viewpoint:

“Working in timeboxes is equal to creating short milestones and achieving those milestones in a continuous manner.

The reason for this we can understand through the Temporal Motivation Theory. This theory (TMT) was developed by Piers Steel and Cornelius J. Konig. The theory emphasizes time as a critical, motivational factor. The Temporal Motivation Theory formula can be applied to human behavior, procrastination, and to goal setting. According to Lord, Diefenforff, Schmidt, and Hall, the theory models the motivating power of approaching deadlines, arguing that the perceived utility of a given activity increases exponentially as the deadline nears.”

So there you go…quote Temporal Motivation Theory. Timeboxing is science

The Happiness Index is a pattern taken from Jeff Sutherlands paper ‘Teams That Finish Early Accelerate Faster’ I implemented the pattern with a team a couple of years ago and found it to be a very useful metric. I’m a strong believer in human centred behavioural metrics which inform intelligent decision making.

The Happiness Metric accurately told a story of 6 or 7 months on our team where we encountered a situation where the current backlog we were working on got pulled just prior to release and we went in to a Waterfa(i)ll style 3-4 month  traditional discovery phase.

The way I facilitated this with the team was at the end of the retro I stuck two post-its outside the room with “How happy are you with the company?” and “How happy are you with your role?” on them and asked everyone to stick post it’s underneath on a scale of 1(low) to 5(high) on their way out the room.


The output was tracked on a spreadsheet and then visualised  in a basic graph.


What is interesting is that the happiness of the team with their roles was substantially more resilient than their feelings about the company. We were a tight knit team and this shows the importance of strong team relationships which can sustain the team through tough times. The Sprints were 2 week iterations so from Sprint 6 to Sprint 01 represents about 5 months. Although every team is different, this empirical data would suggest a mature ‘healthy’ team can support a 4 to 5 month rough patch before losing motivation in their role. In this case a traditional project discovery phase was managed in a typically top down way and left the team in a perpetual spike cycle with no output except for estimates against a growing and churning backlog.

With the index as evidence I worked with the team running workshops and challenging the traditional project management approach to give them hope that there was an end in sight. The knowledge of how the team felt enabled me to adjust my coaching strategy accordingly.

I would suggest that you consider adopting a metric of this nature.

A note on Metrics:

When applying the rule ‘you improve what you measure‘ as distinct from the over used Peter Drucker quote ‘If you can’t measure it, you can’t improve it’, you need to be wary of the negative scenario this creates; in other words whilst you concentrate efforts on improving your measured metric you are likely getting worse in an area that is not being focused on.

Definition of Done

The Definition of Done (DOD) is a key artefact mentioned in the Scrum guide 2016:

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done”means.

It is the cornerstone for understanding whether a User Story or piece of work is completed. I follow a formula which starts with a very basic DOD and then gets gradually more complex. This is to help the team define it’s processes, inspect and adapt and gain pride in the product they are creating.

A simple DOD example would be:

  1. Feature complete
  2. Code/Activity  complete
  3. No known defects
  4. Approved by the Product Owner
  5. Production ready

This is just a skeleton but is typically where I would start with a team. This is an actual DOD that I used with a start-up in the legal sector. A more advanced version used with a more mature team is:

  1. Design approved by Architect
  2. Development /coding complete
  3. Solution builds successfully – (Passes code analysis)
  4. Everything checked in to source control – including code and scripts etc
  5. TFS/Board up to date
  6. Code coverage with Unit Tests – 100% coverage of logical code
  7. Code Review – Code and tests reviewed – (peer to peer review)
  8. Deploy to Test Environment
  9. DB review
  10. All COA’s are met
  11. All tests pass
  12. No known critical defects
  13. Demo to Scrum Master
  14. Complete documentation including release notes
  15. Sign off from relevant parties
  16. Product Owner is happy
 You can also extend this powerful document to cover other activities. I worked for a company in the automotive sector and helped create a Definition of Done for the Scrum Masters:
  1. Review Impediments and seek resolution
  2. Impediments external to team escalated (Update Development Team Impediments Board)
  3. Provide sprint burn down updates to the team (Ensure emailed and all members are aware)
  4. Print daily burn down and advertise on the Scrum board
  5. Ensure/Facilitate accuracy of the Scrum board
  6. Tasks updated
  7. Support Statistics updated
  8. High risk/impact impediments highlights
  9. Sprint work reviewed
  10. TFS accurate (Tasks completed are code reviewed, test cases raised for user stories, rework completed and tested)
  11. Catch up with development team members at local machine to run through project work in progress
  12. Facilitate product backlog grooming / prioritisation
  13. Carry out completed test cases which are “ready to test”
  14. Put time towards study/research/future strategy with the aim of improving development standards

You can accomplish many things by applying the logic of this document to many scenarios. I have worked with a complimentary document called the Definition of Ready to top and tail the development process by acting as a quality gate for work entering the SDLC

I’d love to hear from you if you have other interesting and effective ways of using this document.

Team Boot-Up

I’d like to share my experiences of the workshops that are originated from the Agile Fairies. I’ve run these sessions with several teams now and found them particularly useful for forming new teams and for re-forming teams that have been through a period of disruption.

If I’m working with a new team, I generally run this as a morning session and follow it up with a Scrum 101 workshop.

The itinerary runs something like this:

  1. Icebreaker (10 mins): It’s good to talk
  2. Team definition (30 mins): What do we mean by ‘Team’?
  3. Quality definition (30 mins): What do we mean by ‘Quality’?
  4. Team manifesto (30 mins): The Pirates Charter

It’s Good To Talk – The profile card ice-breaker exercise (For new teams)

profile_cards_blog1This exercise is done in pairs and as with any ice-breaker, breaks down barriers to conversations. The nice thing is that the output is an index card which can be displayed on the wall of the team room.

The ice-breaker takes about 5 minutes and the task is to produce a profile card of each other with:

  • Name
  • Pet love
  • Pet hate
  • Contact details
  • Draw a photo quality portrait (i.e. it is recognisable as the person)

The drawing is approached with some trepidation by most people but also produces the most laughs and is the activity that many people remember.

What do we mean by ‘Team’?

What-do-we-mean-by-teamWe use ThemeStorming (sticky note clustering) to ensure we collect everybody’s ideas. The team is asked to write down on Post-Its what ‘Team’ means to them. Ideas are themed and each team member receives 3 dot votes to identify the most popular themes. The top 5 themes are noted.

I have found it useful to provide a starter for ten with this exercise. Start throwing around a few words which can begin to guide the conversation. Be careful though…It’s easy to start leading the conversation. We are looking for the teams intuition and knowledge!

What do we mean by ‘Quality’?

This is very similar to the previous exercise except that we are examining views on what the concept ‘Quality’ embodies for the team. The output should be the same. The team should be getting the hang of this by now and I usually provide a few examples of words to get the discussion going.

The Pirates Charter

what-do-we-mean-by-qualityI quite like to call this The Pirates Charter. I think that it gives a greater indication that the team is planning a voyage of discovery together as team and these are the values that they will hang their hat on. I have had this challenged by some people who feel there are negative connotations to the pirate metaphor, which is why I sometimes fall back to calling it the Team Manifesto. It depends on the team you are working with and business environment you are operating in.

Now we have the team values and the team’s definition of Quality, they are ready to create the charter or manifesto out of two A0 posters. An illustrated charter should be created by the team for the team.

Everyone signs the poster once it is completed, which re-affirms the values as a foundation for the team. The poster is displayed in the team room which reinforces commitment and provokes discussion with other people who pop-in to say hi.

Have you ever created a poster with a team?

YouAin’tGonnaNeedIt – YAGNI

YouAin’tGonnaNeedIt – YAGNI is an XP principle based on Hoares Law (or Knuth’s Law).

It broadly refers to gold-plating in code and premature optimisation, with regard to Capacity Testing.

The interesting fact I found out this morning was that Charles Hoare denied he ever said it. He did say:

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

What Donald Knuth said was:

“Premature optimization is the root of all evil (or at least most of it) in programming.”

It’s always worth bearing YAGNI in mind, it sits quite nicely next to a KISS approach.

anchor We had to re-boot our approach to Sprint Planning today due to concerns over the way Story Points had distorted our planning sessions. Estimation is a key feature of planning in Scrum and is based on the Wide Band Delphi technique first identified by the Rand Corporation. The Story Points in themselves should have little intrinsic value in the Planning session and simply act as a facilitator for discussion to identify risk or a lack of understanding of requirements. The real value of Story Points lies in the ability to predict Velocity, allowing the Product Owner to perform Release Planning.

Story Points had distorted our activities by becoming a major focus of the planning sessions with an adherence to previous known Velocities. The team lacked the freedom or opportunity to take a common sense or commitment based approach. In short the Story Points had become the main discussion topic when making the Sprint commitment, rather than looking at the work itself.

How did we re-boot the session?

  1. User Stories presented by Product Owner
  2. User Stories tasked up
  3. Planning Poker – Story Points written on the back of the cards
  4. Sprint Commit – User Stories committed to based on content not Story Points
  5. Story Points exposed

I was discussing the session with @cootetom and he pointed me in the direction of an article on Anchoring which was fascinating.

“Anchoring or focalism is a cognitive bias that describes the common human tendency to rely too heavily on the first piece of information offered (the “anchor”) when making decisions.”

He correctly pointed out that Anchoring was playing a part in disrupting our ability to estimate using Story Points. Following the process above we removed the Anchor from the Commit part of the Sprint Planning and prompted some fresh thinking.

I’m a firm believer in the value of Story Points and will continue to help the team use them in the most effective way. It remains a challenge to help team members divorce the relative nature of Story Points from absolute concepts like time. Several team members have confided that they make that conversion in their heads and then pay lip-service to a Story Point approach. The concept of Story Points will be an area of team development that I’ll be exploring in the near future.

Kelly has made this inspired recording (see link below) showing the simplicity of the Scrum Masters role. The analogy of the chess game which is applied to Scrum is also very relevant here – Simple moves that make a complex game. I liked the mp3 so much that I’ve transcribed it:

I’m going to teach you how to be a Scrum Master in 1 minute.

First of all decide who will have the final say about priorities for your product – that is the Product Owner

Put all the features you’d like to include in a list – that is the Product Backlog

Put the list in the order that you’d like to do things and keep it up to date as things change

Get the whole team together every two weeks and plan the next two weeks work, working from the top of the backlog – that is Sprint Planning

Write what you want to do on post-it notes or cards and stick them on a wall in a column called to-do – that’s your Sprint Backlog

Get the whole team together at the same time every day for a 15 minute stand-up meeting, each person takes turns to say briefly how they are getting on, what they did yesterday, what they are doing today and if anything is holding them up – that is your Daily Scrum

Move the post-its or cards to an appropriate column on the wall for example in-progress, done or blocked

What ever happens get together at the end of 2 weeks to discuss what went well, what didn’t and what you can do differently in the next two weeks

Invite others to join you afterwards for a review or showcase of what you’ve done

And that’s it, that’s Scrum in a nutshell

Apologies Kelly if I’ve missed anything!

One Minute Scrum Master – original article

One Minute Scrum Master – mp3

This article has been inspired by a former colleague who has recently taken up the mantle of Scrum Master. As a new Scrum Master you face very unfamiliar Yodachallenges and your success is very much based on your ability to utilise coaching and soft skills to gently guide your team and colleagues. As a bit of fun, I’ve used some quotes from Yoda to frame the top 10 tips for Scrum Masters:

10. “To be Jedi is to face the truth, and choose. Give off light, or darkness, Padawan. Be a candle, or the night.”
–YODA, Dark Rendezvous

Scrum is an MRI scanner on the business you work with and the team you are coaching. The outcome of a successful Agile transformation is the exposure of issues that impede the progress of the team. The number one role of the Scrum Master is to remove these issues wherever possible or enlist help if the issues lie beyond the scope of the team.

Light the way to a brighter future for your team – remove impediments

9. “On many long journeys have I gone. And waited, too, for others to return from journeys of their own. Some return; some are broken; some come back so different only their names remain.”
–YODA, Dark Rendezvous

Each Sprint is a journey, as is the process of Agile transformation. The path of that journey is illuminated by the Sprint Burndown Chart which at once celebrates success and exposes a deviation from the path or Sprint Goal. Scrum is as heavy or light on metrics as you choose as a team. I would recommend that a Sprint Burndown Chart is created manually or reported daily if you have the software in place to do this. The chart should be displayed prominently on you whiteboard or other information radiator.

Take the journey with your team and share the path – Show the daily burn down

8. “To answer power with power, the Jedi way this is not. In this war, a danger there is, of losing who we are.”
–YODA, Star Wars: The Clone Wars, “Lair of Grievous”

Know that you are a Servant Leader and you should be available at all time to serve the needs of your team and facilitate Scrum process. It’s highly likely that you will encounter Product Owners or other colleagues that enjoy the Command and Control approach to management. Command and Control is not the way of the Scrum Leader. You must find ways to protect the Scrum team from legacy power structures and guide colleagues by becoming an exemplar of Servant Leadership.

A key part of the Scrum process is Stacking the Backlog. The Product Owner is the only person who can prioritise the backlog, but the backlog is open  to other people to add items and is owned by the team. As a Scrum Master, a great way to facilitate the output of useable high quality chunks of software is to facilitate Stacking the Backlog. The process of Stacking the Backlog is the breaking down of large User Stories to smaller Stories that can be delivered in a single Sprint. The Scrum Master should support the Product Owner.

Know that you are a Servant Leader – Facilitate Stacking the Backlog and support the Product Owner

7.”When nine hundred years old you reach, look as good, you will not, hmmm?”
–YODA, Star Wars Episode VI: Return of the Jedi

It’s important to have a sense of the legacy the team is leaving behind. Time and time again we encounter legacy code that is extremely difficult to maintain and re-develop. A good Scrum Master encourages Agile engineering practices which build quality in to the software development process at the start. Bear in mind that a hyper-productive team will make a hyper-productive mess. Simple practices such as Pair Programming produce code the team can be proud of.

Be mindful of the software legacy you are creating – Implement Agile Engineering practices.

6.”If no mistake have you made, yet losing you are … a different game you should play.”
–YODA, Shatterpoint

A key principle of Scrum is ‘Inspect and Adapt’. The Sprint Retrospective is the key meeting to examine the process the Team is using and enable the ability to provide continuous improvement. Empiricism is built in to Scrum right from the Daily Meeting, to the Burndown and finally the Sprint Retrospective.

Engage the team in continuous improvement – Facilitate the Sprint Retrospective meeting and act on it’s findings

5. “Death is a natural part of life. Rejoice for those who transform into the Force. Mourn them do not. Miss them do not. Attachment leads to jealousy. The shadow of greed, that is.”
–YODA, Star Wars Episode III: Revenge of the Sith

Scrum is a team game and it’s vital that work is accepted by the team as a whole. Scrum helps to engage the individuals in the team and reduces the dissatisfaction that leads to people leaving the business. Inevitably over time people will move on. The concept that you need to grasp here is ‘Bus Factor’. Bus Factor is the number of team members who could leave before the team ceases to function. Teams that consist of specialists have a very high Bus Factor i.e. code ownership and knowledge of the codebase is held by one individual.

The team should take the next available Story not ‘cherry pick’ from their comfort zone – Develop a cross-functional team

4.”No! Try not. Do, or do not. There is no try.”
–YODA, Star Wars Episode V: The Empire Strikes Back

Scrum has a simple set of rules that make up a complex game. The implementation of those rules is straight-forward and the framework and roles should be followed closely. There is a tendency to try to cherry pick parts of the framework and do the bits that fit easily with the existing culture. Commonly you may come across Product Owners that are Scrum Leaders or Scrum teams that have Project Managers. Be clear that mixing roles or missing roles is like having a game of football without a referee or goalie – it just doesn’t work.

Follow the Scrum framework – Ensure the correct roles are in place to guarantee success

3.”Lost a planet, Master Obi-Wan has. How embarrassing. How embarrassing.”
–YODA, Star Wars Episode II: Attack of the Clones

Communication is key to the success of a Scrum team. The Daily Meeting ensure that at least once a day the team has the opportunity to let each other know how they are getting on. The Scrum Masters role is to facilitate the meeting. Be wary of the team reporting to you – they should be speaking to each other. If necessary make an excuse and don’t attend the meeting for a few sessions allowing the team the space to speak to each other.

Encourage communication – Ensure the Daily Meeting takes place

2.”Fear is the path to the dark side. Fear leads to anger, anger leads to hate, hate leads to suffering.”
–YODA, Star Wars Episode I: The Phantom Menace

The incisive nature of Scrum is intimidating to incumbent power structures and those that hide behind them. The role of the Scrum Master is to educate and act as an Agile Ambassador. The business benefits of adopting the framework need to be repeatedly emphasized and communicated to the wider business. Return on Investment and the continual release of reliable and working software are two of the key factors that should be explained regularly and clearly to everyone involved.

Become an Agile Ambassador – Communicate the benefits of Scrum

1. “When you look at the dark side, careful you must be … for the dark side looks back.”
–YODA, Dark Rendezvous

The responsibility for the adoption and practice of Scrum, lies with the Scrum Master. The Scrum Master shows by example that the techniques and framework of Scrum is the most successful way to move forward. If as the Scrum Leader you start to miss elements out or take the line of least resistance that these cues will be picked up by the team and the business and the benefits of Scrum will not be realised.

Walk the walk and talk the talk – Take responsibility for the adoption and practice of Scrum

Thanks for looking over Yoda’s top ten tips for new Scrum Masters.
Here they again in summary:

10.   Light the way to a brighter future for your team – Remove impediments
9.     Take the journey with your team and share the path – Advertise the Daily Burndown
8.     Know that you are a Servant Leader – Facilitate Stacking the Backlog
7.     Be mindful of the software legacy you are creating – Implement Agile Engineering practices
6.     Engage the team in continuous improvement – Facilitate Sprint Retrospectives, act on findings
5.     The team should take the next Story not ‘cherry pick’ – Develop a cross-functional team
4.     Follow the Scrum framework – Ensure the correct roles are in place to guarantee success
3.     Encourage communication – Ensure the Daily Meeting takes place
2.     Become an Agile Ambassador – Communicate the benefits of Scrum
1.     Walk the walk and talk the talk – Take responsibility for the adoption and practice of Scrum

If none of that helps then watch – Sh*t bad Scrum Master say…

Have you got any hints and tips you’d like to add to Yoda’s list?


Creative Commons License
All work is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.

There is a lively debate around whether the Death Star could be classed as an Agile Project. I would suggest, that it’s more relevant to look to the Rebel Alliance. The Alliance shows us a good example of a cross-discipline hyper-productive Scrum Team in action.

The Death Star project does have a clearly defined Vertical Slice, which would seem to point to an Agile approach. The planet-destroying superlaser was delivered as a functional artifact whilst other less important features were dropped.

On closer inspection however we could surmise that the legacy command and control management structure has produced a flawed ‘Scrumbut’ implementation.

The failure to embrace good Planning and Engineering Practices left the weapon with a fatal flaw – open exhaust conduits that allowed it’s destruction.

Don’t be too proud of this technological terror you’ve constructed.” Darth Vader

Clearly a reference to ‘gold-plating’. It seems that Darth Vader was not attending the Daily Meeting or Sprint Review. I’ll leave you to decide whether Darth Vader was a Product Owner or Scrum Leader.

The Death Star was an Agile Project | Hacker News

1] Ackbar, Return of the Jedi “It’s a trap!” [2] The Emperor, Return of the Jedi “As you can see, my young apprentice, your friends have failed. Now witness the firepower of this fully ARMED and OPERATIONAL battle station!” qa-ds1-15215: I was checking out the design and noticed that thermal exhaust port AH-51 is open to the world.
Death Star II As an Agile Project

So, Vader takes an Agile approach. He prioritizes the features list (“Look, we really need the big laser thing; our customers will just have to come to us at first.”), and he works in vertical slices. At the end of the movie, it seems to have paid off.

A recent marketing campaign for MS Project postulated that Luke Skywalker achieved his goal in Episode IV using a traditional Gant Chart. I’m somewhat sceptical – the intuitive nature of the force and the distributed nature of the Jedi are far more akin to a self-organising Agile model.

The Episode IV team comprising Luke, Han, Leia, C3P0, R2D2, Chewy and OB1 is clearly a hyper-productive, cross-discipline Scrum Team. Conforming to the 7+ or -2 team number ‘sweet spot’. The team follows the pattern of an effective geographically distributed(at times) Scrum.

InfoQ: Jeff Sutherland: Reaching Hyper-Productivity with Outsourced Development Teams

Nathan Marz explain Storm, a distributed fault-tolerant and real-time computational system currently used by Twitter to keep statistics on user clicks for every URL and domain. Founding members of the ICAgile Consortium, Ahmed Sidky and Alistair Cockburn, discuss IC Agile, along with Bob Payne, a consultant, coach and trainer.
Distributed Teams Content on InfoQ (Information Queue) is an independent online community focused on change and innovation in enterprise software development, targeted primarily at the technical architect, technical team lead (senior developer), and project manager. InfoQ serves the Java, .NET, Ruby, SOA, and Agile communities with daily news written by domain experts, articles, video interviews, video conference presentations, and mini-books.

I was recently thinking about a definition of ‘self-organising teams’.I quickly came to the conclusion that collecting examples of self-organising behaviour was the best means to help this process.

My team approached me because they were confused about how we calculated Capacity for a Sprint. The team had two new members and I was reducing their capacity down to 50% and therefore the number of hours that were available for project work by the same amount. @phil_12d3 (Twitter tag) pointed out that this made no sense as everybody was at work for the same amount of time. The result of the variance I added, was that the newer members of the team ended up filling up their time with Support work. My attempt to measure and estimate personal capacity for the Sprint was flawed. We worked through a few new ideas as a team to find a better and more accurate way to estimate the number of productive hours available.

Phil eventually honed the rough calculations we made on a white board to the infographic below:














Creative Commons License
All work is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.

The hours are broken down between Project work, Support time, Meetings and Study time per developer. This made for a far simpler calculation.The variance in how long different tasks would take, was applied via a modifier during the final phase of Task Estimation. I was slightly uncomfortable with the necessity of allocating tasks per team member at the beginning of the Sprint. The preferred route would be a fully multi-disciplinary team that chose which tasks were worked on a voluntary and priority basis. My intial misgivings were overcome by the enthusiasm of team members over the ability to measure capacity and thus delivery on a daily basis.

To return to my original point; the process we went through as a team to develop this crucial process is an excellent example of a self-organising team. The team was not only focused on delivery but also the mechanism to improve the estimation and process of the Sprint.

Can you identify examples of self-organisation within your teams?