Avoiding Agile Fragility Beware Silo Left Shifting

Imagine the scene: You’re working on a project where the intention is to follow an agile approach.

You’re a few months in and are happily writing user stories, but something prompts you to pause briefly and reflect.  You look at the user story in front of you and there are reams of detail. It is very similar to what a requirement would have looked like in a traditional business requirements document (BRD).  Yes, the format is different, and the story is written in a fancy agile management package that produces all sorts of fancy management charts and graphs, but when you step back you see a BRD split into functionally-decomposed story cards. In fact, you notice there is more detail on some cards that you’d have expected in a traditional BRD and the backlog is so huge it’s difficult to see the wood for the trees.

You conclude that yes, the work might be being delivered incrementally, but the delivery approach looks far more like a series of mini waterfalls than a truly agile process. There’s little discussion or communication, and a lot of documentation being produced.  You pause and ask yourself ‘how did we get here? We seem to be working in a hybrid approach which combines the worst elements of various approaches!.  Do you recognize this pattern?  If so, you’re not alone—I can still remember the shock when I first experienced it and it’s a pattern I’ve seen fairly regularly since. I’ve nicknamed one of the causes of this pattern silo left-shifting, and I thought I’d write this article to share my perspective and see if other BAs have experienced it too. Of course, your experience may be different!

Beware Silo Left-Shifting

I’m sure there are many reasons why this pattern can occur, but one relates to the way that a product (usually software) is being delivered.  In many cases, off-the-shelf packages are customized, configured and integrated by one or a number of third party suppliers.  Quite rightly, the accountability for the business analysis stays within the client organization (‘the requirements’) and the accountability for the technical design and implementation stays with the third party (‘the solutioning’).  There will undoubtedly be a desire to collaborate, but there will be a contract between the two organizations which determines that certain artefacts need to be produced, and there are certain contractual sign-offs etc, potentially with penalties for non-delivery.  Whilst we might not ever see the text of the contract, on the ground we feel its implications.  Collaboration can become difficult when the contract is divisive and coercive.  When the ‘pre-sales’ team within a supplier has had to concede on price to get the bid, the ‘delivery team’ (who may well be made up of different people) are stuck with the commitments their colleagues have made.  The pre-sales team may have even committed to a delivery date based on an initial understanding of scope that was ‘optimistic’ at best…

Imagine being a vendor who wins a bid and needs to get up to speed quickly, with a pressing contractual deadline.  You probably haven’t got team members spare, just ‘sitting on the bench’, so it takes time.  Yet the client wants to move fast, their project started months ago.  In fact, the client’s BAs are already writing user stories and the project manager and supplier management team at the client are worried about a lack of progress.  Your account manager is under pressure, and that pressure gets passed to a project manager which gets passed to the part-time developers who you’ve currently ‘borrowed’ to at least begin to get things moving.  They are doing their best but need the client-side BAs to slow down… there’s no time for the conversations that go alongside the user stories.  But it would be politically difficult to ask the client to ‘slow down’ as it would admit a lack of current capacity… so there’s a dilemma.  Then the silo left-shifting starts… Why not ask them for more detail?  And if there’s still not enough development capacity ask for even more…. Shift the work left! This will act as a useful speed-bump and seems constructive—it’ll be useful when the development team is up to speed.  It’s a small, seemingly insignificant change that incessantly creeps over time.

Crucially, this overlooks a key problem: The analysis and design/delivery activities aren’t synchronized, aren’t collaborative and two silos have emerged.  One team is moving at a faster pace than the other, and work is being produced just to act as a buffer between the two teams.  If the desire is to focus on agility, then surely the focus should be on communication, discussion irrespective of role?  There shouldn’t be ‘left-shifting’ between silos because there shouldn’t be silos in the first place. If there’s no conversation happening, and if everything is written out on story cards weeks or months before a developer sees them, then is this even the least bit agile anyway?  Aren’t we just ‘throwing it over the fence’ and haven’t we inadvertently crept towards a fairly linear, waterfall-esque delivery approach?

Calling It Out: This Is An Organizational (Not Vendor) Issue

It might sound like I’m having a pop at vendors here, and that really isn’t my intention.  Often vendors are stymied by contracts, estimates that have been taken as ‘commitments’ and all sorts of other constraints apply.  Ultimately, much of what I have described here is to do with the way the organization has managed its contractual relationship with the vendor.  There might be little we can do at a ground level to influence this.  However, there are several questions that we can ask, in particular I have regularly found the following useful:

1.What do you mean when you say ‘agile’?  ‘Agile’ is a word that appears a lot in the product and project world, but there are vastly different interpretations of what it means in practice.  I’ve learned to ask different stakeholders what exactly they mean by agile, and also whether they are happy with the potential implications of that.  Understanding whether different expectations exist over ‘estimates’, whether we really are going to have a self-organizing and multidisciplinary team, the delegation of decision making to product owners and so forth is important.   And calling out where differences in perspective exist.

2.How are we going to handle communication and documentation?  ‘Documentation’ is sometimes seen as a dirty word, but in my view it shouldn’t be.  The question here is how much are we going to document, and to what extent are we comfortable relying on communication? What will be documented after implementation?  Are we comfortable with a user story being ‘a placeholder for a conversation’, or are there contractual reasons that more information is needed up-front?  If there are, then let’s discuss that early.

3.Do we have the conditions to practice agile?  If the contract has been written assuming a waterfall delivery and if there’s no appetite to have collaborative cross-functional teams then perhaps we’re better off not kidding ourselves.  We could still be incremental or maybe even iterative; but let’s agree on an approach that works for the context.  Let’s not force an approach that doesn’t fit the context.  This is often an unpopular view, but let’s face it, if we march on ignoring the fact that the conditions aren’t right, we’ll just end up with a BRD split onto story cards anyway.  Of course the longer-term game here is to cultivate the conditions that will be conducive to agility, but when there’s a ‘burning project demand’ it can be worth separating this out as a longer-term objective.

I’m sure there are other questions too, and the questions above when taken with others can help create a conversation that avoids the fragility created when the silo left-shifting occurs.  Of course there are other causes of these issues, and this article addresses only one.  I hope you’ve found this article useful, and I’d love to hear your experiences too. Please do connect with me on LinkedIn and tell me your experiences!