Have you ever been so focused on something that the rest of the world seemed to disappear for a while?  This can be great under certain circumstances, but in other cases it can be extremely harmful.  When someone focuses on a target and doesn’t see anything but the target we call it “target fixation.”  This can have dire negative effects!  For example, a fighter pilot can become so fixated on a target that they forget to avoid the target and run right into it.  The same can happen as we go through a curve in a moving vehicle.

Unfortunately, a variation of this can also occur to agile teams!  When it starts happening to agile teams it can be very difficult to detect and correct because everyone thinks they are doing the right thing.  It isn’t until much later when most teams finally determine this was the problem.Let me start by giving a few things I think happen when agile teams are too fixated on the target:

1. It becomes vital to “hit the date” or “hit the story point goal” or whatever other goal is laid out.  While this is not inherently bad, when combined with some of the other items below it may be indicative of a problem.
2. The team starts to cut corners on quality in order to hit the goal.  This is done subconciously in most cases.  Teams simply write fewer and fewer tests.  Especially automated tests.
3. Risks and impediments are no longer raised in meetings.  After all, dealing with them may cause the team to miss the goal.
4. Team members work more overtime hours – all in the interest of getting to the goal “just this once.”  If it happens more than once it is time to take notice.
5. Team members start to silo rather than collaborate and communicate openly.  “If I can just stay heads down I can finish this” becomes a pervasive attitude.
6. The team starts to think about dropping the daily stand-up meeting so they have more time to reach the goal.
7. Retrospectives turn into blamestorming sessions.
8. The team starts to miss obvious problems until it is too late in the iteration to do anything about them.

If your team is starting to suffer from more than a couple of these items you should take a step back and see if the goal has become more important than doing the right thing.  I tell my classes “Do the right thing and trust that the right things will happen as a result.”  Starting to do the wrong thing will not magically make the right results appear – except as a mirage.  Sacrificing something good will always lead to an issue further downstream.  Don’t fall into the trap of thinking you can get away with it!

If a team is starting to overly focus on “the goal” to the detriment of doing the right thing then someone needs to step up and say it!  This is where the Scrum value of having courage comes into play.  If someone doesn’t have the courage to stand up and say it is broken then nothing will ever get fixed.  Teams can spin in this cycle for a long time if no one notices the problem.  On occasion a team in this mode will make all of their iteration commitments along the way and then have massive rework to do at the end.  No one ever traces it back to making the goal more important than doing the right thing.

Focus on doing the right thing, inspecting the results and adapting.  This is the only way to improve and reach real goals in realistic timeframes.  Some good reference blog entries to read would be:

• New to agile? Lean principles can help
• Agile antipatterns: Agile burn-down chart roundup post
• New to agile? Learn how to split stories
• New to agile? Remember the power of automation
• New to agile? Keep it very simple
• Agile antipattern: Working overtime

Hopefully your team isn’t overly fixated on the target, but if they are, get it fixed ASAP!

Until next time I’ll be Making Agile a Reality^® by pointing out to teams when they are too concerned about the wrong things (which all too often seem like the right things)!

Related posts:

1. Agile antipattern: But the development lead said it would take way less time than that I’d be rich if I had a nickel for every time I’ve heard...
2. Agile Antipattern: Everything is priority 1 I was just working on some Powerpoint slides for our Agile Product Management...
3. Agile antipattern: Treating symptoms not causes Agile teams often get to a point where they have a number...

Is the bug to the left a large bug or a small bug?  It looks HUGE to me!  Well, in reality it is probably between .5 and .75 inches long.  Not really a very big bug at all.  Why do we care? Because trying to size the fixing of software “bugs” is at least as hard as figuring out how big this bug is!

When I teach an Agile or Scrum course someone will almost always ask a question like “How do you handle bug fixes in iterations or sprints?”  When I ask “How do you want to handle them?” we get into a pretty interesting discussion.  Most people say something similar to “We should prioritize them with the user stories, size them like we do user stories and then see what fits into each iteration.”  I usually smile and ask any developers if they know ahead of time how long it will take to fix a defect.  They ALWAYS say “Sometimes.”  And THAT is the problem!

