Agile Advice, Like Youth, Probably Just Wasted On The Young

Agile Advice via Everyboyd's Free (To Wear Sunscreen).
Everybody’s Free (To Wear Sunscreen)

Background

In June 1997, Mary Schmich published an essay in the Chicago Tribune titled “Advice, like youth, probably just wasted on the young“. It was a hypothetical graduation speech as a “Guide to Life for Graduates”. She also encourages readers to try it themselves, which begs the question of what agile advice might be.

The speech is probably best known through its use as lyrics for the song Wear Sunscreen by Baz Luhrmann. There’s an interesting Switched on Pop podcast episode that describes the history and references a BBC documentary.

When I listened to that podcast, I wondered what a parody version might look like which gave advice about Agilem and put the idea on my backlog where it stayed. However, I never felt inspired or creative enough to do anything with it.

Then came the current chatGPT craze. Maybe that could help write the parody version for me. It turned out not to be as easy as that. In the end, I spent a lot of time tweaking the input prompt, to change the probabilities of the output from the stochastic parrot, to get something I was happy with!

However, while I couldn’t quite get chatGPT to match the structure and length of the lyrics in the way that I wanted, it came up with some good ideas I have used. So it did at least get me started and create something which I could finish. Maybe chatGPT is the new rubber duck debugger?

Hopefully, that sets the scene for this post. Maybe one day I’ll submit the version as a conference proposal and perform it live…

Everybody’s Free (To Limit WIP)

Ladies and gentlemen of the Agile class of 2023,
Limit work in progress.

If I could offer you only one tip for your agile teams, WIP would be it.
The benefits of limiting WIP have been proven by many teams,
Whereas the rest of my advice has no basis more reliable than my own meandering experience.
I will dispense this advice now

Enjoy the power and freedom of Agile, oh, never mind
You will not understand the power and beauty of Agile until you have gone through the agony of waterfall.
But trust me, in 20 years, you’ll look back at your old ways of working and recall in a way you can’t grasp now
How much possibility lay in the good old days of Agile.
You are not as experienced as you imagine.

Don’t worry about skills or certificates
Or worry, but know that worrying is as effective as trying to finish everything in your backlog by tomorrow
The real challenges in Agile are continually learning and growing,
So don’t hesitate to ask for help, collaborate and share knowledge.

Do one thing every day that you learn from

Automate

Don’t be reckless with other people’s code
Don’t put up with people who are reckless with yours

Refactor

Don’t waste your time on documentation
Sometimes it’s right, sometimes it’s wrong
The effort is large, and probably no one will read it anyway.
Remember the conversations you have, forget the arguments
If you succeed in doing this, tell me how
Keep your old test suites, throw away you old UML diagrams

Integrate, continuously

Don’t feel guilty if you don’t have everything figured out yet.
The best developers I know didn’t know at 22 how to solve every problem
Some of the best 40-year-old developers I know still don’t
Get plenty of rest
Be kind to your team
You’ll miss them when they’re gone

Maybe you’ll write clean code, maybe you won’t
Maybe you’ll release continuously, maybe you won’t
Maybe you’ll debug for hours, maybe you’ll do it pairing with a rubber duck
On your 75th wedding anniversary
Whatever you do, don’t congratulate yourself too much
Or berate yourself either
Your choices are half chance, so are everybody else’s
 
Enjoy your agile knowledge, use it every way you can
Don’t be afraid of it or what other people think of it
It’s the greatest concept you’ll ever know
Experiment, even if you have nowhere to do it but in your own cubicle
Read the man pages even if you don’t follow them
Do not read requirement documents, they will only make you feel depressed.
 
Get to know your customers, you never know when they’ll have new needs
Be nice to your colleagues, they have a wealth of experience from the past
And they’re the people most likely to help you in the future.
 
Understand that colleagues come and go
But for a precious few, you should hold on
Work hard to bridge the gaps in geography and time zone
For as the older you get
The more you need the people you wrote the code when you were young
Work in a big conglomerate once, but leave before it makes you hard
Work in a small startup once, but leave before it makes you soft
 
Learn
 
Accept certain inalienable truths
Backlogs will grow, Product owners will change their minds, you too, will get old
And when you do, you’ll remember that when you were young
Stories were small, Product Owners were noble, and team members respected their Agile coaches
 
Respect you coach
 
Don’t expect anyone else to fix your bugs
Maybe you’ll have a tester, maybe you’ll have a junior developer
But you’ll never know when either one might quit
 
Don’t be too hard on your ScrumMaster
Or by the time they are 40 they will look 85
 
Be careful with which frameworks you use but be patient with those who create them
Frameworks are a form of nostalgia, creating them is a way of fishing the past from the disposal,
wiping it off, painting over the ugly parts
And reselling it for more than it’s worth
 
But trust me on limiting work in progress

A Model for Creating a Kanban System

This post is a high level overview of the model I use when I think about Kanban Systems. As the saying goes, “all models are wrong, some are useful”. This is what I currently find useful based on working with teams and organisations in recent years.

At the heart of the model is Systems Thinking. Without looking at what we do as part of a system, with a purpose to be met by outcomes, we risk focusing too heavily on the activities and practices we perform. Having a clear understanding of a systems purpose, from a customers perspective, helps us to design a method which serves that purpose.

The model then has three foundational building blocks which underpin an effective process; Flow, Value and Capability.

  • Flow – Keeping the work progressing and avoiding delays by focusing more on the movement of the work, and less on the movement of the worker.
  • Value – Ensuring that the work serves the system’s purpose, satisfying customers and stakeholders and resulting in successful organisations.
  • Capability – Creating knowledge of how well the work serves the system’s purpose in order to maintain and improve the system’s effectiveness over time.

In other words, we want to flow value through capability teams.

Finally, the model has five aspects, from which we can look at a process to help us understand and improve it; Workflow, Visualisation, Work in Process, Cadence and Learning.

  • Workflow – how does the work progress through the system? Understanding workflow helps improve how the work moves from concept to consumption.
  • Visualisation – where is the work in the system? Understanding visualisation helps create a common mental model of the current state of the work.
  • Work in Process – what work is in the system? Understanding Work In Process helps identify bottlenecks and impediments to improving flow.
  • Cadence – when does the work in the system happen? Understanding Cadence helps with co-coordinating the work and improving system reliability.
  • Learning – how does the system continuously improve? Understanding further models with which to view and explore the system ensures the system gets better at serving its purpose.

While this is only a model, and contains no specific practices, I believe that it can be useful in describing why some techniques work in some circumstances, and provide context for applying the right tool to the right job.

Isn't Kanban Just a Task-board?

While the word Kanban comes from the Japanese for “visual card”, the term Kanban as used by the Kanban Software Development community, represents much more than a standard task-board, or team-board. Additionally, the Kanban Software Development community have not tried to replicate the mechanism of the Toyota Production System kanban tool exactly, but have taken the underlying principles in order to achieve similar effects in software development. So what is a Kanban System for Software Development?

A Kanban System visualises some unit of value. This unit of value could be a User Story, Minimal Marketable Feature, Plain Old Requirement or something else. This is different from a task-board, which generally focuses on visualising the current tasks.

A Kanban System manages the flow of these units of value, through the use of Work In Process limits. This is different from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the end of a time-box.

A Kanban System deals with these units of value through the whole system, from when they enter a teams control, until when they leave it. This is different from a task-board, which generally only deals with the work in the build/test stage, but shows no information about what work is being prepared, or what work is ready for release.

By putting these 3 properties of a Kanban System together, we can describe a Kanban System for Software Development as one which allows value to flow through the whole system using WIP limits to create a sustainable pipeline of work. Further, the WIP Limits provide a mechanism for the Kanban System to demonstrate when there is capacity for new work to be added, thereby creating a Pull System. Finally, the WIP Limits can be adjusted and their effect measured as the Kanban System is continuously improved.

A task-board simply shows what development tasks have been predicted to be done in the current time-box, with their status.

Traffic Jams

One of the metaphors I use when I talk why a kanban system has work-in-progress (WIP) limits, is traffic jams. The greater the WIP, the lower the throughput, and this effect can be seen when too many cars clog up a motorway. Watching the BBC’s “Britain from Above” last night, they had an interesting section on this subject, including a nice simulation on how a bottleneck ripples back as it frees up, explaining how traffic jams can seem to appear and disappear for now apparent reason.

You can seen the clip here – the simulation is about 3 minutes in.

I expect you get the same effect in software development value streams, although I would also expect that software development value streams are short enough for the effect to be unnoticeable.