Agile antipattern: Target fixation

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. [Read more…]

Agile antipattern: Sizing or estimating bug fixes

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! [Read more…]

Agile antipatterns: Agile burn-down chart roundup post

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:

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.

Agile antipattern: Another burndown chart that lies!

sprintburndown6That 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.

[Read more…]

Agile antipattern: Changing the definition of done

sprintburndown5Ever 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? [Read more…]

Agile antipattern: Burndown “wall”

sprintburndown4Does 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. [Read more…]

Agile antipattern: Burndown charts that hide the truth

sprintburndownSee 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!

[Read more…]

Agile antipattern: Doing Agile!

successladderI 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. [Read more…]

Agile antipattern: Working overtime

working_overtimeEver 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! [Read more…]

Agile antipattern: Waiting for all the requirements before starting

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.