It is 2021 and almost every IT organisation on the planet associates itself with “agile software development”.
Except that most of them are not agile.
How is that possible? The answer is simple. Agile software development became just another buzz word that our industry uses.
Remember DevOps
In a sense, it is like it was with “DevOps”. “DevOps” brought us this idea that we do not draw a line between operators and developers. Instead, we embrace a company culture where developers are also responsible for the deployment and support of their code.
A few years later, and recruiters search for “DevOps” instead of “Software Developers”.
We created this great paradigm “DevOps” which shall help us to improve the way we develop software as a community, and we reduced it to another job title. The “DevOps” is the “Software Developer” that became Jack of all trades.
And we developers play along. At some point, we got tired of explaining time and time again that “DevOps” is a culture. We submitted to the growing demand of buzz words in our industry.
Who do we blame for that?
This post shall not roast recruiters or companies for the misuse of buzz words such as “DevOps” and “agile”. I can understand that it is difficult to attract enough talent in a growing tech landscape. You fear to be left behind, thrown into the “old economy” bracket.
But there is a better way than using terms like “agile” superficially.
Embrace them.
The agile manifesto
The agile software development concept largely derives from the “agile manifest”.
2001 Utah, a group of 17 programming enthusiasts meet in a skiing resort to create what the world today knows as the “agile manifest”. The participants had different ideas in mind how software development should be approached.
The “Extreme Coding” representatives neglect most of the planning effort and focus on coding.
The “Scrum” advocated follow a step-by-step approach and divide long processes into chunks, the sprints.
…
The participants did not expect to come to any conclusion. The opinions and approaches that each of them had in mind were too different.
But we would not sit here if they could not agree on a couple of principles.
Eventually, they agreed on 4 principles.
(1) Individuals and interactions over processes and tools
Processes do not create complex IT systems, people do!
And it is the job of executives to provide enough space for those people to be creative and productive.
The first principle does not teach us anarchy. It does not mean that we should not have any processes or tools. Processes are great, they help us to solve problems. But they also defeat the higher purpose if you force them on people.
A process should never feel obligatory. There should always be a way to bend the rules if the situation demands it. And your developers should have the power to decide when to diverge from the process.
But the first principle teaches us more than that.
It tells us that we should not create a fixed plan. That does not mean that we will never create a UML diagram. Neither does it mean that we jump into an idea without planning our approach first.
It tells us that we should be flexible with the plans that we create.
Compare this with the “waterfall” approach:
(1) Requirements
(2) Analysis
(3) Design
(4) Implementation
(5) Maintenance
And then rinse and repeat.
What happens if we find out in (4) that our UML diagram that we created in (3) does not work?
Or we find out in (4) that the requirements from (1) changed?
We adapt.
We throw the plan out of the window if that’s necessary. Just because it was a good idea to do it like this 5 weeks ago, does not mean it is a good idea today.
And yes, that hurts, but how much more will it hurt if we go willingly into the wrong direction 5 more weeks?
(2) Working software over comprehensive documentation
Who here truly believes it is better to document an ugly code passage rather than refactoring it in the first place?
I guess none of you raised the hand.
But why do we still do this in practice?
A software product is not a thing that is set in stone. Software is more like a living organism. It requires attention and produces waste. We call this waste “technical debt”. And it is the job of every software developer, regardless of experience, to clean that waste up!
That does not mean that developers should refactor their code until they reached perfection. No, but perfection is far away from code that got hacked together in the first place and enforced by duct tape in the years following.
Any software product should have a reasonable code quality.
You may ask: “when do we know that we reached reasonable code quality”.
Let me answer this question with a counter question: “how does a sailor know that his ship is good enough to swim?”. Probably not when there is water coming in from all sides and your captain is drunk in the cabin.
Reasonable code quality follows a few ground rules:
- Our colleagues understand each other's code. Code passages that are too complicated to understand receive small doc strings.
- We have tests that answer whether the software works with a simple “yes” or “no”. These tests are reliable, they deliver the same result when we don’t change the settings.
- Our code is not redundant. We extract code that does the same into helper functions or helper classes.
- We tested our code in a realistic setting. Our testing environment simulates the production system reasonably well.
Now where does that leave us with documentation. Is documentation evil?
No, it is not.
But sadly, more often than not, technical documentation of source code consists either of “captain obvious” comments or feels like a novel by Stephen King.
If you think you need to write technical documentation:
- Think again. Do you really need more documentation? Can I expect other developers to understand my code without doc strings?
- Avoid passive speech and write short, simple, sentences. “Called by the great object Foo, the method Bar computes the square sum of a and b” vs. “Called by Foo, computes the square sum of a and b”
- Good documentation answers how it works. Great documentation answers also why. Document important architectural decisions.
(3) Customer collaboration over contract negotiation
“I am sorry, we cannot change that, we wrote in contract position 15.3.2 that the feature should …”
Who cares? The customer hired you to solve a problem, their problem. You should not nail them down on the contract that they signed months ago when they did not even know 10% of the challenges that lay ahead.
Behaviour like that does not solve problems, it creates problems.
“Ok, but shall we pay the additional cost of adjustment requests of the customer?”
No, you don’t have to pay the extra cost.
Listen to customer feedback and let it sink in. Tell them that you discuss the topic with the team if you don’t have a solution now. Come back in the next meeting and provide a solution. Show that you go a few steps of the way before you want more money.
Don’t be that person who comes with empty hands and demands something.
You can discuss the additional cost with the customer once you came up with a solution. The third principle teaches us to put the customer first and the contract second.
(4) Responding to change over following a plan
Have you every asked yourself how project management approaches such as “Scrum” transformed an entire industry?
“Scrum” was one of the first that implemented a quick feedback system that embraces changes in projects.
The entire concept of sprints and customer demos leads to early feedback. And you can react to this feedback within the next sprint.
Of course, that works only if you don’t plan five sprints ahead.
This taps again into the first principle “(1) Individuals and interactions over processes and tools”. We do not follow a fixed plan, and we do not plan five steps ahead. Staying agile means to go one step after another.
This point is also the biggest shortcoming of classical approaches such as “waterfall”. The customer feedback comes at the end of a full “waterfall” cycle. But the problem is that we are already committed 6–12 months of work into the project. Mistakes that we made during the requirements phase become more expensive with every week that passes by.
We do “Scrum”, we are agile!
Let me tell you this: you can implement any project management — tool or approach in your company. It does not matter. Your organisation is not agile unless you embody the agile manifest principles.
You don’t believe me?
Then ask yourself how agile it is to follow “Scrum” by the handbook word by word. It is not. It violates our first agile principle, “(1) Individuals and interactions over processes and tools”.
There is no place for dogmatism in agile software development.
Regard project management paradigms like “Scrum” and “Kanban” like a framework. Developers use frameworks to make their life easier. They are great. They provide us with structure, stability and save us a lot of work.
But how often does a developer use 100% of a frameworks' functionality?
Never.
It would not be efficient. We just use the bits of a framework that we need. Executives should do the same. Focus on the “Scrum” bits that provide your company business value, ignore the rest.
So please, the next time you send your Scrum master to the certification, sit down with them afterwards and discuss what processes make really sense for the organisation.
You don’t need to do a “Team Velocity analysis” after each sprint if you only have two developers.
Following the ”Scrum” handbook from A to Z will not improve productivity. It will slow your organisation down. Even worse, it will annoy the developers. And when developers don’t like their working place, they leave.
Keep developers out of the loop
So try to put yourself into the shoes of a developer. Almost every organisation that I know has not enough developers. Consequentially, developers have to work in multiple different projects and perform in different roles.
And that is ok. We accept that challenge. We accept any challenge that you present to us. But we cannot duplicate ourselves. We will prioritise and some things remain unfinished.
But please, do not add a dozen project management meetings on top. The “time to market” or “return of investment” does not matter to us. Developers are there to develop code or technical systems.
It is nice to gather the staff once in a while and give them a presentation, explaining to them how the organisation is doing. Transparency goes a long way in building trust between the management and the team. But please keep the frequency and length of these meetings at bay.
Avoid open-ended meetings. Most meetings can be done in 30 minutes and in some cases extend to 60 or 90 minutes. Consider a follow-up meeting if you can’t discuss something in 30 minutes.
Keep non-technical meetings short and move them after lunchtime. The morning is the most efficient time of the day.
But how do you find out if you should invite your developers to a meeting?
Just think about the reason you need them in the meeting. If there is no good reason why they should attend, then they don’t attend. And “keeping people in the loop” is not a reason. That is cheating. ;-)
Summary
People are different. Everyone has a unique perspective on life, on work. The same is true for developers and executives.
We studied in different fields, and we work on different things.
And that’s great. That makes us succeed.
Unfortunately, it makes us misunderstand each other, too.
That is the reason I wrote this post. It is not about pointing the finger at people and demonstrating an organisational shortcoming. It is about demonstrating another perspective, the perspective of a technician.
So let us discuss this topic.
Tell us what you think about “agile”, what you understand about it. Do you agree with the ideas that I presented to you in this post? Do you disagree?
Then write a comment!
Top comments (0)