How can you actually determine the size of fixing something which is broken in an unknown way?  I tell people in my classes I only know two sizes for defect fixes: 1) Trivial because I already know what’s broken and how to fix it, or 2) Infinite because I have no idea what’s broken or how to fix it!  If those are the only two sizes available to us how can we possibly put them into iterations effectively?

I have found one effective solution to be the use of Kanban techniques for defect fixing.  I don’t want to get into what Kanban is or isn’t and when it should or shouldn’t be used, so I’ll just lay out what I have seen be effective for a number of teams:

1. Prioritize the defect list.  This is NOT done in the context of user stories, but separately.  The list is prioritized however the Product Owner says it should be prioritized.
2. The team and Product Owner decide on how much effort (time) should be used each iteration to work on defects.  Hopefully this is not a large amount, but it might be for teams which have large numbers of defects in a legacy system.
3. The team determines when the defect fixing time occurs and how they do it. Most effective is to put a gate or two in place on the defects.  For example, gate 1 may say the developer needs to know within 2 hours if the defect is going to take more than a day to fix.  If so, then put it off until a discussion can take place with the Product Owner.  Gate 2 may be after a day if the defect is not fixed perhaps another discussion needs to take place.  However the gates are set up (if they are)  the defects are worked in priority order.
4. Limit the number of bug fixes being worked at one time to a very small number.  If you don’t do this you will have each developer working on at least one defect and run the serious risk of none of them getting fixed before the iteration or sprint ends!

This 3 step approach allows the team to work on defects in priority order while allowing a set amount of time to be spent on the defects.  The amount of time spent can be changed as needed to address the business needs of the organization at any point in time.

The downside of this is no one can tell a stakeholder something like “that bug will be fixed by date X” or “we’ll knock out X bugs this iteration.”  Saying anything like that is a lie anyway, so this shouldn’t be a big issue.  I say these statements are lies under the assumption the defects are non-trivial.

How else have you managed a defect backlog that has been effective?  I’d love to have more proven techniques for people to experiment with!

Until next time my clients will be Making Agile a Reality^® by using sizing only when appropriate!

Related posts:

1. Testing to find defects is waste Have you ever heard someone say that testing to find defects is...
2. Agile antipattern: Code freezes during each iteration Over the past 18 months I’ve encountered a number of teams where...
3. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...

Do you want to see several different ways agile and scrum burn-down charts can lie?  If so, you are in the right place! This month I went on a burn-down chart craze and posted several blog entries about the different ways those charts can lie to us or expose us to team dysfunction.  In order, the blog entries are:

• Agile antipattern: Burndown charts that hide the truth
• Agile antipattern: Taking on large stories
• Which led to New to agile? Learn how to split stories
• Agile antipattern: Burndown “wall”
• Agile antipattern: Changing the definition of done
• Agile antipattern: Another burndown chart that lies!

The whole series had a LOT of web hits, so clearly I’ve touched a nerve.  Good luck improving your agile or scrum metrics.  Sometime next year I’ll do a series on metrics in general.  Our current state of the art for agile teams is pretty pathetic because the data can be skewed so badly (as shown by all of these blog posts).

Until next time I’ll be Making Agile a Reality^® by helping people understand the real meaning behind their agile burn down charts.

Related posts:

1. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...
2. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...
3. Agile antipattern: Burndown charts that hide the truth See that burndown chart over there to the left?  It looks beautiful...

That burndown chart looks sweet doesn’t it?  The team finished the iteration on time.  What could possibly be wrong.  Well, a lot actually.  Notice that one day this team completed a tremendous amount of work.  Do you ever see teams really do that?  It certainly could be a symptom of allowing large stories and they just got completed that day.  But I’m not buying it.  When I see a chart like this I immediately think the team is hiding something.  Most of the time they are hiding that they changed the scope for the iteration.  They saw their trajectory and simply said we have to remove some scope in order to have a successful iteration.  DO NOT BE TEMPTED TO DO THIS!!!  There are far better ways to fail.  If a team starts to believe this is ok then they will use it as a fallback position too often.  How do I know this is the situation?  Easy, I look at the burnUP chart.

