Before you read further, take a moment and answer the following question for yourself: what is the primary purpose of a development team?
Don’t worry, I’ll wait…
Okay, what was your answer? Is it to create working software? (Well, yes.) Is it to complete everything on the sprint backlog (Hmmm… kinda.) Is it Henry, the mild-mannered janitor? (Could b… No!)
Above all, the primary job of an agile development team is to build quality into the product.
That focus on quality is important because it informs us and shapes us in everything we do as a team, from planning through to delivery.
When I introduced agile to one team with whom I worked, it took me a long time to help them get beyond their misconception that agile meant quickly hack things together and shove it out the door. Release early and release often—yes; dirty hacks—no! Done well, agile should be more disciplined than other traditional methodologies and focus on quality.
The first principle of the agile manifesto reads, “our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” The agile manifesto values “working software over comprehensive documentation”. Valuable software is working; working software relies on quality.
The fourth principle of DSDM/AgilePM is “never compromise quality”.
What small step could you take now to improve the quality of your work?
The other day in a meeting, I quoted one of the statements in the Agile Manifesto.
“Wow! Do you know the Agile Manifesto off by heart?” they asked me.
To be fair, not including the 12 principles, it is only four sentences long but I joked that I read it every night before I went to bed. I mean, obviously I don’t… it’s every second night.
The last few times I’ve read through the Agile Manifesto principles, though, one of the principles has grabbed my attention. It’s not one that gets too much attention. It’s this one, number 10:
“Simplicity—the art of maximizing the amount of work not done—is essential.”
Simplicity is big at the moment, which isn’t much of a surprise given how complex and complicated modern life is. Look at the attention people like Marie Kondo and The Minimalists are having.
A couple of years ago, I sat down and wrote a number of goals for my life, how did I want to live my life? The first item on that list was to live a simpler life. “Live a simple life,” I wrote, “Be aware. Live in the now. Observe yourself. Be kind to yourself. Love yourself and those around you. Slow down. Observe. Be curious. Go deep.”
Simplicity is good for development teams too. There are maybe things here that we can apply to Scrum teams.
One of the reasons that agile teams employ user stories rather than detailed requirements documents is that user stories promote simplicity. User stories are reminders to have conversations. User stories encourage us to leave some decisions as late as possible.
By focusing on the ‘why’ of a particular requirement, the team is encouraged to ask questions to get to the heart of the problem, rather than blindly following a checklist of requirements.
Slow down. Observe. Be curious. Go deep.
By focusing on the ‘why’, teams are encouraged to build what the customer needs as simply as possible and then iterate until the customer is happy.
Be aware. Live in the now. Observe. Be kind.
Simple code will have fewer bugs. Simple code is easier to understand later. Simple code that solves your immediate problem is better than complicated code that future proofs your application for scenarios that may never happen. Simple code is cheaper.
Maximize the amount of work not done
Let’s follow an example. Imagine that your customer says they need you to build them a car. So you gather all the requirements and you get to work. A year later, you present them with a car. It is a work of engineering genius. It has everything they dreamed of when you quizzed them about it 12 months ago. It has heated seats, a heated windscreen, a massive car stereo, eight gears, seven seats and has an enormous amount of storage in the boot. Brilliant!
Except, you learn that your customer only needs it to transport themselves the 17 miles from St Andrews to Dundee, on a daily commute with minimal luggage, and only during the summer. So they have waited a year to get something that is over-specified and over-engineered for their needs.
Let’s restart this scenario and write a user story to capture why the customer needs a vehicle.
As a commuter I want a method of transport that will enable me to travel the 17 miles from St Andrews to Dundee so that I can travel to my work (Monday to Friday) during the summer.
(Ignore that I’ve included some acceptance criteria in the user story to speed things up here.)
The engineers think, it sounds like they could do with a car but what if we start simply and first build them a pedal bicycle?
It takes them two sprints and deliver the bike to the customer. After four weeks the customer has something usable. They try it out. It does the job but it takes them 90 minutes to cycle to Dundee.
“Hmmm… could I have something a little bit faster, please?”
The engineers discuss it, agree that it still sounds like they could do with a car but what if we just motorise the bicycle and create a scooter?
Three sprints later (6 weeks) they deliver their scooter to the customer. The customer tries it out.
“This is brilliant! I can now do my commute in 40 minutes, and I love how I can weave in and out of traffic! I can use a pannier for my briefcase and wear waterproofs if it rains. I thought I was looking for a car but I’m really happy with this solution, let’s stop here.”
By thinking simply, the engineers have delivered a solution the customer is happy with in just 10 weeks, rather than an over-engineered solution that they had to wait 52 weeks for.
Yeah… you’ve guessed it, we never used it again, anywhere else on our 300,000-page website. What a waste of three days; what a waste of money. If I had been aware of the Agile Manifesto principle “Simplicity—the art of maximizing the amount of work not done—is essential.” I would have stopped and deployed after two and moved on.
Over to you…
What would benefit from being thought of more simply in your product? What would benefit from having less work done?
In 2014, Dave Thomas, one of the seventeen who met at Snowbird ski resort in Utah and came up with the Agile Manifesto, wrote a blog post with a wonderfully clickbait title: “Agile is dead (long live agility)”.
In the article he laments that too many people focus on ‘Agile’ with a capital ‘a’ as though it was a brand: Agile™. Agile isn’t a noun (a naming word, my primary school teacher would drill into us), agile is an adjective (a describing word). Thomas urges us to think about agility not Agile.
“The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.” — Dave Thomas
I’ve been thinking a lot recently about agile principles. What are the fundamental truths that serve as the foundations of agile development—sorry, of development that shows agility?
Of course we have the Agile manifesto:
“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.”
Scrum values and pillars
Scrum has five core values:
and three pillars
AgilePM (DSDM) principles
I’m fond, too, of the eight principles on which AgilePM (formerly DSDM Atern) is built:
Focus on business need
Deliver on time
Never compromise quality
Build incrementally from firm foundations
Communicate continuously and clearly
Bertrand Meyer in Agile!: The Good, the Hype and the Ugly (Springer, 2014) argues for the following principles that promote agility:
Put the customer at the centre
Let the team self-organise
Work at a sustainable pace
Develop miniminal software i. Produce minimal functionality ii. Produce only the code requested iii. Develop only code and tests
Develop iteratively i. Produce frequent working interactions ii. Freeze requirements during iterations
Treat tests as a key resource i. Do not start any new development until all tests are passed. ii. Test first
Express requirements through scenarios
Back to basics
Dave Thomas finishes his blog post by showing us how to do something in an agile fashion:
Find out where you are.
Take a small step towards your goal.
Adjust your understanding based on what you learned.
And “when faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.”
Orientate, plan, do, check, adjust, repeat.
Where do we need to focus?
I’ve often found these lists of principles useful to focus the mind on what’s important about working with agility.
Which principles stand out as those we need to focus on