source | link

We see it all the time. (full disclosure: I'm developing a project management application). The problem is that agile methodologies introduce an inherent tension into traditionally managed organizations. Typically, upper managements wants to be able to plan ahead. They want 3-year plans; they want properly estimated projects; they want to be able to budget hiring new people; they want to be able to commit to significant milestones when it comes to partners/customers.

But then the R&D department decides it's going to go agile. It's no longer about planning ahead for two months before writing code. Sprints are going to be short and beyond sprints you get very low-resolution estimates of the stuff that's in the backlog/roadmap. R&D realizes that requirements change way too frequently for classic waterfall to be effective, but product managers want a clear, thought-out and well budgeted vision of what the product will look like in 12 months.

The problem, then, is to reconcile the two. As I said, we see this all the time happening with our customers. Our solution is thus to unify the tools used to do both sprints and long-term planning. Okay, now here comes the part of the shameless plug, so feel free to take it with a grain of salt. One of our unique features is that we use a zoomable-user-interface for managing tasks. Meaning it's very easy to drill down into some user-story/task and elaborate on it. (you can see how it looks here). There's actually no concept of a "project" in our system at all. It's all tasks containing other tasks, linking to other tasks (a fractal, really). This creates a nice blur between user-stories, tasks, projects, epics, etc.

In practice, what many of our users who practice agile methodologies do, is create a telescopic plan that merges the long-term road map (or backlog) with managing the short term sprints (or iterations). Managers still get to see a nice, estimated road-map of major features waiting to be added, and developers simply zoom in more deeply and deal with actual work tasks. One advantage this has is that it reduces the amount of "haggling" that takes place when managers review the work-plan. Instead of the development team providing only very rough estimates (i.e. "4-6 weeks!"), they get a chance to zoom into each user-story in question and break it down to smaller chunks. When you do that there's suddenly less room for haggling. You spend 10 minute breaking down a 5 week user-story into chunks that are about 1-day in size, and all of the sudden the argument isn't "no, you can do it faster. no we can't. yes you can." but "here's what goes into this effort, including all the hidden work the initial estimate didn't consider. What do you suggest we eliminate? Quality assurance? Testing? Training the new guy? Setting up the build environment?".

This approach works as long as you're using a tool that lets you change plans as quickly as you initially draft them. Which is the real reason people these days detest waterfall. Most systems make it exceedingly hard to completely redo existing plans and people are very rationally refusing to waste time on this activity.

Okay, I feel like this is turning into a sales pitch, so I'll stop now. :)

    Post Made Community Wiki by Assaf Lavie