This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi, I was wondering if your book addressed the difficulties and strategies for scheduling software development for an agile team. I'm relatively new to industry (been out of school only about 2.5 years) and I really only work on the development side, not the project management side. I'm on an agile team, and I'm really interested in techniques for how much scheduling you can actually do for a huge piece of software up front and how much is done ad hoc. Thanks.
We devote an entire chapter to planning-related practices, 70 pages, and cover the material thoroughly.
There are a lot of different components to scheduling. First, you have a choice between "scopeboxed" schedules or "timeboxed" schedules. Scopeboxed schedules release when all of the planned features are complete, adjusting the release date to match. Timeboxed schedules release on a particular date, adjusting features to fit.
We recommend timeboxed schedules in the book for two reasons. First, they're a lot less risky. Second, they force you to make hard tradeoff decisions. These decisions are a good way of weeding out the less valuable requirements that invariably get added to any software project. You only ship the most valuable software, and you do it on a specific, predictable date.
So in a way, scheduling is easy in the agile world. Pick a date. Ship your software on that date. Done.
Okay, it's not quite that easy.
To make this work, you have to develop software in such a way that it's always technically ready to release. (Our "Releasing" and "Developing" chapters talk about this topic.) Many people develop software by technology: they develop the database layer for all of the features, then the UI layer, then the business layer, and so forth. This means that the software can't be released until all of the layers and all of the features are done.
Agile methods develop by feature: they develop the database, UI, and business layer for one feature, then for another, and so forth. This is a little harder technically but it means that the software can be released after each feature. Most agile methods work in iterations that are one to four weeks long. They are also timeboxed: in an XP project, for example, you are always finished and ready to release on, say, Wednesday morning.
Now, technically ready to release on Wednesday morning doesn't mean that you'll actually release. The other component to this is managing your priorities so that when your release date comes you have something worth shipping.
There are several aspects to this planning effort. First, you have to have a good overall understanding of what you're building, why it's valuable, and what success means for your project. Our "Vision" practice addresses this need.
Second, you need to determine what the "minimum marketable features" of your product are. A minimum marketable feature (MMF) is something that has value to the marketplace. The "marketplace" can be paying customers or internal users depending on what kind of software you're developing, but either way, an MMF provides value. MMFs are also small ("minimal"), which is important, because small features are easier to finish quickly, which reduces the risk that you'll throw away partially-done work on the ship date.
MMFs in turn are broken down into stories, which are bits of MMFs that represent recognizable progress to your business experts... the people XP calls "on-site customers". It's important that stories be customer-valued because that's how you demonstrate progress that everybody can understand.
Stories can be estimated extremely accurately. Well, sort of. This is actually a simplification. The estimates are not at all accurate, but when combined with slack and velocity, they lead to very consistent and predictable iteration schedules.
So a naive approach would be to identify your vision, brainstorm MMFs and stories, estimate them all, and build a schedule based on those estimates. In a perfect world, that schedule would be accurate.
I'm tempted to leave it at that, but in fact it's not that simple. Reality is messy. First, even if you did brainstorm all of those MMFs and stories--and you shouldn't (see below)--your consistent iteration schedule won't always come true. People get sick, there are unexpected events that disrupt your work, and so on. These risks reduce the amount of work you can finish before the deadline. We have a section on risk management that tells you how to predict schedules in the face of risks. We provide some simple arithmetic that will give you probability curve for how much work you'll get done. In other words, you'll have a 10% chance of getting X amount of work done, 50% chance of getting Y amount done, and 90% chance of getting Z done.
With these numbers, you can then say: "We will ship on this date no matter what. On that date, we will almost certainly have Z features done. We will try to get Y features done, but it's a stretch. It's almost impossible for us to have more than X features done." Then you actually do ship exactly on your ship date and you nearly always have features done in the range that you promised. And, as each iteration completes, you get more information that tightens and improves your predictions.
This is already far beyond what you see in most projects, but it's still rather simplistic. The big problem with everything I've told you so far is that it's static. It assumes that your plan is made at the beginning of the project and never changes. But in fact, your initial plan is your worst plan, because it's made at the point when you have the least information about how people will react to your software. You can add a lot more value if you change your plan as you learn new things.
One of the big advantages of agile development is that it allows you to change your plan. This leads to a technique called "adaptive planning" that is very cool, but I don't have time to go into right now. The nutshell version is that you actually seek out opportunities to learn new things and take your plan in unexpected directions. You do this because it allows you to increase the value of your software. For example, when my wife and I traveled to Europe a few years ago, we used adaptive planning. When we were in Italy, we discovered that our plan to go to Turkey would take too long, so we went to Prague and Switzerland instead and had some of our most memorable experiences. We increased the value of our trip because we weren't locked into an up-front plan.
There's much, much more to this, including a technique of tiering your planning horizons to reduce planning costs, but you'll have to refer to the book for the details.
James Shore, coauthor of <a href="http://www.amazon.com/Art-Agile-Development-James-Shore/dp/0596527675" target="_blank" rel="nofollow">The Art of Agile Development</a>. Website and blog at <a href="http://www.jamesshore.com" target="_blank" rel="nofollow">http://www.jamesshore.com</A> .
I don't understand what these small releases represent. Customers usually want the full working application. I thought that customers don't want to hear about MMF. If we consider a new Swing application, do you mean that you may release a login screen first, then another screen ? In your 70 pages explanation, do you show what MMF could concretely be ?
Yes, there's quite a bit of strategy behind release planning and we devote 12 pages to that topic alone. I have to go to bed (and this is my last day here, sorry) but briefly you don't release until you have enough to make the release valuable. Doing that is a matter of focusing on what makes your software most valuable. For example, a word processor seems like the type of product that couldn't possibly deliver in small releases. It would take years of work before it could even achieve parity with Microsoft Word, let alone compete with it.
Yet Writely (the online word processor) shipped their first version in two weeks and was acquired by Google ten months later, forming the basis for Google Docs. They did this by focusing on what set them apart (online collaboration, simplicity, instant access from any computer) rather than on achieving feature parity. [ November 02, 2007: Message edited by: James Shore ]
Joined: Apr 07, 2007
Thanks so much for such a detailed reply and I look forward to reading the book! Thanks again.
Originally posted by Christophe Verre: If we consider a new Swing application, do you mean that you may release a login screen first, then another screen?
I doubt that a login screen would come early. It's probably not what provides the most business value to your users, is it?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus