Being agile means being willing to adapt. But what, exactly, are we willing to change?
Consider a team approaching a deadline with more work than it can finish. Should it extend the deadline, squeeze in extra hours, reduce testing or deliver fewer features?
That choice deserves a conversation before the pressure arrives.
Decide what to protect
DSDM, the Dynamic Systems Development Method, makes the trade-off explicit: fix time, fix cost and fix the agreed level of quality, then vary the scope.
Lower-priority requirements provide room to adapt. They can be deferred by agreement when the work proves harder than expected.
The aim is to deliver a useful solution within the agreed constraints. That requires clear priorities and enough flexibility in the feature list.
If everything is a must, there is nowhere for that flexibility to go.
While it’s true to say we use the Scrum framework here at Vision, that’s not the whole picture. As Bertrand Meyer says in Agile! The Good, The Hype and the Ugly (Springer, 2014), “every agile team in the field makes up its own cocktail of agile practices, rejecting the ones that do not fit” (p.vii).
In terms of project lifecycle and team management practices, we are fully embracing Scrum. But Scrum has little or no opinion about engineering and delivery practices, which we complement largely with XP methodologies. The Scrum model assumes the development team will work with a product backlog but has no guidance on how that will be created—tools from AgilePM, DSDM or even PRINCE2 might be considered to supplement Scrum. (I’ve not been with Vision for long enough to fully understand how this is done here but that will come.)
Since I was introduced to it, I’ve always considered myself a proponent of agility rather than being partisan to any particular flavour or methodology: XP, Lean, Scrum, DSDM, Crystal, etc.
My agile journey
I was first introduced to agile through XP (extreme programming) having picked up a book at the 2008 Scotland on Rails conference in Edinburgh. (Memorably, that was the same day my then-wife learned we were expecting twins!) The keynote speaker spoke eloquently and persuasively about how agile approaches to software development had brought huge benefits to his team. I was hooked. I raced home, read the book from cover to cover and began to implement the ideas in my own team.
Then the university I was working for embraced Lean and I was introduced to its five principles, eight wastes, kaizen, kanban and a host of other useful concepts. I saw first-hand how empowering teams to own and change their processes reduced waste and improved productivity, effectiveness and team morale.
Latterly, it was decided that our team should embrace DSDM Atern. From a project management perspective, DSDM/AgilePM is the most complete. I have a terrific fondness for both its structure and flexibility.
Agile toolbox
Beneath the umbrella term ‘agile’ we have a toolbox of practices. Some have been codified into highly defined systems like AgilePM, DSDM and Scrum, others like XP and Lean feel more like loosely-related methodologies grouped into adaptable frameworks.
Within each there is the freedom to mine other disciplines for best practices: business analysis techniques, MSP, P3O, traditional project management tools, etc.
Just as you wouldn’t chastise a plumber for using a joiner’s hammer, it makes no sense to prevent an agile team from using a technique from another discipline if it does the job.
None of the frameworks cover everything. It makes perfect sense to supplement them with tools from elsewhere. DSDM makes that explicit: “for most organisations, DSDM is all that is needed,” the handbook proclaims, “although some gain value from integrating DSDM with project management methods such as PRINCE2 and PMI, or detailed development techniques, such as extreme programming (XP).”
This is one of the most helpful diagrams I’ve found that demonstrates the relationship between agile methodologies and how they complement one another:
Diagram credit: Agile Project Management in Easy Steps by John Carroll (2012)
Over the next few weeks, I expect my blog posts to focus on aspects of both Scrum and XP in particular, exploring in more depth some of the tools we have access to in our agile toolbox.
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?
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
Agile principles
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?
Agile manifesto
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:
Commitment
Courage
Focus
Openness
Respect
and three pillars
Transparency
Inspection
Adaptation
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
Collaborate
Never compromise quality
Build incrementally from firm foundations
Develop iteratively
Communicate continuously and clearly
Demonstrate control
Bertrand Meyer
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
Accept change
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.
Repeat.
And “when faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.”
That’s it.
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
as a company?
as a team?
as an individual?
What is the next small step we need to take?
Originally posted on Vision internal blog.
I use analytics cookies (Microsoft Clarity) to understand how the site is used and improve content.