Be Wrong!!

May 12, 2016 Leave a comment

An Information Radiator often comes about when teams realize that there isn’t a shared understanding.  Unfortunately, not everyone recognizes that lack of shared understanding at the same time.  This leads to a resistance to putting in the effort to create the radiator, why would we work on something that isn’t needed.  This in turn often means that the radiator never materializes.

Fortunately, there is one great way to get people to participate in building an information radiator.  Be wrong!!  This may seem counter-intuitive and maybe even a bit scary.  It certainly has prevented me from creating a much needed information radiator in the past.  Yet this is one of the best ways to raise awareness that there isn’t a shared understanding, and an even better way to get people talking.

Whenever there is a new radiator in the team space, people are interested.  They will gather to look, ask questions and point out mistakes!  Be ready for this, this is exactly what we want to happen.  Leveraging people’s desire to be right and to point out when others are wrong, allows the information that is hiding inside people’s minds to be shared.  Conversations, clarification and a shared understanding soon follow.

Now that the needed conversations have happened and we have reached a shared understanding, it is important to update the information radiator so that the team can leverage it in future conversations.  Encourage the team to make the updates and make it easy for them to do so.

Why constrain your retrospectives?

October 22, 2014 Leave a comment

Retrospectives are a wonderful tool for continued improvement and learning.  Yet, we often don’t retrospect on our retros!  I have often found that the grouping of topics is constrained by the format of the retro.  This week I tried an experiment to remove that constraint and was pleased with the results.

Imagine a team with mixed software delivery beliefs.  Bob loves to pair, yet Rob wants to work on his own.  Bob, and a few others put stickies up in the positive section.  Rob, and others, put stickies up in the improve section.  The team dot votes, and though the two pairing groups each have a lot of dots, neither is the largest.  The team discusses a different topic and the conflicting opinions on pairing don’t get discussed.

What if we Bob and Rob’s team had removed the categories before grouping? They would have had a mixed bag of stickies on pairing grouped together, but when they dot voted, all the pairing votes would have been together.  The team then would have gone on to discuss an issue that was causing tension within the team, and hopefully identified some actions that could improve the situation.

In summary, categories such as anchors/engines or happy/sad/confused are great tools to help the team generate insight.  Once the insight is there, they have served their purpose.  We need to let them go as we move to the next phase of the retro.

Categories: retrospectives Tags: ,

do your stories tell a story?

April 18, 2014 Leave a comment

I want to address a common anti-pattern that I see and suggest an alternative approach.  I’ve seen different styles of user stories, and though the sections differ by the needs of the team and the style of the BA/Product Owner, one common section that I see is the context (aka business context, narrative, etc).  This is usual a paragraph or two that is meant to show how the change  facilitated by the story will impact the user.  We’ll come back to that goal in a bit.

Anti-pattern:  A context that does nothing more than describe how the product will work after the story has been played.  The first reason I don’t like this is that there is already a section of the story whose responsibility is just that – the Acceptance Criteria.  Repeating the ACs in a paragraph is duplication of work and does not add any additional value.  The second reason is that it doesn’t achieve the goal of the context.

A Better Way:  We build software to aid us in activities that we need/want to do.  A story’s context is a chance to remind us how that story fits into the bigger picture and how it helps the user achieve a goal.  So let’s use the context to talk about just that…  what the user is trying to achieve.  Specifically we should focus on the benefit that capability will provide.  This allows us to bring the story to life.  It makes it real and allows everyone (stakeholders, the development team, even your grandmother) to think about why we need to play (or not play) that story.

I see four main benefits to using the context to tell a story.

  1. it aids in prioritization
  2. it allows the team to be creative in thinking of alternative solutions.
  3. it allows the team to know when they have done enough.
  4. it can be a lot of fun!

After all, there is a reason that we call them stories!

Let’s look at an example for a mobile application that connects riders with taxis

Example:  Changing the pick-up location for a taxi

