Elastic Leadership or How to Be a Better Team Leader

First time I heard about the Elastic Leadership, where the leadership changes based on the three team phases, was in March 2011 during QCon in London. I knew the speaker Roy Osherove already because of his book “The Art Of Unit Testing”. However this time he gave a talk with the title “Team Leadership in the Age of Agile” as a part of the „Software Craftsmanship“ track. Roy talked about things I’ve felt or even done already, but they were not transparent to me. He gave those things the names. At the end of the Session Roy played guitar and the whole audience was simply delighted. Me too.
From this day forward I decided to follow up the activities of Roy at his 5whys.com homepage. His idea about the Elastic Leadership got matured and my personal experiences I’ve collected during last months have confirmed he was right! So let’s explain shortly what the Elastic Leadership is and how it suits to the agile software development.

The Roy’s main idea behind the Elastic Leadership is based on the realization that the role of the team leader is not to solve the team’s problems. If you do so, the only person who learns is the team leader and additionally having the control over all topics, caused the team leader to be a bottleneck.
The role of the team leader is to get the team grow. If you grow people the value delivered by the team grows and additionally the commitment of the team to work effectively and efficiently grows as well. Your team is motivated internally, loyal and happy.
The role of the team leader is to get the team grow.
To grow the team, the team leader has to help the team members to learn, to acquire new skills. And because my definition of Agile says “Agile is about learning”, this type of the leadership suits ideally to the needs of the agile software development.
I fully agree with Roy that if you as a team leader want your team to learn, you have to challenge it, challenge the team members to solve their problems on their own. Agile frameworks like Scrum have this challenge in focus due to their empirical pillars knows as transparency, inspection and adaption.
Roy points out however that sometimes this way of leadership named “challenge to grow” might not be the perfect solution. Sometimes the team leader has to take the control, make hard decisions and decide for and not with the team. On the other side sometimes the team has to be left alone, because the guys know what they are doing. Regardless if you are already a team leader or if you are just a team member I suppose you do agree with these observations.
These three leadership styles can be named, according to the Roy’s definition as a command and control style (I name it commander style), coach style and facilitator style. As a commander you are the decider, you tell people what to do. As a coach you are challenging the team to solve its own problems, teaching the team members how to make decisions and how to be self-organizing. As a facilitator you make sure that the project environment delivers everything the team needs to get project done.
There are three leadership styles: command and control style (or commander style), the coach style and the facilitator style.
However, the question is how to recognize which leadership style is right? Do you have to change the leadership style, and if so what are the conditions to do it and when? The foundations for the answer on these questions are so called “three team phases” a team can belong to: the chaos phase, the learning phase and the self-organizing phase. Depending on the team phase, the team leader has to change the leadership style he or she uses. And that is the core of the idea. Elastic, adaptable or I would simply say, agile way of leadership, where the leadership style changes depending on the phase of the team.
There are three team phases: the chaos phase, the learning phase and the self-organizing phase.
Depending on the team phase, the team leader has to change the leadership style he or she uses.
According to the Elastic Leadership, a team is in the chaos phase if it has not enough time to learn. The main goal of the team leader in such situation is to get the team out of this phase by creating so called slack time. This time the team needs to focus on learning. It is quite obvious that in this phase the most appropriate style of leadership is the commander style.
If a team is in the learning phase it means it learns to solve its own problems. The team is still not self-organizing (it learns to solve) but it has enough time to learn and experiment. In this phase the team leader should change the leadership style from commander to the coach style.
The team leader’s goal should be always to get the team into self-organizing phase. In this phase the team knows what and how to do, the members have proper skills to solve their problems, they are able to experiment and evaluate on their own. The leadership style should be changed into facilitator style.
What is additionally important is the pace of leadership style changes. Roy defines two assets their changes can force the team leader to change the way he or she leads the team: team skills/knowledge and the amount of slack time (I would prefer to call it schedule). So any changes to the team structure, any changes in the scope of the project that requires additional knowledge or any changes to the schedule that impact time the team has to learn could cause the change of the team’s phase, thus change to the leadership style. And we know how our projects are, such changes can happen every day.
The Elastic Leadership is a great tool and I’d like you to convince you to use it in your projects. Roy has written a great book about his concept “From Chaos to Self Organization – Growing Effective Software Teams”, that can be found at his 5whys.com.


