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

What’s wrong with the user story on the card?  It seems to have everything we need: a) short title, b) a size (in this case 2), and c) a well-written story using the standard “As a … I want … so that …” format.  So what’s wrong? Nothing!  Well, almost nothing.  The user story card is a great STARTING POINT, but it is not sufficient by itself.

In coaching Agile and Scrum teams I see many of them starting out with the assumption that the user story card contains all the information they need in order to create a high quality piece of software.  Forgive me for being harsh, but how stupid is that?  Assuming a single sentence can fully describe something which might take a few days to analyze, design, code and test seems pretty ambitious.  No, let me take that back.  It’s more than pretty ambitious, it is just not possible. So I ask again, what’s wrong with this story card?

And again I’ll answer that there is nothing wrong with it, but it is a STARTING POINT.  Many people are familiar with the phrase “INVEST in good user stories” which is an easy way to remember to use the INVEST acronym for guidance when creating user stories.  I wrote a blog entry about that titled “New to agile? INVEST in good user stories“  Web searches lead people to that blog entry many times every day.  But it isn’t sufficient!  If you read agile literature for any period of time you will eventually see the phrase “A user story is an invitation to a conversation.”  This is vitally important to success!  A conversation allows more description than a single sentence.  It can clarify many aspects of the user story.  Taking this a step further we also need to be able to confirm the user story is completed.

Taking all of this together we end up with the 3 C’s of good user stories: Card, Conversation, Confirmation.  Ron Jeffries wrote about this all the way back in 2001 and his advice is still good today.  Agile and Scrum teams need to remember the card is the starting point.  It leads to a conversation where more specifics are given and negotiation (the N in INVEST) can occur.  All of that leads to confirmation in the form of tests (the T in INVEST).  A good story card will likely end up with a back side covered with results of the conversation(s) and confirmation tests.

Next time you see a user story card don’t ask yourself if you need to have a conversation about it.  Instead just assume you need to have a conversation and have it!  Go to the Product Owner or customer or customer proxy and ask to discuss the story.  Make notes for yourself.  In fact it is even better (vital in my mind) to have the conversation involve a developer, tester and product person.  I call them 3-headed conversations.  This allows everyone to be on the same page so later there is no disagreement about what was really meant by the story.  This avoids one of my least favorite conversations which happens when the tester and developer disagree about what the requirement means AFTER the code is written.

If you are using an agile lifecycle management tool rather than physical cards, record the decisions made during the conversation and any resulting confirmation tests in various fields in the tool.  You must make sure the information is captured in case someone else who was not part of the original 3-headed conversation ends up doing some work on the story.

Try using the 3 C’s and see if your results improve.  I’m sure they will.

Until next time I’ll be Making Agile a Reality^® for my clients by continuing to train and coach them to use the 3 C’s effectively.

Related posts:

1. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...
2. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...
3. When in Doubt Ask “How Will I Know I’ve Done That?” Tired of not knowing exactly what to create or test? Get in...

In Scrum one of the named roles is that of Product Owner.  Some people have taken to referring to this position as the “single wringable neck” on a Scrum team.  This is because the Product Owner is ultimately responsible for the prioritized product backlog which the team uses as their to-do list to build the product.  If the Product Owner does a poor job then the resulting product will not meet customer needs.  That scenario leads people to believe the Product Owner should be held accoutable for the failure.

To me this is very short-sighted.  The Product Owner has a LOT to do without having this additional burden placed upon them.  Because I want to keep this blog entry short I will give 5 reasons why the “single wringable neck” concept has to be left behind:

