Agile and Cybernetics

Software development is a complex endeavour, that’s why Agile is very relevant. Agile methods enable us to cope with this complexity. I want to give one explanation why Agile works.

Ashby's Law - Photo by Dave Gray

Credit: Flickr – Dave Gray

This post will also prove that command-and-control is not working to solve a complex problem. I will show this by linking software development to Cybernetics, the science of controlling. The special discipline of Management Cybernetics was introduced by Stafford Beer in 1959 and relates Cybernetics to management. Economist Fredmund Malik references Management Cybernetics in his work. As I mentioned in the previous post, the science for leading agile organisations already exists.

Ashby’s Law

Ashby was a pioneer in cybernatics. Ashby’s Law is also called the Law of Requisit Variety. Understanding Ashby’s Law requires to understand variety. The variety is a measure of a number of distinct states of a system. This measure can be used to exemplify complexity in a system. Ashby’s Law describes the condition for the variety in two systems, that make it possible for one system to control the other.

Simplified, the law leads to the following rule: The higher the variety of the controlling system, the better it is able to cope with the variety of the system under control. If the system that I want to control has three different possible distinct states and the controlling system has only two possible distinct states, then the direct control will be impossible.

Let’s take another simple example to explain this law in our domain. The system that we want to control is an existing legacy software and the controlling system is a programmer that needs to fix a defect. Variety in a software system is higher, if the software system has more lines of code. The more options the programmer knows to change the code, the better are the chances to fix the defect. Or on the side: more simplicity in legacy code leads to better chances to fix the defect.

Imported to note is that we have two possibilities to get to a successful control and therefor a successful software development.

  1. Reduce variety in the system under control, which means simplify the problem that we are facing. It would mean to simplify the software or the scope of the problem.
  2. Create a controlling system with more variety, which means you get a more complex organisation in the project team.

Agile and Ashby’s Law

Let’s apply this to a another example. The system that is under control is a business problem that needs to be solved by creating a piece of software. The system that want’s to control is the project team. What can we do to improve the variety of the project team:

  • Skilled team members – the more tricks they know, the more options they have to contribute to the solution.
  • Collaboration between people to combine the variety of every single person. This increases the total variety of the team.
  • Team members from different function in one project team – a tester may see different options to solve a problem than a programmer.

These are only three things that help the project team. What are the things that reduce the variety of the project team, which we should avoid:

  • Hire less skilled people or don’t train people – well, that’s obvious.
  • Have a single person that commands other team members to execute his ideas. The variety of the whole project team is reduced to the variety of this single person.
  • Less possibilities to collaborate. Team members wont share their thoughts and combine them with others.
  • A fixed organisation with defined roles (Architect, Lead Developer, …). This reduces the options that the team has to re-organize and adapt in the solution process.

This explains quite nicely why so many things in Agile are helping us to get the job done. It also explains, why a command-and-control culture is not helping us to solve a complex problem.

What are the implications for management?

In Agile we make all the things explicit that increase the variety, e.g. self-organised teams that are empowered to make the decisions, no explicit roles in teams and close collaboration. As a manager you create the environment for such an organisation. This organisation is a complex social system and can be very precious, when it’s functioning well. You can compare it to a biotope. Like with a biotope, you cannot mindlessly intervene in the system. Making a change in the system may have destructive results, that you cannot foresee.

Since it seems very difficult to lead such a complex social system, managers usually fall back into old habits. They constrain the individuals, introduce roles, create hierarchies or directly intervene in the solution process. But all this reduces the variety in the development organisation and therefor will create a system that is not able to cope with the complexity. Additionally the complexity of the problem to solve will be reduced by demanding big upfront specification. And then we are back to the waterfall environment.

How can you create and lead an agile organisation, to actually cope with more complex challenges of the enterprise? I will cover this in the following posts.

Veröffentlicht unter Agile, Management

Agile Management vs. Good Management

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

Veröffentlicht unter Agile, English, Management

Agile for Digital Transformation

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.

Veröffentlicht unter Agile, English

User Stories, Epics, Themes and MVPs

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?

Veröffentlicht unter Agile, English

Design Thinking meets Agile

