In my career, I’ve never had an entire team approach a transformation into agile project management with open arms. I usually get to participate in a psychological case study of groupthink. In a typical group, you have one or two people in the group that are extremely vocal in their opposition to changing their process. Many in the group would sway either way (for or against), however they don’t want to disagree with the majority and don’t want to stand out, so they typically will go along with the more vocal people. Then, you have juror number 8 (reference the 1957 film “12 Angry Men”) who goes against the group, defends his or her position and causes others in the group to question their initial decision. Not all groups have a juror number 8, so it falls on the agile project management practitioner to play that part.  

I recently reconnected with a former colleague who told me that I changed his perspective on agile project management. In all honesty, that is one of the biggest compliments any agile project manager could receive! I will share his feedback after I provide a quick history of this partnership.  

When I first joined the team, he was the most vocal critic of the agile processes and explained that they were forced (literally) onto them by leadership. He told me that the process was heavy and presented no value whatsoever to him and the team. During the first few weeks that I was part of the team, I told the team leader that I just wanted to observe their process, ceremonies and meetings first before I took over. Please note that many agile project managers don’t take the time to observe and understand a teams’ current processes before pushing a change. We’re taught to define a problem before recommending a solution, however in reality we don’t apply this practice when it comes to deploying a new process. Not many people like it when someone shows up and moves their cheese!  

What I observed: 

• Standups were a waste of time. Lots of talk, little organization, no action.  

• Quarterly (PI) planning was more about making sure previous features and stories were closed out and new ones created…even if the work was going to carry over into the next quarter.  

• Stories existed, but only because the leader built the stories and tracked everyone’s work for them.  

• Sprint (Iteration) planning was happening but didn’t truly reflect the value delivered by the team in that sprint.  

• Retros were too frequent for the type of work this team performed. Demos were in place but only involved the internal team.  

• There was no time in a quarter (PI) devoted to truly planning for the upcoming quarter. It was work all the way up to the quarterly (PI) planning event leaving no time for coordination with other teams.   

• Attention was focused on adherence to the story writing process (As a <>, I need to <>, so that I can <>), acceptance criteria and story pointing using Fibonacci. 

• Nobody was looking at capacity, so there was a lot of work planned for a quarter, but only part of the work completed.  

• The process was indeed heavy and provided no value to the team other than being able to tell leadership that they were following the prescribed Scaled Agile Framework.  

  ---

With the team leader’s permission, I completely disassembled the agile process that they were following.  

1. I took over standups and created stories on the fly for individuals. As soon as we identified the need for a new story, I created it (in the standup), sized it and assigned it. 

2. We canceled all retros and demos.  

3. We moved into a continuous planning cycle rather than a sprint (iteration) cycle.   

4. We focused on visualizing and then prioritizing the work. 

5. We removed Fibonacci as our unit of measure for sizing and started estimating based on days of effort.  

6. The stories were mostly used to track their own work and convey capacity, so I told the team to drop the user story format and acceptance criteria. 

The dynamics of the team shifted within weeks of making the large changes above.  

Win #1:The team observed me creating stories during standup and saw how quick and easy it was. Within two weeks the team started to tell me that they would create the stories and that I didn’t need to do it anymore.  

Win #2:We started to discuss feasibility of completing work based on available capacity rather than committing to all work. We had full visibility into all of the work that the team had committed to.  

Win #3:After a month and a half of working in this manner, we decided that we were ready to demo a few deliverables to the internal team as well as to a few external stakeholders. We began ad hoc demos only when needed.  

Win #4:After four months of working with this team, we agreed that a Scrum Master could take over my duties and the team became a self-organized, well-run machine. Their output was higher, their capacity was in control, they had predictability around their work, and most importantly, they felt like a winning team.  

Let’s circle back to the feedback my colleague shared with me about how I changed his perspective on agile project management. He told me that before I was part of the team (notice that although I never owned any output, he considered me to be part of the team), the process was a box to check and felt overly complicated. He said that I simplified the process, helped the team understand the value, and created what felt like a bespoke solution that addressed the needs of the team.  

The team felt better; like they were in control of the process. They felt freed from the chains of process, that they could keep moving, improvising so they can flow. The music was in the hands of the individuals on the team; there was no longer the need for a conductor.