Experienced agile practitioners probably all know that process goes first, and tool goes next. This principle is vital for the teams that are just starting out with agile adoption. They might grab a PM tool thinking that it’s all they need to keep their newly born “agility”. If that’s the case with your company, read this memo:
Once an agile team has matured, and come up with their custom dev process, there comes a time for another major checkpoint:
Copy-paste your process as is to a project management tool
Surprisingly, quite many teams neglect this step, and I want to write about its implications, and why it’s so important.
Here’s an example of the task at hand if you want to replicate the process of 2 teams working on one project. You can consider this as a brain teaser, instead of a sudoku puzzle, and see if you can copy-paste this to the project management tool that you’re using.
That’s the whole point. If the process is reproduced accurately in the tool, you can use it as a full-gear device not only for tracking and reporting, but for making sensible corrections. If not, the reports and data make no sense, as well as the retrospective analysis, and you’re unable to make good decisions to correct what’s wrong. An extreme case would be if there’s a dichotomy, and the tool is used for the “deluxe” version, while the real dev process is different. That’s an extreme case, but it might happen in some teams, if they’re compelled to use a tool that their management has chosen for them, and the tool does not do what is really needed. It’s the same as when people buy new furniture. You’ve got your lifestyle habits, and if you decide that you’re buying this table because now you will sit and work there, while you still prefer to work on a cozy couch, this would only mean that this new table will get all dusty, and you will end up not knowing what to do with it. You need to fit a piece of furniture to your lifestyle, not the other way around. Buying a table and tying yourself to it would not improve your creative flow and your work experience. You’d still find it uncomfortable. This looks simple but surprisingly people do such things not only with tables, but with project management tools, too.
The third checkpoint is: replicate any changes that you make to your dev process in the tool, and do this when the time is right. I will outline several meta-principles for any changes of that kind:
1. Set clear boundaries between Backlog and Work In Progress. Yes, it might be hard at times, as the concept of backlog is blurred in software development, due to its very nature. Decide about the thresholds, maybe it’s a ready specification, a kick-start meeting, a meeting with stakeholders. Find this exact ridge where a backlog item becomes a WIP item. This is even more important if we leverage this principle against the general “limit work in progress” guideline of a flow-based process. Obviously, outlining clear thresholds would save you from the pumped up WIP. As an example, sometimes bugs would retreat back to the backlog, while they’re nothing else than stale work in progress OR a part of user stories that are considered Done:
2. Outline all possible transitions for your Work In Progress states in your project management tool. Identify which state can follow which, which state is final, who is allowed to switch states.
3. Set clear boundaries between Work In Progress and Done. This meta-principle transcends to many rules that any team can define for their particular needs and preferences. If there’s a slightest implication that something that is “not done” sneaks to done, this will mess up the reporting and corrections.
Finally, you need to know the right time to adjust the process, and its replica in the tool. If a team decides to update the process in the middle of a release, they won’t get a good coverage. Setting up the times for the dumps from real process to go to the tool is important. Like, after a major release. Or at any other point that makes sense to this team. You might even want to assign a Process Police role for that one :) Seriously, someone has to take on this responsibility, and the easier it is to set any possible boundaries and state transitions in the tool— the better. That’s something I’ve covered in the post The Paradigm of Project Management Tools.
Summing up, there would be 3 checkpoints in this cycle:
1. Process first, tool next.
2. Replicate your dev process in an agile project management tool
3. Make corrections to the replica.
(Repeat as needed.)