How cross-functional should my Team be?

In a Lean/Agile world teams should be cross-functional. Period.
Or maybe it’s not that easy? What does cross-functionality actually mean? And is it true that the more cross-functional, the better?

I wrote an article together with my brother Arne Roock adressing these questions. The article is published in the current edition of the “Agile Review” by it-agile. The article is available as PDF for download. (There is also a german version of the article).

Wie cross-funktional soll mein Team sein?

Agile Teams sollen cross-funktional sein. Punkt. Oder ist es vielleicht doch nicht ganz so einfach? Was genau bedeuted Cross-Funktionalität eigentlich? Und gilt generell die Regel: Je cross-funktionaler, desto besser?

Zu diesen Fragen habe ich zusammen mit meinem Bruder Arne Roock einen Artikel verfasst, der in der aktuellen Ausgabe der “Agile Review” von it-agile erschienen ist. Es gibt den Artikel auch als PDF zum Herunterladen. (Es gibt auch eine englischsprachige Version des Artikels als PDF).

Buchempfehlung: Tribal Leadership

Nicht mehr ganz taufrisch ist das Buch “Tribal Leadership” von Dave Logan, John King und Halee Fischer-Wright. Trotzdem ist es immer noch sehr lesenswert für jeden, der sich für Team- und Unternehmensentwicklung interessiert.

Das Buch vertritt die These, dass für die Leistungsfähigkeit von Teams und Unternehmen die vorherrschende Kultur wichtig ist. Sie stellen ein 5-stufiges Modell der Kulturentwicklung in Teams/Unternehmen vor:

1. “Life sucks” – Das Leben an sich ist schlecht und es wird auch nicht besser werden. In dieser Stufe kommt es häufig zu Gewalt gegen andere oder sich selbst – wenn das Leben sowieso an sich schlecht ist, ergibt es auch wenig Sinn, sich an moralische Maßstäbe zu halten.
2. “My life sucks” – Das Leben anderer Leute mag gut sein, aber mein Leben ist schlecht. Auch wenn der Übergang von “Life sucks” zu “My life sucks” sich häufig wie eine Verschlechterung anfühlt, ist es ein Fortschritt. Die Erkenntnis, dass das Leben nicht für alle schlecht ist, enthält die Chance, dass es für mich auch besser werden kann.
3. “I am great (you are not)”: Ich bin großartig, viele andere leider nicht. Daher muss ich immer alles selbst erledigen. Dieser Zustand ist der vorherrschende Zustand in den Unternehmen in den USA (und sicher auch in den meisten anderen westlichen Ländern).
4. “We are great (they are not”: Jetzt steht das Team-/Unternehmensergebis im Vordergrund nicht mehr das, was ein einzelnes Individuum leistet. Das Team/Unternehmen grenzt sich dabei gegen andere Teams/Unternehmen ab und definiert sich auch dadurch, dass es besser ist.
5. “Life is great”: Jetzt verschwindet die Abgrenzung gegen andere und ein höheres Ziel (Noble Goal) definiert das Team oder das Unternehmen.

Laut den Autoren kann man bei der Kulturentwicklung Stufen nicht überspringen. Wenn man sich auf Stufe 2 befindet, kann man sich nicht einfach zu Stufe 5 weiterentwickeln, man muss den Weg über die Stufen 3 und 4 nehmen.

Das Buch zeigt Techniken, mit denen man (anhand der verwendeten Sprache) den Zustand von Teams/Unternehmen bewerten kann sowie Techniken, wie man die Kultur weiterentwickeln kann.

Das ganze ist übrigens nicht einfach ausgedacht, sondern mit Studien belegt und so finden sich in dem Buch immer wieder Fallbeispiele zu den einzelnen Stufen.

Von mir eine eindeutige Leseempfehlung für alle, die sich für Unternehmensentwicklung interessieren.

• Ein Cheat-Sheet gibt es als PDF.
• Und es gibt eine Webseite zum Buch.

it-agile 28 weeks later

In january I blogged about the internal state of it-agile. Let’s have a look what changed during the 28 weeks since then.

• We have introduced autonomous business teams to enable scaling and support local experimentation. The business teams synchronize monthly at a whole-day face-2-face meeting and with an offset of two weeks at a shorter monthly telco.
• After we introduced the teams we discovered some limits to the teams’ capabilities. Not every team was able to generate sufficient customer demand to “make a living”. Therefore we created a virtual sales team (consisting of members of business teams) that focused on demand creation.
• There was a institutionalized group called “senior consultant group” consisting of the two CEOs and the two most senior consultants. This group decided to dissolve since most of its responsibilities were transfered to the employees and business teams over team.
• One left over was the process for deciding on salaries. Employees had and have peer groups with whom they discuss their personal development and peer groups may suggest increases in salaries. The final decision was made by the “senior consultant group”. As this group dissolved completely we introduced a “SalaryChecker” group consisting of four people elected by all employees. (The two CEOs were proposed as candidates for the group but didn’t accept the nomination. The current “SalaryChecker” group consists of the two “seniors” of the original board and two other employees.
• Intrinsifier published an article about it-agile.

Selbstorganisation im Unternehmen

Selbstorganisation in Teams ist durch Scrum und andere agile Verfahren heute quasi Stand der Kunst (ja, ich weiß, ess es vielfach in der konkreten Umsetzung noch hakt). Aber ist damit das Ende der Fahnenstange schon erreichen? Ich glaube nicht. Nun, um ehrlich zu sein, ich weiß sogar, dass das nicht der Fall ist (durch den Grad der Selbstorganisation, den wir bei it-agile aber auch einige andere Unternehmen erreicht haben).

Selbstorganisation über Teams hinaus und sogar im ganzen Unternehmen ist möglich. Ich habe Folien auf Slideshare hochgeladen, die zeigen, wie Selbstorganisation auf Unternehmensebene funktioniert: Folien

Die Folien stammen von einem halbtägigen Workshop, den ich bei einem Kunden zu dem Thema “Selbstorganisation im Unternehmen” durchgeführt habe. Wer so einen Workshop auch gerne bei sich im Unternehmen durchgeführt haben möchte, kann sich dazu gerne bei mir melden.

Risk Management in Complex Domains

We had a discussion with some it-agile colleagues about risk management in complex domains and if there is a relevant difference to complicated domains. Here is my current understanding.

Classical risk management in software development comes from waterfall like approaches tailored for simple and complicated domains. In a nutshell you create a list of all risks at the beginning of the project. Every risk has a probability and a potential damage. Multiplying probability with damage yields a kind of “risk cost” which is then used to prioritize the risks. After that we define countermeasures or mitigations for the risks. Here is a short introduction to classical risk management.

In my experience the focus of classical risk management  is on creating a plan that can be executed without big surprises. And second is focus is on avoiding the risk to ensure project success.

For this traditional approach it is crucial to anticipate cause-effect relations. That is possible in simple and complicated domains but not in complex domains. Therefore traditional risk management is of limited value in complex domains (yes, I tried it for some years).

Feedback driven approaches like Scrum have built in risk management for a lot of typical risks:

• Does the software match customer needs?
• Will we deliver in time?
• Does the software scale?
• etc.

But we believe there is more to it. Let’s have a look at a story told by Don Reinertsen at the LSSC 2012 conference about fire fighting. Fire in forests behaves in a complex way. It is impossible to forecast what the fire will do in the near future. There is the influence of wind and rain and even the fire itself may create relevant wind.

The fire fighters do risk management in a when-then pattern. “When the fire crosses this boundary, then we will evacuate this town.” It is not possible to guarantee that the fire will cross this boundary. Therefore we make a plan to minimize damage not to avoid the damage completely.

We think that this pattern of risk management is applicable also for software/product development. We identify the risks that may cause critical damage and were we need to react really fast. For these risks we create a plan what to when the risks becomes reality.

This is exactly what one of my clients did when the global financial crisis started. “When sales drops below this point we will reduce costs here and use money from another business area to avoid layoffs.”

With such a plan the appropriate preparations can be done in advance (e.g. not signing long term contracts that bind a lot of money and put new investments on hold). And it creates a safe atmosphere for employees. They see that there is a plan and that this plan does not include layoffs.

Conclusion
In complex domains risk management ist more “when X will occur we will do Y” than “to avoid X we will do Y”. (That doesn’t imply that traditional approach had no place n complex domains. It is just less important.) But one thing stays the same: More important than risk lists are the collaborative discussions about risks with and within the team.

P.S.: I used the term “risk management” throughout this blogpost although I think it is misleading. Risks in complex domains can’t be managed. We only can prepare to be able to react accordingly. But by now I don’t have a better term. I love to see proposals in the blogpost comments.

P.P.S.: I like to thank my colleagues for the discussions about the topic, namely Arne Roock, Norbert Hölsken, Christian Dähn, Jens Coldewey, Sebastian Sanitz (and I hope that I didn’t forget anyone).

Incremental Platform Migration

In Scrum workshops participants often come up with platform migration as a task not suitable for Scrum. Examples are the migration from Rails 2 to Rails 3 or from one EJB version to a new one.
For technological reasons it is often not feasible or even impossible to have both platforms in parallel in the system. And the new platform API has breaking changes. Therefore installing the new platform results in a completely broken system and the team would need several Sprints to have a potentially shippable product again. The consequence at first sight might be to adapt Scrum regarding shippable product increments or to use another approach.

Fair enough!

But: Sometimes we gather new insights when we make the probem worse. What would one do if we had to replace the programming language (e.g. migrating a COBOL system to Java)? You wouldn’t just install the Java compiler and try to compile the COBOL source files, would you?

You would rewrite the whole system step by step having potentially shippable code all the time. When this approach works for replacing the programming language it should work for an easier problem like replacing infrastructure as well. And it does.

Rewrite the system on the new platform/infrastructure feature by feature. Of course you make heavy use of copy&paste to reuse the existing code.

Is it worth it?
At first sight the incremental approach needs higher efforts. There has to be something on the plus side to make the approach attractive:

• Bugs are easier to fix: When you make a mistake during the big bang migration you will not recognize it until you have finished the whole migration. But then you introduced the error weeks or months ago and it will take you a really long time to figure out how to fix the bug. Using the incremental approach shortens the time from producing the bugs to detecting and fixing the bugs. That makes it much easier to fix the bugs and therefore reduces the effort.
• Remaining time is easier to estimate: When you proceed feature by feature you can compute an average velocity and create a rough forecast when all features are done.
• Release early: With proper prioritization you can deliver the migrated system to some customers long before all features are migrated. (You could start with the features for the customer who needs the smallest feature set). These early customers would give feedback about the system in production and so lower the risk of the whole migration.

Lawless Agile

In march 2012 seven it-agile people (including me) formed the StartupMarch team. We decided to build a product to make online discussions more effective. In the end we had built http://www.discuss2decide.com and http://www.discumeter.com.
This blog post is about the “process” we used. We just started to build the product – without any discussion of the process to use – Scrum, Kanban, XP? We just didn’t talk about it. This is what emerged:

• Before the start of the StartupMach we only had decided on the problem to solve (online discussions) and the technology we would use (Rails). So we invested the first day for some conceptual work.
• At the second day we started the development of the first ideas. We had the first product (Duscuss2Decide) live at day 3 and the second (Discumeter) at day 5. After that we had more than 15 releases per day. The rule was simply: whatever you commit into the master (aka Trunk/Head) will go live immediately.
• Typically we started the day with an informal wrap up of the product usage (a kind of review if you want). Then we discussed what to do during the day (kind of planning). And then we did it. For both “meetings” together we invested 30 to 90 minutes.
• During the day we had 2 to 4 sync meetings to check where were and how to proceed (kind of Daily Scrum).
• We did no Task Breakdown but Story Splitting on a very tiny level. We worked with MMFs (Minimal Marketable Features) that we broke down into User Stories. Most stories were done in less than 2 hours.
• We managed work in progress by gut feeling. Normally we all would work on the stories of one MMF (single piece flow). That way a MMF normally needed one day to complete.
• We did Pair Programming in most cases and often switched pairs at the sync meetings.
• We had two retrospectives. One in the middle of march, one at the end of march.
• There were no roles. No Product Owner, no ScrumMaster, no Testers etc. Just team members. During our second retrospective we had a discussion about the roles. The conclusion was that we sometimes would have profited from a ScrumMaster for facilitating discussions and forcing us to face uncomfortable facts. And we thought that the absence of a Product Owner person was helpful. The team was not only empowered to decide on how to do the work but also on what to work on.

It was a great time. We had a lot of fun, we learned a lot and it felt very productive. Although we didn’t acquire millions of venture capital for our products, Discuss2Decide seems to have value for users. There are some regular users of the tool and most online discussions at it-agile are done with the tool today.

Will it travel?
Will the “process” travel to other contexts? I don’t know. I think there were two special ingredients that are uncommon and may have been crucial:

1. With the seven team members we had roughly 45 years of experience with Agile of different flavors in the room: Scrum, XP, Kanban, FDD.
2. All team members shared a common cultural background (it-agile) that showed up as an extreme openness for other’s ideas, perspectives and needs.

Read more about the Startup March.

Artikel “Auf der Suche nach dem Qualitäter” erschienen

Mein Bruder Arne und ich haben zusammen einen Artikel mit dem Titel “Auf der Suche nach dem Qualitäter” im “Business Technology“-Magazin veröffentlicht, das in der Ausgabe 1.2012, Heft 8 ganz unter dem Titel “Qualität” erschienen ist.

In dem Artikel beschäftigen wir uns mit der Frage, was überhaupt Qualität ist und stellen die klassische Qualitätsdefinition (“Qualität ist die Übereinstimmung der Realisierung mit den Anforderungen.”) in Frage. Wir stellen die kundenorientierte Qualitätsdefinition (“Der Kunde definiert, was Qualität ist.”) dagegen und bringen diese mit agilen Verfahren wie Scrum und Kanban in Zusammenhang. Nicht zuletzt zeigen wir auf, wie die kundenorientierte Qualitätsdefinition in der Softwareentwicklung besondere Herausforderungen an die interne Qualität des Systems stellt.

Auf der JAX-Konferenz werden wir übrigens zum gleichen Thema zu sehen sein, allerdings in einem etwas ungewöhnlicherem Format (Schauspiel).

it-agile: State of Play

We founded it-agile seven years ago. This is a good reason to reflect on what we have achieved regarding management and organization within it-agile. Some of the things listed below were already in place seven years ago, others are just a few days old.
We believe that our employees are it-agile with the implication that the best employees would make the best it-agile. And we do not just aim for satisfied customers, we want to delight our customers. To express these believes we have a defined purpose:

“Create fulfilling jobs for our employees to delight customers.”

We achieve this purpose by:

• Transparency and openness: Nearly every information is visible for every employee including the wages, travel expenses and time sheets of every colleague (the CEOs are just colleagues also). On a company level the economic data etc. are accessible for everyone.
• Peer groups: Employees have self selected peer groups that work with the employee on personal improvements and suggest promotions.
• Pull principle: We have implemented the pull principle for coaching and development. Customer requests are visible for the whole company and employees pull these. So employees may choose to prefer jobs in their local area and decide on themselves if they are capable of doing the job.
• Meetings at it-agile are optional. Every employee decides for himself if he attends.
• As long as the results are achieved everybody can work when and where he wants. (Of course this has to be coordinated with colleagues and customers since most of the results can’t be achieved without colleagues and customers.)
• Every employee has 30 days of slack were he can do whatever he wants: go to conferences, work on a self selected project, read books, go to trainings, … Of course it is transparent within it-agile what everybody did.
• Employees don’t apply for holidays. They decide on themselves when they take their 30 days of holiday.
• Overtime: There is no pressure for working overtimes. Sometimes employees decide themselves to work overtime to achieve important results. The overtime is collected in a work hour account. Employees decide when to withdraw time from that account.
• Expenses: Employees decide how they travel and what equipment they need for their work. They don’t ask for permission. They just buy what they need.
• Profit sharing: About 2/3 of the company profits are distributed to the employees (in principle every employee gets the same percentage).
• Company ownership: About 2/3 of the company is owned by the employees. This implies ultimate empowerment: The employees can change ANYTHING. They could even fire the CEOs or change the purpose of the company completely.

Is it successful?

We have more employees, we have higher revenues and we have higher margins today than we had in the beginning. You never can be sure if the described principles created this growth or if it just was good luck. But I think we were and are successful.

Will it travel?
In general the described concepts shouldn’t be taken as a blueprint for another organization (although there are similarities with other companies like SemCo). I think we wouldn’t have been able to start with out current state even if we had known it. I think that we observed a kind of co-evolution during the last seven years. We made a small modification to the organization of the company. That enabled a small progress of company culture. This progress in company culture then enabled the next small modification of our company structure and rules. And so on…

Will it scale?
We started it-agile with 10 people. Now we are 35. In my point of view the things we did enhanced empowerment and autonomy which are important building blocks for our growth. The changes we made enabled growth. I think for further growth we have to intensify empowerment and autonomy even more.

The Future
Since there is no big boss at it-agile you never know what will happen next. There are some very interesting and challenging discussions in the moment.

BTW 1: We are hiring agile coaches and developers. (Notice; Sometimes people seem to think they wouldn’t match our expectations and therefore don’t apply for a job at it-agile. There is only one way to find out: Let’s talk!)
BTW 2: We offer consulting to managers who want to transform their company/business unit in an agile way towards more empowerment and autonomy.

References

• Christian wrote about his first impressions at it-agile (in german), especially the transparency.
• Bernd did a presentation about some of our changes at the Lean Kanban Central Europe Conference 2011.
• Henning and Jens presented some aspects of it-agile (in german) at the XP-Days Germany 2011.
• Jens wrote about self-organization at it-agile (in german) in his blog.
• Markus wrote about mentoring and peergroups at it-agile in his blog.
• Bernd wrote about the it-agile slack model in his blog.