Agile Delivery : A Slice of Delivery

TL;DR: For me, Agile is about ensuring that my teams can deliver predictably, consistently with quality. An important part of that is understanding how to split out your deliveries, so that every deliverable is instantly useful and has some value for your stakeholders. 

So, um, when do we deliver?

In the first ever Agile class that I took, taught by the awesome coach Christopher Avery, towards the end of the class, a product manager that I worked very closely with at the time asked the age old question - “Agile is awesome and all, but what about the delivery? Sprint Shprint, when do I get to deliver something to market? How do we see forward motion?”.

It’s about the delivery innit? At the end of the day, when your business teams are asking when you can push something to your customers. That is not a very comfortable time to talk about Agile and how you’re following the process, if you’re not delivering value. Most young Agile teams are very enthusiastic to adopt Agile, but ultimately give up on the discipline required to make most things work. Even if you’re disciplined, teams will begin delivering in small increments that the business team cannot consume.

Here is where we rejoin the conversation with Chris Avery, who basically said, it’s about how you structure your deliverables - most teams are used to delivering horizontally (database first / middleware next and so on), versus what they should be doing, which is to deliver vertically (shell of an app / static sign up page / validations implemented etc). His advice was to slice the work vertically.

At the time it didn’t really sink in, till we tried it, and when it worked, it was like a light-bulb went off. It’s hard to think horizontal delivery anymore, just doesn’t make sense. 

Agile gets a bad rap because people think Agile is about building something large in small un-shippable increments. First and foremost, Agile is about delivering constant value to your stakeholders, in everything that you do. Therefore, any deliverable that your stakeholder cannot consume, cannot test, violates a basic principle of Agile. It might not be shippable to your customer, but it sure as hell should be shippable to your stakeholder in some form. 

Dice and “Slice"

While there is a lot of conversation about Minimum Viable Product (MVP), sometimes, even sarcastically so, the concept of Earliest Testable Product (ETP) very eloquently captures the concept of vertical slicing. I’d recommend reading that long, but rewarding article on ETP, I haven’t read a better explanation of how to approach Agile delivery. Post your planning meeting, once you’ve figured out what it takes to build the product, take it the next level and talk about sequencing and what your stakeholders will get every week or two weeks, whatever your release cadence is.

Now, this is harder than it sounds. Requires a shift in how you think about work and what you think mentally constitutes value. A page with just a button that does nothing, for me, is a deliverable I’d take. It’s testable. I can view it on multiple client resolutions. I can show it off to my business guys if I want to, who might tinker with it’s placement lets say and might have early comments about it’s usability. 

Slicing Visual Features

If you’re building an app or a website, it’s easier to get on board with this method of dicing the work. Lets say you were building a brand new landing page experience, which had a hamburger nav element and a news feed as the default. 

Here is a sample slicing of how that work might look like: 

• Blank landing page post login
• Hamburger icon, does nothing when you click it
• Hamburger icon, slides open new menu frame, nothing in menu frame
• Hamburger icon, slides open new menu frame, shows static selection options, not clickable
• Hamburger icon, slides open new menu frame, first item clickable, takes you to existing page
• …..
• Hamburger icon, slides open new menu frame, n items clickable, takes you to existing/new page
• Default landing page with static text
• Default landing page with first element as interactive 
• ...

Notice that each “slice” is observable, testable and stakeholders can interact with it, if they so desire. Technically, this work will break down into back-end and front-end tasks.

Lets pick one of the slices and break it down into what it means:
"Hamburger icon, slides open new menu frame, shows static selection options, not clickable"

• Enhance UI widget with slide option
• Call API delegate to get list of menu options. API can return hard-coded JSON to start with. 
• API will return real list
• Sorting as per spec
• Localization per spec

See what we did there? We took a vertical slice and stuck back all the real engineering that was needed to make it happen. If you were to do a horizontal slice, you would probably not integrate the UI with the API in the same “deliverable”. Therein lies the difference. You integrate often, contracts are made and honored right from the beginning, so that we front load risk. 

Slicing Non-Visual Features

When non-visual features are being delivered, it can be a bit challenging to show value to your stakeholders. Let’s say that you were making the search feature of your product smarter. How would you break down the work, so as to demonstrate progress? When you’re in these situations, a good way to test and demonstrate progress, even for the team, is to build a quick and dirty demo app / page that invokes your API. You can even leverage API automation products like PostMan or whatever your favorite client is to test and organize API’s.

The deliverables here might look like:

• Identify input search strings and output search result sets. Validate them on the mock app, to work as it does today. 
• For each type of search string, hard-wire the result JSON from the API. (this allows integrators to get a crack at even using the existing apps to start testing)
• For each type of search (lets say you had samples for exact, partial and predictive matching), remove the hard wiring and show the real result
• Demonstrate performance bench marks for each type of search
• Demonstrate the scalability bench marks for each type of search

Again, each deliverable leaves you with something to show for forward progress. These are vertical slices, rather than horizontal slices, where you would potentially spend time first tuning your schema or back-end models first and when asked for progress or to show something, you’d show perhaps a query result or something in a spreadsheet. Not very satisfying or convincing when you’re trying to demonstrate progress. 

Toggle or not Toggle?

If you’ve been with me so far, your next quality question should be about when something goes into production. The answer is - as often as possible. Release to production in smaller increments, so that you’re not left with a giant big bang release, which are always jittery affairs. Now, again, like everything else, this will require planning as well, you’re going to have to build in feature toggles into your product, so that you can deploy your changes “dark”.  

Depending on what you’re building, this will vary in difficulty. If you’re able to build in the feature toggles, it will afford you immense flexibility in getting code to production in smaller bits. It will also allow you to potentially test your changes in smaller test groups of team mates or stakeholders in a production setting, which always gives very valuable feedback.  

Slice It, Prep It, Cook It!

Hopefully, now you see the orchestration. Starting with planning, then sequencing into chunks and ensuring that each deliverable goes behind a a feature toggle so that you can deploy at will.  

I’ve said it in my earlier posts, you should make your customer work at your own peril. For the purposes of this discussion, your customer is your Product Manager or your supervisor. Making them work by showing them highly technical output or by rattling off a complex technical issue list is only going to add to the FUD. These are your allies, your partners in crime. You’re doing all the hard work, so show that off!

To me, the most important side-effect of this technique is - satisfaction of delivery. This is the true joy of Agile, when work is completed at regular, short intervals, your stakeholders are so busy accepting the things your team is producing that they’re gasping. That is a wonderful wonderful thing, the sweet hum of delivery and customer facing value! 

Teams take time to adopt this mentality and some people get it right away, while others struggle with giving up their traditional notions of delivery. Ultimately, moving to this type of model in your Agile team has shown me the most value from my teams. 

Let’s go out and make em sweet vertical slices!