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.

Artikel zu flexiblen Architekturen online

Früher oder später werden Softwaresysteme unwartbar. Änderungen werden so teuer, dass sie faktisch unbezahlbar werden. Irgendwann werden die Schmerzen so groß, dass ein neues System entwickelt wird. Und das Spiel beginnt von vorne. Dabei handelt es sich aber nicht um ein Naturgesetz. Wir können Software entwickeln, die sich langfristig zu moderaten Kosten weiterentwickeln lässt – und das, obwohl wir auch bei der initialen Entwicklung nur moderate Kosten verursachen

Der vollständige Artikel findet sich hier.

Definition of Ready: A double edged sword

A german version of this article is available at: https://www.it-agile.de/wissen/agile-teams/definition-of-ready/

The Definition of Done is a well known concept in Scrum: The Scrum team defines when a feature is Done and may be demonstrated during the Sprint Review. The Definition of Ready is a newer concept that is less common. The Definition of Ready states the conditions under which a User Story (or more general a Product Backlog Item) is ready to be included into the Sprint. The goal is to avoid working on User Stories in the Sprint that are too fuzzy to be successfully finished within the Sprint. This is definitely a good intention since often development start to work on a User Story although their understanding of the User Story is too weak. In that case working on the story may be blocked due to necessary clarification or work may loose focus due to different interpretations of the User Story.

On the other hand the Definition of Ready may be used to create an over regulated process that impedes collaboration between Product Owner and development team: Whenever there are communication problems between Product Owner and development team the Definition of Ready is extended by a new policy. After several “improvements” the Definition of Ready requires the Product Owner to specify each requirement correct, complete and consistent pre-checked by another Product Owner and a Software Architect to avoid any ambiguity or missing details.

This is NOT Scrum and it is NOT Agile.

The Agile Manifesto has something to say about the intended relation between the Product Owner and the development team:

  • “Individuals and interactions over processes and tools”
  • “Business people and developers must work together daily throughout the project.”
  • “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
  • “The best architectures, requirements, and designs emerge from self-organizing teams.”

Don’t forget about the underlying values and principles of agile development! For the Definition of Ready I recommend: The smaller the better. The team becomes more and more capable of handling incomplete information. Therefore the Definition of Ready should be shrinking over time and not growing (while normally the Definition of Done is growing with the capabilities of the team).

 

Moreover the Definition of Ready should focus on the process not the artifacts (like User Stories). I prefer “Product Owner and Development Team defined the acceptance criteria of each User Story collaborating in a workshop.” over “Each User Story has acceptance criteria.” as part of the Definition of Ready.

References

 

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.

Understanding Sprints and Timeboxes

There was a lot of buzz and critics about Scrum-like Sprints around the last time. One of the merits of the discussions was that now only the how but also the why was discussed. I try to do a short wrap up of what I read and think.

Forcing Hard Decisions

A Sprint in Scrum is timeboxed. Every Sprint has the same length and it ends when the time has come – no matter how much we completed. Jim Highsmith wrote on Twitter about timeboxes: “I’ve always said timeboxes weren’t about time, but about forcing hard decisions.” I think this is an important statement since it questions what a lot of Scrum teams do: Plan what to do during the Sprint and get the approval for that in the Sprint Review. When we look at the Sprint through Jims Eyes we get something different. First we have to think about the “hard decisions” we want to force. There are definitely several options. In my point of view there are two very important questions nowadays, that are related to each other:

  1. Did we validate or invalidate our assumptions?
  2. Did we produce value for customers and users?

The Sprint timebox forces us to decide how to proceed based on the feedback we got. Should we pivot or persevere? Should we stay with the current Product Backlog or adapt it?

Without timeboxes it is – of course – still possible to force these hard decisions. But most of us like to avoid hard decisions and tend to postpone and postpone and …

Creating Rythm and Flow

Tobias Mayer wrote on Twitter: “Reading anti-timebox tweets. It’s amusing how much disgust is aimed at a unit of time. Units of time create rhythm. Rhythm creates flow.” He added a blog post called “Timebox != Commitment” where he explains his perspective on timeboxes. It is NOT:

  1. Set a timebox size
  2. Commit to a bunch of work
  3. Realize you are failing to complete it all
  4. Rush to finish
  5. Produce crappy work
  6. Be exhausted
  7. Go to #2—repeat until dead, or company goes out of business

But it is:

  1. Set a timebox size
  2. Engage in dialog with requester/s. Review requests, prioritize
  3. Select a request, small enough to fit inside the timebox
  4. Complete the work to the satisfaction of the requester
  5. Breathe [reassess remaining requests if necessary]
  6. Go to #3—until there is no request that can fit in the remaining time.
  7. Stop work [if time remaining, take Slack time]
  8. Reflect. Learn from mistakes, and adapt accordingly
  9. Go to #2—repeat until all requests met, or deadline arrived at.

This perspective is supported by the latest modifications to the Scrum-Guide published by Ken Schwaber and Jeff Sutherland: The development does not commit to the Sprint Backlog but does a forecast (like a weather forecast) about what might be achieved.

Other options

Scrum-like Sprints are one possible implementation of timeboxes. I know of at least two other possible implementations. Here are the three options I am aware of:

  1. In Scrum we batch together a set of features during the Sprint Planning and use this feature set for the Sprint Review.
  2. In Kanban planning and release/review cadences are often decoupled. Review cadences can still be used in a timeboxed way (in the sense of Jim Highsmith to force hard decisions). In this case we batch together some features for review but not for planning.
  3. Eric Ries suggests to have a kind of deadline per feature in his book “The Lean Startup“.

In the end it is just the question of when and what to batch together and that is a question of transaction/coordination costs. Batching features together for a review is an easy-to-implement solution when we want to get face-2-face feedback from customers and users. When we have a lot of active users and work a lot with Lean Startup-like cohort metrics and the like we may not need to batch together features for review. Batching features together for planning is an easy solution when the “feature requesters” are not continuously available. When the “feature requester” is available all the time (e.g. because the Product Owner role is shared across the team) it may not be the best solution.

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.

Scrum in project business

Scrum is for product development. Check. There is the Product Owner, the Product Backlog and the Product Increment. Check. There is no project in the Scrum framework. Check. But…
What does that mean for all the service providers that are in the project business? They develop whole software systems and single features for clients. Therefore they face a broad range if project sizes: months or years with complete teams as well as one to ten days for a single developer. Therefore one of challenges for these companies is the so called resource management: How to staff all the projects and how to ensure that everybody is working on paid tasks.
When applying Scrum to these contexts I recommend to ignore the Scrum framework for a while and think about the Scrum core. That is – in my humble opinion: a cross-functional team with end-to-end responsibility that applies inspect&adapt to the what and the how of their work.
Therefore I suggest to start with the team and not the project: form long term stable teams and reorganize work so that it matches the team concept. Every team has its Product Backlog with all the thing they plan to deliver. These may be features of a larger development project mixed with single feature requests. Assign a Product Owner and ScrumMaster to each team or even better let the teams self-select Product Owners and ScrumMasters.
E voila: Ready to start with Scrum for projects and a lot of new options will occur. The teams could take over additional responsibilities like writing the offers, managing customer relationships, hiring new team members etc. Be prepared to be surprised.

References

Scrum for Top Managers

“As a top manager I want to introduce Scrum.”

“Don’t!”

“What?”

“Ok, you are used to say people what to do. But Scrum is about not saying people what to do. You should not start the journey to self-organisation with command&control as the first step.”

“So I am not allowed to do anything? I just have to sit here and hope that something changes for the better? You are kidding!”

“Of course you can do something. To make change happen you have to do something. But focus on the goal not on a specific approach like Scrum, XP or Kanban. So what is your primary goal?”

“I want shorter time to market and better products.”

“Fine. You could tell the team that you want to see running software demonstrated to happy customers every 14 days. And you leave it to the team how it achieves this goal. You should offer your help when impediments occur and you could offer to hire a coach. But the most important thing is: don’t interfere with the work the team is doing. Focus on their achievements.”

References

This blogpost is very much in line with Tobias Mayers Scrum: a 5-step guide for managers.