Agile transformation with Henrik Kniberg @OCTO Technology
Henrik Kniberg is Agile/Lean coach at Crisp in Stockholm, speaker at international conferences and author of popular books about XP, Scrum, Kanban and Lean from the Trenches. Working primarily with Spotify and LEGO, he enjoys helping companies succeed with both the technical and human sides of software development.
After his presentation at USI, Henrik had accepted our invitation to answer some questions from our clients in their transformation journey towards Agile. This event is facilitated by Sergey Larionov, Agile Coach at OCTO Technology, and made in a breakfast format, where clients can come for 2 hours before starting their day of work. The event was filmed and full video can be found on this link (user/password : hkniberg/the_nextmorningafter_USI).
How did you get to Agile?
“Entirely by accident…” :)
Looking for a way to run Henrik’s own organizations as an entrepreneur and manager, and searching for diverse sources of inspiration, he discovers some frameworks such as Scrum or eXtreme Programming and by implementing them step-by-step learns that it is way better than waterfall. Being a consultant, he started helping clients to apply these methods as well. He started to write about what he learnt, generated more consultant engagement and it became viral.
What brought you to Spofity?
Spotify is the most known example of Henrik’s work on Agile culture and Product Ownership.
One day, after delivering recurrent talk, what he use to do between consultant engagements, Henrik got a call from Spotify, a small start-up at that time build by a group of students from a Swedish university, who participated on his talk. They were trying to apply Scrum and had a “growth pain” and asked Henrik to come and help dealing with that.
What about Agile journey?
The journey is quite different depending on where you come from. For big organization with many people Agile means simplifying, allowing teams autonomy, removing waste and overloaded structure. For startups, it is the opposite, Agile serves to add structure where there is a significant growth with too much entrepreneurial chaos, although not becoming bureaucratic. When there are few teams it is easy, when it comes to 6-9 teams, the books don’t give you answers anymore to questions such as synchronization between teams or how to organize people into teams, etc. Applied experience in different contexts, use case study and try some patterns may bring you these answers.
How did you get into LEGO?
LEGO is Henrik’s second flagship project. They got inspired by his work at Spotify, notably by Scaling Agile, and asked him to create an environment where people are happy and doing a good job. Agile might help to do it. LEGO was using SAFe framework and they needed help.
Why LEGO have decided to implement SAFe?
The Product department has already been Agile, but other departments such as Sales, HR, Marketing, used a lot of Waterfall method, which worked well, until one day they understood that the world is moving too fast and they had too many failures. Since then, they have gone crazy with innovation by allowing teams full autonomy. LEGO was running out of money and almost went bankrupt because of loosing control of everything. They made up changes and became super focused as a company by aligning everything that everybody does with the high level goals of the company.
Meanwhile, there was a disconnect between portfolio and budgeting systems based on 2 years cycle and software development teams trying to be very fast. They had a middle management layer running in meetings all the day, updating spreadsheets and sending emails. Over several years they figured out that it doesn’t make sense, not effective nor motivating. Until one day middle management took trainings about Agile and SAFe and got inspired. They were not sure if it would work, but maybe it’s worth trying. And they started from experiment. Experiments are a lot easier to sell than organizational change. LEGO asked Henrik, who is framework neutral, helping them trying these experiments. They tried to put 120 people together and do sprint planning with single backlog, introduce cross-functional teams, etc. and it kind of worked. Then they focused on removing waste in this new functioning.
Starting from 80% couple of years ago, nowadays LEGO is using only about 20% of SAFe. In conclusion, SAFe is a framework based on Agile & Lean principles, it is just too detailed. At scaling there is no “one-size-fits-all”, but there are some patterns. All frameworks are saying the same thing: use Agile principles, work with teams, do the planning together if you have dependencies, plan synchronisation meetings where all the teams come together for an integrated demo where everyone can learn, then make changes.
“All the frameworks are saying the same thing, it is just a different level of detail”.
Look at frameworks and case studies, steal the best ideas, but avoid the trap believing that a framework is going to answer all your questions.
How to switch from command & control to the Agile mindset?
Those who behave in command & control mode are used to top-down way of working, but once they tried another approach they would switch the mindset, because often their behaviour wasn’t intrinsic, but the result of the system they are living inside.
When the system changes, behaviour changes.
Of course for those people who love control and get scary by uncertainty, they may not fit into Agile. It doesn’t mean that they don’t fit for the organization, but they don’t fit for the part of the organization where there is uncertainty. For repeatable actions with minor changes and low complexity you probably don’t need Agile. But for uncertain, changing and complex world, Agile will definitely help you. Although command & control people would not be happy in this new working mode, would not deliver a good work and will resist. Better to find for them another environment.
Starting a transformation, don’t judge people. Just go, but be observant. For people, who do not understand, help them to understand, listen to them, but if you notice that someone is clearly unhappy help him to find a place where his skills would fit better.
How to deal with top management who wants 100% control, but also convinced by need of Agility to welcome continuous rapid change?
Start by asking, “What do you want to control?”, “Why do you need Agile?”, “How did the last project work out?”, “Did it work out as planned?”, “Are you happy with the results?”. If the previous project worked perfectly, you don’t need Agile. But often all you have in the waterfall is illusion of control.
We can control the budget, number of teams and the deadline, but not what exactly the product is going to look like. It doesn’t make sense to lock the product, instead focus on the desired outcome and what problem we want to solve.
Mostly you will find out that Agile gives a better control. Every sprint is a real-time control point to look at something that runs and works, to see what failed (after one sprint instead of at the end of the project), and make changes. Agile increases the control and removes the illusion of control.
How do you go to maintenance mode after product has been developed? What do we do with an Agile team when the main functional scope has been finished?
In waterfall mode once the project team has done their project, it goes to a low-cost maintenance team.
Giving the project from Agile team to maintenance team is not a good idea, as it is a risky and costly action. No matter how much project team documented, the most knowledge is in the heads of developers. It takes time to understand the product, why it was designed this way, writing documents, spending time on explaining. A better solution would be to move the Agile team on another product while delivering value and keeping maintenance of a previous one.
One of common patterns is, once the main functional scope is delivered, the team just starts working on a new product B, and fix what is needed from previous product A. Whether adding it when needed in a current sprint, whether plan a specific sprint for maintenance, which would impact the A product fixing reactivity, but would let the team focus on product B and make it move faster. Basic Agile architecture is stable teams, stable backlogs, just decide which team pulls from where.
Another pattern is a common single backlog, where teams just pull from it to make sure the highest value is delivered by following the development. Gather teams, introduce them the context, explain the priorities and let them choose their own team backlog items. If there are a large number of people you may need a Chief Product Owner to prioritize between different Product Owners and take decisions on common priority.
Only you can decide which pattern makes sense in your context. If you are not sure, then just try, and if it doesn’t work, try something else.
How can we do continuous delivery in multiple teams when we have dependencies?
One of very powerful patterns is integration cadence. It is a moment, every week @Spotify or every month @LEGO, when everyone, who works on the same product, gets together. It creates intrinsic motivation to collaborate in preparing demos and space to fail for innovation. It also helps to solve a typical Agile problem of abused autonomy by introducing a hard constraint, where no matter what, the team has to show the results. In addition, it forces them to communicate with dependent teams on potential delays and take decision on planned scope.
How to deal with dependencies between Agile and waterfall teams?
It is exactly the same situation at LEGO where Digital solutions is an Agile team and Corporate IT is a waterfall one. A pattern that helped here was to visualize dependencies and invite teams to see it, let the people speak to each other. It happens every month at LEGO during Planning meeting (see also Program Increment at SAFe) where teams collaborating in optimizing planning taking in account mutual dependencies.
Visualize, optimize, remove the bottleneck and organize yourself to minimize dependencies.
Here is the presentation shown during the event.
Do you have a transformation template to standardize the working process?
If your way of working is pre-defined, what happens with continuous improvement? In the case when the team wants to make an improvement they would have to pass by phase of negotiation with others or do it secretly. Any of these cases generates frustration. Standardization is greatly overrated. Some people may become rebellious and hide the way they work. It breaks trust and goes against Agile, as it is about “Individuals and Interactions Over Processes and Tools” (one of Agile values).
When people ask for standardization leading to the common way of work, there is usually a reason for that. First of all, ask why they want it and what need do they want to satisfy. Usually the need is valid, but solution is not good.
For instance, their need is to go faster and standardization is the proposed answer. Let’s think about other options to go faster. By making teams work, whatever way they want, they continuously improve and in consequence move fast. Another example is to reveal problems. Within the team, the retrospective or any other tool of continuous improvement can help to visualize impediments and let team members find most appropriate solutions. In dependent teams make them discuss together and collectively find a way to solve problems. The standardization could happen if it answers to a real need. In case of generic problems, for instance, when different teams are using various versioning control system or none, that causes absence of a simple way to integrate the whole product, multiple teams are working on, and to test it in a continuous way. Bring them together, do root cause analysis and choose a system that they all hate the least. Let the problem drive the standardization and keep it on the minimum level to not slow down the rate of innovation.
How do you deal with the feeling of loosing the ability to do everything in start-up, which is growing and multiplying specialisations?
Scrum organization says “we are the team” and within that team, we are cross-functional, so we have a designer, back/front developer, and other roles demanded to deliver end-to-end functional scope. People still have a specialization or main competency, but in Scrum there is a permission to step out of your specialty to help others, as well as common goal, demonstration and mutual learning.
Sources
Article “Agile is about taming complexity”
Visual support produced by Nicolas Kalmanowitz, Agile Coach at OCTO Technology:
