Agile has exceeded the boundaries of it’s original domain, software development. Today many companies claim to do Agile. Projects are executed in sprints, requirements are documented in backlogs. Yet customer expectations are seldomly met, let alone surpassed. When taking a closer look at how products are being developed, this doesn’t come as a surprise. Join me in this 3 part blog post to find out the difference between talking the talk and walking the walk.
In the closing days of 2023 I received a newsletter titled The purpose of a system is what it does. The author argued:
[…] Agile never intended to revolve around agile frameworks, coaches, conferences, and certifications. And yet, here we are. The agile industrial complex is what we all ended up with. That is what Agile is now. […]
Jurgen Appelo, Agility, Innovation, Experience #62[1]
This got me thinking: Has agile turned into an industry that demands hording and comparing credentials to prove your worth? Is this really what I want to settle for? Why did I start favoring agile over waterfall to begin with? In order to resolve the cognitive dissent this created in my mind, I decided to dedicate an event of the Vienna Scrum Meetup [2] group which I’m hosting to work through these questions, and document it here.
A brief excursion to modern Project Management
I’m working as an Agile Coach (here we go again, claiming titles…) at iteratec. We are striving to develop our customers into Digital Champions. Typically, we are doing that through successfully implementing business models in software. What has this got to do with the agile industrial complex you might ask? Well, developing software is not a one person job. So we need some way of coordinating our efforts toward a shared goal. Also, our customers would like to know when our work will be completed, while we are interested in tracking efforts in order to stay within the agreed upon budget. In other words, we need some form of project management.
One of the first things that spring to mind when thinking about project management are project plans, typically visualized as Gantt charts.
A simple Gantt-chart
Based on the work-breakdown-structure in the tasks column, tasks are visualized as bars and arranged on a schedule. The duration of a task is represented as the length of a bar. By formulating dependecies (e.g. finish-start, where the previous task must be finished before the next one can start) between tasks, they can be scheduled in order to determine the overall completion date.
The work breakdown structure is created by applying reductionist[3] thinking to a problem domain. The Gantt chart is named after Henry Gantt, who created the chart around the years 1910 - 1915 to visualize systematic routine operations.
Due to the reductionist thinking and the deterministic approach of linking tasks, Gantt chart based plans, however, implicitly assume tight coupling, in the form of a strong cause-and-effect relationship, within the problem domain they describe. Their ability to schedule tasks places them as an ideal tool for solving such linear problems. However, they struggle when being confronted with unknowns.
Wicked problems
The availability of ever increasing computing power and more powerful programming languages, allowed software developers to address more complicated or even complex problems. While a number of frameworks addressing software craftsmanship emerged, the domain of planning remained largely unchanged. This lead to more and more failing software development projects. Towards the end of the 20th century, in 1999 Dave Snowden created the Cynefin (pronouced as kuh-NEV-in) Framework as a sense making device.
Cynefin Framework by Dave Snowden, CC BY-SA 3.0, via Wikimedia Commons
The Cynefin Framework offers five decision making contexts or domains (Obvious, Complicated, Complex, Chaotic and Confusion in the center), along with some characteristics of the problem domain (in red font), guidance for how to act (blue font) and applicable solution spaces (green font).
Seeing that the tight coupling of determinstic behavior can only be found in the Obvious and Complicated domains, we can conclude that Gantt-chart based planning can only be safely applied to such problems.
Today’s challenges which we often set out to solve with software, largely fall into one of two categories:
- they either address problem domains so complicated, that it is cheaper to apply empiric means to determine their behaviour than to thoroughly analyze them, or
- they deal with complex or even chaotic problems
Taking into account ever faster changing customer expectations driven by a reinventing market that is contested by multiple competing players, it is no longer sufficient to create elaborate plans and see them through without deviation. The need for a new category of management frameworks became apparent.
The Agile Mindset
“On February 11-13, 2001 at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax and try to find common ground - and of course, to eat. […]” [4]. What better way to start an era, than with a vacation. Those seventeen people got together to find “[…] an alternative to documentation driven, heavyweight software development processes […]”. They called themselves the Agile Alliance and created as a result of this meeting the Manifesto for Agile Software Development [5].
Manifest for Agile Software Development by Andreas Erber
It is important to note that what is stated on the left is not meant to replace what is stated on the right.
Processes & Tools for example support people in standardizing the way they work, and thereby promote cooperation. Individuals & Interactions however, are even more important, because tools on their own won’t do any work. (It will be interesting to see how Generative AI is going to impact this balance, or if GenAI will be perceived rather as an individual than a tool!) Processes which, under the pretense of standardization, introduce more friction and impediments than they are enabling cooperation, are just not that helpful. Following them produces more wasteful, nonproductive activities than benefits. Individuals should in such cases not only be encouraged, but expected to design a set of interactions to boost cooperation.
Comprehensive Documentation is important for users of complicated systems to understand how they are supposed to use these systems in order to get the expected results. Without Working Software, or any type of product for that matter, documentation is just text about something that isn’t there. For the sake of reading, most people, I guess, prefer a good novel, maybe even a badly written one, over technical documentation.
Contract Negotiation obviously is important in any business context. All parties entering an agreement will want to have established a set of rules to play by. But should every possible detail be regulated by a contract? Definitely not! (Don’t show this to your legal department. Based on experience, they most likely will disagree.) Anything that is part of the contract can no longer be changed afterwards, at least not without re-negotiating the contract as a whole. By putting everything into the contract, you are severly limiting the options you have to react in the course of your endeavor. Imagine, you are a service provider negotiating the only agile project you know of in the whole enterprise of your customer. You may think, that 2 week iterations are a great idea and, thus, put that into the contract. Over the course of the project it turns out that your customer has set up a 3 week cadence for other teams you have to cooperate with. You suddenly find yourself between a hard place and a rock, since it is now difficult for your to synchronize with those other teams. You can either take the penalty of continuing to work on your contractually fixed 2 week cadence, or re-negotiate your contract. That however, would also open up the oppertunity for other parties to the contract, to re-negotiate terms, which you would rather leave untouched. The one thing you can’t do in that situation, is to just switch to the now common 3 week cadence because that would mean you’d be in breach of your contract. (This you can safely show to legal.)
Rather, Collaborate with your Customer on all aspects of your cooperation. First and foremost, find a contractual model that aligns the interests of all parties to the contract. Sidenote: Fixed price contracts are an exceptionally bad example when it comes to aligning interests. These types of contracts rather put the interests at conflict: The customer will want to get as much as possible from the contract, while the vendor will want to spend as little effort as possible.
Following the plan is a valued strategy in projects which are based on an elaborate Gantt-chart types of plans. Devising, formulating, and updating these plans already has been and still is costing. In addition, chances are that the plan had been shown to management and guarantees have been given to stay on time and within budget. So no deviations at all cost. Change, however, means that we have learned something new about our product, our customers, or the market, which we think is worth considering at the cost of changing the plan. Responding to Change simply means building a better product.
Even the “[…] organizational anarchists […]” of the Agile Alliance have foreseen that the Manifesto alone would not provide sufficient guidance for practitioners. Thus, they complemented it with Twelve Agile Principles.
Continue in Part two: Understanding The Power of Basics to learn how the twelve Agile Principles form a solid corporate culture.
Quellen
[1] Jurgen Appelo, Agility, Innovation, Experience #62
[3] Reductionism is any of several related philosiphical ideas regarding the association between phenomena which can be described in terms of other simpler or more fundamental phenomena. It can also be described as an intellectual and philosophical position that interprets a complex system as the sum of its parts.
[4] History: The Agile Manifesto
[5] Manifesto for Agile Software Development
Christoph Murczek - works at iteratec as a passionate Product Owner and Scrum Master by conviction. He is the founder and main organizer of the Vienna Scrum Meetup, a forum for discussions about agile ways of working with more than 2.500 members from India to California, resp. Sweden to South Africa.