A few weeks back, I had a conversation with a peer coach who was introduced to me. As we chatted, we discussed several aspects of coaching. At one point, he asked me a question that has proven difficult for me to answer.
Well, to clarify, I gave an immediate answer, but I have since changed my mind about it. The question has been weighing heavy on my mind for the past few weeks. I keep coming back to it. …
“We are putting all work items in Jira so we can make our teams’ work and progress transparent.”
— Manager in a company undergoing an Agile transformation
This sentiment of making all work visible to everyone is rampant these days. On the surface, it appears to be a step towards increasing transparency. But in Agile thinking, making all work and progress transparent is not the goal of transparency. Transparency in Agile and Lean reveals problems early so the team can resolve them or ask for help.
Scrum is not a silver bullet. It does not provide solutions. Rather, it can only reveal problems. To modify your behavior and adapt to the obstacles Scrum reveals takes grit.
Scrum is lightweight, simple to understand, and difficult to master.
Many teams start on the journey without much guidance and hit issues fast. In the product development world, issues encountered are typically commonplace, with responses stemming from old behavioral habits.
To name a few:
We have messed up. For too long, managers have not had a home in an Agile transformation. Excluding managers has created a huge impediment for embracing the Agile Mindset. We coach on removing silos, but we have created a manager silo. Transformations all over the world stall out due to this.
By “We,” I mean Agile Coaches, Scrum Masters, Team Members, Product Owners, and others on the Agile journey. …
Procrastination. Everyone does it, and falling in love with creating the perfect plan is often the culprit.
For instance, I spent two days thinking about how to write this post instead of simply taking action. I deliberated on the title, planned points to cover, and thought through arguments. And this cycle continued as I researched and built my writing plan of attack.
Most of my delay tactics result from being afraid of writing something that sucks. I fear my post will not resonate and will fall flat. …
When I was in school, I never got an “A” for messing up and breaking the rules.
This drove me to cautious behavior. I was fearful of trying anything extreme that would tarnish my report card. I — like everyone else I knew — played it safe and did what would get me a good grade and little else.
This “playing it safe” behavior continues for most of us as we enter the workforce. My chosen profession as an Agile coach puts me face-to-face with it daily. …
“We are Agile! We have a backlog, and we host awesome PI Planning events.”
— Manager in an Agile Transformation
In one form or another, I hear a statement like the one above all the time. And every time I hear it, I cringe. I wonder how things have gone so far astray.
I cringe because Program Increment (PI) Planning from the Scaled Agile Framework (SAFe) does not support an Agile mindset. All my experience with it tells me this is true. …
“Our primary goal is to increase revenue. It is coming from the top. All teams need to focus on this OKR. No light remains for any result other than this.”
I heard this statement a few weeks ago. It reaffirmed my belief in how misguided our pursuit of value has become.
These words were coming from an organization trying to shift from an output to an outcome focus. While spoken with good intent, the objectives and target results fell flat. …
“We are doing hybrid Scrum. Pure Scrum won’t work here.”
“We have too much other work to do. We can’t dedicate our time to one team.”
“If we allow teams to self-organize with no checks and balances, chaos will ensue.”
“We are starting our Agile journey with an output focus.”
“We need to reorganize our company structure before we can try to work like this.”
“We still have to maintain existing management mechanisms while we transition to Agile.”
“We have had too much change. …
Our fear was building, and it was resulting in irrational behavior. The statements coming from my team members were crazy:
“We should demo our work even though we are not done. We can finish it next Sprint.”
“If we demo around the known defects, we can still show we made progress.”
“We can be ‘Done’ if we take on technical debt. We can pay it back in later Sprints.”
“We can’t have a zero for velocity this Sprint. This will tarnish our consistent track record. …
Todd is an Executive and Enterprise Agile Coach with 25 years in consulting. His coaching is focused on making Agile simple again.