As a Rider, I want to change the location of where the taxi will meet me, so that I can reduce the overall time it takes me to reach my destination

Context:  Late Larry was rushing home to pick up his son after work.  He knew he was later than usual, so he decided he would take an taxi from the station.  He requested the car to pick him up outside the station while still on the train.  When he exited the station he noticed that the car was stuck in traffic a few minutes away… coming from the direction he wanted to go.  Larry waited anxiously, glancing at his watch and realizing that he is going to be late again.  If only he could meet the car half way, he might just make it on time.

Acceptance Criteria:

Option to Change Meeting Point
Given I have connected with a taxi
And the taxi has not yet reached me
When I view the ride options
Then there is an option to change the meeting point

Select new location
Given the taxi has not yet reached me
And I am viewing the ride options
When I begin the process to change my meeting point
Then a map is displayed
And the taxi’s current location is displayed on the map
And my current location is displayed on the map
And I can indicate a new meeting point

Notify the driver
Given I am viewing the map to change the meeting point for a ride
When I select the new meeting point
Then the driver is informed of the new meeting point

Give it a try!  Add any good ones to the comments…

Categories: Agile, Business Value, Stories

increasing the pull when walking the wall

November 26, 2012 1 comment

A while ago while consulting a day a week at a previous client, I was discussing some of the problems the team was having when trying to walk the card wall.  They were struggling to get beyond just a status update of the card.  We bounced a few ideas around and settled on changing the facilitator as you moved right to left.  The idea was simply that the person who wanted to work on the card should be the one leading the discussion.  I took this back to my other project and asked them to be guinea pigs.  ,


For illustration purpose, consider a project with swim lanes of:  Ready for Analysis, In Analysis, Ready for Dev, In Dev, Ready for Testing, In Test, Done.


As normal we would be starting from the right, looking to pull the stories to completion. 

Swim Lane
In Test Stakeholder (or proxy)
Ready for Test QA
In Development QA
Ready for Development Dev
In Analsys Dev
Ready for Analysis BA


I was amazed with the change.  The questions became focused on the facilitator wanting to work on the story and the discussion became much more focused on what needed to be done to progress the work.  It also increased the collaboration between functions in the team as QAs were looking to help developers finish coding and Developers were looking to help BAs finish narratives.

Stop saying estimate

June 8, 2011 1 comment

There is a certain connotation with the word estimate. People think of cost and time. Think about the last time a mechanic fixed your car or you hired a painter to put a fresh coat of paint on the third floor windows. You are thinking about time and cost aren’t you? When we start thinking about a software project we are still estimating the cost and time, but of the project not the stories.We are doing ourselves a disservice when we say we estimate our stories.

We have been relatively sizing stories on projects for years. We are not estimating our stories. When we look at a group of stories it is pretty easy to compare them relatively to each other and have a good understanding of which ones are similar. The hard part is to predict how fast we will finish each story. It is the velocity at which we complete stories, combined with the total number of points, which allows us to estimate the project’s cost and length.

So why does it matter if we size our stories or estimate them?

As soon as we talk about estimating stories the client (and team) naturally start to think about the time it will take to complete a story and how much that story costs. This leads to people wanting to change the number of points associated to a story because “it is taking longer than the estimate”. Just because a story has taken longer than anticipated, does that mean its relative size is different to all the other stories? Maybe… but most often it is that our velocity is not what we initially thought it would be. Talking about the size of the story helps to focus on the velocity being the value that is different from expectations rather than the number of points on the story. With this mind set, we can move away from constantly updating the the number of points on every story and instead focus on improving our velocity by finding ways to be more effective and reduce waste.

Introducing Agile Planning with Apples, Chikoos, Raspberries, Jackfruits and Watermelons

March 11, 2011 3 comments

Learning a new concept or process works best when done in a simple situation. Once you have mastered the process, you can apply it to more complex situations. I’ve made the mistake before of introducing relative sizing and velocity calibration to a group with the actual stories that were going to be used for the project. Though we’ve managed, there has always been a challenge of re-explaining the process throughout and pausing to discuss edge cases.