Seit einiger Zeit beschäftigte ich mich mit Design Thinking. Diese Methode hat eigentlich nichts mit Software-Entwicklung zu tun. Sie soll dazu dienen, innovative Ideen hervorzubringen. Agile Methoden verfolgen in erster Linie das Ziel, auf Veränderungen der Anforderungen zu reagieren. Aber wie kommt der Anwender oder Kunde überhaupt auf die richtigen Anforderungen?

Was ist Design Thinking?

Diese Methode basiert auf eine Reihe von Werten und Prinzipien, die jedoch nicht so gut niedergeschrieben sind, wie die Werte und Prinzipien im Agilen Manifest. Die beiden Wertesysteme sind aber sehr ähnlich und daher kompatibel. Zusammengefasst ist bei Design Thinking folgendes wichtig:

  • Gutes Design ist nicht das Ergebnis eines einzelnen, sondern eines interdisziplinären Teams.
  • Teams arbeiten iterativ in festen Zeitrahmen (Timebox).
  • Jeder wird zum Experimentieren ermutigt.
  • Fehler werden als Anlass zum Lernen angesehen.
  • Teams involvieren echte Benutzer in ihre Arbeit.
  • Jeder lässt sich inspirieren von anderen Ideen, Prototypen und Lösungen.
  • Empathie ist notwendig, um die Bedürfnisse der Benutzer zu ergründen.

Ein wichtiger Aspekt vom Design Thinking ist das interdisziplinäre Team, also ein Team, was sich in einer Firma aus verschiedenen Bereichen rekrutieren würde. Zu einem solchen Team könnten z.B. Techniker und Marketing-Leute gehören. Dieses Team durchläuft einen Prozess, der jedoch nicht starr und rigide ist. In den Prozess können je nach Bedarf Iterationen eingefügt werden. Ein wichtiger Bestandteil dieses Prozesses ist die Entwicklung von Prototypen, die dann an echten Benutzern getestet werden.

Konkret beschäftig sich Design Thinking nicht nur mit Werten und Prozessen, sondern auch mit Praktiken, in die in einzelnen Phasen des Prozesses angewendet werden können. Dazu gehören, z.B.:

  • Story Telling
  • Verschiedene Brainstorming Techniken
  • Prototyping

Wir bezeichnen Design Thinking auch als einen “Body of Knowledge”, der von verschiedenen Seiten weiterentwickelt wird. Im letzten Jahr fand in Deutschland die erste Design Thinking Konferenz statt. Mittlerweile entwickeln sich lokale Gruppen, die sich mit Design Thinking beschäftigen. Aktuell wird gerade die Gruppe Design Thinking München gegründet.

Product Owner als Flaschenhals

In der agilen Methode Scrum ist der Product Owner verantwortlich für das Hervorbringen und Priorisieren der Anforderungen. Er legt die Anforderungen als User Stories ins Product Backlog und das Entwicklungsteam setzt diese Anforderungen um. Aber wie kommt der Product Owner zu den richtigen Ideen? Sind die Features, die er umgesetzt haben möchte, die richtigen? Da er eng mit dem Team zusammenarbeitet ist die Situation viel besser als im herkömmlichen Wasserfall. Der Product Owner kann direkt Ideen auf technische Machbarkeit mit dem Team klären. Ob diese Ideen dem Kunden bzw. Anwender der Software helfen und mehr als ein “Me Too”-Feature sind, wird mit dem agilen Vorgehen nicht angegangen.

Wedding Day by flickr:Mike_fleming

Die agile Community hat dieses Problem erkannt und schaut über den Tellerrand. Design Thinking bietet Anregungen, die Arbeit des Product Owner anders zu organisieren, sodass innovativere Produkte entstehen. Viele Konferenzen haben mittlerweile Design Thinking als Thema, so z.B. die SEACON in Hamburg oder die XP2012. Pierluigi Pugliese und ich waren bereits mit dem Vortrag “Innovation needs Waste!” auf verschiedenen Konferenzen. Ich bin gespannt, wie sich der “Body of Knowledge” Design Thinking mit dem der Agilen Softwareentwicklung verbindet. Beide Communities können von einander lernen.

Veröffentlicht unter Agile, German