Human centered software delivery
Updated: Jun 1
Where we came from
Back in uni, I took a subject called HCI: human computer interaction. The early days of how we consider the interaction of people and computer systems.
At the same time, there was a lot of talk about how to make the software development process more human centred. The prevailing software development methodology of the time was waterfall. One of the major pitfalls of waterfall being the lack of feedback loops throughout the development process.
Ironically, one of the people credited with bringing the waterfall model into the mainstream consciousness highlighted this deficiency in the 1970s https://en.wikipedia.org/wiki/Waterfall_model.
Where we arrived at
It took a lot of pain and suffering for the broader software community to realise there must be a better way. There were certainly sub-cultures along the way, but generally "Agile" has penetrated into the corporate world deeply and widely.
Has "Agile" fundamentally changed the way organisations deliver software?
For some yes, for others no.
Without demonstrated success Agile delivery would have never caught on in the first place, however now we are seeing many large scale agile transformations not delivering expected advancements in software delivery quality, speed or value.
Where the agile was lost
What does agile even mean to people these days?
From my personal experience, I see organisations treated as another set of processes to follow. Standup, sprint planning, kick offs, backlog grooming, big room planning… The list goes on.
We’ve gone from replacing a set of processes that we called “waterfall” to a set of processes we call “agile”.
Is this really what it means to be agile?
How much thought have you given into the purpose and value behind each of these agile rituals?
Where did these agile rituals even come from?
What is the problem they are trying to solve?
An example of losing the purpose
To give a concrete example of losing the agile I’d like to touch on standups.
Every team I’ve seen that declares they are agile does standups, so hopefully most people can relate to this example.
In many teams I’ve worked in, the focus of standup seems to be keeping it short. There’s usually a time limit imposed of say 10 to 15 minutes, and if standup is finished by then you can typically hear declarations of “good stand up”, “cool we only took 8 minutes today” etcetera etcetera.
If the desire for standup is keeping it as short as possible, why not make it 5 minutes? 30 seconds? Eliminate it entirely?
No stand up is the shortest standup!
In a world of packed calendars, we have started measuring success in terms of hitting our time box, not achieving outcomes.
The core tenants of agile
I know many people are familiar with the agile manifesto, some may not be. So here it is:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
No where does the manifest mention standups, stories or retros. So why do we do them? How do we reclaim the importance of the why?
Mapping it out
I recently used the following mapping technique with a team to help realign expectations of outcomes from the common agile ceremonies they participated in.
1. Lay out ceremonies
Using a real or virtual whiteboard, get the team to lay out all of the regular ceremonies
2. Understanding outcomes and why
Next up, get the team to put stickies next to each of the ceremonies describing expected outcomes or why that ceremony is held.
3. Creating an operational cadence
Finally, with an understanding of what each of the ceremonies is for, lay them out on a timeline indicating when they should be happening during the sprint.
The image below shows that at the start of the sprint the team has a sprint kick off.
Then during the first half of the sprint backlog grooming and estimation sessions occur to try and keep the backlog in good shape and ensure upcoming stories are understood.
Toward the end of the sprint, planning occurs followed by a retro and showcase.
There are some ceremonies that don’t occur at set times. These have stickies added to them to show what triggers that ceremony to occur.
Wrapping it up
Hopefully by running through this simple exercise, you can help your team refocus and get shared understanding on why certain agile rituals occur.
You might find your team gets better value from having standups three times a week instead of five. You might find people didn’t really understand what the point of a sprint kick off was.
Most importantly, realise that all of these ceremonies are there to help people build better software.