For more than two years, on and off, we have been guiding the people of ComAp through the Agile Transformation. We’d like to bring you this transformation from different perspectives, so we decided to create a series of articles in which we interview one person at a time in a key position in the company.
If you’d like to learn more about ComAp or want to get a balcony view of the entire transformation before reading on, we recommend reading this article first.
The main driver of the ComAp change on our side was Honza Krchňák, who was this time interviewed by our colleague Radek Gajdušek.
Honza, how did the cooperation with ComAp start?
We met with Marek, the head of the whole R&D development. From his words we understood the situation in ComAp as follows:
- ComAp is undergoing an Agile transformation.
- They have an idea of what it should bring them, they know why they want to be more Agile: they have a lot of projects and the number is growing. It’s hard for them to navigate, they’re working on everything and nothing is really moving.
- They have a couple of Agile enthusiasts who are very interested in this topic and they have a couple of people who went to some Agile training.
- They’ve made organizational and process changes – development was split into Tribes – relatively self-sufficient units capable of developing and delivering a complete part of the product.
- They added Product Management people to these units.
- The work was distributed in a chain of Product Manager – Analyst – TeamLead. The TeamLead had then redistributed the work within their team, or they were working together within the broader Tribe in multiple teams.
- And they started working in 14-day sprints.
The beginning of the transformation described above brought them some benefits: the production manager knew more about who his team was and what they were doing, they were in contact more often and in detail as needed. But realistically or measurably, there was no major benefit. There were always arguments about what to do earlier and later, there was constant pressure from Product that deliveries were slow and small. And there was always a search for who was to blame.
Is this a typical situation you face with your clients?
Yes, we see this a lot in transformations. Most often it points to these underlying problems:
- Applying agility to the end teams only (Scrum just for the development teams).
- Strong decision making role at the top, a lot of decisions have to wait for approval
- Departmental responsibilities, there are silos with different goals and different needs
- Scrum only serves iterative planning of tasks, teams don’t care much about overall benefit/value
- Product Owner is the only one who figures out WHAT we’re going to do, the team just accepts it
- PO and team have seemingly the same goals, yet they differ (one to increase earnings, the other to deliver the promised functionality on time)
- The division into tribes was done only in IT, not in the whole organization
- Retrospectives are only used in the development team, so the impact of changes from them is very limited
- An intermediate layer of projects between the product and the development team remains. This helps with planning but hinders focus on value delivered by discouraging changes – just trying to deliver what was promised and planned.
- The workflow of the work remains original for teams – analysis, estimation, design, implementation, verification – exactly in this sequence. Thus, we only have an iterative waterfall without much change.
These and other problems are typical for many companies. On one hand, Agile/Scrum still helps here because iterative delivery alone helps with transparency and uncovers possible problems earlier. However, the main benefit of the Agile approach is missing here – early identification of true value and regular value re-prioritization. This is typically how Agile provides the greatest acceleration – it looks for what NOT to do and gives us the ability to actively manage it.
What did we do for them?
We used our RainFellows framework, which we call the Transformation (re)Starter Pack (TSP). It’s a sequence of activities and workshops that helps clients to:
- Clarify what is the problem they want to solve and how they will know when it’s done (OKR of the change)
- Decide which part of the organization should be affected by the change (team, department, entire company)
- Get a feel for what an Agile approach really is, how it differs from others, and what they are missing
- Experience what Agile leadership is and that it is not only the process that needs to change but also the culture
- To take those experiences and translate them with their people into real change that they themselves will desire to push forward
- Help them hands-on to actually make it happen, measure it, and evaluate it
- Transform this approach into a permanent new state and develop it further with internal people.
The outcome is usually that the area in question is then truly Agile and really reaps those promised benefits of Agility. Together with the stakeholders they really focus on the right thing and it shows in the project’s deliveries.
Usually, of course, this will generate other improvement topics – even here at ComAp. However, these are topics of a more pleasant nature – how to adapt the rest of the organization to the fact that one area suddenly runs significantly more agile, that it reacts lightning fast to changes – just how to align this state with more rigid processes (e.g. roadmap creation, company strategy, etc.).
You mentioned “get a feel” – do you change teams on the fly?
Yes, we change teams on the fly – only real everyday situations will show you if the change is real or just written.
But the wording was aimed at our way of teaching. We have great educational games that let teams really experience aspects of Agility with all the challenges and benefits. For one thing, it’s more fun (for the clients, but also for us), but more importantly, it’s extremely effective. Even the most die-hard resisters and naysayers just get to experience the different approach in a safe environment. And in subsequent sessions and workshops, it’s no longer a mental step discussion of “where do we go” but “where do we go back” – because they’ve been there in the game and they already know it there.
By the way, most companies then ask for these individual experience events further down the line, for new hires, when rebuilding teams, etc. They find it’s a great way to engage new people and teams much more quickly and enjoyably.
Okay, so the experience, the workshops to get the ball rolling… and then what’s next?
Then it’s follow-up mentoring. This part is quite hard to plan because every team needs something different. With some, we go even through the basics like creating the right requirements and prioritizing, with some we just tweak the details, like cross-team collaboration.
Overall, we try to lead by example for the team for a while (leading from the position of an external Agile coach) and pass it on to an internal person who leads the change instead of us as soon as possible. We are then available for that person, and they learn to address specific issues on their own and consult only selected topics with us.
With those internal change agents and the client, we then identify further areas to focus on. For ComAp, this was the topic of Portfolio Management (how to address topics in the far future) and the topic of efficiency and innovation (a workshop they aptly called “Twice as much in half the cost”). We do specific problem-solving workshops on such topics, where we break down the problem, describe it, analyze it with the team, and begin the steps to solve it. We then connect these steps into the running processes so that the activity does not “die” after the workshop.
Overall, we are then available according to the client’s needs – sometimes more, sometimes not at all.
From your point of view, how do you evaluate the contribution of your work for ComAp?
I think we have achieved several things:
- We’ve helped to bring Product and Delivery significantly closer together so that they now look at anything from a “we” perspective. It may not sound important, but it’s a huge change that has moved them forward massively. Now instead of fighting internally, they’re directing their efforts outwards and can focus on the challenges of the market, of which there are currently enough for everyone.
- We have enabled them to experience the benefits of Agility through hands-on mentoring. On the project where we were involved, the stakeholders cheered – they finally had the project firmly in hand. And when problems came up (as they do with just about every project), they were free to decide how to address it and chose the best way forward together.
- Long-term – we have been working here in a position of external inspiration: sometimes a problem comes up that has no clear solution or owner. So we are available and help them solve it and bring in an outside perspective – how people have solved something like this elsewhere and what theory says about it. This is great for them – no one has to study the topic at length internally, we just run a workshop and work just on the area of the specific solution.
How long did it take and what is your current involvement in ComAp?
We have been working with ComAp for over two years now. Initially, a couple of workshops to get started, a break to evaluate, then intensive mentoring of one area, again letting it run for a while. Then came a few more rounds of workshops for inter-connected departments and follow-ups. We are currently in the phase of occasional consultation or ad-hoc workshops – we don’t have any particular ongoing topic.