In a recent inception, I decided to introduce the concept first with an abstract example… fruit. I had worked this through in my head, and was happy that it would introduce the basic concepts and make the actual relative sizing and velocity calibration much easier. I was right on that sense, but it also did much more. We were able to see many real world examples and pitfalls come to light which made the actual relative sizing and velocity calibration go much easier.

Relative Sizing

To start with I had written about 30 different pieces of fruit down on story cards.  Rather than relatively size the stories based on the effort it would take to develop them, we were going to relatively size the fruit based on the effort to eat them!

Here are some of the lessons learned while doing the relative sizing:

The Technical Story

Things were moving along well and the team was making good progress through the sizing of the fruit.  Then came the kiwi… someone commented, “we need a knife”.  I asked them what they should do.  The team wanted to raise a story to buy a knife.  I asked what would happen if they played the knife story then the business decided not to play the kiwi story.  They quickly agreed that if we never played the kiwi, buying the knife would be a waste.  This led us to making an assumption that the kiwi story would include buying a knife, hence more effort.

When we later hit the pineapple story, we assumed that we already had the knife.  There was a brief discussion about what happens if the kiwi is deprioritised and the pineapple is not, and everyone was comfortable that the assumption of already having the knife would then be wrong and we would resize.

The learnings:

  • Do not create stories that will introduce technical infrastructure
  • Include the effort to do this in the first story that needs it
  • If multiple stories need it, make sure to assume the one that will be played first and assume in the others that it is already in place.
  • If those assumptions change, you resize the stories.

The Unknown Story

There were two other fruits that caused us trouble.  The jackfruit and the dragonfruit were both unknown to the team.  The jackfruit was easier to resolve.  One of the team members knew what it was and was able to describe it in enough detail for the team to size it relatively to the other fruit.  The dragonfruit was much harder (I was the only one who knew what it was).  Soon someone had an iPhone out and had it up on wikipedia.

The learnings:

  • The team should support each other by sharing knowledge about the stories, allowing them to come to an agreement on the size of the story
  • When the team doesn’t know the answer immediately, the BA should go away to discover the information.
  • Set the unknown story aside until the information is found
  • Capture any assumptions that you make

The Duplicate Story

Though we didn’t do this at the time, I’ve since realised that you could very easily include duplicate stories in the exercise.  Depending on where you are from and where you have travelled, finding fruits with multiple names may be a challenge.  Two examples are: carambola & starfruit and chikoo & sapodilla.  This would be a nice way to set everyone’s expectations that there will be duplicates and to keep an eye out for them.

Velocity Calibration

After the relative sizing, we moved on to velocity calibration.  We decided on a team size of two pairs and decided that we would have 4 iterations of 15 minutes each.  We asked the team to select the different fruits that they felt they could eat each iteration (with the assumption that they had a chance to digest their fruit between iterations).  Besides learning the basic concept, we also encountered what happens when you try to include your Too Big stories.

The Too Big Story

As we were doing the velocity calibration, we had one iteration whose velocity was quite a bit bigger than the others.  No prizes for guessing which fruit was included in that iteration.  After a bit of a discussion it was easy to see that we shouldn’t include the watermelon in the velocity exercise.  In fact we realised that the watermelon could be broken down into smaller pieces – think of the number of times where you have seen a half or quarter of a watermelon for sale in the produce section…

The learnings:

  • Exclude your Too Big stories from velocity calibration
  • Break your Too Big stories down, resize them and include the smaller stories


When we repeated the exercise with the real stories.  The BAs and SMEs were aware that they needed to answer questions on the unknown stories, we excluded the Too Big stories from the velocity calibration, and the team was diligent at capturing assumptions.  Numerous times I heard someone comment “we need a knife for that story”!

