Springe zum Inhalt

There is a lot of noise around the management of Agile. A new discipline of Agile Management seems to be necessary and is discussed on conferences, in articles and is the base on new consulting products.

20130908-154255.jpg

Agile as a body of knowledge has its roots in Agile Software Development. For many years the community ignored the managers. Statements that managers aren't needed anymore in agile organisations were not very helpful to adopt new agile methods. Nowadays the management practices are much more in focus by the agile community. We understand that management plays the important role in the change process towards Agile.

What is an Agile Organisation?

The agility of an organisation can be described as the ability of this organisation to adapt to new market conditions. Depending on the products and the market the required agility may differ to actually qualify it as an Agile Organisation. Even with traditional processes a company could achieve some level of agility. Agility of an organisation's business alone is not enough to call it an Agile Organisation.

What I mean with Agile Organisation is the use of agile methods and the compliance to the Agile Manifesto for a group of people within a company. For example a multi-team Scrum organisation that creates one product can be called an Agile Organisation. The management of the Agile Organisation is the focus of this post.

What is Agile Management?

Agile Management is the management practice in the context of an Agile Organisation.

The term Agile Management indicates that there is something special in the management of Agile compared against the management of traditional organisations. While this may be true depending on the context, the knowledge in science of complex social systems and self-managed teams exists already for many year. The agile movement has not invented a new type of management. It rather discovered the knowledge and has incorporated it into the Agile body of knowledge. This means for managers that want to move to Agile - apart from learning the essentials of agile methods - they can re-learn or improve the knowledge about management based on what already exists in science.

There is nothing unique about the management of agile organisation, so I did not recommend to use the term Agile Management. It's because people may anchor on the wrong things: agile people may think that Agile Management is new and they have to teach managers their own - agile - way of management and managers may think that Agile Management is not adoptable in their company or it's a buzz word, that has nothing todo with real management.

My experience is that using the word Agile for everything, like Agile Marketing, Agile World or Agile Management, is not helping us to adopt our body of knowledge. I usually explain the real business benefits and the insights to convince people. Labelling it as Agile often creates immediate resistance.

What is good management?

We had a discussion on our company how an agile manager should behave. We brainstormed several properties of an agile manager, that I cannot fully recall. It was something like: supportive, empower the team, remove impediments, ...
My colleague David from the UK noted, that all these properties will make the manager a good manager (in the context of product development). Even, if no agile methods are used at all, a manager that behaves and leads his people like this, would create a very helpful environment for product development.

This means that we have organisations out there that are not using agile methods but with good management. I met some of these managers. Although they were not heading an agile organisation, they understood very well, what it takes to lead in the context of Agile. One difference is that agile organisations require good management. Agile does not stick in an organisation with bad management.

In the next posts I will continue with the topic "Leading in Agile".

Credits: Photo from Flickr Michael Heiss

What is a Digital Transformation?

The term digital transformation has been coined some years ago. It describes the process for an organisation or society to change in the digital age. Caused by more connectivity between individuals, the possibilities for new types of interactions have dramatically increased. This creates new forms of how we live together.

20130804-125032.jpg
Source Flickr: Tom Bennett

If we look closer on organisations and commercial companies in particular, we can observe more potential business models. These business models have much more variety than the standard eBusiness models that were implemented over a decade ago during the internet bubble. With mobile commerce and social media, customers can be reached via different channels in many places. This makes it possible for a business to get in touch with the customer at the right time and the right place. The value that is delivered to the customer can be higher but depends very much on the experience he or she has with this interaction. If the company is doing it right, the delivered value leads to more customer satisfaction and binds the customer more closely to the brand.

These new business models are also an increasing threat for traditional businesses. Due to the leverage a new market player can create, it may disruptively change even a whole industry. We have seen this in the music and currently in the publishing sector. Also the automotive industry is changing because the traditional vehicle-centric business model does not meet the expectations of young digital natives anymore. Automotive companies must shift from the vehicle-centric to a customer-centric business model. They will provide mobility services rather than vehicle products.

What needs to be changed?

As elaborated earlier, the business models will change. How does a company find a new business model? It’s an innovative act to create a new business that is attractive for customers and successful. Not every company culture supports innovation well. Very often they have been optimised for efficiency. Even when the senior management calls out for more innovation, the culture may prevent it. How can you create a culture for innovation?

A new business model can be successful but very often they fail. According to Forbes, 9 out of 10 startup go out of business. The environment for a new business is very uncertain. Often the strategy to implement a new business model is to invest a lot of resources and time founded on many hypotheses. These hypotheses are ideas that are later often proved to be false. Companies need to come up with new methods to deal with this uncertainty without spending a lot of resources and time.

The existing structure of a company is often another hurdle to overcome as well. Especially the new innovative cross-channel business models require changes of the internal processes that connect different departments and even devisions. The silos of such an organisation obstruct the process to find the solution. Creating the best solution requires phases of divergent and convergent thinking of together with multiple departments. Silos must be overcome to get the best out of the company.

Why is Agile helpful?

What we mean with Agile is the Agile with a big „A“ - the body of knowledge that is growing in the agile community. Agile (with a big „A“) is not just for software development. Although - due to digital nature, software plays always a big role in a new digital business model. Within the agile community the knowledge is growing on the whole value chain. Agile consists of practices that turn an idea into cash. Agile helps to deliver more customer value in shorter cycle time, hence increasing competitiveness.

Within the agile community the method Design Thinking is combined with software development. Design Thinking is used to create innovative ideas for new products. Main concept of Design Thinking is the interdisciplinary team that consists of people from different departments. This method helps product development teams to be more innovative.

