Have you ever wondered what implementing or upgrading Agile — without using popular frameworks — can look like? Here is a story from one of my current clients, a tech company with a pronounced engineering culture.
This company’s leadership reached out to me a few months after embarking on their Agile journey. They were still putting out major releases once or twice a year, and though the seven teams were following something like Scrum, they were neither acting as teams nor enjoying the process (as was evident in how they’d modified the Scrum events). Recently hired senior managers, who had all seen great Agile before, wanted that for the company.
First, everyone took my Agile foundations training: When we’re being Agile, what choices do we make regarding people and work? With that understanding, I then worked with the entire leadership — from the top to the team level — on how they wanted to be in 2022 and later.
One part of that is to identify new beliefs: What do we consider to be true from now on? They came up with about 20, including:
- “If something’s not working with another team, we should first look for a collaborative solution vs. a workaround.”
- “Quality and testing belong to everyone.”
- “People should be able to focus on their work.”
In conjunction with these beliefs, they chose their values: What do we want to consider most important from now on? (Note: Up to that point, there had been no explicit and consistent value system — a phenomenon I’d seen in many places.) They chose:
- Customer productivity
- Striving for simplicity
- Taking action
- Helping each other succeed
- Continuous improvement
Next, the leaders chose principles and guardrails: What standards should each team implement in their process and practices, so that we live our values and beliefs? Examples from their list include:
- “Don’t go more than two weeks between planning opportunities.”
- “Effective first, efficient second”
- “Strive to make communication easy, effective, and efficient; proactively build shared understanding.”
- “Don’t let each other spend too long on something without reevaluating where it’s going.”
- “Keep looking for what’s slowing the team down, and deal with it.”
This part of the design is the kicker. We didn’t prescribe any meeting, practice, or artifact. The first item on this list says to plan frequently, not that teams must use sprints (in fact, one team later shifted to flow). The last item says to look for delays, not to analyze cycle time. We didn’t tell teams to do standups, but they are responsible — together — to keep themselves on track. These are all Agile concepts they learned and practised in the training.
The next step was long overdue: clarifying the responsibilities and interactions of product owners, product managers, and Agile team leads. They hadn’t been clear and consistent previously.
All these discussions took about seven hours spread out over a week.
Then we had a kick-off with everyone. The general manager explained that all these choices have been made so we can succeed together. Every team can design their way of working as they wish according to these choices.
The first example of living this new mind-set came that very week. Management had recently restructured the teams somewhat, according to 2022 priorities, and not all members were pleased. Management now said to the team leads: get together, talk about the new structure, and if you propose a better one, we’ll use it. The next day, team representatives met to hash it out. They decided to keep the membership as is, but to shift some of the technical/component responsibilities around.
It’s been about six weeks since then. The teams are generally happier than before. They are gaining good rhythm and better visibility, and their collaboration is improving. The team leaders are excited, facilitating purposeful planning and supporting teamwork. Many of the principles and guardrails have been implemented, others are on the way. Nobody is complaining about meetings; in fact, some teams have extended their planning and retro meetings so they can have richer conversations. One of the team leads has said to me, “Everybody likes having a more defined structure.” This is telling, because they had had a defined structure before; however, the new one is their own.
The client continues to work with me, one or two half-days every week, as they have since the training. Most of that time goes to coaching and advising with the leaders.
GIL BROZA
Company
Gil Broza helps organizations turn their software development teams into engaged, productive, and trusted Agile delivery partners. He also supports their non-software colleagues in creating real business agility in their teams. He has helped close to 100 organizations make Agile work well in their unique contexts by using his Right-Fit Agile system, which focuses on what really matters for Agile: mindset, culture, and leadership. Companies also invite Gil for specialized support, such as strategic assessments, facilitation of large collaborative events, and keynotes for internal conferences.