Cool, My Paper Has Been Accepted at Manage Agile 2012!

I will talk about "Agile Culture Capability Model - Impedance Mismatch and Influence of the Culture Standards on Agile Projects with Onsite-/Near- und Offshore Teams". See you at the conference: 16-18/10/12 Berlin, Germany, http://www.manage-agile.de/.


Extreme Scrum: Using SIP to Create a Matured Product Backlog – Part I: Partitioning

Do you know SIP? No? You should. SIP stands for Simple Iterative Partitions and has been developed by Roger Sessions some years ago. It is a methodology specifically focusing on the problem of controlling business and IT complexity. SIP focuses on managing critical aspects of enterprise architectures and promises a huge increase of the return on your IT investment. If you want to know more about SIP just visit the inventor’s homepage here.
But what is actually the reason I’m writing about SIP and enterprise architecture? Our goal, as stated in the title of this blog entry, is to create a matured product backlog, isn’t it? After I have read the book about SIP some months ago, I was quite convinced I could reuse the principles and laws defined by Sessions not only to create an enterprise architecture (I’m an architect too) but also for any other area where the complexity has to be controlled and finally reduced. And my first candidate was the Scrum’s Product Backlog.
As defined in the Scrum tutorial the Product Backlog is one of the Scrum’s artifacts. It is actually an ordered list of the project requirements. These so called product backlog items describe what has to be built and they are maintained by the Product Owner. The Product Owner decides, based on the business value, risks, dependencies etc. about the priority of each of the product backlog item. Those product backlog items are commonly written using the well-known user story format. All these activities are often called Product Backlog grooming.
It seems to be quite easy to create some user stories and prioritize them, isn’t it?… However it is not the case as you might already have experienced in one of your projects. Especially at the beginning of product backlog construction you will get into trouble looking for the answers to common questions like “how to define a good user story”, “how to group user stories”, “how to reduce complexity” and so on. Our aim is to have our Product Backlog DEEP defined (DEEP is an acronym coined by Roman Pichler and Mike Cohn and states for Detailed appropriatelyEmergentEstimated, and Prioritized). And that is exactly where the SIP principles and laws come into the game.
SIP process consists of three phases named preliminarypreparatory and iteration. For our goal the phase preparatory is the most interesting one. It comprises three sub-phases:
  1. Partitioning – grouping of the functionality
  2. Simplification – consolidation or removal of unnecessary functionality
  3. Prioritization – determination of priority based on business value, risks and other factors
