The more agile software development becomes mainstream, the more often I run into a typical pattern of management mismatch. It comes in several flavors. A recent client CTO who is responsible for the IT of an online store illustrates one example. “We have just raised an additional budget of 1 million Euros for this year to implement this fantastic feature,” he told me. “And now I’d like to talk with you about how to cut the teams.” A management workshop on agile contracts with another client demonstrates a second example. The workshop began with its current situation: “We want to build this platform and already have three Fortune-20 clients on our list. Our mission is to …

For nearly 20 years now, management theory has been changing. It started with single books, such as Peter Senge’s Fifth Discipline. By the end of the 90s it had developed into several independent movements/management models. One of them was the Agile Software Development movement; others included the Beyond Budgeting movement and the Human Systems Dynamics movement. Though each of these movements was launched from a completely different perspective (e.g., organizational development, software development) each came to a very similar conclusion: The traditional way to organize companies is well suited for industry and mass production but hinders knowledge work and is unable to adapt to the ever-growing pace of the market. Traditional companies are based on a deterministic …
I recently watched a talk by a self-appointed agile "expert" who tried to explain the key elements of Scrum. There were lots of minor and major mistakes in his presentation, but the sentence that struck me most was: "User stories are what we call requirements in agile." The sad thing is not that much that this guy said was completely wrong, but that his view is quite common. Another "Scrum" team I was visiting recently showed me its task board. On the left, the group had "prioritized" their stories by assigning them to three categories. Their choice was pretty representative: they had eight cards with priority one, three cards with priority two, and not a …
One of the saddest patterns I’ve seen several times in my career is that of an agile island. The story usually goes along this route: a highly motivated middle manager finds herself in some difficult situation and decides that agile is the right way out of her turmoil. She starts to read books, she engages skilled consultants, she gets the team on board, introduces self-organization, finds skillful product owners, and, after one year or so, she has a highly successful agile team. Well, not everything is really perfect, but after all, the situation is way better than it was before the transition and the clients notice a significant difference — though there is still some …
“You did not finish the stories you committed to!” a product owner at a client of mine recently raged against the team. “What the hell are you doing all day long? This commitment was pointless!” And he was right. The team commitment Scrum includes as part of the planning ritual is a dangerous practice that needs care — and committing on a certain number of stories or story points really is pointless. “Commitment” is one of these management buzzwords you have to use carefully. You should be very clear about what you commit on, what the appropriate tools to keep that commitment are, which tools are illegal, and what happens if you don’t keep the …
The next two years will show a major change in the Agile world: The predominant position of Scrum will suffer from both the inside and the outside. On the inside, the struggles within the community will weaken the thrust effect of the certification program. Right now, we already have two competing certification programs, and, at least in Europe, single trainers are trying to establish their private programs, too. This will lead to several dialects and maybe even more competing certification programs. Though competition generally helps progress a profession, I consider this a sign of increasing weakness for the Scrum Alliance. The ongoing merger between Scrum and XP – now marketed as “Scrum development practices” – …
How much architecture does an agile team need up front? Most agile methods are surprisingly silent when it comes to this question. Scrum regards architecture as an issue the team has to deal with on its own discretion — and thus does not include any advice. In Crystal Clear: A Human-Powered Methodology for Small Teams, Cutter Senior Consultant Alistair Cockburn suggests having a lead designer who is responsible for creating the system architecture description — “usually fairly early in the first iteration” — but also emphasizes that “the architecture will probably evolve” and gives two strategies to help evolving: Walking Skeleton and Incremental Rearchitecture. XP finally suggests using a metaphor to keep up the technical …
Last week, we celebrated the 40th anniversary of software engineering. Between 7 and 11 October 1968, the NATO Science Committee hosted 62 leading academics and professionals of the young computer industry in Garmisch, a beautiful place in Bavaria, Germany, at the foot of the north face of the highest German mountain. During this conference, the term “software engineering” became popular and started its journey through our domain. Not too long ago, I understood agile development as an oppositional concept to software engineering. I had identified software engineering with the heavy document-driven processes widely in use in the 1980s and 1990s. This is a popular conception; especially one the proponents of traditional methodologies like to support. …
Software Engineering Radio, the world’s leading podcast on software development, published an episode on “10 Years of Agile Experience” yesterday. In this podcast Marcus Völter interviews me about introducing agile technology to different organizations, the experiences I made doing this job in the last 10 years, and stratgies I derive from this experience. The podcast was recorded in January at OOP 2008 in Munich.
This is the second post on the German book “Evolutionary Management” by Klaus-Stephan Otto and others. If you missed my first post on this, you may want to start there. Traditionally evolution is connected with fight and competition. Darwin phrased the mechanisms “Survival of the Fittest”, which is often interpreted as “Survival of the Strongest”. Otto and his colleagues point out that modern biologists have a slightly different view on this: It’s not the fittest who survive but the unfittest who die out. In other words you don’t have to be best, it is enough not to be the worst – an observation you can also make in today’s economy. In addition Otto points out, …


Recent Comments