Agile Planning

Getting more agile:

In a word, agile methodologies are about acknowledging at the most inner level that change happens: http://agilemanifesto.org/ and http://www.AgileManifesto.org/principles.html

Agile methodologies still need planning. After all, I doubt that many commercial software projects are started without at least a partial visibility on the budget and the scope involved. They need a vision, a goal to reach for and the steps to get there in order to convince.

These methodologies welcome and favor change and their practitioners are not afraid to modify plans if needed. The tendency is to keep things simple and manageable, keep the team happy and focused for undetermined periods of time and minimize risk on quality through constant releases. Stakeholders are informed about what happens in the project by directly experiencing the results, rather than getting through tons of reports. Yet still reports and accompanying documentation may be needed for proper understanding, but the focus is on the product.

In a sense, the planning methodology described in a previous post has agile traits. Early planning is kept to a minimum, refinement is achieved throughout the course of the project, flexibility in terms of vision and features exist. It's just that we need to go beyond that and add new elements to get where we want: high quality within budget and a happy, proud team.

Improving processes and optimizing workspace:

First of all, let's start by ripping off the authoritative aura of the traditional manager, making him part of the team and adding him a new role: that of the facilitator. His/her goal when acting in this role is to find creative ways to improve team performance by removing obstacles and clearing the path ahead. Let's quote from the agile manifesto:

"At regular intervals, the team reflects on how 

to become more effective, then tunes and adjusts 

its behaviour accordingly"

Then, let's add some means to find out what the blockers are: the best I could find (yes, it was not my idea;) ) is to have a daily 10-15 minutes meeting to find out what the current problems are and have people discover if the problem is local to them or more common. The purpose of this meeting is to create an urgencies agenda for the day:

• Action plan for the manager
• Find out who has encountered the problem before, if any, and gather some quick suggestions
• Schedule more detailed meetings with people that manifest interest in the problem, after this meeting completes
• Celebrate success when the project advances
• Update the plan - where we are, where we are going

Software development and management are continuous, iterative processes of self improvement. While the goal for the agenda is noble and visibly useful (and fun), the actual meeting may not succeed from the first. It is important to keep the goals in mind, have patience and iterate. At first, it may become boring or too long but, as experience grows, it should get more and more successful and to the point. Just like anything else, the process is under continuous scrutiny by the team and suggestions for improvement should be made and always taken into consideration.

A second meeting should be considered; a longer meeting this time, one hour for instance, scheduled once a week or two, to discuss how we can improve and streamline our activity on a more macro level. While the daily meeting usually touches hot subjects, blockers that have just appeared, the longer meeting should take the form of a coaching or a brainstorming session, where more subtle issues can be discovered and action plans are laid to overcome them. Ideally, this meeting should be lead by a more experienced person or set up at first under less stressful periods so the people will be more eager to iterate.

Quality enforcement:

The second level of transition from the normal waterfall method to agile should be the quality enforcement. We need this because, in order to gain approval, we need success stories fast. We need a build that gets visibly better. People should feel first hand that something has changed such that, instead of focusing on putting features in as fast as possible, we now shift our attention to details, quality and, thus, self-esteem:

• Bugs have a higher priority than features.
• Quality is enforced early through smoke testing (daily builds) and code review. Additionally, the dev tester should be called in to verify the feature before check-in as, if the daily build fails, this is a dramatic event - part of the team may not work!

To have this, we need two prerequisites:
• A working pipeline and a daily build process that is checked continuously.
• Visibility, like play the version once a week, an hour, in an organized manner, with an emphasis on new developments.

The most important aspect of development is to keep the version clean and working smooth. This has higher priority than anything else and all the team should focus on this and find ways to improve and secure the daily build.

Planning in a more agile way:

Planning is a little bit more tricky because it has to deal with uncertainty. I think it should have three levels:

1. Macro level should contain top level components, with allocated times and budgets. Unlike imperative planning, where tasks are assigned and fixed, this level is maintained as a general baseline, a guideline for communication and for risk estimation.

2. Second level is created by adding user stories. User stories are the requirements. Their scope ranges from "the game should have a crew management system with an interface" (along with a rough estimation) to "when the player clicks on the crew icon, it should change colors". These user stories should have a time estimate (given by team) and value (given by the requirement owner) and they become more and more detailed over time, as implementation moves forward. They can be changed or deleted easily.

3. Refinement is done by the team, in a planning meeting, before the iteration begins. The team chooses what to do in the iteration based on the value and the dependencies of each user story. Then, each story is split into tasks.

Agile planning should be an on-going, forward looking process. User stories should be detailed ahead of the iteration so that, when iteration begins, the team knows exactly what they can commit to. Important: 1st step to develop a team: make everyone stick to their commitments fully, no matter how small they are. This increases self-awareness and self-pride.