A burnup chart measures not only completed story points for an iteration or release, it also has a line representing the commitment the team made.  In this case the chart is quite enlightening.

Now we can see a completely different picture of how the team performed during the iteration.  They removed scope from the iteration and faked a success.  They decided they didn’t want to move work from one iteration to the next (another antipattern I wrote about) and instead they failed in what I believe is an even worse way.  Nothing gets learned from failing in this way.  The team did not meet their commitment, but we really have no idea if they were even approaching it well.  Wouldn’t it be better to see what work was left at the end of the iteration and determine if the team at least worked in priority order?  Based on the work remaining we might even be able to come up with some ways to help the team.

Fail in the right way (leaving low priority items which have not been started is best) and learn how to do better next time.  Agile failure is ok if 3 conditions are met: fail fast, learn from it, and don’t do it again.  In this case the team failed fast but they don’t have a good way to learn from it and there is no incentive to do it again since it looks like a success on the burndown chart.

In case you can’t tell, I prefer for teams to use a burnup chart when possible.  It exposes more issues and keeps the team more accountable.

Until next time I’ll be Making Agile a Reality^® by helping teams understand it is important to be transparent with their metrics.

Related posts:

1. Agile antipattern: Burndown charts that hide the truth See that burndown chart over there to the left?  It looks beautiful...
2. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...
3. Agile antipatterns: Agile burn-down chart roundup post Do you want to see several different ways agile and scrum burn-down charts...

Ever see a burndown chart like the one to the left?  I’ve been on a big burndown chart kick lately and when I saw this one I just couldn’t resist using it.  This one is a bit different from my previous blog entries here and here.  This burndown chart is a release burndown rather than an iteration burndown.  It sure looks like the team was incredibly successful and finished early, right?  Wrong!  What this burndown actually shows is all of the stories being “done” and the release not actually occurring for several more iterations.  How is that possible?

Unfortunately this is a symptom all too common for agile teams, so learn from this blog entry and don’t repeat the mistakes of others!  What this shows is a lack of commitment to a definition of done.  I touched on this briefly when I wrote about using a rules of engagement document.  If you don’t settle on a definition of done the pattern in this burndown chart can easily occur.  This pattern can also occur when a team is trying to hard to meet their deadlines.

If you went back and examined what occurred in this example you would find a team pressured to try to hit a release date by working at an unrealistic pace rather than a sustainable pace.  In order for the team to keep looking like they were on track for an ontime release they built technical debt by not sticking to a strong definition of done.  The result is a tremendous amount of testing which was delayed and triggered massive test-fix cycles.  In fact, the original release date was projected for after iteration 6, but instead it took 4 more iterations to actually release the product.  Technical debt cannot simply be allowed to build.  Software projects don’t have the luxury of deficit spending like the US Government.  At some point the bill will come due and it will almost always come due prior to release.  In fact, if it comes due after release it is even worse – you now are in emergency mode because customers are suffering!

Rally Software recently posted their definition of done on their blog.  It makes for some interesting reading and gives good perspective for other agile SaaS companies.

Richard Lawrence has a recent blog entry on this topic as well.  Richard encourages teams to not build technical debt and in fact he encourages growing your definition of done in order to release high value, high quality software as quickly as possible.  It is fascinating reading based on his work at a large organization.

Until next time I’ll be Making Agile a Reality^® by helping teams agree and abide by their definition of done.

Related posts:

1. Agile antipatterns: Agile burn-down chart roundup post Do you want to see several different ways agile and scrum burn-down charts...
2. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...
3. Holistic vs. Dogmatic Agile Definition – Results Matter! I originally wrote about this topic in our September email newsletter.  In...

Does your team have an iteration burndown chart (giving credit only for completed stories) look like the one to the left? If so there are a couple of possible explanations.  Last week I blogged about how this could be a symptom of working on user stories that are too large.  However, there is another possible explanation, and it is one that is FAR harder to solve.  The culprit is pushing testing to the end of the iteration.  The difference between the two is the steepness and abruptness of the wall.  When testing at the end is truly being done there are no stories finished until the last couple of days of the iteration while large stories pushes most until the last half of the iteration.  See last week’s entry on large stories to see the subtle difference in the burndown charts.

