I’ve recently been in a series of conversations with CTO’s and the topic of how to manage Agile development within large project teams keeps coming up. The central issue seems to be that sprinting (an agile term for a one week planning cycle) doesn’t lead to longer term thinking. This is exactly what the Agile community wants, since most long term thinking ends up being pointless as the domain isn’t well enough understood, and the market changes. Agile was initially designed by practitioners working on custom software development. There really was one “client” and that client was highly invested in the outcome. Thus, co-creation was entirely possible, and absolutely warranted. Now that Agile has become an almost subconscious choice for much development, it is being applied well beyond that initial frame of custom development. The struggles that I am hearing from CTOs center around:
Refactoring: We end up refactoring in a major way, a lot of the time, where we actually knew about the requirements when we initially did the development.
Burn out: Teams can only sprint for so long, before they start to wonder where they are sprinting to.
Strategic Planning: My teams are loath to commit to any longer term plan, as they trust only the Agile process, and don’t believe in roadmaps that go out more than a month.
Management Visibility: I can’t deliver to management what they really need - a framework to plan around - without undermining my team’s process. I hate committing without bottom up estimates, yet I acknowledge the X factor that Agile handles well.
The litany above points to a central issue, that Agile doesn’t inherently address longer term planning and roadmapping, and often leads to a polarization between THE TEAM and THEM (management).
I wanted to share a principle that we discovered turning around Visual C++:
Milestones are about the “spirit” not the “letter”.
The letter of a milestone is the plan of record, usually a precise feature list and accompanying schedule estimates. The spirit is the actual meaningful change in the user’s experience. Teams that try to get the letter right end up in the trap of driving themselves crazy trying to live up to the foolish, uneducated promises of their former selves. This means overwork, mistargetting, disappointments, and an increasingly incoherent product. They also slip - a lot. Teams that focus on the spirit are more successful. By focusing on the desired impact, rather than the chosen features, the team takes every missed estimate or new issue as an opportunity to be creative about how to achieve the spirit, without slipping the milestone. Features get scaled back, cut, or replaced, and the team constantly reconnects to the initial intent. There’s a lot of subtlety to getting the spirit right, and communicating it to the team the right way. For example, if we’re working on a todo list manager for mobile phones, we could state the first milestone as:
Item creation, management and deletion. Sending reminders through email and/or social network of choice. Registration, login, authentication. Screens to support single list workflow on each native platform.
This is a “letter” definition. It’s really a long inclusive feature list. There’s no wiggle room once we realize that we haven’t factored in Facebook Connect and OpenID, or don’t have anyone who knows anything about Symbian. Instead, we could define it as
Get started, get reminded.
There is plenty to be inferred here, but there are many ways to achieve the spirit without getting hung up. The exhaustive feature list still exists, but now we can use the spirit to define backlog priorities for the team to do an incrementally better job of getting started and getting reminded. The biggest advantage is that consumers of the roadmap know what they will be able to do (get started, and get reminded) but not how (through email and/or social network of choice). That means that when MySpace tanks halfway into our milestone, and we decide that Facebook is all that matters, we don’t have to backpedal with anyone. The spirit enables the team to be righter every day, where the letter almost ensures that they are very wrong as the milestone date approaches. The disadvantage of the letter based approach is that the team ends up being either late, wrong, or both. The spirit gives enough guidance on what will be achieved, but gives the team the ability to make the right calls and cuts to deliver on time, and on (more abstractly defined) target. Management can plan. Developers can deliver. Product Management can relax. Spinning this out, five milestones on the way to a todo list app might look like:
Get started, get reminded
Share tasks with friends and teammates
Organize teamwork
Integrate with calendars
Mobile and in-sync
At each step of the way, I’ve got a full featured, working, complete product, which even the dumbest Director or CEO can understand (“Can I assign tasks to others?” “Not till milestone 3”, “Does it work with my Google Calendar?” “Not till milestone 4”). Even better, questions that shouldn’t be answered now (“Can I make lists of lists?”) aren’t (“As of milestone 3, you’ll be able to organize the work of a whole team, how exactly that manifests as features will be figure out as we get closer to that milestone”). And when milestone 3 comes along, the PM can be reasonably sure that the team will actually deliver something better than what the dumb Director would have expected from “lists of lists”.