Most importantly though, the entire team had done the fruit exercise.  SMEs, PMs, BAs, QAs and Devs were familiar with the process before going into the actual sizing and calibration.  For the devs the benefit was obvious, but the understanding from the other members of the team was invaluable.  Even though the other team members recognized that they could no longer participate with the exercises, they were engaged and involved throughout.  They took turns facilitating, answering questions when they could and rarely challenged what the developers decided!

Categories: Agile, coaching, learning, Planning

How long should your iteration be?

March 9, 2011 Leave a comment

This is often a question that comes up on a new project.  Folks who have been doing iterative development for a while rarely want more than 2 weeks and often only 1 week per iteration.  Yet folks new to the game push for more time; 4 weeks per iteration is quite common.  The most common reason that I hear for wanting longer iterations is that 1 or 2 week iterations means that too much time is spent in showcases and retrospectives.  Which leads to an interesting question, what is the goal of an iteration?

This is one of those questions that if you ask 10 people you will probably get 11 answers.  For me, an iteration is nothing more than a heartbeat for the progress of the project.  I’m not worried which stories we complete in which iteration, I’m not worried if we have a showcase or a retrospective.  What I want from iterations is a frequent measure of our progress towards our end goal, releasing software that delights our customer.  Of course release planning, retrospectives and showcases are an important part of delivering software that makes our customer happy; they may just be needed at a different frequency to your heartbeat of progress.

Once we separate the frequency of capturing your heartbeat from that of your planning meeting, showcase and retrospective, I find that the willingness to have shorter iterations is much greater.  Great… but now we have four questions to answer:

  1. How often should we plan what should be worked on next?
  2. How often should we have a showcase?
  3. How often should we have a retrospective?
  4. How long should our iteration be?

My first project with ThoughtWorks 12 years ago had 2 day planning meetings.  Talk about waste!  That was two days of development that we lost out on, but we were new to iterative development and were learning!  Now I never see a project that has a two day planning meeting, but I do see projects that have half a day or two hour planning meetings. That is still a lot of time away from development.

Rather than having a planning meeting every iteration, why not pick the next most important thing to work on when you are just about* ready to need something new to work on?  This allows us to be flexible when priorities change and avoid having the whole team locked up in a room for 2 hours. Plan continulously when needed rather than on a fixed schedule.

*Of course we want to make sure people are not sitting idle, so you need to find out what just about means for your team.

Let’s take the showcase next.  Ideally as often as you can!  Why wait a week or two weeks, if you have something that is ready to be seen by your stakeholder, pull her over to your desk and show it.  Better yet, show it while it is still in progress and then again when it is finished.  Frequent feedback cycles reduce our chance of waste.  For showcases to a wider set of stakeholders with busy diaries, you need to find a regular time that you will have sufficient work done to make the showcase worth attending but not so infrequent that you are having to make numerous changes based on their feedback.

Retrospectives are easier, they are for the team.  You don’t need to worry about busy stakeholders who are trying to support your project and do their day job at the same time.  On well functioning teams you have constant retrospectives.  The discussions on the way to lunch or at the pub after work are a great time to look at how we can improve.  Unfortunately, it is difficult for everyone to be involved in those conversations and a formal retrospective is a great tool.  Look at how your team is functioning and the value you are getting from the retro.  Have them as often as you can as long as the value is still outweighing the cost.

Which brings us back to our original question. How long should your iteration be?  The explanation that I’ve used recently is “frequent enough to avoid missing crucial information but to not cause huge fluctuation in points from iteration to iteration”.  Too frequent and we lose the ability to predict what we will achieve in the next iteration.  Too infrequent and we can realise too late that we are off course.

Stop thinking that an Iteration has to be made up of a pre-definied set of stories, have a planning meeting, showcase and retrospective. Measure at the right frequency, plan continuously, showcase when you have something to show and retrospect as needed. All four activities are valuable, maximise the value they bring to delighting your customer by doing them at the frequency that is right for each activity.

Categories: Agile, Iterations, Planning