Setting priorities

In Agile development, milestones are typically 2 -3 weeks long and are called sprints.


Before each sprint, the team gets together and decide what needs to be done. Typically, the Product Manager will have a backlog of tasks from which to choose from.


Obviously, urgent tasks that will make a noticeable difference to income, traffic or user experience will get priority.


However, less-important tasks also need some attention, otherwise they will never be done.


The date at which a task was first presented to the sprint-prioritization meeting should be noted. If a task has been presented 3 or 4 times and is still in the queue, then a decision needs to be made:
Either do the task in the coming sprint, or delete the task.
If a task is simply being mentioned for old times sake, and everybody would like to do it but nobody has the time, and nobody can see the urgency, then it is simply taking up time in the prioritization meeting.


Since we live in a dynamic world, not every task can be planned 2 - 3 weeks in advance. That is why a typical Kanban board has more lanes:

1. Emergencies and Showstoppers. 
• Either the live system has become unstable (e.g. web site down,under attack or slow) or a 3rd party wants something urgently (e.g. a tracking code is being changed, a seasonal ad campaign was suddenly signed)
• This is not to be used for VIPs to push their pet projects; those have to be approved at the prioritization meeting.
  
2. Legacy bugs
1. For bugs that are found in code that has already been released. If these are added to a sprint, then eventually no new work can be done in sprints as all available time will be used for legacy bugs. Therefore, legacy bugs need to be taken care of in parallel to the sprints.
3. Maintenance
• Time needs to be allocated for maintenance of systems without becoming the man focus of the team, similar to the philosophy of legacy bugs.

These 3 types of incidences need to be attended to without affecting the sprint's schedule. With experience, a Project Manager will become adept at predicting the unpredictable and will know how much slack to add into the schedule.

Once a team has agreed to its upcoming sprint, an atmosphere should be created  to ensure that the team can focus on its sprint, and realizes that it is expected to meet its commitments, come what may.

This is easier to enforce if the major players involved are in attendance at the prioritization meeting, and they they each have a say in defining the sprint.

If management are in the habit of interrupting sprints with special demands, then they should also be present at the meeting, so that they can later be confronted with "But you agreed to the scope at the meeting. Please keep this for the next sprint."

Stop starting. Start finishing.

When we started using the Agile development concepts at Answers.com, we started by putting up a Kanban board.


We then created a post-it note for each active project.


Result? The board was not big enough and the concept of Kanban looked overwhelming. How were we supposed to track this many projects?


That's when we took the drastic step of stopping many of the projects we we re working on. We implemented the "Stop starting; Start finishing" philosophy.


Initially it was counter intuitive: We were trying to get more done by doing less?


Yes. That was the game plan - and it worked!


Instead of thrashing between multiple projects, each team was focused on a single project or milestone. More than that: we stopped using each team to its full capacity!


What? You had people do nothing?


No. Never. Worst case scenario, the spare people would take care of things link technical debt; those little annoying things that really should be done but nobody gets around to them.


Most of the time these spare people were taking care of emergencies and other rush jobs that had to be done immediately, if the company was to survive. They could also step in to replace a team member who is absent, or do pair-programming on difficult issues.


What happened? Since the teams were now focused on a single task, and didn't have to spend time deciding which project was more important, and since they were not distracted by "emergencies", they started delivering in record time.


They were now often able to deliver in 2-week increments, including testing. Previously they were delivering in 2-month increments with many weeks of testing and integration issues before the project could actually be delivered.


So the fewer things that were started, the faster they get finished. Throughout goes up, as well as team morale.


It takes while for management to get used to the idea that a pet project is waiting for a slot. But they eventually understand that once that slot is found, their project will be finished in record timing.


But don't they classify their projects as emergencies? In a future post we'll discuss what are emergencies and what gets to jump the queue.


Lesson learned: Do one thing at a time, and do it well. 


- Danny Schoemann

Scrum: Rugby or Project Management?

A scrum in rugby is a is a way of restarting the game and pits the 2 teams against each other in close proximity. It's one of the less gentlemanly parts of the game.

In Agile software development, a scrum is a daily meeting to sycn up all teams - similar to what I described in a previous post titled: Sync up in 15 minutes: The daily stand-up

The agenda of the daily scrum is always:

• What has the team done since yesterday?
• What is the team planning to do today?
• Does the team have any problems that would prevent it from accomplishing its goal? 

The scrum is run by the Scrum Master - who is often also the Project Manager - and, as expected, it is the role of the Scrum Master to be in charge of finding solutions to any impediments that arise.

The reason I keep away from the term scrum is because of its rugby definitions.

• The daily meetings do not restart anything; most healthy projects do not time-out every 24 hours.
• The daily meetings don't pit the teams against each other. 
• I prefer to think of projects as being made up of people who work together to a common goal,  as opposed to the various members of a project seeing themselves as being on opposing teams.
• The word scrum has violent undertones, which are wholly inappropriate to software projects.
• The British also use scrum as A disordered or confused situation involving a number of people - which should not be the case in a well run project, except - maybe - when the concept of scrum is being introduced for the first time.
  

Therefore I prefer that my 15-minute daily stand-ups not be called scrums.

- Danny Schoemann