No, I don’t hate agile project management software — it can serve a purpose. At issue is if there is an actual purpose and if it is misused. Often the software stalls progress or worse, move us backwards. For any readers who are not familiar with agile or don’t work in software — the idea here is that instead of using the monitor to display some type of software tracking tool, the new scrum master just used sticky-notes and stuck them on the monitor. What is the simplest thing that works in your world? Note that I am using the term ‘agile project management software’, many companies use other terms to describe their software, focusing on products instead of projects or on life-cycle management.
Tweet the Agile Safari Cartoon!
The most common reason I hear for using agile project management software is because teams are dispersed. Some seem to take the extreme position that if you have a dispersed team(s), you are stupid. The funny thing about that opinion, is that it bumps up against work-life balance. What I know is that we do have people who are not working in the physical office, due to child related things, appointments, weather, travel, traffic, or actually not living near the office. I recently worked on a team where we had people in 4-6 countries depending on the week. Some would again argue that we should not have worked that way. The situation does exist — although any person might decide they do not want to work with an organization that has dispersed people. Any organization that chooses to have dispersed teams will have a cost associated with that choice. That cost will vary, depending on the people and organization, and they decide they are okay with the cost. While there is much more to be said on dispersed teams, that is not the central topic in this article, so I’ll move on.
Instead of looking at pros/cons or likes/dislikes, I look for signals. Signals can be explored before a decision to use agile project management software is made and on an ongoing basis.
Signals that Agile Project Management Software May Be Holding You Back
- Most of the team(s) are actually NOT dispersed.
- The software is used as a reason to avoid moving people who are in the same building closer together.
- Time is spent every day discussing the software at the expense of actual work or team improvements.
- People believe the value of an agile board or scrum board is simply to report to management.
- The process of updating the software is a big part of the day.
- People are constantly trying to “find that item in the software” — often at the daily standup. You find that at the start of every meeting people are looking through the software, trying to get it to display on the monitor, updating information, looking issues/stories/features/whatevers.
- Your “agile process” is more about the software than people actually working together to produce valuable ‘stuff’ for customers.
- People keep saying, “we just have to get this software process figured out and then we can focus on _____.”
- The software continues to get more complicated for everyone to use, enter information into, and adjust — to the point that you have or will soon have, people dedicated only to managing the data in the software!
- You hear people talking about how much time software saves vs. paper.
- People talk about how the software allows them to compare teams to each other.
- People keep adding more and more fields to the software, to track more metrics, but no one has asked what the outcomes of tracking that data will be.
I’m know I missed some, but you get the point. These are signals. Each one of these needs to be explored to determine the intent and affect it is having. For example, #11, why are teams being compared and how? Are they being compared based on team estimates & velocity to see which team is working harder (Please don’t do this!!)? There are many ways to dig into this signal and find out that things are not good! However, perhaps the goal is to see how many stories each team picks up each sprint, to see which product people might need help breaking stories down into smaller chunks. This might not be a bad idea, although could be done without agile project management software. This is one of the reasons why agile coaching is more than just telling people the answer, which a lot of organizations want. Agile coaches need to explore, with the people in the organization, what is really happening — at least if you want to move beyond fogging the agile mirror.
“We Think We Need Agile Project Management Software.”
If you are a new team or organization using agile and most or all of your teams are co-located — ALWAYS start with a physical board. You learn so much more about what is happening, team relationship improves, they are more interactive, they minimize extra processing, and so much more. My experience is that many technically focused people never believe this until they do it. I recall a very technical product owner who argued that the team did not need a physical board for months. He attempted to rely on an agile project management software and it was not working (too much processing and the team never settled into a groove). When it was finally required that all teams have a physical agile board of some sort, he said “he was amazed at how much more they were getting out of it.” I say this not to point a finger at the product owner, but because explaining the experience of it is not easily achieved. Try it.
If you make the decision to use a tool, and it is a decision, use something that is simple and use it as simply as possible. Even the big tools have simpler ways to use them, if you look at them from an effectiveness standpoint. “Do you need 28 statuses?” “Do you really need to enter tasks as separate items? Really??” Start using a process that is SIMPLER than you think you need. Involve the teams in this process, don’t top-down the management of the system. I do believe that you need to have some standards in using a software tool (e.g. if everyone names everything differently, it creates confusion and silos), but teams tell me regularly that they have to take extra steps to use the agile project management software and are “not allowed to make changes to improve it!”
Using agile project management software requires you to really break down what you are using the software for and why you actually need it. You need to understand and actively observe how the software affects people’s abilities to work together as a team. How is it affecting their team relationship? Is it adding value? More value than a physical board? How much waste is it creating? How do you know?
