The seeds that you plant at the beginning of an organization’s life influences how the organization grows over time.
I think it’s safe to say that you have some macro goals:
- Predictability: you as managers want to predict what will happen and when it will happen
- Flexibility: you want to be nimble to satisfy customers and close sales
- Open Communications: you guys want to have good, open, honest communications with the team, especially when the situation is suboptimal
It’s been my experience that agile achieves the above goals, even though it might not seem that way.
Waterfall, lots of up-front type of methodology is not agile and will ultimately result in falling short of the above stated goals, despite that having a long-term plan seems to jibe with predictability.
So, when I say ‘agile’, I mean the following:
- The team works towards periodic goals. The period is the same every time and is relatively short: 1-3 weeks… an Iteration.
- All tasks are placed in a central ‘backlog’ and prioritized in that backlog. Simple tasks are called stories and complex tasks are called epics. Any story that cannot be completed in an iteration is an epic and before it is started, an epic must be broken into sub-stories. Anything that’s going to consume time is a story and that can include ‘be available for customer support requests’, ‘partnership calls’ and ‘take a few days off over Christmas.’
- Backlog re-prioritization can happen any time.
- Each story is assigned a point value agreed to by the team. I have found that point values based on the Fibonacci series are most effective.
- At the beginning of an iteration, each team member signs up to complete certain stories and also identifies certain stories as stretch goals (they’re not guarantying that they’ll complete the stretch goals).
- Periodically through the iteration, we have short ‘stand up’ meetings (I’d recommend twice a week) where people each talk about ‘what they did since the last meeting, what they plan to do between now and the next stand-up, and any blocking issues’ No more than 60 seconds per person. These low impact touch-points help keep the team aligned.
- At the end of the iteration, each person demos what they completed so the whole team keeps in touch with what’s going on and so that we can celebrate each team member’s accomplishments.
- Points for completed tasks are put into a spreadsheet.
It’s pretty obvious that the above methodology leads to flexibility. There’s no more than 1 iteration needed to change direction based on a reprioritized backlog.
What is less obvious is that it also leads to better predictability. Having the short iterations means that people can do a better job of predicting how hard a 2 or 3 week task is going to be and if they can complete it or if it needs to be broken down into sub-tasks. So, on a per-iteration basis, you have immediate predictability. But, the benefit that you get is that over 3 or 4 iterations, you’ll get a very good and stable ‘point consumption’ model for the team as a whole and for each team member. This point consumption model leads to very accurate predictions. You’ll find that stories (less so epics) are accurately priced and that each team member has a narrow band of points they deliver, consistently, iteration after iteration.
What is even less obvious is how agile leads to much better communications. In the traditional waterfall model, there are always slips. Slips lead to ass covering and blame and a whole lot of other ‘I don’t trust my team members, so I’m going to communicate in a way that could cause me the least pain.’ The bad and common case scenario and one I’ve seen over and over is the 3 month project that slips a month or two within weeks of the due date. By the time that happens, everybody is stressy and cranky (unlike the beginning phase of the project where you guys have money in the bank, prospects, and a motivated team… a phase where nothing seems impossible.) In an agile process, the folks who sign up for a task and don’t deliver it by the end of the iteration are not punished. What happens is that if it’s a repeated event, as managers, we can simply say, ‘Joe, you are signing up for 45 points this iteration, but you’ve historically consumed/delivered 30 points per iteration, how about signing up for 30 points and making the balance as stretch goals?’ Although consistant underperformers should be removed from the team.
Another benefit of this approach is that all code and all ideas are open to improvement. This means that people are more likely to say, ‘I was wrong about that, let’s improve it,’ ‘I’m glad you improved on my code,’ and other things that leverage the skills of all the team members.
But, you say, ‘what’s the architecture look like?’ I say, ‘who cares?’ Keep in mind that this is my attitude towards Lift. There are a couple of touchstone concepts in Lift (e.g., security, abstracting away the HTTP request response cycle), but by and large it’s grown based on user feedback. Whatever architecture we come up with today is going to be wrong, broken or so broad that it’ll be outdated in 4-6 months. On the other hand, if we grow the product organically and make sure we’re willing to throw away pieces that no longer fit, we can keep satisfying customer demand as well as learning from the mistakes we’ve made along the way. Note that no matter what direction we choose, we’ll make mistakes. In a waterfall model, we are encouraged to conceal our mistakes where as in an agile model, we are encouraged to acknowledge mistakes and fix them as interation tasks.
It will take a few iterations to get the rhythm of the process, but it’s been my experience that once the rhythm is there, management and sales gets predictability and flexibility and the whole team gets open communication.
Reference: My thoughts on Agile from our JCG partner David Pollak at the Good Stuff blog.
