Blog Image


Agile - sharing experience

The idea with the blog is to share experience about Agile in practice, I have been facilitating CoP (Community of Practice) with Scrum Masters, Product Owners, Team members etc. since 2010 with the purpose of sharing learnings from team to team...

“Learn from the mistakes of others-you can never live long enough to make them all yourself.” quote from John Luther

Shifting to Agile – Shifting organization

Scaling Agile Posted on Sun, January 20, 2013 20:37:10

When you start to use Agile in an organization, you often forget to transform the organization, this is causing some practical problems afterwards.

I will here try to give my view on how an organization could transform from a traditional organization into an Agile organization, I believe that the principles I show are working, but there can be room for discussing how to implement it in practice.

Inspiration come from daily work in organizations trying to work Agile and from Steve Denning’s books and his presentation “Making The Entire Organization Agile”.

The traditional organization is top-down, with control functions, and a lot of roles who are expected to make decisions to generate more profit for the company and the share holders. Most of the organizations that I have seen is silo based, so a simplified chart like below is something that I have seen several times, it can be different depending on the company, but I guess you get the overall picture.

If we try to step back and look at what we have and what we want to achieve, and then try to build the organization with the “delight the customer” in focus.

Let us start with a really simple example.

Let us assume that the customer is a company who hire a group of freelancer

The Customer have requirements which the PO filter and prioritize to the team, the team implement the requirements and ask the customer to test it when a resonable amout of requirements have been implemented.

This example does not require any support organization to help the Team (including the PO).

If we keep the customer in focus and have the “delight the customer” as the vision for the company, but make it a company rather than a group of freelancer, we will still have the Team (including the PO) as the most important in the organization, it is the team who can deliver what makes the customer delighted.

The team could need help from

* Q&V with various things, among others to secure that the team have the right tools to test, release, communicate, developer tools etc.

* HR to secure that everyone get salary, get the oppotunity to develop through education, have coaches to secure the communication between all stakeholders, finance to handle the economical part of the company (sell, buy, tax etc).

* Marketing to secure that the products gets exposed if we have a company without direct contact to the customer like mobile companies (Sony, Samsung, Apple etc), help to communicate with customers, help to analyze and create customer requirements (customers does not always know what they want before they see it).

This will require a huge mindset change, both with the team and with the rest of the organization, i.e. the team(s) must learn to use the new support organizations and stay down to earth, the organizations must learn that they do not exist to maximize their own or the companies profit, but to help the team to delight the customer!

How will this work if we scale it to the size of companies with 5000++ employees?

Let’s look at mobile companies like Nokia, Apple, Sony, Samsung etc – this is an area where I have a lot of knowledge, but I am sure that the exact same principle can be used in other industries.

Mobile companies produce phones (we focus on this, they have other “products”), each phone they produce has the purpose of delighting a group of customers, so they will have a number of teams who are responsible for the product, they will have multiple products, but we will only look at one, the others are individual-copies and will use the same support functions more or less.

When we have several teams, it is very important that each team know what the teams does, it is also important that there is a good description of the product vision and the customer profile.

The teams will need coaches to secure the communication and help them to become better at what they do and how they work.

The teams will work in a environment where they have several servers to keep control of the SW, HW developers need to have equipment etc, this means that the teams need someone to support their environment – this could be handled by Q&V.

You may ask yourself, what happend to all the managers in this organization? They have become enablers or coaches – there is still a need for someone to set the salary for the employees, we are probably not ready to follow the example from Semco where the employees are setting their own salary, so some system is needed to help in this area.

Portfolio planning

Scaling Agile Posted on Wed, December 19, 2012 20:31:34

When I worked at Nokia, high level management decided to work according to Agile, a cross functional group was created to ensure that the changes needed for the organization was implemented. An external Agile coach was hired to help the change management process – Dean Leffingwell, this was probably one of the most important reasons why we managed to change the organization successfully (at least according to my understanding); Dean brought experience from other organizations and was a valuable coach to discuss the changes we did – however it was also important that we did it our way, and not only according to how it was done in other companies.

When you talk about working with Agile and Scrum, people think about the teams working in Sprint, but often forget that the entire organization need to change to get everything to work. There are many things involved in changing a big organization into Agile way of working, I will focus on Portfolio planning in this description.

When Nokia did portfolio planning, the steering committee looked at the visions and high level stories (epic’s) and prioritize it according to each other on the portfolio planning backlog. I will here try to describe the lifetime of an Epic and give my comments on what was good and where we could improve – now that I can be wise afterwards, please notice that I do not know details at portfolio planning level, but I have a fairly good understanding of what happens after portfolio planning, so I believe that my picture is fairly correct, at least good enough for an illustration…

When a new Epic was created, s short high-level description would be created together with a profile where cost, time and competence was estimated (very high level), this was very rough, but gave an idea of what it would require to implement the Epic.

The steering committee would receive a presentation of the Epic and decide if they believe that the company should invest in this or not – if the Epic is important enough, it will enter the backlog of the portfolio planning.

Now the really tricky part comes – priority – it is so simple when you say it, but I have never seen anyone who did not struggle with this, it is so easy to say yes and extremely difficult to say no – but we always have a limited number of resources and need to priority what we want to accomplish. The backlog with Epic’s have to be prioritized, normally a new Epic only have to be compared to the others to be prioritized, but at the end, it could mean that some of the old Epic’s on the backlog would not be implemented. The steering committee will not know details about resources available and cost of Epic’s, but they would have a rough overview, this overview was updated by the portfolio planner contact person, we can call him mister X, mister X was the interface to the different organizations that was implementing the Epic’s on the portfolio backlog. Figure 1 illustrate the flow:

Mr X and a planner from each organization was having regular meetings (I think that each organization was 100-250 people), the planner in each organization knew exactly how many resources they had, who was working on what (maintenance, Epic x etc.); when a new Epic arrived, the resources (based on the profile) was allocated (PO and teams), they would then make a better estimate and feedback to the steering committee – if there was not enough resources available, they would go through the Epic’s from the top and secure that the Epic’s with highest priority was the once that they were working on and inform the steering committee about the results, update Epic-profiles etc.

The important thing in this flow is that the resources follow the Epic!

The PO and the team execute the Epic, the PO is responsible for writing a DoD for the Epic and together with the team to create a release plan for the Epic, this will be communicated to the stakeholders – including the steering committee.