We live in an economy and in a world where organizations are challenged to do the same amount of work (frequently MORE work) with fewer people. Frankly, in the United States and Europe, if we don't quickly learn how to succeed with fewer people than we had a few years ago, we won't be able to compete in a growing technology labor market where labor costs are substantially lower.
We must learn how to do two things.
- Do it right - We have to learn how to create high quality software without first sending our software to our customers to tell us if we got it right (both in terms of functionality and defects).
- Don't waste time - We MUST learn how to stop wasting time on activities that do not support solid business decision making and do not contribute to the previous item.
I spend a lot of time traveling to locations around the world, teaching Agile Development and coaching organizations to use Agile Development. In pretty much all cases, I find myself confronted with attitudes and beliefs that are ensuring that "Do it right" doesn't happen and "Don't waste time" can't happen. As there are many examples of articles that discuss "Do it right," in this article, we'll focus this article on "Don't waste time."
Time wasters are amazingly prevalent in the "modern" IT organization. You can find them anywhere, all you have to do is look around a little. Here is an example of what I mean:
Release Planning is one of those potential valuable events frequently overburdened with time wasters that can be easily disguised as a beneficial activity. When done properly, release planning can be beneficial. But usually, it isn't done properly. Release planning, more often then not, is done as an exercise that runs counter to everything that Agile Development is about. Here's an example of the wrong way to do release planning.
ACME software has just completed it's release planning cycle for Version 3 of it's iACME software (why not? Everyone else uses "i" before their software to make it cool these days!). The release is scheduled for twenty-eight two week Sprints. The entire release backlog has been identified and prioritized and the release plan has been built showing what will probably be built during all of the 28 Sprints. The Scrum teams' performance will be based on their ability to deliver the content of the release backlog. The next release planning meeting is scheduled for twelve months from now, two months before the current release will be finished, in order to plan the next release.
Now, some might be looking at this and thinking that I just created the worst case situation in order to make a point. A LOT OF ORGANIZATIONS plan EXACTLY like this!!! And some of you might have finished reading the example and are thinking, "OK. So what's wrong with this!" Well, let's review...
- The release is scheduled for 28 2-week Sprints - If you want to run a thirteen or fourteen month release, go for it. But ask yourself this question -- "Do you and your customer know what they need in the product so well that you can plan it out in detail for the next year or more?" In reality, the more we try to plan into a release, the less right we are going to be. Regulatory changes occur, market shifts occur, economic changes force content changes, and technology changes as we go too. By planning for large releases, we are INCREASING product risk and development costs, not decreasing them. Plan for shorter cycles -- you don't have to ship every release.
- The release plan has been built showing what will probably be built during all of the 28 Sprints - here's another problem. It is rare indeed that our ability to plan the development of a complex product can withstand the uncertainty of 28 Sprints, much less 1 Sprint, and not change or grow. Stuff happens during a development project. Technology changes, defects are discovered, operating systems behave in unexpected and unwanted ways. When this happens we have to adapt. Frequently, adaptation leads to adding content (to change unwanted behaviors) or adding more time (because it takes longer to get something to perform than we expected). This means that, unless we're going to be willing to just add Sprints to the end of the project until we get everything done (which, hey, maybe you can do that), we're going to be delivering bad news about release content pretty much from the end of the first sprint to the end of the project.
- The Scrum team's performance will be based on their ability to deliver the content of the release backlog - Holding the teams accountable that nothing in the release backlog will change is kind of like asking them to reverse the effects of gravity or slow down time. It's not going to happen. They don't have that kind of control over the environment around them. When teams are measured in this way, we engage in a couple time-honored time-wasters: first, the team spends extra time trying to make things look like everything's OK ("cooking the books"); second, we spend more time writing status reports and updating Excel spreadsheets trying to convince everyone that everything is OK ("greenshifting"); third, we spend even more time trying to figure out why everything isn't OK and who's responsible for it ("the witchhunt"). This is what I call "dysfunctional."
- The next release planning meeting is scheduled for twelve months from now, two months before the current release will be finished, in order to plan the next release - The problem here is that the next release planning meeting should be at the end of the first Sprint and another should occur at the end of every Sprint in the release. The two things we can count on in software development is that 1) our plans aren't perfect and that 2) they WILL change. There's enough variability in software development that no plan survives the first couple days of the Sprint. Viewing content change as something to be controlled and minimized is simply saying that the plan cannot possibility be improved -- and that's just wrong. No matter who you are, what market you work in, or what product you're building -- there's always room for improvement in your release planning.
So, what should we be doing instead? Let's try this example instead...
ACME software has just completed release planning for Version 3 of it's iACME software. The release plan is detailed for the next two or three Sprints but is pretty much high level stuff for the rest of the release. The iACME Product Owner worked with many people in the organization (sales, marketing, regulatory, management, etc) to create the prioritization of the backlog; he checks back with those personnel on a regular basis to learn more. Each release of software is planned for eight two-week Sprints. At the end of each Sprint, the plan is re-evaluated and updated based on what the organization has learned by building the software, by showing features to customers and stakeholders, and by analyzing market trends. Short term (high-priority) changes are worked immediately into the current release plan. Other changes are added to the planning for the next two or three release cycles. As each release is finished, the product needn't be delivered to a customer, but is considered DONE if it is at the same level of quality as if ACME WAS planning to ship the product.
In this example, ACME builds the iACME product in short, two month release cycles. Not every release has to be shipped to a customer, but every release must be potentially shippable, regardless. Short release cycles reduce risk and, therefore, cost. ACME also has learned that the release plan is a good long-range prioritization tool (for managing product development over many months), but that the plan is subject to constant change as we learn more and more about the product, the market, and the technology. ACME can still use the release plan to say, "Here's where we're going and here's what we think it's going to cost," but they haven't decided that change is bad. They haven't decided that the plan can't be improved or that changes to the plan are the result of mistakes as opposed to changes being the result of learning more about what they are doing.
Release management in an Agile environment is about accepting the fact that the further we try to predict what's going to happen, the more wrong we are going to be. Building a plan without understanding and accepting that the plan will change compounds risk and, as a result, cost. To truly embrace release planning in an Agile environment, one must be willing to accept that priorities, features, and customers change and that frequently those changes lead to a better product in the end. Stop wasting your time trying to be a perfect planner and get busy writing software!
We'll examine more time wasters in future posts.