This is basically a version of the code freeze during an iteration antipattern.  It is all too common for an organization which switches from waterfall to agile to continue to try to do testing the same way it had been done previously.  This generally is done by having a handoff from development to testing during the iteration.  Since waterfall tested large chunks of code, most organizations have developers write as much code as they can prior to sending a large chunk to testing.  In order for this to occur the development goes for as long as possible during the iteration.  Stories can’t be completed until they are tested, so all of the completion of stories happens in the last couple of days of the iteration.  This forms the burndown “wall” shown in the sample burndown chart.

So what is wrong with having a burndown wall if everything gets completed?  I’m going to surprise you and say there is still a LOT wrong even if everything gets completed in this structure.  Here is a list of issues you probably want to look at if this is your current situation:

1. What are the developers doing while testing is going on?  They SHOULD NOT be working on the next iteration.
2. If developers are spending their time fixing the defects found during testing how do you guarantee all the defects will get fixed and tested in time for the end of the iteration?
3. What happens if testing runs up against a big problem and can’t finish testing the stories prior to the end of the iteration?
4. If there is pressure to finish testing in time does testing subconsciously cut down on the breadth or depth of testing?
5. What are the testers doing during the early part of the iteration when the developers are writing a pile of code?

These are real concerns and in my experience one or more of them will cause significant issues in almost every iteration.  If a team actually manages to overcome all of these issues in the majority of their iterations then there is still one more question to answer: Is it the most efficient way?

Team after team after team has proven it is not the most efficient way to do things.  When teams start doing things differently using Acceptance Test-Driven Development (ATDD) using automated tests they are much more efficient.  It also gives them the ability to accept stories every day.  Being able to accept stories every day gets rid of the wall and makes a more classic looking burndown chart.  Knowing things are completed and working every day will help the entire team feel better about how they are performing.

Until next time work at Making Agile a Reality^® by integrating testing and development so stories can be accepted every single day and see how much your team can improve!

Related posts:

1. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...
2. Agile antipattern: Burndown charts that hide the truth See that burndown chart over there to the left?  It looks beautiful...
3. Agile antipattern: Changing the definition of done Ever see a burndown chart like the one to the left?  I’ve...

See that burndown chart over there to the left?  It looks beautiful doesn’t it?  It is an actual burndown chart with no made up data.  It looks like this team is kicking butt and having a great sprint.  Unfortunately, the chart lies!  It turns out this team is actually in difficulty and in fact are unlikely to make their sprint commitment.  Are you confused yet?  I know when I do this exercise during agile courses the course attendees all look at me like I’m crazy.  I assure you, I am not crazy.  This team is in trouble, it just doesn’t show up in this chart!

The problem is hidden from view.  Notice the vertical axis has no units associated with it.  This is the problem!  It turns out this team is burning down task hours.  Of course they go down every day, and they even do it reasonably predictably.  However, there is NO correlation between task hours and the amount of completed users stories!!!  This is an important distinction which is often glossed over in agile training.  I like to say if you measure completed hours you will get completed hours, but that is no measure of completed stories or delivered value.  Instead you MUST measure completed user stories in order to be assured of delivering value.  From experience I can tell you the hours left unfinished on the burndown chart in the example are almost all testing hours (consider your own experience).  In other words the team pushed testing to the end of the iteration, which is more or less guaranteed to fail.  Most teams in this situation forget to account for rework hours once testing finds defects and the problems get worse.

On the other hand, the chart to the left of this paragraph not only looks nice, it really is nice!  Notice the vertical axis is now labeled with “Story Points.”  In other words the team has completed a significant number of story points and they look like they will finish their commitment based on the current trend.  In fact, this team might even finish early!  The only difference between these two charts is the legend on the left side.  I tricked you with the first one because I didn’t give units at all.  If I told you it was hours it may have led you toward the right answer a bit faster.  However, I wanted to point out how charts can be made to lie VERY easily.

