Far too many Agile development projects fail. It is hard to even accurately measure the number of failures because so many software development projects end up “complete” and shipped, even though:
- They took far too long to build
- The quality of what we built was poor
- What was built was not what the customer wanted
- The cost to develop was more than it should have been
Over the years, I’ve worked on many different Agile teams and have consulted for and trained many teams on Agile development. In this time, I have found 5 common problems, that if not resolved, are very likely to cause a project to be a failure.
1. Not having a product owner
Of all the things that can cause an Agile software project to fail, not having a person that is ultimately the decision maker for the product being developed is the quickest way to ensure its demise.
It doesn’t matter if you are following Scrum, doing your own Kanban style project or something else; if you want your project to succeed, you need someone who can set its direction and make decisions about the product being developed.
Think about remodeling a kitchen. If you hired a bunch of contractors to come in and do the various jobs, like: plumbing; carpentry; flooring; etc, but you don’t have someone deciding what the actual finished kitchen should look like, you are going to get a random mess.
A few skilled contractors will probably be smart enough to find the right person to ask about what should be done, but it takes more than just making arbitrary decisions about where the cabinets should go to design a kitchen. You need someone to actually come up with a real design and vision and be able to modify that vision appropriately as the project progresses and problems inevitably occur.
It seems pretty nuts to spend a huge amount of money remodeling your kitchen, but not want to invest any time or effort in either designing the finished product or hiring someone to do it.
Yet, day in and day out, I see this exact behavior in software projects. I see companies investing huge amounts of cash in Agile development, but not appointing anyone to be the true owner of what is being built and to set the vision for it.
2. Not iterating
One of the key values that Agile development brings to the software development world is iteration.
What is iteration though?
You may think it means breaking your project into 2 week sprints or iterations. While doing this can facilitate iterative development, it doesn’t mean you are actually iterating.
Confused? Let me explain.
The key to iterating is to develop a product a little bit at time. It would be accurate to describe the process of iterating on a product as evolution of a product.
Whether you believe in macroevolution or not, microevolution, or adaptation is a proven concept. The idea behind evolution is that things change gradually over time. Those small changes add up to result in a big change.
Imagine how silly it would be if evolution worked the way most “Agile” software is built.
Imagine, if you will, a fish that swims in the ocean and has some little fish babies that are born with fully functional legs. Then, those legged fish babies grow up and have fish babies that have wings.
Probably the legs and wings wouldn’t do that fish much good, nor would they be designed properly, because instead of adapting and changing over time, they just suddenly appeared.
Features should not be built in a single sprint or iteration. It is as silly as legs showing up on a fish in a single generation.
Instead, features should be evolved and grow over time. A feature shouldn’t be pushed into a single sprint or iteration and then be done. A feature should start out small and develop and evolve over time as feedback is received and customers or the product owner tries it out.
Far too many times, I see Agile development projects mistake having iterations with actually iterating the development of the product.
Don’t try to ship a completed feature at once, let it evolve over time.
3. Not breaking things down small enough
The main reason why this is so important is because it prevents procrastination. Procrastination usually occurs when either we dread some large task that will be difficult or we don’t know what to do next.
If you can break a big project up into small parts, it will seem easier to accomplish and will have clear steps of progression.
I often see software projects where the person creating the backlogs or work items is not considering the work enough before giving it to the team.
I coined a term for these kinds of backlogs: fatlogs. Fatlogs are backlogs that are not broken down small enough and often are very vague in what needs to be accomplished.
Fatlogs are notoriously difficult to estimate and waste time when trying to explain and understand them. It is critical that fatlogs be broken down into smaller actionable backlogs before being given to an Agile development team or a large amount of time will be wasted.
Many times, I have found that the creator of the fatlog could have easily broken down the work it represents into several smaller backlogs that would be easier to explain and understand, even without knowing much about software development.
I often recommend to Agile development teams that they outright reject fatlogs and send them back up the chain.
“If you can’t take enough time to clearly state what you want, it must not be that important.”
This doesn’t excuse development teams either. Development teams should break down any backlogs they get into small tasks as well.
4. Not setting done criteria
What is the first thing a waiter asks you when you order a steak?
That’s right, they ask you how you would like it done.
If the chef doesn’t know what the done criteria is for your steak, the chef will have to decide what he or she thinks the done criteria is.
You may get back a well-done steak, or a rare steak, or something in between, depending on the personal preferences of the person cooking your meat.
This isn’t a good way to cook steaks and it isn’t a good way to cook software either.
In many software projects I often encounter lots of steaks being cooked but no one defining when they are done. The backlogs most often end up being “done” when time runs out.
It is very important to have explicit unambiguous done criteria for any backlogs being worked on by an Agile development team.
This means that the product owner should be defining some level of acceptance testing. It doesn’t matter if the tests are manual tests or fully automated tests (BATs), what matters is that some criteria is defined by which the team can evaluate whether they have achieved their goal or not.
Lacking this criteria is like a parent responding with “enough” when their child asks “how many more peas do I have to eat?”
Not having done criteria is demotivating and results in the finger pointing game of why the correct thing was not built.
I have found that if you tell someone exactly what is expected of them and what criteria they will be judged by, you get much better results than just throwing them in the ring, slapping them on the back, and saying “do a good job.”
5. Not letting the team be a team
Teams are strange organisms, especially Agile teams.
There are many dynamics that affect how teams act and interact. There are many ways to foster a healthy team and many ways to create unhealthy teams.
A healthy motivated team has synergy, a unhealthy gaunt team can be less effective than all of its members are on their own.
The key to having a healthy motivated team, is letting them be mostly autonomous. Regardless of your political persuasion, you would probably agree that when a country invades another country and sets up an unelected government to oversee the people, there are going to be problems.
The same thing happens in Agile development.
I’m not saying teams shouldn’t have accountability. But if you want to run a software project in an Agile way, you have to let teams self organize and self manage to some degree.
When big brother is always watching and interfering, team dynamics become very different. Naturally, teams usually develop their own cadence, leadership and roles (this is called norms.) However, when outside forces directly interfere with how the team does things, and they don’t have the power to decide their own fate, team members begin to realize that they need to look out for themselves.
Additional agile development resources
I’ve found it to be pretty difficult to find good resources on these topics, but here are a few books I’ve found useful that address some of the issues I described above.
- Succeeding with Agile: Software Development Using Scrum - This book is focused on Scrum but it applies to many different kinds of Agile projects as well. Mike Cohn and I usually agree on most Agile subjects.
- Agile Retrospectives - I’ve found this book to be useful for getting good idea for team retrospectives that can really help to break down some barriers and help teams learn to resolve issues themselves.
- Scrumban and Kanban and Scrum - Both of these books have excellent information about combining Scrum and Kanban and have great solutions for dealing with some of the problems I described above.
What do you think? Have I missed any of the major Agile project killers? Any useful tips for dealing with them?
Let me know in the comments below.
One of the biggest challenges in breaking down backlogs is knowing how to split up the work from a backlog into right sized pieces.
I’ve already talked about the concept that smaller is better, but I we haven’t really addressed the decision of how to actually divide a backlog up to make it smaller.
The default path
Most developers trying to break down a backlog into smaller chunks will automatically head down the path of using a “horizontal slice.”
This is how we tend to think.
What do I mean by a horizontal slice?
A horizontal slice is basically a slice through the feature or backlog that horizontally divides up the architecture.
Most things are built this way.
If you were to build a house, you would probably start by slicing up the project horizontally.
You would first pour the foundation. Then put up the walls. Then put on the roof and many more steps, leaving the finishing work for last.
This same thinking usually gets applied to breaking up backlogs in Agile development.
It would seem pretty silly to build a house where you finished one room completely at a time.
Agile software development is different
There is a distinct difference though, between developing software in an Agile way and building a house.
The big difference is that in Agile software development, true Agile development, you don’t know exactly what you are going to build until you are done building it.
With a house this is rarely the case.
With a house, you have some blueprints that you have drawn up ahead of time. You know exactly where each wall will be and where each outlet will be. You may have even built houses before that are very similar.
When building software, unless you are taking a waterfall approach and planning everything upfront, you don’t know what you are really building until you are done.
Before you object to this statement, consider this:
This is the point of Agile development.
Agile means responding to change.
Building a house, you do not expect the customer to say:
“Hmm, yeah, I don’t really like that wall there.”
“Actually, I am thinking we are going to need 5 bedrooms now.”
In software development, you are expecting statements analogous to the above!
So what is vertical slicing?
Simply put, building one room at a time.
But it’s not functional! Who wants a house one room at a time?!?
Correct! It is not functional as a house, but we can pour more foundation, change how we are going to do the rest of the rooms and even knock down the walls and start over without incurring a huge cost.
The point in building our software “one room at a time,” is that we are giving the customer a chance to see the product as it is being built in a way that matters to them and enables them to test it out.
Sure they aren’t going to be able to live in it until it is all done. But, they will have the ability to step into a room and envision it with all their furniture in there.
Customers don’t care about foundations and framed in walls. As a developer, you might be able to look at some foundation and framed in walls and envision what the house will look like, but the customer can’t and worse yet, it can’t be tested.
Vertical slicing in software development is taking a backlog that might have some database component, some business logic and a user interface and breaking it down into small stepwise progressions where each step cuts through every slice.
The idea is that instead of breaking a backlog up into the following:
- Implement the database layer for A, B and C
- Implement the business logic layer for A, B and C
- Implement the user interface for A, B and C
The backlog is broken up into something like:
- Implement A from end to end
- Implement B from end to end
- Implement C from end to end
Sounds easy enough, why the debate?
Because it is NOT easy.
I’m not going to lie to you. It is MUCH easier to slice up a backlog horizontally.
As developers we tend to think about the horizontal slicing when we plan out the implementation of a backlog.
We tend to want to implement things by building one layer at a time.
Thinking about how to break apart a backlog into vertical slices requires us to step outside the understanding of the code and implementation and instead think about the backlog in small pieces of working functionality.
There is almost always some progression of functionality that can be found for a large backlog.
What I mean by this is that there are almost always smaller steps or evolutions in functionality that can be created in order to produce and end result in software development.
Sometimes the steps that are required to break up a backlog vertically are going to result in a bit of waste.
Sometimes you are going to purposely create a basic user interface that you know you are going to redo parts of as you implement more vertical slices.
This is OK!
It is better to plan small amounts of rework than to build up an entire feature one horizontal slice at a time and have to rework huge parts of the feature that weren’t planned for.
So what is the benefit?
You might be thinking to yourself that this sounds like more work without much benefit. So why would I bother to break up a backlog vertically?
Is it really that important?
I’ve already hinted at some of the benefits of slicing things vertically.
The true impetus behind vertical slicing is the very cornerstone of Agile methodology. It is about delivering working functionality as soon as possible.
We aren’t going to cover the whole reasoning behind this idea in Agile development. I am assuming that you already subscribe to the idea that delivering working functionality as soon as possible is important and valuable.
Based on that premise alone, you can see that horizontal slicing is in direct violation to one of Agile methodology’s core tenants.
It is interesting to me how many people are huge proponents of breaking entire systems up into functional pieces that are delivered one piece at a time, but are so opposed to doing it at the micro scale when dealing with individual backlog items.
If you are opposed to what I am saying about vertical slicing, you really have to ask yourself whether or not you truly subscribe to the same idea applied at the larger level, because there really isn’t a difference.
As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple. Feel free to check out ElegantCode.com where I post about the topic of writing elegant code. Also, you can follow me on twitter here
Imagine this common scenario if you will.
One of your friends calls you up and says:
“Hey, would you mind helping me move on Saturday, I am getting 4 or 5 people together and we are going to move my stuff to my new house?”
You of course reply:
“Sure I can help, what time do you want me to be there?”
“We are starting at 10:00 AM sharp!”
You might have guessed what is going to happen next. You show up at your friends house expecting that everything is nicely packed in boxes and that you are just going to move some boxes and furniture into a U-Haul, but instead what you see is this:
He couldn’t have cleaned up the house and at least put the stuff in boxes before having 5 people show up at his house to move stuff?
So what should have been a 2 hour jobs turns into a 2 day ordeal as you and 4 other friends sit around waiting for moving friend to pack up his stuff so that you can put it in the truck.
All 5 of you can’t actually help with the packing of stuff and the throwing out of garbage because there is only one person who knows what is trash and what things need to go in what boxes.
If your friend would have cleaned up the trash and packed up everything in boxes before he had the 5 of you come over and help, things would have gone much much faster!
Your backlog list is your apartment
The same kind of thing happens when you call up 5 of your developer and QA
”buddies” and ask them to get some work done for a sprint.
If the team is trying to sort out what needs to be done, what is trash, and what things need to go in what boxes, they are going to be much slower at actually getting the work done.
You see, your list of un-groomed backlogs is not unlike a hobo. Often times it could use a good wash and a proper shave.
When I am talking about backlog grooming here, I am not even talking about having a planning meeting, where you plan what you will do next.
Angela Druckman has a good description of a Grooming Session.
The idea is that periodically you groom the top x% of your backlogs so that they are in nice clean boxes ready to be worked on when the team picks them up.
The important thing here is that this is a team activity, everyone should be involved with backlog grooming. The business really owns the backlogs in most cases though, so they should be directing the team as to which things go in which boxes so to speak.
What about just in time backlog grooming?
Why work on a backlog until the very last responsible minute?
For the answer I point you back to the moving scenario I started this post with.
The reason why it is so inefficient for your friend to have everyone come over and try to move him before he has packed up everything and gotten rid of the trash is that you end up having a large amount of idle time waiting on one person.
Think about when happens when a team of 8 developers starts working on backlogs for an iteration at the same time.
If all of the backlogs are not “groomed”, but instead are a scattered mess of mismatched sizes and parts, each developer is going to have to talk to perhaps the same business person about the backlog that developer is working on.
What happens when this business person is out of the office?
What happens when this business person is trying to field questions from 8 developers?
What happens when there is a turn around time to get back to the developers on questions about the backlog?
Now contrast this with the scenario where all the backlogs that are going to be worked on in an iteration are nicely packaged in neat little boxes.
The backlogs may not contain all the technical details of what is going to be implemented, but they are broken down to small bite size pieces that are fairly well understood by the team.
In this scenario the team is going to be able to pick up the backlogs and start going to work. Sure they will still have to ask the business questions about the backlog, but the kind of questions being asked change fundamentally.
Contrast this kind of question:
So what exactly is this backlog about? What kind of things do we want to build to report on this data?
To this kind of question:
As we discussed previously and I see in the backlog, we are creating a custom report for this customer. I also see that we had defined what this column A should do. Should I be using calculation X or calculation Y to compute this column?
The first kind of question is better answered in a bigger meeting with all the right people. To answer the first kind of question might require some research. The first kind of question would hold up the completion of a backlog because it is not easily answered. It requires thought and perhaps asking other people, talking to the customer, etc.
The 2nd kind of question is specific. This is something that can be figured out usually by a single person. Most importantly it does not hold up the work. Developers can continue implementing parts of a solution and put in the algorithm for computing some value later.
As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple. Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week. Also, you can follow me on twitter here.
The process of breaking down a backlog is one of the most important steps in any Agile process.
I have found over the years that the better a backlog is broken down the smoother the implementation of that backlog is.
I have found that the single greatest influencer in the success or failure of a backlog is the process of breaking it down.
What does it mean to break down a backlog?
Before we can really discuss how to break down a backlog it is worth taking a minute to discuss what I mean by breaking down a backlog.
If you are following some kind of Agile process, you probably have a story board. On that story board you probably have a swim lane dedicated to a step that is just before the development of the backlog is ready to begin.
The process of breaking down a backlog is moving a backlog from the state of selected for implementation to that state of ready for implementation.
Different teams indicate this transition in different ways, but most teams have some way of indicating that a backlog is ready to be worked on.
So when I talk about breaking down a backlog, I mean the process of moving a backlog into a state where it is ready to be developed.
Why break down a backlog?
So why do we want to do this thing? Why don’t we simply pick up a backlog and start developing it?
The main reason we take the time to break down a backlog is because we adhere to the old philosophy of measuring twice and cutting once.
The process of breaking down a backlog is the process of thinking ahead to lay out a path which we can follow to the successful completion of a backlog.
By skipping this crucial step, we almost inevitably set ourselves up for failure.
Not breaking down a backlog to me is like going on a week long camping trip by taking with you everything you happen to have in your car rather than carefully planning out what you’ll need.
Packing the right gear
Now that we have talked about what breaking down a backlog is and why we should do it, let’s talk about the steps that are involved.
Step 1: Review the backlog as it is
In this step our goal is to understand the backlog and evaluate the kinds of questions that we will need to ask about the backlog and the areas of code that will likely be affected by the implementation of the backlog.
We will want to carefully read the backlog and try to understand the basic idea of what is being asked for.
We want to look for any kind of trouble areas that either indicate what is being asked for will not be possible, or that it will require significant architectural changes to the existing system or paradigm.
We also want to look for indications that a backlog might be too large and actually might be a fatlog that will need to be broken down into smaller backlogs.
Step 2: Pre-review the affected area of code
After we have gotten enough of a gist of what the backlog entails we should have an idea of the area of code involved.
It is important to take a look at the area of code that is going to likely be affected by the implementation of the backlog so that we know what we are getting ourselves into.
Nothing it worse than thinking something is going to be easy to implement then actually looking at the code and finding out that it is a total mess that has to be cleaned up before anything can be done with it.
Our goal here is not to solve the problem or even to outline the solution. We just want to have enough education about the affected code to be able to have a conversation with the business about what will need to be done to implement this backlog.
Step 3: Initial discussion with the business and QA
Armed with an understanding of the basic idea of the backlog and the areas of code that are likely to be affected, we are ready to talk to the business and QA about the backlog.
The goal here is to fully understand what is going to be implemented and what the goal of the backlog is.
We have QA here so that both the development team and QA get the same understanding of the backlog at the same time. We don’t want QA or the development team dictating what they think the backlog means. If it is at all possible, it is important to get someone responsible for the backlog from the business to tell both parties exactly what they want.
Step 4: Define skeleton tests
Before we leave the initial discussion about the backlog, we want to come away with an initial skeleton of tests that everyone has agreed upon.
This is a very important step that is often ignored, because often teams think that QA will just go off and write some tests.
It is important to make sure that everyone, including developers and the business, has agreed to the general tests that are going to be used to qualify the backlog as done.
Without knowing exactly what criteria will be used to judge the completion of a backlog and agreeing to it up front, you may be committing yourself to whatever the whims of either QA or the business are at any given time.
Defining skeletons tests help to define scope.
It doesn’t mean that requirements and details can’t change, but it does mean that the current set of requirements and criteria is well enough understood for development to begin.
I often call the skeleton tests “done criteria.”
At times I have actually reworded a backlog to explicitly state the done criteria that has been agreed upon after this meeting.
Something similar to
This backlog is done when:
- I can create a new user
- I can see that the new user exists from the admin tool
- The creation of the new user is audited and specifies details about the creation of the user.
Step 5: Task out the backlog
If you can’t task out a backlog, you don’t clearly understand what you need to do to accomplish the goal.
Tasking out the backlog is the process of breaking down and identifying the steps required to implement the backlog.
I often try to make done criteria be in the form of business language and tasks be in the form of implementation details.
Tasking out a backlog can be a cumbersome process, but it is akin to mapping out a trip before and carefully packing your supplies before heading out on the road.
When I am tasking out a backlog, I try to think of each sequential step that is required in order to completely implement the backlog.
Part of this process often involves the actual design of the solution, because without some kind of design it is often difficult to create a series of steps to get to the end goal.
This is one of the reasons why I see tasking as so important, it ensures proper upfront design. Many Agile teams think that Agile means no upfront design. This simply is not true. Agile means that we don’t upfront design the whole system, but we should always try to design something to some degree before we implement it. Especially in a complex system.
Tasking also helps to split the backlog up into workable pieces that can be worked on by different members of the team either jointly or in isolation. It is very difficult to coordinate work on a single backlog item when it isn’t properly tasked out.
I often like to define done criteria for each task in order to make sure that anyone picking up a given task will understand when it is complete.
One thing to watch out for is whether certain tasks are sequential or if they can be done in parallel. When possible, dividing up a backlog into parallel tasks is preferred, but many times tasks must be sequentially implemented.
Ready, set, GO!
Following these steps might seem a bit cumbersome to your development process, but I can assure you that if you take the time to implement this process you will not regret it.
Taking the time up front to clearly define the work that is going to be done on a backlog can save huge amounts of time that can be wasted reworking a solution that hasn’t been thought out clearly.
Here is a short recap of the steps for breaking down a backlog:
- Review the backlog
- Review the code affected by the backlog
- Discuss with the business and QA
- Define skeleton tests and / or done criteria
- Task out the backlog
I would love to hear any success stories or issues your team has trying these steps out.
As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple. Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week. Also, you can follow me on twitter here.
I talked about how moving the finish line is one of the most destructive things to do to a Scrum team, but I wanted to talk about another variation of the same problem, which is scope creep on backlog items in progress.
Responding to change
Agile is all about responding to change. Don’t get me wrong, I am not for one second suggesting that you should specify your requirements upfront before working on the backlog item.
Agile is also about iterative development. We take a thing, get a rough idea of what we want to build, build it and then iterate on it, making it better as we progress and figure out what we truly want.
The specific problem I am after today is about knowing when to allow change and at what resolution to iterate.
I think these are very important ideas that need to be understood to really be successful at Agile software development.
To some people Agile means we allow change at any point in time. I think this view is a little too far on the extreme. There are certain points in an Agile process where change is welcomed and that depends on the process.
Scrum welcomes change up to the point the team has committed to the sprint. After that point changes to the scope of what will be worked on during the sprint are detrimental.
Kanban and Kanban like methodologies embrace change all the way up to the point that the backlog is in progress. At that point a significant change to the scope or focus of the backlog causes more harm than it provides business value. (In general)
What kind of changes are also important to define.
The kinds of changes greatly affect whether or not they can cause harm or be good. Changing the layout of a screen during the development of a backlog usually is not a big deal. Changing the way the screen functions usually is. Changes that add significant functionality also are harmful when the backlog is already in progress.
A little later on I’ll talk about some of the reasons for this. For now let’s look at…
There is a prevailing misunderstanding of what iteration means and how it is valuable in Agile software development.
Many Agile practitioners think iteration applies only to the software package itself and to iterate means to add features.
This resolution is far too large. If the smallest iteration of your software is a complete feature, you probably have fatlogs, and you are going to run into trouble.
You may not ship features to a customer until they are completely evolved, but if you try to complete the evolution of features all in one sprint or cycle, you are probably going to bite off too much and miss out on the true value of iteration.
Just as your software should be iterating by adding features, the features themselves should be iterating by adding functionality.
Think of your software as a tree and features as branches. If you were to watch that tree grow, it would be pretty bizarre if whole complete branches just started popping up on the tree everywhere.
It is much more natural for the branches themselves to grow from little stubs into a large branch that might even have branches of its own.
Tying it back together
Given a backlog is already in progress and you have a good understanding of when change should be allowed in your process, and what resolution iteration should happen, it should start to become obvious why adding new requirements to that backlog is a bad idea.
If you take an existing backlog in progress and add new requirements to it, you’re introducing change at the wrong point, and possibly trying to “poof” branches onto your software tree, instead of truly iterating.
It is much better to add a new backlog that will serve as an iteration of the existing feature than it is to try and tack on new requirements to the work already in progress.
Well, hopefully our discussion of change and iteration resolution has given you some idea of why, but there is much more depth to the question than that. Let’s discuss some of them.
There is a huge psychological portion of software development. We tend to be motivated by accomplishment and feelings of a “job well done.” We tend to be demotivated by goals changing out from underneath us and feeling like a job won’t ever really be done.
Let me give you a simple example. Imagine you tell your child that their chore for the day is to make their bed.
They go and do it, come back to you and tell you it is done, then ask for you to check it. When you check, you see that the bed is made, but you say “the floor also needs to have everything picked up.”
So they go and do that, it takes a little longer this time, because they have lost some motivation, but they finish and come back to you again and you see the floor is now cleaned up, but this time you say “the floor needs to be vacuumed.”
In this situation although each request is reasonable, the building of the requests on top of the original task has the effect of demotivating the individual and deprives them of their sense of accomplishment.
When you do this in software development, a similar thing happens. You also lose the trust of the team because the team starts to think that when the business says X they are really going to want X + Y + Z. The team starts to work much more slowly because it doesn’t really matter anyway. You do not want to operate in this mode! It is very bad!
Not letting evolution takes its place
If you try to cross a river by taking a huge leap across it, you are either going to get wet or you are going to make it. If the river is big, you will mostly get wet.
It is much better to cross a river leaping from stone to stone until you are all the way across.
Adding a requirement to a backlog in progress can be like making a big leap. By adding another backlog to bring you closer to the goal, you allow the current backlog to be a step, and the new backlog to be the next step.
It is a judgment call whether or not a change to an in progress backlog represents a new requirement which should be a new backlog or not. I would err on the side of making new backlogs rather than adding requirements though. I generally say if it will increase scope significantly it should be a new backlog. Either way the work is going to be done, so why not have your…
Estimating more accurate
Nothing kills historical estimations like scope creep. If you want accurate data, don’t add unaccounted for work. Squeezing new requirements into in-progress backlogs adds work to your historical data that is not properly accounted for.
It is much better to catalog the work and account for it than to tack it onto a place where you will not have a way to extract it back out when you are trying to analyze your data.
Consider also the loss in quality as a developer assigned to the expanding backlog starts rushing the work in order to get it done because they feel like they are going to be measured against the backlogs they completed, and work added to an existing backlog isn’t going to be counted in the metric.
Don’t forget prioritization here. If you tack a requirement onto a backlog in progress, you can’t prioritize that work. You may add that requirement at the expense of delaying other higher priority work in other backlogs. Make the new requirement into a backlog and you can prioritize it correctly.
If you are a product manager, product owner, or business person reading this, give it a try. You will be amazed how much more happy and productive your team is if the next time you are working on a backlog with them and realize it needs to account for X and Y also, you announce that you will create two more backlogs instead of tacking it right on.
If you are a developer on an Agile team, you may not have even realized this problem might be sapping your motivation. You might not be in a position to do much about it, but you can always suggest that the new requirement be a new backlog.
In our morning standup meeting one of my team members made a pretty good point about story sizing not being so important.
In Kanban we strive to have relatively same sized stories because it allows us certain benefits:
- More accurate metrics on estimated time in queue for any story to be delivered.
- Reduced dependence on estimation and planning.
- Continuous flow as opposed to slow… fast… fast… slow.
I thought you said the story sizing is not so important?
Right, exactly. It is important for them to be relatively same sized, but it is not so important that they be exactly the same size.
Basically, we don’t want to have mice and elephants thrown in together.
It is the difference between breaking a candy bar in half to share and measuring out prescription medication.
You can look at the candy bar and say “yeah, that looks about the same size,” but you’d better not do the same thing with medication.
It is a complete waste of time to go overboard with the splitting of the candy bar, getting it even to the exact milligram.
It is a complete waste to try and get stories estimated down to the hour.
Size ‘em up against each other
In that case how do you actually size the stories?
Just compare them against each other. When looking at a new story, consider the other stories you already have on the board. Is this new story like an elephant in comparison to a bunch of mice? Is it the other way around?
If so, adjust the story to make sense. Don’t trust your gut without comparing it to what is out there already, otherwise you’ll start to drift in your estimations.
Don’t worry too much if you’re wrong sometimes. As long as you are close, it will all balance out in the end.
Also don’t forget to get rid of all the Blue Whales. You don’t want any of those on your board, ever.
I come from a QA background.
I started off my career doing testing. I learned about testing the same way I learned about development… reading lots of books and applying what I learned.
This is how you are supposed to do QA:
- Write a test plan for the project.
- Gather requirements. Put them into a repository and give them cold hard labels like REQ1.2.5.
- Create test cases from the requirements. Store those test cases into a tracking system which can map them back to individual requirements.
- Execute test cases, each test step should either pass or fail. Record the results. File any bugs found into the bug tracking system which maps the bug to the test that failed and the associated requirement.
There is more to it, but that is the basic outline.
But it doesn’t work in Agile!
Heck, it doesn’t work anywhere. At least not the requirements part. That is the part that is always missing, or woefully inadequate.
Don’t panic though. It makes sense. Let’s think this through. The reason we all started jumping off the waterfall ship and into Agile is because we realized that it is almost impossible and certainly worthless to try and define requirements up front.
With that idea in mind, how do we test? How can we test in an Agile environment?
First goal is automation
Let me explain to you why this is the most important part. It may seem a little out of order, but bear with me.
When you are doing iterative development, you are building things little by little. You’re not waiting until the end to test things, so there is a really good chance something you do in any iteration will break something you did earlier.
How do you deal with this? It’s called “regression.” Yes, you probably need it in waterfall, but in Agile it is an absolute must, otherwise you’ll find that for every step forward you take, you take a step backward as you fix something that you broke.
Running an Agile project without automation is like walking the tight-rope without a safety net, except the tight-rope is on fire, someone is strumming it like a banjo, and you’re wearing two left shoes.
People groan when I say this, but I firmly believe it and I have done it several times.
Part of every backlog’s done criteria should be that it has automated tests!
Unless you have automated tests for each piece of functionality you build (or at least the ones you care if they stay working), or an army of manual testers running your regression suite every iteration, your software will break in your customer’s hands.
Next goal is change the focus
Testing is traditionally an activity that happens at the end of development and is the gate-keeping for software. It has to go through QA before it gets released.
That is not a good model for Agile, because what happens when there is a bug? If the testing happens at the end of the iteration and there is a bug found, there is no time to fix it.
What if we change the order of things, change the focus?
When you write your code, you write unit tests first, right? (Or if you like BDD, you write the specifications, or behaviors.) And you run them continuously as you’re working on your code to make sure you don’t break them, right?
We can apply the same thing at the higher level.
- We can focus on creating a failing automated test before implementing the software.
- We can iteratively build more failing automated tests and make each one pass by building the software.
- We can run those tests as we build the software.
How many times have you built a feature only to have it tested and find out the test cases were not at all testing what you built? (I’ll raise my hand.)
That happens when we try to independently create the test cases from the development of the software.
What we want to do is blur the lines between testing and development. We want to get close to continuous testing. Just like we do when we are running unit tests as we are writing code. Short feedback cycles are the key.
Sounds good, but how do we do it?
Here is a walk through of what your workflow might be when doing Agile testing.
- Backlog item is pulled into iteration.
- Team members talk to backlog owner about the backlog. The goal of this conversation is not to get all the details of the backlog, but to get enough information to understand the bigger picture of the backlog and get enough information to get started.
- Team members talk about what is the basic, first, automated test to write for this backlog.
- Team starts writing the automated test.
- Team starts writing the code to make the automated test pass.
- Team goes back to backlog owner to demonstrate completed parts, get feedback, and ask for more clarification.
- Team continues to write automated tests, make them pass, and have conversations and demonstrations with backlog owner.
- When backlog owner is happy and backlog is complete, and everyone considers it well-tested, the backlog is done.
Observations about that process:
- Steps can happen parallel or out of order, steps can overlap.
- Steps can be split among team members.
- I erased the words “QA person” and “Developer” and replaced them with “Team,” we don’t care so much about roles, we want to blur those lines as much as possible.
- There aren’t really phases, for development, QA, etc. Development involves testing as you go, when the backlog is done being “developed,” it is done.
- Focus is on making customer happy, not passing an arbitrary set of requirements the customer gave you upfront, or you tried to interpret. Take a look at my post on comparing user stories requirements gathering to hanging a picture for more on this.
- There is no useless documentation. All documentation is executable.
- There is no “gate-keeper,” quality is being built as we go, we are not trying to “test it in” at the end of the iteration.
What is the role of the QA person?
It might seem that we have eliminated that role by this process, or diminished the value, but nothing could be further from the truth.
What we have actually done here is elevated the role from writing documentation and manually executing tests to being the expert on quality and the representative of the customer on the team.
You can think of the QA person as the “quality coach” for the team. They might not always be the one creating the automated tests or running them, but they are one of the main forces guiding the direction of the creation of those tests, and making sure the customer’s interests are represented.
The QA team members will also occasionally manually test things that cannot be automated, and exploratory test as needed, but the focus should shift towards being the “quality coach” for the team instead of doing all of the quality work.
I found this excellent presentation on Agile Testing by Elisabeth Hendrickson from Quality Tree Software if you are interested in further reading on the topic.
In my last post, I talked about some of the problems of Agile processes and suggested the introduction of a new process which takes some of the best parts of each of the popular processes and condenses them into the Kanban lean-style-thinking of limiting the work in progress.
For this post I want to clearly define what I am calling “Kanbanand” with two primary goals in mind.
- Allow someone who is interested in doing a Kanban like process to find enough information to be successful.
- Create a common thread for people who are already basically doing what I am suggesting.
Three Pronged Fork
I want to present Kanbanand as a three pronged fork. In my mind there are 3 distinct areas of a successful Agile process which must be addressed.
- Business and overall encompassing project process.
- Development practices, including standards and best practices.
- Infrastructure: build systems, deployment, source control.
We must know how to run our day to day process, how we physically construct our product, and how we actually build and deliver the product.
- Project is broken into stories which are small vertical slices through the system which are prioritized.
- A Kanban board is used to make the progress of a team visible and has limits to control the Work In Progress (WIP).
- At least once a day team members meet around the Kanban board in a stand up meeting to talk about the progress of the board.
- The team meets on a regular basis to have a retrospective to discuss how to better improve their process.
- Teams always pull in work, work is never “pushed” in.
- Once work has been approved as “done” it can never be “not done”.
- Find something to measure and measure it.
- The team is responsible for, and empowered to determine how the team accomplishes its goals.
- Roughly same sized stories over irregularly sized stories.
- Stories specifying what, over stories specifying how.
- Stories that are one sentence over stories that are one page.
- Talking about how to move the board forward over talking about what I or someone else did.
- Cross functional teams over specialized teams.
- All code is unit tested.
- Static code analysis tools are used to set code standards, all code must meet those standards.
- Any code that is done, is completely done. It is refactored, it is unit tested, it meets the quality standards.
- Code is never commented out. Anyone is allowed to delete any commented out code at any time.
- Determining code is meeting the quality standards must be done in an automated way.
- No one owns code, anyone can work on any code.
- Documentation is ONLY created when it will serve a known purpose and has an immediate value. (Code should document itself with good names and simple flow, unit tests document the low level requirements of the system. Automated tests document the behavior of the system.)
- Testing requirements come from the customer, not from the developer.
- Test driven development over writing unit tests after the code is done.
- Pair programming over working alone.
- Readable code over smaller sized code.
- Doing things right over doing things fast.
- Showing the customer over asking the customer.
- Impromptu discussions at white-boards over scheduled meetings.
- Building tools that will help make completing ten things faster, than completing one thing faster.
- Writing automated tests over manual testing
- Code is continuously built and integrated as soon as it is checked in.
- Builds build code, run unit tests, run quality checks, produce deployable bits.
- Builds fail if any unit test fails, or any quality check fails.
- Code is only deployed from the exact bits that were produced by the build machine.
- Code can be deployed to any environment with the push of a button.
- Production data never goes to any other environment.
- Developers can always run a local build which is the same as what will be built on the build server.
- Moving forward to fix problems over rolling back.
- Integrating soon over merging later.
- Quick builds over slow builds.
- Deploying on demand over deploying on a schedule.
That is my first crack at it. I have tried to keep the process as simple as possible, but still include as rules the things that I think are most important to be successful. I tried to keep the things that involved judgment calls as values. I believe this provides enough information to allow an organization to create a custom process that will work for them, but will still have enough controls to be consistent in the things that I feel make Agile practices valuable.
Let me know what you think or if you have any suggestions. I will update this post as this list evolves. I am sure there is something I missed or could state in a better way.
Like I said before, if you are doing some form of Kanban, you probably are already doing Kanbanand. If you are doing Scrum, your major change would be to drop the planning and instead try to get same sized stories while limiting your WIP.
Just make it work…
Basically, a fatlog is a Scrum backlog, or any Agile user story, that is too big and can be sliced vertically into thinner functions of the system.
I talked about the kinds of symptoms which might indicate a backlog is indeed a fatlog, but today I want to hone in on a special kind of fatlog that really only exists in maintenance mode.
I like to call this kind of fatlog the “just make it work” fatlog. It is kind of hard to describe what this fatlog looks like, but perhaps easier to describe one of the ways it comes to be.
Let’s say you have a major feature for your application. Some feature that you built over several backlogs, perhaps over several sprints. Some users start reporting a few bugs for that feature. This doesn’t work, it doesn’t work when I do this, etc. The business doesn’t really understand what the user is saying or doesn’t want to take the time to fully understand what is broken, they just know some of the parts of this feature are broken. So what do they do? Create a user story which describes all of the requirements of the entire feature and make it one single backlog.
What you end up with is a large backlog that really should be 10 or more backlogs, but is excused as one backlog, because “most of the stuff is working anyway.” The idea here is not so far fetched. The idea is that if most of it is working, the team should be able to identify which things are not working according to the requirements and fix just those things, and in the end the whole thing needs to work anyway, so they should make sure the complete feature works.
What is wrong with this?
It may seem like not that big of a deal, you can just estimate the backlog based on the parts you know are broken and the testing for the entire feature. There are a few problems with this line of thinking.
- What if one or more of the things you thought were working are not working? What if they are horribly broken?
- How will you know how to test the entire feature without the entire detailed requirements? If you think you’re just going to pull up the tests from back when you first implemented the feature, you had better check with your business first. Chances are their idea of the correctness of the feature has changed.
- How do you know where to start working? You will have to access what is broken first. This will mean that you must run all the regression tests to see what is broken. The only problem is if your original tests would have failed for the failures in the first place, you would have already known about it and fixed it the first time. You will have to write new tests to exploit the bugs that you don’t know about.
- If the business cannot tell you what is broken, how will they know when it is fixed? Your success criteria will be very interpretable. That is a recipe for failure.
Have you ever played one of those games where you try to figure out what is different between two almost identical pictures? Some of those pictures can be very difficult to spot the differences. It is a good thing they tell you how many wrong things you need to find. When you have a “just make it work” fatlog you have exactly that. Except you don’t have the count of how many things are wrong. You have to keep guessing and hope you got them all.
Here is the key point: a user story sizing should not be based on the size of the work, but rather the scope of the work. The difference may not seem like much, but it is huge.
Consider the difference between these two statements:
- Find the one 1 needle in all of the haystacks on the entire farm.
- Find 50 needles in the one haystack by the side of the barn.
The first statement is not much work, (just finding one needle), but the scope is huge. The second statement is much more work, (finding 50 needles), but the scope is much smaller.
Which statement do you think is likely to have more success?
One key thing each Scrum or Agile team should ask about each maintenance story they are going to take into an iteration is: can you tell me what is broken? If the business cannot tell you what is broken, but only lists a set of requirements of how something should work, you are going to be searching for a needle in an unknown number of haystacks. Instead, the backlog should be changed to either reflect exactly what is known to be broken, or be broken up into many smaller stories with smaller scopes.
How many times do we complete an agile user story or backlog item and end up with something like this?
Holes in the wall from where we changed the requirements 10 times during the sprint; picture is crooked because that is what the final requirement said; picture is not centered on the wall because we already put too many holes in the sheet rock there.
Let’s be honest here. If you hired someone to come to your house to hang a picture on your wall, and he ended up doing a job like the one above, you wouldn’t think it’s your fault. Neither do your users or your business people. They look for the guy with the cheesy grin holding the hammer.
From his perspective it makes sense. Before he even looked at your wall, he asked you to draw a picture of your living room. He asked you to give him the exact dimensions of the picture you wanted to be hung. He even asked you for the exact height and horizontal distance to hang the picture. You couldn’t provide him with any of those things, so instead you gave him the best description of your living room, the size of the painting and where to hang it. With that he did the best he could and hung the painting on the wall. You didn’t hear from him again until he was “done.” (Some strange person from his company even came by and did a bunch of measurements with a tape measure, checked the strength of the nail and a bunch of other tests, and finally also stated it was done.)
You take a look at the work. Nicely anchored to the wall, as level as possible, exactly in the wrong place. You quibble over the work for a bit. He pulls out his tape recorder and plays back your exact description of the site and how you wanted the picture hung. As he plays it back he points out how he did exactly what you asked. And he is right, sort of. What he did matches what you said, the only problem is what you said could be interpreted several ways. The way he interpreted it wasn’t what you intended; he should have asked more questions. As you look at the placement of the painting, you realize the original height, which he actually did get right, is not what you want anymore, now that you can see the painting on the wall.
You try again, trying to be more specific with your requirements this time. He asks a lot more questions, you have a hard time answering without seeing the project. Finally, after some time you agree on how it should be done, and he sets out to tear down the old painting and re-hang it again. You don’t hear from him again until it is “done.” The process repeats, more holes in the wall, more playing back your words. He’s honestly trying to do a good job, you’re honestly trying to tell him what you think you want, but it is hard upfront.
Finally, you end up with the picture above. Lots of holes in your wall and a crooked painting hung in the wrong place. It is not what you wanted, but rather than go through this process again, you decide you can “just make it work.”
Can you see the problem yet?
If you’re exclusively blaming either party here, you’re not looking hard enough.
The problem is, you would never hang a painting like this. If you were going to hire someone to hang a painting, you would stand there in the living room while they held the painting at various levels and locations against the wall. Someone listening nearby might hear:
“Higher, higher… ok now stop. Wait back lower again. How about a little to the left? Hmm, I don’t think it is quite straight. Ok, now it is. Yeah that looks good. Honey, what do you think?”
What about you?
So, how are you developing your backlog items or user stories? Are you doing them like the first example, where you are asking for all the requirements upfront and then building what you think the business person wanted? Or, are you doing like the second example where you are working with the customer as you build the solution, not putting nails in the wall until you know you have built what the user wanted?
As developers, especially if we have come from a waterfall background, we have the tendency to want to get all the requirements upfront. It is often difficult to figure out how to work with the customer to build the solution instead of simply gathering the requirements and then doing the work. There may also be barriers in your organization which prevent you from doing so.
Here are some tips to help get the customer involved:
- Co-locate. The best way to communicate is face to face. If you have to email, message, or call your business person or customer, you are adding overhead which makes it less likely to happen and more difficult.
- Keep the story about the business problem, not about the solution. This will force you to talk to the customer about the solution later.
- Don’t try to do one upfront design for the story. Instead have mini-design sessions as you go.
- As soon as you have something to show to the customer, show it to the customer, even if it is on your own development work-station, even if it is a picture you drew with a marker.
- Have the customer develop or co-develop the test cases with the team or person doing the testing. Developers should be building the thing that passes these test cases.
- Figure out who the real customer is. You may not be able to control this much, but sometimes the person pretending to be the customer isn’t the person who will actually use the product. If this is the case, you have to find a way to solve this problem or have a good representation of the real customer.