One of the biggest hurdles in getting to Continuous Delivery and truly being Agile does not lie within the development team itself. Change requires a mindset that all people (managers and executives too) must adopt. Just as it takes a village to raise a child, it also takes a (corporate) village to raise a new culture. The movement away from Waterfall to Agile and Continuous cannot be handled just by one person.
Does the following situation sound familiar? Someone asks you for an estimate for the Level of Effort (LOE) of a feature. Not just a t-shirt size, but in days — something to be delivered sometime that year. You don’t have much time to really dive into it (it could even be during the same meeting that you first hear about the new feature), but you have to know all the details up front. So you give a number that you aren’t supposed to be held to because of all sorts of caveats you listed. But, someone remembers that number. And since someone said you are Agile (and Continuous Delivery), now you have to not only meet that estimate you gave up front, you are now tied to an Agile sprint with no room for error. This goes against everything you say you are!
To truly get to Continuous Delivery, you may need to step out of your comfort zone. Step away from promising a feature in a particular timeframe. Think priority. Think small chunks. Think iteratively. Get used to the unknown, but plan for it. Forecasting is not accurate and results in broken promises across the board. It certainly doesn’t help to hold someone’s feet to the fire if what they built today doesn’t match what they thought four months ago. The inexact nature of estimation doesn’t matter as much when you are delivering frequently and iteratively. Release early and often, and you can be dynamic in responding to customer feedback.
It is so important to have this ingrained not just in the team doing the work, but also in the people making decisions, prioritizing features, and talking to clients. If they are stuck in a Waterfall mentality, how can you progress to a Continuous model? I think everyone needs to know what it really means to be Continuous and Agile. It is a culture and a mindset — not just a process — that everyone needs to understand and believe in,from the individual contributor to the CEO.
Turning the Tides
Let’s take a look at some ways teams may be struggling, and how they can adapt to turn the tide and get to Continuous Delivery.
|The Struggle||The Agile (or Continuous Delivery) Way (1)|
|One person (or a small group) pre-defining granular stories and what is in or out of scope before it even gets to the team.||Team gets epic, maybe milestones.
Team discusses epic together regarding open questions and overall definition of functionality.
Team defines milestones.
Team defines the stories for first the milestone and starts the backlog.
Team defines technical or planning spikes for subsequent milestones.
Team determines granular estimates for initial work, rough estimates for following work where possible.
|Telling someone WHAT to build
(Example - “Just build this feature”).
|Understanding WHY you are building it and WHO you are building it for.
(Example — “As a
|Planning and scoping everything (all stories, all tasks) in advance.||Iterative planning that occurs every sprint, in priority order. Maybe you don’t get to a few stories. THAT’S OK.
You don’t know the effort for everything up front. Just what you are taking into the sprint.
Use backlog grooming and story mapping to flesh out stories and assign story points.
Focus on the higher priority things. Lower priority things can wait.
|Dev Managers make decisions on prioritizing backlogs based on ad hoc conversations with various people.||Priorities need to be clearly communicated by PM, with daily (or at least weekly) involvement in backlog grooming.
Prioritization cannot happen in a vacuum. Overall feature/theme/epic priorities need to happen at the cross-tribe level and be visible to all.
|Accepting things into a sprint without knowing acceptance criteria.||Don’t start work until everyone on the team knows what is needed to be successful.|
|Driving towards feature complete, and not releasing until an epic is complete.||Release early and often. Get customer feedback as soon as possible. The Minimum Viable Product (MVP) needs to be small. Think of it as a preview. This way you can pivot from customer feedback, and work on epics doesn’t go on for long periods of time.|
|Making feature branches live for long periods of time creating a maintenance, merge, and regression. Headache.||Leverage feature switches so that you can merge feature work into release branch as soon as it’s done, even if it won’t be visible to customers.|
|No Agile training or prescribed process for team members.||PM/management needs training in Agile and needs to commit to changing along with the dev teams.
All engineers, UID, QA, and PM involved in scrum teams need Agile training.
Let’s be clear, though — The Continuous model is not something that just happens overnight. It takes hard work and discipline, and understanding what is needed to address each aspect in order to be utilized successfully. If your leadership understands what it truly takes to be Agile, they can help you realize your goals. Without their transition to the Agile mindset, you are still Waterfall compressed into the pressures of an Agile timeframe.
(1) The opinions in this column are a combination of experience and research derived from Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and Janet Gregory, Chapter 3 – Cultural Challenges.
Ashley Hunsberger is a Quality Architect at Blackboard, Inc. and co-founder of Quality Element. She’s passionate about making an impact in education and loves coaching team members in product and client-focused quality practices. Most recently, she has focused on test strategy implementation and training, development process efficiencies, and preaching Test Driven Development to anyone that will listen. In her downtime, she loves to travel, read, quilt, hike, and spend time with her family.