1. Product Owner’s normally do not have sufficient training to do the job well.  We often here of Certified Scrum Masters (CSM), but we don’t hear about Certified Scrum Product Owners (CSPO) nearly as much.  This is a shame.  If they are the single wringable neck, why not give them a fighting chance by giving them some training specific to their position.  I don’t care if the training is a certified training or not, so long as it is good, solid training.  A few months ago we had our Agile Product Management Boot Camp which is a great way to get this training.
2. Some organizations isolate Product Owners in a way which does not allow them to interact with customers properly.  I’ve actually heard sales people say “We can’t have the product person talking to our customers – it would just confuse the customer.”  When I heard this I think my reply was “In other words they might tell the customer the hard truths?”  You can guess how the conversation went from there.
3. Many organizations expect too much from their Product Owners.  Product Owners need to interact with the team and customers on a regular basis.  They also need to be doing other forms of market research.  They may need to attend trade shows.  They may be involved in Change Control Board meetings.  They may prioritize defect lists.  They may be helping the marketing department develop materials.  They may be creating nice charts and fancy reports for executives about how products are expected to perform.  They may…   The list can go on forever.  Please make sure your Product Owners have time for what is truly important.  Find other ways to accomplish the tangential items.
4. Product Owners don’t get to understand lost sales.  If you are trying to create a product to grow your market share then finding out why you lose sales is CRUCIAL!  Lost sales is a huge potential source of product ideas.  Talking to current customers may help you maintain your market share, but it isn’t guaranteed to grow it.
5. Product Owners ultimately report to someone else and that someone else sometimes makes inappropriate decisions.  Sorry to be so blunt, but this occurs more often than anyone wants to admit.  How can a Product Owner be held accountable if someone else ultimately pulls the strings?  Worse yet, the person in charge often doesn’t admit the errors were their fault.  This all falls in the category of sad but true.

As you can see, I don’t agree with the single wringable neck concept.  I believe a team creates products and all members of the team contribute.  A Product Owner may ultimately be one of the major contributing factors to failure, but it is rarely the only one.

Until next time I’m going to be Making Agile a Reality^® by helping teams get effective training and coaching for all team members including Product Owners rather than concentrating on just one or two team members bringing information back to the team.

Related posts:

1. New to agile? 3 ways to cut scope (and live) The primary way I see teams release products faster is by reducing...
2. New to agile? Give thanks! Here in the United States we will be celebrating the Thanksgiving holiday...
3. Agile pondering: How does agile work with a team of 1? See that picture off to the left?  That is me and my...

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

Yesterday’s blog post dealt with how to manage scope for an agile project.  Today I have to admit it was a bit of a setup.  It was designed to set up today’s blog post which is really the important one!

See that pile of money over there to the left?  That represents a small fraction of the amount of money your organization is potentially wasting by not being able to properly manage the scope of projects.  I want to be clear this is not about project delays and overruns caused by scope creep.  I am actually writing about something completely different.  Something much more fundamental and actually fairly easy to obtain when an organization has truly embraced all that agile has to offer.  To me this is one of the most important benefits of agility, but the number of organizations doing it well is extremely small.  Warning, this is a LONG blog entry, but I think it is well worth the effort to read it!

The topic I’m writing about is the ability to manage scope and expectations properly.  The gains available by doing this are truly staggering.  If your organization was given the opportunity to increase ROI by 100% per project would someone in the organization be tasked with looking into the opportunity?  What if the ROI per project could be increased by 200%?  If the opportunity was for 500% increase in ROI per project would your organization perhaps have more than one person look into the opportunity, or would it sound too good to be true and therefore be discounted?  I know this sounds unbelievable, but the ability to achieve much, much higher ROI is very real, and it only depends on your organization’s ability to manage scope and expectations effectively.

Do I have your attention yet?  I hope so because this is really valuable information that most people just gloss over in various agile courses.  I have to admit that I didn’t cover it very well until recently.  I glossed over it mostly because I didn’t understand it very well.  Now I understand it and I’ll try to help you understand it.  The basic concept is VERY simple and can be covered with just 3 words:

More frequent releases

Yup, that’s the key.  It is much easier said than done though.  It means expectations must be set for releases to be smaller but still have significant marketable value.  It also means managing scope for smaller releases so the value can actually be delivered to meet the expectations.  If we make the assumption these two pre-requisites can be handled, then we can also assume faster releases are possible.  Yes, I know, releasing software is expensive, requires other groups, etc.  For now, let’s assume all of those costs are negligible compared to the potential results and see where we end up.