The uncertainty to develop a new business model can be overcome by using the Lean Startup method. This method is combined with agile software development and develops new business models by testing underlying hypotheses step by step with minimal resource usage.

Apart from these new methods, the common agile software development methods help companies to get quicker from a business idea to real customer value. Cross-functional teams deliver digital value and use practices like Continuous Integration to get this done on a larger scale. The power of Scrum to drive the change in an organisation is a good catalyst for a digital transformation.

Product Owners employ User Stories as product backlog items. User Stories represent requirements and are detailed during the course of the project. Large User Stories are called Epics. Epics are coarse grained User Stories and are usually decomposed during the project and detailed further on. And then there are Themes ...

Often Themes are not used properly by some teams. I have seen that a Theme is either a more fine grained concept than an Epic or a more coarse grained concept and contains multiple Epics. It may not be wrong to use the concept of a Theme this way, because neither an Epic nor a Theme is clearly defined. But this confuses the team members and it is not helping us to adopt agile planning.

Clarifying the three different concepts before you work with them will help:

  • A User Story represents a requirement and is small enough to be implemented by a team within one Sprint.
  • An Epic is a larger User Story and represents a requirement as well, but it is too large to be implemented in one Sprint.
  • A Theme is a set of User Stories or Epics. A Theme can reference multiple User Stories from even different Epics.

But for what are we using the concepts?

A User Story is a requirement that is digested by the team within one Sprint. A lot have been written about how to use user stories. Some teams avoid the concept of Epic and simply call them large User Story - fair enough. But it makes sense to call a large User Story an Epic, because the sizing of a User Story is an imported information. Having Epics in the Product Backlog indicates that the items have to be split. If in the Backlog Grooming meeting the team labels the backlog items as Epics, which means they cannot be estimated. Separating the large and small user stories with different terms, forces the team and Product Owner to make the backlog items smaller, which is a decent goal.

But Themes? Why do I need the concept of a Theme? The answer is: For roadmap and release planning.

Usually customers and users want to have many many features. It's not agile and not helpful for the customer to convert all their wishes into fine grained User Stories, so they can be implemented by a team. It's better to narrow down the desired scope and to get closer to the best business value for available team capacity with agile planning techniques.

Agile planning has many different levels. The highest level is the product vision, that describes the actual business goal of a project or product. The next level is the release roadmap. In this roadmap the product owner and the team agree on a series of releases with a rough scope - the Themes. Releases have Themes that describe the scope of the release. Within a release we usually want to build and deliver a Minimum Viable Product (or Minimal Marketable Feature). That's a single or set of features that bring value to the customer.  In the roadmap planning we want to find out which Epics and User Stories are a minimal necessary valuable set of functionality. Since Themes are a set of User Stories they can help us to find and describe the MVP.

How can I identify Themes?

I had a discussion recently with a colleague about the usefulness of the Last Responsible Moment (LRM) in the context of a complex project. The LRM is when the Cost of Delay overweights the Benefits of Delay. In other words, it's often useful to wait with a decision until a certain point - last responsible moment - before the cost of making a decision too late will be higher than the benefits. I want to come up with an example that may happen quite often in a project:

Lets assume you want to order server hardware that will host your web application. If you order it very early, you may not have enough information to buy the hardware properly sized. Later in the project you may have enough information to make the decision about the hardware sizing. But ordered too late there is a risks that the hardware will not be up and running before the release date and you will loose some expected income from your web application.

http://www.flickr.com/photos/krystalt/5286861375

We came to the conclusion that the LRM makes practically no sense. The only thing we know is that not all decisions have to be made in the beginning. The nature of complexity is that we cannot plan all details in advance. Only after a project has finished, we know exactly which decisions have been made correctly. Although there exists a LRM, we cannot find it in advance (in complex software projects). By focusing too much to find the LRM in advance, we may actually risk that some business value is not delivered.

Of cause, if we can quantify the Cost of Benefit and Delay then we can find the LRM. It may also help us to know about the LRM while we are still making decisions trusting our guts. But agile coaches should teach the whole story, so people avoid gambling for the LRM.

Ken Schwaber explained the changes to Scrum in a Keynote at the Scrum Day in Germany. One major change is the renaming of the Sprint Commitment to Sprint Forecast. Ken said that some Product Owners were yelling to the team that had just missed to Sprint Commitment. I understand that this yelling is not something you want to have when you introduce Scrum.  Scrum and agile methods in general rely on highly motivated teams. Choleric Product Owners wont help you. But is the reason for this behaviour the much more binding term "Commitment"?

From http://www.flickr.com/photos/fabiovenni/

If a team fails to meet the commitment, then this may be an indicator for two things:

  1. change in the environment of the team is needed
  2. the problems the team has to solve are to complex.

In both of these two circumstances the team or the organisation should learn and improve. The team can learn how to better cope with the complexity of the given problems and the organisation can learn how to transform to support the teams better to get things to done. IMO: Renaming the Sprint Commitment to Sprint Forecast will take away the urgency of the necessity to learn.

We find commitment in many cultures. The Germans for instance are well known for their punctuality. Everybody commits to be at a certain place on time. It reduces the time to wait and people can start working immediately. Every German who has worked in another country realizes how this behaviour helps to get things done and avoids wasting time. Commitments help us to better work together.

In the organisation we have commitments on various level. Shareholder, investors and owners give their capital and want commitment from the board that the investment will have a return. Customers pay for the products and services and want commitment from the vendor to keep the promises. Employees want a commitment that they get a monthly salary. There are commitments everywhere on the boundaries of the organisation. Inside the organisation we have managers who commit to certain goals, e.g. increase revenue, create innovative products or reduce costs.

Is a commitment by a team to deliver some value after two weeks not possible within a learning organisation?