Agile Transformation Pitfall #9 and #10: Misalignment between the team, customers, and the IT enterprise organization
Since these Agile transformation misalignment pitfalls are straightforward and related to one another, we thought it would be easier to deliver them in one post. These pitfalls are geared more towards the IT Enterprise rather than a product shop but still good lessons to keep in mind. Read the previous posts if you need a refresher.
- Pitfall #1: Thinking Agile is Simply a Process Change
- Pitfall #2: No Guidance
- Pitfall #3: Not Providing Slack to learn
- Pitfall #4: Leadership Out Of Alignment
- Pitfall #5: Transparency Is Abused
- Pitfall #6: Lack of Feature Teams
- Pitfall #7: Not Improving Tech Practices
- Pitfall #8: Focusing Only on the Team
Agile Transformations Pitfall #9: Teams Not Aligned With Customers
IT organizations are shifting the focus from projects to products. This is a good thing for a few reasons.
In a project-focused environment, a team is assembled for a specific project and re-allocated to another when complete. This has two impacts:
- Breaking the team apart and moving members around will cause a decrease in performance. Everything you have invested in team building and domain knowledge by the team is lost.
- Customers lose support and attention. When a team goes away after the project is done, in order to get any additional enhancements to the product they have to get another project approved. y This typically requires getting something approved again through their portfolio management budgeting process which may happen months or years later.
IT projects often get stuck in a User Acceptance Testing (UAT) infinite loop because the project customer is hesitant about signing off until they have everything they could ever want. They know that as soon as they sign-off, there’s a big chance they will lose the team and never see them again. The project is therefore delayed with ever-bloating requirements. The famous “64 percent” Standish Group statistic alludes to the waste and bloat that can happen when customers lose focus from just getting the Minimal Viable Product (MVP) out the door and then evolving the product from there.
It is better to spend time focusing on evolutionary product discovery instead of locking in requirements. Gather customer feedback by deploying early and often to make sure stakeholder priorities are in line with the user’s and inspect adapt from there.
Agile Transformations Pitfalls #10: Organization Culture Agile Transformation Misalignment
Using the competing values framework to assess culture, we often see that things like “Control” and “Create” are at odds with one another. In most organizations, if you assess the culture of the company, they are heavy on the Control quadrant and very light on the Create, Compete, and Collaborate.
While Agile still has components of Control, it has just enough to add structure. It really plays more to the other three quadrants. Agile is about:
- Create – Innovation and building great products
- Collaborate – Agile is about the people, the team, and self-organization
- Compete – outcome-driven, focused on the customer, getting feedback fast
When I survey an audience, this is usually the top pitfall: the culture at the Agile team level is different from the department level which is very different from the organizational level. Ideally, if you create scatter plots assessing the cultural values for each tier, they can be different but they should still be balanced.
Take, for example, one of our old clients, a medical devices manufacturer. At the organization level, their culture is very control-heavy and I’m glad for that. You want a lot of governance when you’re directly affecting people’s health. However, the software team that creates the CRM system does not need to be as control-heavy. The misalignment caused conflict between the team and organization. Leadership wanted the team to be innovative but they still wanted all the control.
It’s about balance and alignment. Is your goal to become Agile truly aligned with your organization’s culture? As explained in pitfall #1, it’s not just a process change, the culture of the entire organization has to shift. You will have different cultures at a team, department, and organizational level. If you’re committed to Agile, the first thing you have to do is understand where you want to be and define a path on how leadership can begin to shift the culture in that direction. As discussed in the fourth pitfall, there are lots of good reasons to adopt Agile, but there are many of them. Therefore, each stakeholder (whether leadership, department lead, or team member) can have a different reason for wanting the transformation. Alignment is crucial.
Before starting the transition, communicate why the change is happening, particularly to departments beyond software development. After all, they may not understand why the annual budgeting process may be impacted by the transition to agile. Providing Agile training is a great first step towards organizational alignment as it will give everyone the same, solid foundation. Second, we would recommend building a transformation roadmap and backlog to help your leadership prioritize what areas of improvement to focus on next. Let us know if our coaches can help assemble the roadmap.
If your business is going through an Agile transformation, you know it’s difficult to navigate. What challenges are you having? Have you reached any important milestones? Share your experience below or ask us questions.
For more on our approach to building lasting business agility, you can check out our Transformation Services page.