Fighting my way to agility - Part 3

Breaking down work

On a large complex hairy project, work just gets big.  Our work was big.  And breaking down work is sort of an art.  The think time was usually 10x the coding time, and the test time would explode by just changing 1 line in the SPC engine.   When we tried to force big work into a small box, the team kept trying to slice it in ways that didn't independently deliver anything useful - which you're not supposed to do.

A lot of times in a break down we'd get a requirements story, a design story etc… and not because the team was just hung up on waterfall, they were trying to figure out how to break down 'think'.  After all, how do you break down a 1 line code change story when the scope of the work is really thinking through and testing the implications of changing that line of code?  Clarifying the exact expectations for a specific SPC behavior might take the developer and customer working together for a couple weeks.  Our stories might have looked 'wrong' to some, but when these cases came up, breaking down 'think' work this way was helpful.   A more problematic breakdown attempt had stories that checking in the code for story part would leave the system unshippable.  When this would come up we would work really hard to find another way - which usually meant creating a story to find another way.  In either case, all of the various story parts that didn't independently deliver anything useful we tracked under an epic that did.

In the process of trial and error with breaking down work, we learned a lot about what mattered and what really didn't.  

Lessons Learned on Breaking Down Work

Teach over Force - Given all the pain we had, rather than making a box and forcing work to fit, I would focus teaching break-down work skills.  Whether your box is fixed or not, you need to solve this problem.   You can aim for a box, but don't mutate the work to a degree that it violates the below constraints.  If you can't come up with a way to do that, just leave it as a big item.

No Invisible WIP - If you have stories that don't deliver anything usable to the customer (e.g. my requirements story), track them under an epic.  Not because of some Agile holy gospel, but because if you don't it HIDES work in progress.  You have a partial investment in work, and over time you have thoughts rotting away, and code that may not even work sitting in your code base.  If its not ALL done and you have to even think about the set of changes again, its WIP.  Keep all your WIP in front of you, all of the time.  It should remind you of everything that is part way done.  Push to finish what you started before starting more stuff.  Push to get back to shippable as soon as you can.  Don't let yourself feel like the work is all done when you still have WIP.  Its not done.  That looming manual testing that tells you whats broken in your code? The integration testing with that other system?    Your stories are still in progress and if you hide that fact its easy to feel ok about starting more work.   

If you are not shippable, you still have WIP.  This is probably the most critical thing I see missed for people in any process - invisible, hidden WIP.   I think its one of the main reasons people don't even see what otherwise would be a glaringly obvious problem.

Vertical Slicing - The typical strategies of trying to break work into vertical slices (sliver of usable functionality traversing all layers of the system) and finding the smallest possible thing that can work - all are generally good advice.  Try to break down the implementation of the work by iterating over even smaller vertical slices, even if its totally not useful.  You learn a lot in the process, which tends to reduce rework.

Don't abandon your requirements format - "User story" format can be helpful, but it's not that important.  The key is communication.  Whatever you need to do to effectively communicate the purpose and expectations effectively - use what works.   If you've got something that is working well for you, don't change it.  Don't assume stories are going to work better for you.  After some chaos and thrashing, we basically settled on a 'story statement' added to our existing really formal requirements document.  Distributed communication, cultural barriers, complex requirements all make communication REALLY hard.