Blogbeitrag
The core of agile: a (new) profession in search of its identity
Timm Richter, 10. August 2019
While businesses around the world try to become more agile, there is a growing discomfort with agile in the software development community. Jan Wischweh has written a great summary of the history of agile and its current state. At the end of his post, he raises a question that, I believe, resonates with many developers: what is the core of agile?
I read this question also as: can or shall we fix agile? And what would that mean, anyhow? What, if any, is the essence of agile that is and will always be true?
The discussion is heated with a lot of emotion and passion. It obviously means a lot to the software development community. Why? I claim that the agile movement has always been about its self-conception as a profession. As such, it raises two existential questions. Who are we? And what is good software development?
The Agile Manifesto revisited
The Agile Manifesto itself reveals that these two questions for identity are at the core of agile. However, you have to look at the page History: The Agile Manifesto to really appreciate the fundamental scope of the authors.
At this history page, they make clear that they hate „corporate bureaucrats“. Those are the enemies. Developers are different from them, even though some of the developers also have shown the same bad behavior committed by „marketing, or management, or external customers, [or] internal customers“.
They dream of a „developer community freed from the baggage of Dilbertesque corporations“. Their ideal are „organizational models based on people, collaboration“ with „values based on trust and respect for each other“ such that they get „organizational communities in which we would want to work.“ For the authors of the manifesto, this ideal defines who they want to be and how they want to work.
They also point out, that they are „not anti-methodology, in fact, many of us want to restore credibility to the word methodology.“ Point in case: the authors are all process-focussed, describing themselves as „representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes.“ This is part of their identity as well, they „want to restore a balance.“ This idea of balance is captured better in their original naming before they chose the word „agile“, namely „Lightweight processes“. Processes and methodology: of course. But in a way, that respects people and is of help, not a burden.
I have put these findings in the above diagram. At the top you see the two things developers base their identity on and which they want to balance. At the bottom you see the anti-identity, what the initiators of the Agile Manifesto don‘t want to be or don't want to have. Which is what happens if you exaggerate one of the sides. They do not talk that much about the exaggeration of the trust / collaboration / respect side in the manifesto. It is what you get when there are no methodologies and no processes - something like a free-wheeling, anything goes approach. Bob Martins complains in a talk about the lack of (personal) discipline which hints that trust is not unconditional but must be earned and collaboration needs professionalism. So I would argue that unprofessional lack of discipline captures this exaggeration.
Identity as the balance between man and machine
I see this balance that the authors want for their profession as an expression of the following more general conflict between two poles:
| Man | | | Machine |
|---|---|---|
| Art | | | Science |
The authors care about developers as human beings. They want an environment where developers can enjoy work and feel well in order to deliver quality work. They want to be appreciated for their human creativity of writing good code. Good craftsmanship creates code that is elegant, thoughtful and ingeniously simple. Developers care about the code quality they deliver. It is their contribution to a better world. This is the man / art side of their identity.
And with all their creativity, developers program the world. That‘s what they do. They try to put the world in code to make things predictable and controllable, always done in the same way. Software developers aspire to apply techniques that are scientifically reliable to deliver automated solutions of high quality. This systematically eliminates errors which they hate. Programming takes humans out of the equation. Software development is the natural extension of industrial engineering, increasing the leverage of mankind and replacing product and service delivery that used to be done by human beings. The next logical step is to apply the mindset of programming to the process of programming itself. And sure enough, that happens all the time. Developers write new, more abstract and capable languages that make programming easier and take out mundane tasks. Testing is automated. Developers are fascinated by AI - can we program software that is as smart or smarter than human beings?
I described the main conflict of man - machine and art - science in rather philosophical terms. We can put it in business context and they become terms of the Agile Manifesto.
| Man | | | Machine |
|---|---|---|
| Art | | | Science |
| Interaction | | | Organization (process) |
| Change | | | Control (plan) |
So the identity of developers is all about finding the right balance of those two poles. Yet the Agile Manifesto sides with interaction and change and puts them OVER organization (process) and control (plan). And this decision is the root cause for the tension with agile, because it is impossible to maintain that exclusive choice for one side.
First, it negates a major part of their professional identity. Programming, both code and processes, is what defines a developer. Developers seek clear processes, structure, methods. And, by the way, organizations are looking for the same thing! I have the feeling that also agile developers have the dream of coming up with a way to PROGRAM better programming.
Second, organizational reality always brings the non-agile side into view. Lets go through the four values in turn:
Individuals and interactions over processes and tools?
Emphasizing individuals and interactions increases the capacity to use individual knowledge and increases the creative potential. They play a crucial rule in particular in team settings. Yet organizations consist of a great number of teams. In order to create alignment between all those teams you need some processes to coordinate the work. OKRs have become fashionable (not a new idea, by the way) because they promise to deliver this kind of coordination that has been missing if you focus on agility at team level. The very idea of an organization is to split work and become independent of individuals. We expect from an organization that it delivers its products and services with certain standards. And as said above, software plays a central role in delivering standardized, repeating processes with (software) tools.
Working software over comprehensive documentation?
The intended independence of individual developers is also one reason why there will always be documentation. Having the knowledge about specific code only in one head is a major business risk. Already on team level, you want to avoid this situation. Even more so on organizational level. Working software with fast iterations is particularly helpful when you develop something new. Documentation is helpful when software is meant to be improved and used by other parties and scaled.
Customer collaboration over contract negotiation?
Yes, customer centricity is the key. Peter Drucker famously said: there is only one reason for a business - a customer. Yet the devil is in the detail.
If you develop software for external customers, a contract is a legal necessity of doing business, so you won‘t be able to avoid it. Contracts are also representing the economic side of business. While being customer centric, organizations also have to make sure that the business is economically viable.
In larger organizations there is an even greater problem. Literally, the customer is not sitting on the table. Organizations are only internally discussing what they believe is good for the customer. You have the challenge to bring different perspectives to a productive conflict about the course of action. What to do is not clear at all and cannot be calculated. It has to be negotiated and decided. Examples
- Time spent for features versus quality assurance or refactoring
- Sequence of features to build
- Do what customers say they want or build what you believe will help them to solve the problem you understood they have.
Responding to change over following a plan?
Yes, it helps to stay adaptive. On the other hand, in order to act you need an intent, i.e. decide what to do. Many people claim that you can test and iterate solutions. But that only shifts the problem of taking a decision (= making a plan) - you have to decide what to test. Moreover, with iterative approaches, you‘ll run the risk of only getting local maxima. Innovative leaps need insights and courage to make a big step.
At an organizational level, plans also have the function to coordinate resources and efforts. Without them, you run the risk that many teams produces something but the results don‘t fit together or harm each other.
Going forward
I believe the profession should come to the conclusion that it needs both poles. It is not an OVER but an AND.
Living the AND means following one of Peter Drucker's most important advices. Rather than becoming ideological about agile, try to answer his most important question: „What needs to get done?“
Living the AND also means to gain experience, build your craftsmanship in order to become better at balancing the two poles.
And last but not least you could change the four agile values on the left side of the manifesto into four guiding questions that emphazise the AND:
- How can we make plans that adopt to change?
- How can we build processes that harness the power of interaction?
- How can we negotiate (and decide) with a collaborative mindset?
- How can we document (and codify individual knowledge) with working software?