In agile, you WILL get what you measure, so make sure you measure the right things.  One of the 3 Scrum artifacts is the burndown chart (the other two are the prioritized product backlog and the sprint backlog).  Make sure the burndown chart is a valid artifact by measuring completed story points – oh, and NO PARTIAL CREDIT.  Just because the coding is done does not mean half the story points are completed!!!  Otherwise you are no better off than measuring hours.  Measure success in order to achieve success.

Until next time work on Making Agile a Reality^® by measuring properly!  In particular be very suspicious of any metric which tends to look good all the time, yet the team doesn’t get the anticipated results.

Related posts:

1. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...
2. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...
3. Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...

I spent the past week in Orlando, Florida  at the Agile Development Practices conference and I heard a number of people say “We do agile at our company.”  When pressed further it suddenly became “We do agile at our company except we don’t do …”  To me that sums up the problem of DOING agile versus BEING agile.  It is quite easy to DO agile.  You pick the non-threatening pieces and parts and simply do those.  Then you say you are doing agile and no one is the wiser.  Unfortunately, when pressed you have to admit to not quite doing agile very well.

Being agile is completely different.  Being agile means you understand the principles which lead to true agile success.  It also means the team and organization are both constantly improving.  When you are being agile daily standup meetings and retrospectives are both very important meetings which help the team be successful.  Finally, being agile means being unafraid of failure.  Doing agile has none of these qualities because it is all about doing the agile practices, not living the agile principles!

How do you go from doing agile to being agile?  You start by understanding the difference.  To be fair, most agile teams do agile rather than being agile so keep in mind you are not failing you probably just didn’t know something better is available.  Once you understand the difference you can start to rely on the process to self-correct you toward being agile.  For example, during the next retrospective ask why the daily standup meeting is a boring status meeting instead of a vibrant exchange of information which helps the team toward success.  Perhaps you can ask why the team keeps making the same mistake of not meeting the commitment made during iteration planning (maybe you need to go back to real basics and ask why iteration planning isn’t a commitment at all).  It may help to ask if the team is willing to be agile and work toward continuous improvement rather than continuous mediocrity.

Once the questions are asked the team should strive to find some action items which will help them get better in those areas.  If the team is truly dedicated to BEING agile rather than DOING agile they will find action items which they can commit to in order to improve.  This is the key first step to being agile.  Once you have a breakthrough in this area it is very easy to continue being more agile each iteration.

A journey of a thousand miles begins with the first step.  Is it in you and your team to take the first step to go down the path of BEING agile?

Until next time I’ll be Making Agile a Reality^® by helping teams BE agile!

This blog entry first appeared as an article in the November 15, 2009 edition of the Weekly PM Insights newsletter.

Related posts:

1. Agile antipattern: Hiding unfortunate truths “Unfortunate truths” are things which are true – unfortunately!  I’ve heard the...
2. Agile antipattern: Treating symptoms not causes Agile teams often get to a point where they have a number...
3. Agile antipattern: Another burndown chart that lies! That burndown chart looks sweet doesn’t it?  The team finished the iteration...

Ever feel like the guy over there to the left?  Yeah, me too.  Sorry to offend some people with my language, but working overtime really sucks.  I always felt it meant someone else’s bad planning meant I had to have a lousy day, night, weekend (maybe all 3 at once!).  For agile teams, working overtime is bad in so many ways it is hard to count them all.  This post isn’t meant to give ammunition for someone in the middle of a death march.  Once you are in a death march the organization has two choices: a) keep up the death march and pay whatever penalties come up aftward, or b) recognize the penalties may be larger than the benefit and change the objective to be reasonable.  For people on a death march, I’m sorry you are where you are right now, but this blog post won’t really help you.  This blog post is meant to help people on agile teams where overtime is starting to become more prevalent.  Those people need help – FAST!

I’m going to try to conserve some words and just lay out 5 of the biggest reasons why agile teams should not work overtime:

