A few weeks ago I had the chance to give a presentation at a company-wide event about the importance of not forgetting about the developer in the midst of the agile transformation. Why is that you might ask?
What is agile anyway?
Put aside the manifesto, the values and the principles. What does it mean in real life? In the life of a developer working in a big corporation?
Most probably it will mean applying the scrum or kanban framework. It will mean daily meetings, endless sprints turning into marathons. Demos without clients and retrospectives with sugar overdose turning young males who never cooks into pseudo-bakers following their moms’ instructions over the phone.
Joke aside, if your company is big and rich enough it might even mean the Scaled Agile Framework (SAFe). And the key is the last word. It’s a framework. But a framework for what? Well, let’s face it. For project management.
But is that really agile?
I’m a big fan of history and I think it’s important to know ours in the industry. George Orwell knew that “the most effective way to destroy people is to deny and obliterate their own understanding of their history.” Without knowing our history we have no future. In our case, history doesn’t only mean the history of computing, programming languages, but also the way we work. Let’s have a look at that, the history of how we organize our development activities.
Ever since the late fifties, there were attempts to use iterative development methods. Attempts? Well, engineers using iterative development put mankind on the orbit, then they built the primary avionics software for the space shuttle! It’s so funny that there are people saying nowadays that, well, Agile is not for projects where there is a lot in risk and it’s a matter of life and death, for such matters there is still waterfall. Tell that to the Mercury Seven…
As usual, a lot of different initiatives spread around until in 2001, 17 engineers met in a ski resort in the 45th state of the US and around 4 values and 12 principles wrote a manifesto. (I love numbers, don’t I?)
They wrote the manifesto for agile project management. Oh no, sorry, they wrote it for agile software development.
Agile was made by developers for developers.
What are the agile practices?
Let’s have a look at the Wikipedia page of agile software development. If we scroll down, we can see 22 practices. Is that a reference to the catch-22? I’m not sure. But I tried to categorize these practice into development practices and project management tools and practices. The second one is a bit vague, I know, but basically everything that is not directly about the way you develop, but more about meetings, organization, management.
This is how I split
| Agile development practices | Agile project management practices and tools |
|---|---|
| ATDD | Backlogs |
| Agile Modeling | Cross-Functional team |
| Agile Testing | Daily standup-up |
| BDD | Planning poker |
| CI | Retrospective |
| DDD | Scrum events |
| IID | Timeboxing |
| Pair Programming | User story |
| Refactoring | Velocity tracking |
| Specification by example | |
| Story-driven modelling | |
| TDD | |
| Timeboxing |
Of course, the list and the split are arguable, and I deliberately put Timeboxing into both bags. The list I took from the Wikipedia page, so no personal judgement there.
Based on my split, the development practices are in the majority. On the other hand, and this is solely based on my experience both from my job and from the feedback I got from other people I talked to, the implemented practices are mostly from the second bucket.
How agile transformations went wrong?
What does this mean? This means that when we are talking about transforming teams into agile teams, we focus on the way such teams work, the teams and the meetings are organized. Is that important? It is, for sure!
On the other hand, we tend to forget that agile was founded on the grounds of modern engineering practices, extreme programming. Many times, developers don’t even know what TDD is about, they have never tried pair programming and refactoring seems to them as a noble pastime that delivers no value and it pleases only snob software development engineers who enjoy nothing but perfection.
Once, I was attending an agile introduction for a new forming project. The coach was speaking mostly about the non-technical parts. I couldn’t stand and I asked him what about the modern engineering practices that Agile was built upon?
He stepped back thinking for a second. Seemingly he was thinking about whether he should share his honest opinion or not, but then he continued.
Many companies do not pay for the technical coaching part, they want to be agile for sure, but they don’t want to pay for it and they think that changing the project management, project organization part will be just enough. But… If you take a couple of engineers who used to work without modern engineering best practices and they produced crap, so the management was not happy and wanted to change to agile, and now you don’t coach them on those topics, you don’t help these engineers to work with the new practices, they will just produce the same crap soaked with the Agile buzzwords…
So what can you do?
As we have seen, while the majority of agile practices is about the techy parts, in practice, at least big corporations tend to focus on the project management part. Both in terms of trainings and field coaching.
This is a bit of nonsense to me. The agile transformation for a company usually takes years. Hoards of coaches and other professionals are encircling the “changing” company like vultures orbiting their victims to pick up some juicy contracts.
We admit that such a transformation cannot happen without help, yet we fail to give help to those are in the centre of those changes.
What does this mean?
It’s not that much different from clean coding. It’s difficult to learn agile software development given that the number of programmers is steadily growing and there are simply not enough experienced developers and coaches who can help who really know agile software development.
The need to learn agile and as such modern engineering practices is huge, but often stays unidentified.
I’d advise everyone concerned the following three things:
- Educate ourselves and let’s try to teach our teams and colleagues about those agile practices
- Raise our voice towards the training department and the transformation teams that we need help, just like project managers
- Share our experiences to spread the word!