Let’s use a standard scenario as a starting point.  In this scenario a team of 8 people work on a project for a year with an anticipated ROI of 100% after 2 years.  In numbers this means the organization spends $1,000,000 (approximately) in 12 months to build the product and they expect to get $2,000,000 in revenue within the 12 months following release.  ROI is calculated as $profit/$invested which in this case is ($2,000,000-$1,000,000)/$1,000,000 or 100%.  Another interesting number is cash expended, which in this case exactly matches the investment since we did all of the investment prior to receiving any return.

Let’s assume that scope can be managed so the product can be delivered in two phases, each taking 6 months.  Let’s further assume each piece of the product is worth about half of the revenue value of the complete product.  In this case the team works 6 months at an investment of $500,000 to build the first piece of the product.  They then work 6 more months at an additional cost of $500,000 to complete the second half of the product.  However, after 6 months revenue starts to be brought in for the first release.  This revenue equals half of what was originally expected for a full product, so after going through some calculations we realize the amount of revenue during the first 6 months of release of the first half of the product would be $500,000 ($2,000,000 for full product for 12 months = $500,000 for half product for 6 months).  Interestingly, this exactly matches the cost for building the second half of the product, so the cash expended is actually only $500,000 for building the product vs. $1,000,000 for building the product in one step.

Now let’s look at the other numbers.  After phase 2 of the product is completed it too starts to bring in revenue.  We now have the complete product, so we can get full value of it during each time period.  In other words, during the next 12 months it will generate $2,000,000 in revenue.  This brings total revenue to $2,500,000 which means our ROI is now 300% (higher profit divided by smaller investment – $1,500,000 profit / $500,000 invested).  Remember, all we did was have two releases of approximately equal value.  Nothing else changed, but half the cash was saved and more revenue was generated.  Here is a table showing this scenario:

Time to take another step.  Let’s make the assumption we can release 4 times per year with approximately equal valued releases and the same assumptions as in the above scenarios.  Now we work 3 months at a cost of $250,000 to generate release 1.  We do the same thing every 3 months until the year is completed.  Each release generates 25% of the value of the entire release, which over a 3 month period would be $125,000.  This leads to the following table:

Now we have a situation where our cash outlay is reduced to $375,000 and our revenue has increased to $2,750,000.  This gives an ROI of 467%.

For the next scenario let’s say we can do the same 4 releases per year, but now we release higher value items first (after all, we are working from a prioritized product backlog, right???).  In this scenario let’s say release 1 is worth 40% of the total, release 2 is worth 30%, release 3 is worth 20% and release 4 is worth 10%.  Now our table is as follows:

$300,000 cash invested and $2,000,000 total profit which is now 667% ROI.

Bear with me, almost done.  For the next scenario let’s not have the team build the features worth 20% or 10% of the total product value.  They are low priority items anyway.  Doing this would generate the following table:

In this scenario we have the same cash investment of $300,000 but now we only made $1,800,000 in profit for an ROI of 600%.  Why would we want to do this?  Well, what is our team doing during those second 6 months of development?  In this scenario they are idle.  So let’s use them!  Find another project with similar parameters and have them start it 6 months earlier than whey would have otherwise.  Consider the exact same setup as in the previous scenario except we’ll be generating revenue from two different products after month 9.  In this case the table looks like:

$2,900,000 profit on an investment of $300,000 is an ROI of 967%.

Do I still have your attention?  If so, consider one final scenario:  The total cash invested in this project is only $300,000.  The organization was originally willing to commit $1,000,000 for the project.  Can you find 2 more teams and enough projects to do the same thing two more times?  If so, the original $1,000,000 investment will have been reduced to $900,000 and instead of $2,000,000 in revenue at the end of year 2 the organization could bring in $11,700,000 which is 5.85X more revenue than the original scenario and $7,700,000 more actual cash!  This equates to a 967% ROI for each of 6 products across 3 teams with 12 total releases per year.  Remember at the beginning when I said the cost of releasing would be negligible compared to the benefits?  I also mentioned 500+% increase in ROI was possible.  Do you believe me now? 