As you can see, apart from prioritization the Product Owner will have to fulfill two additional tasks named partitioning andsimplification that are not specified by the Scrum methodology.
So the next question is how to conduct partitioning and simplification? In case of partitioning the SIP proposes to use the Five Laws of Partitions, which I have adopted to our purposes. Important: according to the definition used by Session, a partition is a set of subsets that divide up some universe such that every element in the original universe ends up in one and only one of the subsets.
Let’s look now at these Backlog Partitioning Laws. I call them simply BaPaL. The first two laws are the most important ones:
First BaPaL: partitions must be true partitions in the mathematical sense. For the user stories, this means that the functionality must be broken up into a set of subsets such that every function ends up residing inone and only one of the subsets. In case of the user stories these subsets are called epics (it quite obvious I hope). I call this law the BaPaL of Disjunction.
As an example let’s take a simple webshop application. For such system the partitioning is always driven by the business domains so we can easy define such partitions like Sales, Order, Customer, Billing etc. In case of the Sales partition we can assume that a customer should be able to search for a product, to buy it, to return it, to register herself and so on. These are ideal candidates for our subsets because they are separated business processes. A bad candidate for an epic would be e.g. “Create a PDF-Document” subset (with user stories like “Create a PDF for Invoice”, “Create a PDF for User Profile”), because it is a generic functionality, thus it violates the BaPaL of Disjunction.
Second BaPaL: partition definitions must be appropriate to the problem at hand. For the user stories, this means that an epic must contain user stories that are closely related to each other. Ideally such relationship means that functionality defined in user story A always requires the functionality defined user story B and vice versa. I call this law the BaPaL of Synergy.
In our web shop example, let’s define one epic named “Buy a Product”. What are the user stories that are compliant with the BaPaL of Synergy? I would say these are “Search a Product by Name”, “Add a Product to Cart”, “Checkout”, “Create a PDF for Invoice” and so on. A bad candidate however would be the “Register User” user story, because it violates the BaPaL of Synergy. Why? The user stories in the epic “Buy a Product” don’t require the “Register User” user story (often you can buy products “ad-hoc” providing your data for the purchase purposes only) and vice versa, the “Register User” user story doesn’t require any user story from the “Buy a Product” epic (you can register yourself without buying anything). The “Register User” user story cleary belongs to the “Maintain User” epic and not to the “Buy a Product” epic.
The next two laws are about sizing. Equal sizing promotes easier managing, organizing and administering of the product backlog. Here they are:
Third BaPaL: the numbers of epics in a partition must be appropriate. For the user stories, this means that the number of epics that make up a given partition should be in the range of 3 to 10 (based on my personal experience). I call it the BaPaL of Equal Partition Size.
Fourth BaPaL: the size of the epics in a partition must be roughly equal. For the user stories, this means that you don’t want to end up with large differences between the amount of functionality in the different epics of the partition. I call it the BaPaL of Equal Content Size.
And the last law is about interactions between subsets:
Fifth BaPaL: the interactions between subsets in the partitions must be minimal and well defined. In practice, this means that you might have to define more than one user story to support functional interfacing like cross-cutting concerns (security etc.). I call it the BaPaL of Fortress.
Going back to our webshop example, in case a customer would like to register herself (using the user story “Register User” that is actually a part of the “Maintain User” epic) during the checkout process (using the “Checkout” user story that is part of the “Buy a Product” epic) this interaction “must be minimal and well defined”. In this case we should define an additional user story called “Proxy Register User” or similar, that contains tasks allowing this interaction and place it in the “Buy a Product” epic.
I hope I was able to convince you that by applying these laws you can create very good user stories; however your product backlog still won’t be perfect. In the second part of this blog entry I will talk about the simplification. Stay tuned…


Agility, Continuous Delivery, BigData and the Theory of Constraints

I was always fascinated by the new ideas driving our IT landscape. Oh, these new buzzwords changing so fast, these new trends giving us the ability to convince the customer and allowing our IT-ego to grow up, and this tremendous feeling during learning something new, that nobody else knows…

However the “dark side of the moon” of this feeling was always the uncertainty if the chosen topic would be later the hype on the market that could guarantee the ROI or just a simple flop… My decision what to choose, was made mainly based on my stomach feeling, which as you may suppose, was not the most effective method. I needed a better one.

The process of decision making requires setting up objectivities. As a big fan of simplicity I reduced this step to a just single objectivity and renamed it into the goal. So what is our goal? Our goal is to make money.  Ok, in case of a non-profit organization it might not be the case but most of us work for a “normal” company, which has to be profitable. How can I recognize then if the improvement being expected by the introduction of a new IT-trend has really caused that my company makes more money? Everyone who has had something to with the process of improvements would immediately say: we need some measurements. And these are: throughput, operational expense, and inventory.
The most important information you can get from these measurements is the direction of change of the measurement values. We are making more money only when the throughput increases and the inventory and the operational expense decrease. And only then when all three measurements behave like that in parallel.

So let’s try with the Agility: will the introduction of the Agility cause my company making more money?
IT-Trend Throughput Inventory Operational expense
Agility Driven by queuing theory and concentrating on eliminating bottlenecks Agility clearly increases the throughput. The introduction of frequent deliveries, definition of done etc. clearly reduces the size of unfinished code thus decreases the inventory. Reduced inventory as well as self-organizing and role-less teams clearly decreases the operation expense.
As you can see the Agility increases throughput and in parallel it decreases inventory and operational expense thus the introduction of Agility will cause you company making more money. It’s great, isn’t it?
However what about other IT-trends like Continuous Delivery?
IT-Trend Throughput Inventory Operational expense
Continuous Delivery Automating the process of delivery clearly increases the throughput. Frequent deliveries decrease the inventory. However the non-reliable automation of delivery plus lack of release coordination might increase the operational expense.
As you can see in this example the introduction of Continuous Delivery might not guarantee your company will make more money.