1. Overtime is not a sustainable condition.  The amount of time people spend at work is at all-time highs just based on regular work hours.  Increasing the number of working hours will cause disruption outside of work which will in turn disrupt work.  When this occurs people are present longer, but they aren’t working more.
2. Overtime does not increase productivity as much as it increases cost.  Many studies, in different industries, have shown overtime hours to be far less productive than normal working hours.  In fact, some studies show that after 9 hours of work productivity actually goes backwards due to a higher number of defects being introduced!
3. Working overtime causes severe morale problems.  I don’t think my feelings in the opening paragraph are any different than what most team members feel when they have to work overtime.  A friend of mine uses the phrase “your incompetent planning doesn’t change my capacity!”  Is there any greater detriment to morale than feeling you are working for people who can’t do their job?
4. Even when working overtime gets the job done it perverts the process enough to cause problems.  If a team has a velocity of 20 and then works a lot of overtime to get 25 points done what should they commit to for the next iteration?  Most teams say 25 and cause themselves to start getting into the overtime habit.  Other teams pick 20 and end up missing because they are worn out from the overtime effort.  By the way, the team trying to hit 25 while likely miss as well.
5. Is getting in the very last feature really worth it?  This goes back to the title of this blog post – remember we are talking about an AGILE team!  So they are working on things in priority order.  Is it really necessary to get the very last feature completed at the expense of killing the team?

In my opinion working overtime should only be done when the team feels it is necessary to meet a commitment THEY made (not commitments made by others and imposed on them) and are in danger of missing because they made other bad decisions along the way.  In this case I’m ok with people wanting to feel good about themselves by making up for their own mistakes.  In fact, I like that in teams.  It shows they have some pride in their work and they want to continue to be successful.  I can’t come up with another reason for overtime which makes sense to me when I really analyze it.  (I consider the “we’ll go out of business if we don’t work overtime” argument to be  red herring – some businesses should not succeed if they do it by treating everyone like dirt.)

Until next time I’ll be helping teams avoid overtime by making sure they understand planning at all levels of agile in order to make commitments which can be met without working overtime.  Doing this will ensure that long term they will be Making Agile a Reality^®.

Related posts:

1. Agile antipattern: Target fixation Have you ever been so focused on something that the rest of...
2. Agile antipattern: Comparing velocity between teams I recently saw an excellent blog post about iteration velocity.  Good reading...
3. Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...

Time for a short blog entry (I tend to be way too verbose!). I often see teams trying to make sure they have all of the requirements for their projects before they start doing any substantive work on the project. Unfortunately, this often leads to long delays at the front of the process which in turn causes the rest of the process to be squeezed. The Nokia Test for Agility underscores this point by having one of the questions be about specification. See this blog entry to learn more about the Nokia test and look particularly at bullet #3.

Remember a few things when you are tempted to get all of the requirements up front:

1. Requirements WILL change.  In courses I teach the average percentage of requirements which change is 50%.
2. Requirements WILL be dropped.  We almost always think we can get more done than is possible (or even desirable in many cases).  It seems the average percentage of dropped requirements is 25%.
3. New requirements WILL come up during development.  This too seems to average about 25%.

When you take all 3 of these things together you quickly realize you are fighting a losing battle by trying to “get the requirements right” up front.  Get the requirements good enough to start moving forward.  Once work starts requirements can change, be dropped or new ones can come up easily if you truly embrace the agile principle to inspect and adapt.  Keep looking for what will make the product better, not necessarily what a requirements list says from a few months ago.  This isn’t up to the developers themselves, but the product owners and others who maintain the backlog.  Build GREAT products by adapting to changing conditions.  EMBRACE change as a good thing, not as an impediment.

Until next time I’m Making Agile A Reality^® by focusing on emerging requirements over time, not trying (in vain) to get them perfect up front.

Related posts:

1. Agile antipattern: Extending an iteration I had a previous blog post about stopping an iteration and how...
2. Agile Antipattern: Everything is priority 1 I was just working on some Powerpoint slides for our Agile Product Management...
3. Are you agile – the Nokia test I’ve been helping lots of clients start new agile initiatives recently.  This...