Introducing the Agile Anti-Framework
Going beyond Agile to drive flexible development
By Ben Flowers, Lead Engineer at BCG Digital Ventures
In my time working with software teams and building ventures, I’ve learned that each scenario requires a different development framework. That’s why I advocate a new approach — anti-framework development.
Ventures at BCGDV
Every venture that we build here at DV London is different. As a result, we empower teams to build in whatever way makes them most productive. The one thing each end every venture or product building process has in common is the continuous evaluation of consumer behavior and the frictions consumers experience.
We do this through continuous ethnographic research cycles, user testing consultations, and our deeply integrated, analytics-first approach to software development. We are in the business of building businesses, not just software — We focus on delivering viable businesses rather than delivering “to spec” software applications.
One trope you hear often in the startup world is the concept of a pivot. When the businesses we build reach the incubation stage, complete business concept pivots are rare, although they do occasionally occur. But when you talk to customers as much as we do, the information you gather can mean frequent mini-pivots in thinking and approach. These pivots can happen daily. Given this, it’s vital that we have a product development framework in place that enables us to be flexible.
Let’s do Agile
The market is saturated with digital agencies and software houses who advocate for Agile™ delivery methods such as SCRUM® or SAFe©, and so of course these may be the obvious option to deliver working software for our ventures. However, due to the flexibility we require, we’ve taken a different approach.
The comparison
Frameworks like Scrum and SAFe have rigorous rules and procedures that must be followed, referred to as “ceremonies”. Throughout this comparison I will talk mostly about Scrum and related frameworks, partly because Scrum is currently one of the most widely used Agile frameworks and partly because I don’t have the time to get the PhD required to understand what is happening in this diagram:
TL;DR Scrum
Scrum advocates cross-functional teams working together to deliver working software in two-week iterations, known as sprints. At the beginning of a sprint, the whole of the Scrum team (all engineers, PMs, designers, QAs and the Scrum master) get together to estimate the complexity and effort of every single user story for the sprint, which are selected from a long backlog of stories for future work.
The team works on the selected stories, releases the software and then circles back for a retrospective after the sprint is complete. The Scrum master keeps an eye on the number of story points completed and calculates the team velocity. Team velocity should never be compared with other teams’ velocities, but should rather serve as an indicator of the changing productivity of the team week-to-week.
IRL Scrum
The reality of Scrum is somewhat different from the picture painted above.
Sprint planning can take around 3–4 hours, which translates to 27–36 people hours for a team of 9 people, and estimating individual stories does not directly add value to the delivery of the product, as the estimations inevitably end up with something like 1 point = half a day, 2 points = 2 days, etc.. Teams rarely change priority based on story points, and in the event of something new coming up stories are simply added to the workstream without swapping out another of the same size.
Daily standups follow the format of each member of the delivery team giving a cursory update on their work, along the lines of “Yesterday I did…”, “Today I will…”. This becomes an update on what each person has been doing, not on the progress of any story or any blockers they might have.
Transplanting Scrum onto a DV venture
The DV venture model relies heavily on quick, iterative feedback from customers and learnings we gather from this feedback. We have incredibly tight schedules — We deliver multiple ventures each month, and an average venture goes from idea to commercialization in eight months.
When I thought about how the the Scrum model would operate in the case of my most recent venture, I concluded that it simply would not work. The fortnightly release cadence would not provide adequate time to learn from our customers. The long “entire team estimation session” wastes a lot of time for the whole team —Our already-tight deadlines would become even tighter. This becomes more wasteful still when we consider the number of mini-pivots that are likely to occur. If our entire team were to spend time estimating and working on an unnecessary feature, that would eat into our tight deadline.
I believe in empowering teams and actively avoid micromanagement wherever possible. Standups that focus on what people are doing feel like a status update about what each person is doing with their time rather than a genuinely useful exercise in team operation or product delivery.
Another Way
In order to be as productive as possible, on my most recent venture we forewent the traditional Agile framework and focused on feedback loops.
The board
The centerpiece of our process is the multi-streamed Kanban board. The board is the single source of truth as to what the team are working on and a good indicator of progress on an epic or feature.
In our workflow there are several types of cards:
Epics: These represent large user features or themes of work. Examples of this might be the Facebook newsfeed or Account signup.
Stories: These represent individual features which provide user value. Examples might include Seeing status updates from my friends or Creating an account with the service.
Tasks: These represent tasks which are critical but do not necessarily provide any visible user value — these should be used rarely. Examples might include Adding structured logging to the application or Updating the copyright year in the CMS.
Bugs: Obviously we never have any of these. If we did, these would be any issues that come up and require fixing.
The board is broken down into individual epic streams where the highest priority epics live at the top, with the lowest at the bottom. Individual stories that live under the epic are displayed horizontally in the stream and the rightmost story is of the highest priority.
Work progresses through the board as it is picked up by engineers and ultimately released to live once it has been reviewed by the feature owner (the PM, designer or engineer). This process happens continuously, so we can expect to release many times per day.
The streamed approach allows for multiple developers to work simultaneously on a single codebase and allows for the concept of a feature lead — this can be useful when the team grows in size.
Working on features by priority rather than time allows us to quickly and easily adapt to changing requirements and react to user feedback, which can happen quickly due to the continuous release process.
#now, #next, #later
We do not maintain a pruned backlog of user stories for development. This makes no sense in our world, where pivots are a normal part of the development cycle. Instead, we think about things in terms of what we’re immediately working on #now, what is coming up #next, and things we should have in the back of our minds for #later.
The stories are placed in priority order, with the right hand most stories on the horizontal #now being the highest priority.
Stories that might come into #now soon but might not be absolutely necessary for our validated learning are placed in the #next category. This is a wall where we categorise the next-up work streams. We break up the epics and stories into grouped themes, e.g. Security, Tech Optimization or some other broad category at a much higher level than an epic.
This is absolutely not a product backlog or in any way prioritised. Instead, this is a cue for a conversation in the next PED session (see below) where we can look at what we should work on next.
Stories and epics in the #later section are not (usually) broken down to the level of story, and are usually things which need to be done at some point in the future (or not at all). Most of the time, team members will upvote these stories or epics so that they get moved from #later to #next.
PED
The PED session is the crux of the development process. Product, engineering and design leads review the learnings from the previous work period, hypothesize possible solutions and weigh these factors up against delivery speed.
The key differentiator here from a Scrum planning session is that only the key stakeholders are required to attend; everyone else’s attendance is optional. The goal is not to estimate the size and complexity of tasks — or to fill some imaginary bucket of “developer/designer resource”. The output from this is a series of user stories or tasks and a priority. These stories or tasks will go to the design team if they have not yet been designed or to the engineering team to build. These meetings occur with just enough frequency to keep the pipeline full — for us, this was every two days or so.
The stories and epics that come out of the meeting are small enough that they do not need a full requirements spec, but are rather a contract for a conversation about what the expected outcome from the story is and what the user value will be.
How it fits Together
After fitting this simple process together we end up with an incredibly LEAN process which minimises the amount of wasted time and optimizes for quick feedback from real customer insight. This process is something which has grown organically over several projects I have worked on at DV, and it continues to evolve.
Great! Where can I get my certificate?
Frameworks capture a methodology which works in one particular sector, industry or company. They are a snapshot of best practice at any one time in any one place. They are not a silver bullet or an excuse not to follow your own ideas. For these reasons, I will not be going off to the mountains with 16 middle-aged white guys to set these practices into stone.
If you do not follow every practice, that doesn’t mean Martin Fowler will be knocking on your door to shout at you. Nor does it mean your team is somehow less good than that other team, who recite the prime directive before every retro.
The key takeaway is that any rigid agile framework for software delivery cannot work in all situations. Instead, I encourage you to adapt your process to your development cycle and know that it is an organic process, that you and your team can and should change to ensure the very best product hits your users’ hands as soon as it possibly can — and not at the pace dictated by someone else. So join me in rejecting Agile Frameworks and become an anti-framework advocate — be agile af.
Follow Ben on Twitter at @bdwflowers
Interested in working with us at BCGDV? Want to find out more? See our current vacancies.
Find us on Twitter @DV_Engineering.