And what about BigData?:
IT-Trend Throughput Inventory Operational expense
BigData Using new ways of storage (e.g. NoSQL) clearly increases the throughput. Big amount of data might increase the inventory (unused data which has to be maintained). The way how data is stored (e.g. key-value) might decrease the operational expense.
Looking at the table above you can expect some problems with the introduction of the BigData solution and similar as in case of Continuous Delivery it might not guarantee your company will make more money.

These were only three examples of rather subjective evaluation, however the way of deciding is much better as in case of decisions made based on the stomach feeling. I’d like to encourage you to try with other IT-trends. It really works :).

The notion in this post is based on the ideas found the ingenious book The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt and was driven by his Theory of Constraints.
The underlying premise of theory of constraints is that organizations can be measured and controlled by variations on three measures: throughput, operational expense, and inventory. Throughput is the rate at which the system generates money through sales. Inventory is all the money that the system has invested in purchasing things which it intends to sell. Operational expense is all the money the system spends in order to turn inventory into throughput (Wikipedia).


Inversion of Stress (IoS)

As a project manager and coordinator of various teams I had always to do with the topic named stress. It is a common sense that the word project is bound to the word stress and they build a couple that is present in every project. You will hear such sentences like “it was stressful”, “we had too much stress” etc. during almost every review or retrospective meeting.

Actually the stress in a project is not the problem. It will always be present and it has also its good side effects. The problem is the stress strength and its effect on the project team members. If the stress strength achieves the threshold of unhealthy stress strength or even exceeds it, it will cause valuable damages to the team, thus to the entire project. Additionally this threshold exceedance may occur at the end of a project, especially between end of the build phase and start of the run phase, where the project is very fragile, so you won’t get any chance to react and repair any damages. As a result the project may encounter a serious problem to close successfully. Let explain me this based on the following diagram:

As you can see we have three curves. The internal stress curve depicts the stress level caused by the internal characteristics of every project member. We are all humans. You can also understand it as the excitement curve. At the beginning of a project, during transition between the plan and build phases, every member of a project team is excited to some extent. During the build phase the stress strength is quite low, and explodes at the end of the project. “We are going live!”.

Second curve is the external stress curve that depicts the stress level caused by the external factors like low skills, bad planning, micro management, lack of processes and all that stuff classified as the project risks. As you can see, even if the roots are quite different the flow of the external stress curve is almost identical to the internal stress curve, however with stronger amplitude.

What is however really important is the fact that these two curves interfere and build the stress strength interference curve, which values can suddenly reach the threshold of unhealthy stress strength.

Unhealthy stress strength is simply… unhealthy. The most common symptom of it is the disintegration of the team, thus the transition from the team to the group of individuals.

To avoid such situation, I have introduced in my latest two projects a method named Inversion of Stress (IoS). This name might not be the perfect one for that solution but nowadays everyone would like to have something based on iOS, me too, so I have invented the IoS :)… Ok, back to business.

The only curve a project manager or a coordinator has influence on, is the external stress curve. Knowing that its normal behavior means high stress strength at the end of the project I have decided to simulate this behavior… at the beginning of the project. That is the inversion. The aim was to recognize where the threshold of unhealthy stress strength is.

How to achieve this goal? It is not so complicated but requires some good discipline and observations skills. Here a proposal of actions that can increase the stress strength at the beginning of a project:
•    Introduction of strong risk management
•    Introduction of effort tracking system
•    “Healthy” micro management (“drugs under control”)
•    Introduction of code reviews
•    Involvement of testers and operators in the project

Due to the fact that these actions were introduced under my strict control I was able exactly to observe the results and to avoid the risks of the exceedance of the threshold of unhealthy stress strength at the end of the project.
I wasn’t also afraid of consequences reaching the threshold, because I had always had time to reduce the stress strength again and to repair the caused damages. Additionally I have gained a lot of acceptance from the team, as the person “who can listen to the team”, “who is there to protect them”! Wow...