I know this was a VERY long blog entry, but I think you’ll also agree this is an important topic to understand.  To see another way of explaining it try Clarke Ching’s Rocks Into Gold presentation on Slideshare.  I hope after reading this you are as excited about the possibilities as I was when I had my “lightbulb moment” about it.  I think it is vitally important for organizations to truly understand these concepts.  I hope those of you reading this blog entry agree and will pass it on to others so they can have their “lightbulb moment” and hopefully be able to make it happen!

Oh, one last thought – if you can prioritize so the percent of value delivered by each release is even higher, then the numbers can go even higher!  For example, can a first release be worth 50% of the value?  Can a second release be worth 40%?  These may be possible in light of studies that say more than 50% of features are rarely or never used.  Said differently more than half the software in existence has no value.  If we eliminate that half, maybe we can make the earlier releases worth even more!

Until next time I’ll be Making Agile a Reality™ by helping organizations understand why managing scope in order to have more frequent releases can be so important to their bottom line!  By the way, my good friend Richard Lawrence is a person who really helped me understand this concept, so thanks Richard!

Related posts:

1. New to agile? Don’t make it too hard! OK, so this isn’t my normal type of blog entry.  I don’t...
2. New to agile? 3 ways to cut scope (and live) The primary way I see teams release products faster is by reducing...
3. Agile antipattern: Waiting for all the requirements before starting Time for a short blog entry (I tend to be way too...

The primary way I see teams release products faster is by reducing the scope of each product.  However, this can’t be done in an arbitrary fashion.  There are real business reasons for each feature request (hopefully anyway!).  Having seen teams reduce scope successfully I’ve seen three primary ways it can be done.  In order to deliver 50% faster teams can:

1. Deliver 50% fewer features
2. Deliver all features but with 50% fewer bells and whistles per feature
3. Deliver all features with a sliding scale of bells and whistles per feature

Let’s look at each of these separately to see how they work.

Deliver 50% fewer features – This one is obvious and the easiest to make work.  Because agile uses a prioritized backlog of work, a product owner can simply have the team work in priority order until enough value is delivered to make a reasonable release.  A danger here is not being aggressive enough on how much is enough.  Most product owners still go overboard and allow features to be added until the product is well past the point of being releasable.  I believe this is due to product owners being conservative by nature.  Again, this method is simple and effective, except when the sales and marketing teams have “promised” features which are further down the priority list.  If a team delivers 25 of 26 promised features the customer can be upset.  If they deliver the same 25 features when only 20 were promised they are instead praised as heros.  Be very careful with the external commitments so they can be met!

Deliver all features but with 50% fewer bells and whistles per feature – This is a bit different.  It avoids the problems of the method above because all features are being delivered.  This method is relying on studies which show 64% of features are rarely or never used (Standish Group).  In order to deliver 50% faster, 50% of each feature could be eliminated and statistically still not hit the “core” of the software which will be used most of the time.  The drawback here is each feature is treated equally and there is a likelihood too much will actually be cut from some features and not enough from other features.  Which leads to the final method…

Deliver all features with a sliding scale of bells and whistles – In this method the highest priority features are fully developed while the least important features are developed only enough to say they work properly.  The features in between the extremes have a decreasing amount of robustness for each drop in priority.  This allows for the most important features to be the most useful and the least important features to be the least useful.  This overcomes the objections of the first method because all of the features are delivered, while also overcoming the objections of the second method by delivering maximum value for the highest priority items.

I think of the three methods as slicing scope horizontally (a horizontal line through the backlog showing our last feature to be developed), vertically (a vertical line to the right of each backlog item showing how much of it will be developed compared to the maximum) or diagonally (a slanted line to the right of each backlog item showing how much will be developed compared to the maximum).  The first method is clearly the most common, but the problem of leaving off externally promised deliverables is very real.  The last method is much harder to accomplish, but it can be done.

In the last method one way to accomplish it is to create a thin slice of each feature during early iterations.  In this way the product owner knows all the features could be delivered at any point in the future if robustness didn’t count.  From that point forward the product owner can prioritize how much time and effort should be applied to each feature and create the appropriate sliding scale – even properly accounting for changing priorities if necessary.

Too often we fall into the trap of believing every part of every feature needs to be delivered.  When expectations are properly set this is rarely the case.

Until next time I’ll be Making Agile a Reality™ for my clients by helping them cut scope using the method which allows for maximum value to be delivered in the minimum amount of time.

Related posts:

1. What do you want next? The software industry today is plagued by long release cycles for important...
2. Ten Ways to Improve Your Planning Poker Results People who promote the use of Planning Poker understand some of the main...
3. Agile antipattern: Using manual tests In an agile environment manual testing is fine – except for when it...

As a <user> I want <function> so that<value>.

Above is a very simple user story template.  How can something so simple be so hard to get right?  User stories make up the heart of agile development.  They are the primary input to the team.  The team takes the user stories and creates product increments based on completing those stories.  Unfortunately, getting user stories “right” is difficult to do right away.  The Product Owner (or other product facing role) needs to learn how to create user stories which meet the needs of the team.  This is a skill which can be learned over time, but I’m about to save you a bit of learning curve.

In order to create good user stories, start by remembering to INVEST in good user stories.  INVEST is an acronym which encompasses the following concepts which make up a good user story:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Let’s cover each of them with a simple explanation.

Independent:  Stories should be as independent as possible.  When thinking of independence it is often easier to think of “order independent.”  In other words, stories can be worked on in any order.  Why is this important?  It allows for true prioritization of each and every story.  When dependencies come into play it may not be possible to implement a valuable story without implementing other much less valuable stories.

Negotiable:  A story is not a contract.  A story IS an invitation to a conversation.  The story captures the essence of what is desired.  The actual result needs to be the result of collaborative negotation between the customer (or customer proxy like the Product Owner), developer and tester (at a minimum).  The goal is to meet customer needs, not develop something to the letter of the user story if doing so is insufficient!  Remember, you can always ask the magic question to help drive the conversation.

Valuable:  If a story does not have discernable value it should not be done.  Period.  Hopefully user stories are being prioritized in the backlog according to business value, so this should be obvious.  Some people say each story should be valuable to the customer or user.  I don’t like that way of thinking because business value encompasses more than just customer or user facing value.  It includes internal value which is useful for things which are normally called “non-functional requirements” or something similar.  I prefer to say the story has value to the “user” in the user story.  In this way it is clear who is to be satisfied.  Finally, remember the “so that <value>” clause of the user story.  It is there for a reason – it is the exact value we are trying to deliver by completing the story!

Estimable:  A story has to be able to be estimated or sized so it can be properly prioritized.  A value with high value but extremely lengthy development time may not be the highest priority item because of the length of time to develop it.  What happens if a story can’t be estimated?  You can split the story and perhaps gain more clarity.  Sometimes splitting a story doesn’t help though.  If this situation occurs it may be necessary to do some research about the story first.  Please, please, please timebox the research!  If you do not, it will take all available time thereby depriving the product of something else which could have been done instead.

Small:  Obviously stories are small chunks of work, but how small should they be?  The answer depends on the team and the methodology being used.  I teach agile and suggest two week iterations which allow for user stories to average 3-4 days of work – TOTAL!  This includes all work to get the story to a “done” state.  Also remember not to goldplate user stories.  You should do the simplest thing that works - then stop!

Testable:  Every story needs to be testable in order to be “done.”  In fact, I like to think of testable meaning acceptance criteria can be written immediately.  Thinking this way encourages more collaboration up front, builds quality in by moving QA up in the process, and allows for easy transformation to an acceptance test-driven development (ATDD) process.  As with negotiable above, asking the magic question can help ensure the user story is testable as well.

If Product Owners and their teams work together to INVEST in good user stories the learning curve of working together will be much shorter.  INVEST encourages good habits which eliminate some of the bigger problems of user stories like dependencies, being too big, hard to test, etc.  Take the time to INVEST in good stories and see the dramatic change in how effective planning will become, as well as how productive the team will become.

Until next time I’ll be INVESTing in good user stories because doing so definitely helps in Making Agile a Reality™.

Related posts:

1. New to agile? Remember a user story is more than a card! What’s wrong with the user story on the card?  It seems to...
2. New to agile? Learn how to split stories In my last blog Agile antipattern: Taking on large stories I said I would...
3. Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...

As an agile trainer and coach I often see new teams struggle with a simple question: “How much to do on a user story?”  A lot of people say the simplest thing that works is what should be implemented.  I agree with that wholeheartedly and even have a blog entry on how to figure out what the simplest thing is.  Unfortunately, lately I’ve found myself adding a bit to the sentence.

Do the simplest thing that works - THEN STOP!

There are developers who do the simplest thing that works and then keep going because they think the customer will want something more.  While they may be right, it isn’t their decision to make at that point.  Show what the team created at the iteration demo and see if the feedback from the demo says more should be done.  Don’t just assume it!  The extra work costs time and money, not to mention ongoing support costs if it actually goes to production.  The Product Owner needs to take all of this into account when deciding how far to take a story.

Oh, and while we’re on the topic, if you want to know how to have a great demo, read this blog entry.  It has some awesome ideas that all teams should try to follow.  The only thing I would add is to have someone other than a developer or tester be able to try the software during the demo.  Too many horror stories about how things were missed when developers went through demos too fast!

Thanks for reading this.  Until next time I’ll be helping teams in Making Agile a Reality™ by putting up a stop sign when they start trying to gold plate features!

Related posts:

1. New to agile? Remember one thing: Just enough, just in time If you lived through the past few decades you have undoubtedly heard...
2. What style of agile training works best? Have you ever been in a class or training session which is...
3. New to agile? INVEST in good user stories As a <user> I want <function> so that<value>. Above is a very...

Over the past 18 months I’ve encountered a number of teams where it is standard practice to have a code freeze late in the iteration.  The reason given for this was “to allow QA to test what we created during the iteration.” I’m sorry, but I have to be blunt here – this isn’t agile! It leads to 3 main questions:

1. What are the developers doing after the code freeze?
2. What happens if defects are uncovered after the code freeze?
3. Why could testing not be done earlier in the iteration?

The answers to these questions are often enlightening.  Let’s take them one at a time:

1.  What are developers doing after the code freeze?

I’ve heard two primary answers to this.  The first is that developers are fixing defects during that time.  When pressed, I usually find out these are defects from earlier iterations (although this isn’t always the case – more on that later).  If we are fixing defects from previous iterations while QA is working on testing the current iteration, how do we ever get caught up?  Maybe I’m being a bit dense, but I just don’t see the math working on this one.

The second most common answer is developers are working ahead on things for the next iteration.  Said a different way, developers are creating yet more untested code before the commitment for the current iteration has been met.  Let’s think about this model for just a minute.  Let’s assume we are in iteration 1 and the team does a code freeze on day 7.  Coding occurred for 7 days and testing will go for 3 days.  But the developers start stuff from the next iteration on day 7, so for the next iteration they get 3 days from this iteration and 7 from the following iteration for a total of 10 coding days, followed by 3 testing days.  This cycle continues until the project completes.  Anyone feeling sick yet?  Again, being blunt, this is not agile, it is mini-waterfall or what I prefer to call “wagile.”

2.  What happens if defects are discovered after the code freeze?

Again, in Family Feud style, the most common answer is the defects are fixed in the following iteration.  This is a continuation of the first half of the previous answer.  How can the math ever work?

However, this isn’t always the answer.  Sometimes the answer is developers fix them as they are found.  This answer is MUCH less common, but does exist.  The problem with this answer is very simple: if it is possible for developers to fix defects in real time after the code freeze, why could this not be done earlier in the iteration?  Which leads to question 3…

3.  Why could testing not be done earlier in the iteration?

Two answers here are equally common.  The first I’ll cover is the “it takes too much time/effort to move the code to our QA environment so we only do it once per iteration.”  I understand the need for a QA environment for testing, but is it necessary for ALL testing?  In most of the cases I’ve seen it is possible to do a tremendous amount of testing in a development environment to make sure everything is basically working before promotion to a QA environment.  The QA environment should be renamed the Verification environment.  Ideally we want to use it to verify everything works in the stable environment and passes all tests just like it did in the development environment.  So step one is to do more testing in the development environment.  Step two is to use some automation tools to build a stable environment quickly.  When pressed, most teams can create an automated process to do a bare-metal environment build within a short period of time.  It is worth the effort.  If this exists, a new build could be deployed at any time, but at least nightly.  Combine it with automated regression testing and really get some value from it!

The second answer I usually hear is “we don’t know what to test until the code is done anyway.”  Uh oh, can anyone even count how many ways this statement isn’t agile in nature???  Let’s remember the agile process:

1. Product Owner (or similar role) creates stories and some basic acceptance criteria.
2. During iteration planning more acceptance criteria are created based on conversations between tester, developer and Product Owner.
3. During iteration the developer and tester collaborate on their understanding so the code can be written and acceptance criteria can be turned into tests.
4. During development the developer can (and should) access any acceptance tests already written to see how their code is doing.
5. The developer isn’t “done” until the code passes all unit tests and acceptance tests.  Remember the definition of done!

When things are done in this manner the tester ALWAYS knows what to test because they are in close communication with the developer.  Collaboration is vital to agile success.  This is just one example driving it home.

The bottom line for me is there is no legitimate reason for having a code freeze during an iteration.  Teams need to either invest the time/effort to put together a system which doesn’t require a code freeze, or stop calling themselves agile.  This is a nasty antipattern which will cause confusion or worse.

Thank you for reading.  Until next time I’ll be Making Agile a Reality™ for my clients by helping them avoid code freezes during iterations.

Related posts:

1. Agile antipattern: Burndown “wall” Does your team have an iteration burndown chart (giving credit only for...
2. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...
3. Agile antipattern: Extending an iteration I had a previous blog post about stopping an iteration and how...

I was just working on some Powerpoint slides for our Agile Product Management Boot Camp coming up on March 9 and 10 and I realized I should post a blog entry about the point the slides are making.  Actually, I’m trying to make two points with the slides.  The first point is we tend to work in organizations where the phrase “everything is priority 1″ is common.  The second point is my personal distaste for using the phrase “prioritized product backlog.”  I’ll cover each of these points separately.I’ll start with the “everything is priority #1″ problem, since that is the title of this blog entry.  Let’s be very clear THIS CANNOT BE ALLOWED!!!  There are many blog posts on the web such as the ones here and here.  I like what the first of those links says about how to explain why everything can’t be priority 1 – we can’t build it all at once!  I usually approach this with product managers/product owners/stakeholders by asking them what they want if they can only get one thing.  They quickly say one thing is useless they need it all.  To which I reply, I know, but I want to make sure we have the most important item built first so we can learn from it and make changes to other items based on what we learn.  I’d like to rank all of the items 1 to whatever, with no ties, so we can always be working on the next most important item and be able to learn from it as well as all the other items which were more important.  This way we will make sure the most important items are in the release and meet expectations.

Which leads into my second point about the phrase “prioritized product backlog.”  If you simply say the words, nearly everyone in the software industry will say  they already do that.  Why are they saying this when a casual observer can tell it isn’t true?  It is because we have overloaded the word prioritization.  Most software people think having a list of 100 items which has the top 97 as priority 1, the next 3 as priority 2 and no priority 3 items is a prioritized backlog.  Sorry folks, but that is a useless list.  We really need a RANKED backlog, where the rankings go from 1-N and there are no ties.  Then we use the list by making sure we work on the next item in the ranking, not just work on some random thing which seems interesting.

We simply have to keep these two issues in mind when we are dealing with the product backlog or we will not be successful.

So, what do the two slides look like?  Here they are:

This is the first post in the “Agile Antipattern” category.  I anticipate having a few more over time.

Until next time, let me know what you think so together we can be working toward Making Agile a Reality™.

Related posts:

1. New to agile? 3 ways to cut scope (and live) The primary way I see teams release products faster is by reducing...
2. Agile antipattern: Sizing or estimating bug fixes Is the bug to the left a large bug or a small...
3. What do you want next? The software industry today is plagued by long release cycles for important...