This is a guest post from Jenny Martin and Pete Buckney from the Sparkle & Co Made Team. They will be giving an In The Brain Talk on ‘Examples Soup-to-Nuts’ at Skills Matter on 20 March, sharing their approach to Specification by Example, including how they invest in examples, and use them to drive collaboration and feedback at all levels in the business and all stages in the process. You can register for this free talk here.
Jenny works as IT Solutions Director for Sparkle Coupon Services and also provides consultancy in collaborative software development approaches. Jenny believes that great leadership is about creating highly participative teams and encouraging shared commitment and responsibility. Follow Jenny on Twitter @jennyjmar or at www.jennyjmar.com
Pete is a founder director of Co Made, and is passionate about using collaborative approaches to build software that changes businesses for the better. Pete also provides coaching and training in BDD tools and approaches. Follow Pete on Twitter @PeteBuckney or at www.comade.co.uk
The Problem
During the past 10 years there has been a massive transformation in Agile software development practices. Many companies are experiencing some pain. They have invested heavily in Agile transformation programmes but are either not availing of the benefits of Agile, or are having difficulty scaling these practices within their organisations.
Why is this happening?
The Rulebook
Photo: Flickr/Amy Allcock
Agile tends to suffer if implemented as a rulebook. This may be top-down, where a particular Agile implementation is mandated across an organisation, with training courses and defined procedures. It may also happen bottom-up, where exposure to evangelistic Agile messages may lead individuals to believe there is a One True Way out there that will solve all their problems, or may leave them struggling for the confidence to find out what actually works, due to fear of breaking ‘the rules’ or being classified as ‘not Agile’.
We believe that an effective way of working is best achieved by carrying out the work of trying to deliver value, and reflecting, tuning and adjusting our approach. Blind imposition or adoption of rules removes flexibility to respond to change, and halts the experimentation that leads to greater effectiveness.
Anti-Patterns
In the end, what we’re trying to do is put together people with a need and a capability, and collaborate on evolving something to meet that need. We want to measure how good we are at selecting options, providing opportunities for feedback and delivering the intended value, and how much waste there is along the way.
We see some recurring patterns of Agile implementation that do not optimise the overall delivery of value:
Development-Team-Centric Approach
Agile often seems to exist only within the development team with practices such as rigorous protection of sprint scope actually preventing interaction and change, and protecting the daily lives of the developers rather than delivering value to the business.
Product Backlogs / User Story Hell / Water-Scrum-Fall
Where we see a large backlog that reads like a list of product features, this is usually a sign of a waterfall project in disguise, even if the stories have been written in a “I want to…” ”so that…” format in an attempt to link them to delivered value. For example a team may be happily churning through all the items in the pre-ordained backlog without any focus on delivering the highest priority business capability or learning opportunity as early as possible.
Celebrating/Measuring/Optimising the Wrong Thing
This is often linked to a development-team-centric approach. For example, a team may have very accurate burn-down measurements and be improving their velocity every sprint, but may not have focused on the other areas of waste, in particular in the transitions of work in and out of the development team.
In some cases the fundamental impact of what is being delivered is not measured at all and teams get better and better at efficiently delivering features that nobody wants or uses.
Focus on Automation
Automation can deliver amazing value (for example Test-Driven Development approaches can create code of astonishing flexibility) and Continuous Delivery can allow for much earlier feedback, but a focus on automation can be symptomatic of neglect in other areas. To be effective, automation needs to be introduced selectively and at the right time – it’s more important to get conversations working that lead to high quality tests than it is for all tests to be automated.
Tool Focus
We like shiny new tools in IT, but if the process isn’t working or we don’t know what we’re trying to achieve, implementing a tool isn’t going to solve it – it’s more likely to disguise the underlying problems, or at the very best speed up a bad process.
Getting distracted using tools whilst forgetting the underlying principles associated with their use is an anti-pattern. The goal is not to implement the tool or the process, i.e. to ‘do Scrum’ or ‘do Agile’. The goal is the destination, not the method of transport to reach it.
Back to Basics
Would we be better off putting down the rulebook and getting back to basics? To demonstrate this point, let’s ask ourselves – which team demonstrates greater agility?
Photo: Flickr/Tark Siala
Team A: Vehemently protect their sprint scope once it has started, despite desperate pleas from the business to include a new requirement. They have a consistent burndown rate & have been improving their velocity sprint on sprint. They can now accurately predict how many stories they can deliver in each sprint. Releases have gone smoothly but nobody knows if the features delivered over the last 6 months are offering any real business value or how to measure any value achieved.
Photo: Flickr/donjd2
Team B: Don’t know what their velocity is. They have regular prioritisation sessions with the business and frequently change direction in response to changing market pressures. They sometimes don’t achieve all they set out to in a sprint, but have a very clear vision on the business goal they are trying to achieve. They set up small and regular releases as experiments to measure the impact of the new business capabilities they are delivering and are ready to take a different route if the road ahead becomes blocked. They have confidence that they can grow a successful business around the products they are delivering.
What if instead of implementing ‘Agile’ we set out to answer these questions:
- How do we get better at identifying smaller increments of business value to deliver?
- How do we organise ourselves better around the products and business capabilities we deliver to facilitate a shorter feedback loop?
- How do we collaborate more effectively?
- How do we bridge communication gaps between the technical & business teams?
- How do we get the stakeholders more comfortable with flexible scope?
- How to we collaborate on requirements ‘just in time’?
- How do we make our outputs and documentation more valuable and support our new product structure more effectively?
- How do we prioritise our work so that we know we are spending our efforts in the right direction and can respond to change quickly?
To help us with these challenges and to build something great that makes an impact, we need more than a single tool or set of instructions. We need a selection of tools, processes and techniques to choose from as well as the craftsmanship and experience to use them to their greatest effect.
The Toolkit (Here are some things that work for us)
Photo: Flickr/veryuseful
We’re keen to share some of the tools that we find particularly useful, the details of how we use them, and how they help us deliver value.
We keep coming back to Impact Mapping as a superb way to ensure everyone shares the big picture, and then lightening-fast identification of the quickest path to the next piece of value. We also identify items with a focus on what we want to learn next, and the minimum work required to enable this learning.
We use Dream Demo Visualisation to map out the specific demo we want to be able to run, including early sketches of the specific examples that will be demonstrated, rather than listing product features. Like Story Mapping, we find this approach helps to identify a quicker route to value.
We love Specification by Example, and the ubiquitous language of Domain Driven Design. We invest in our examples, and maintain the same examples from initial dream demo visualisation, through requirements conversations, into Test-Driven Development, and then consolidate into Living Documentation and Automated Testing.
We use a concept of Continuous Acceptance where BAs, testers and developers will be in close communication as an item is developed, and an item will be accepted within minutes of a commit, rather than later in a sprint cycle. This also means our showcases to stakeholders are not acceptance events, but are themselves opportunities for feedback on the new items and a chance to factor changing priorities from the real world into selecting the next item of value.
Overall, what is most important to us is maximising opportunities for feedback and learning. Our Feedback Onion Model captures our thoughts around which tools and examples are most appropriate to facilitate collaboration at every layer of our business. We work really hard to ensure we are collaborating on the most important examples in order to get fast feedback on our ideas and assumptions in the real world. Questions such as ‘Should we pivot or persevere?’ and ‘Can we build a viable business around this?’ are more important to us than ‘Are we doing Agile right?’.
Don’t forget, you can hear more from Jenny & Pete at their In The Brain Talk on ‘Examples Soup-to-Nuts’ at Skills Matter on 20 March.
Jenny and Pete are also each presenting at CukeUp! 2014. Jenny is running an interactive workshop on Impact Mapping and Pete is talking about ‘Conversations, Examples and Living Documents’ and sharing some technical tools that support these approaches. Register for your ticket now!
The Skills Matter Blog 
One comment