Skip to main content

Hands Across the Conference Table: Coordinating Simultaneous Agile Work Streams

Most of the people I interact with are unequivocally excited about the opportunity to try agile for the first time. Not.

Most people have doubts. And one of the top questions I often get is "can I seriously use agile for a very large project with multiple work streams, and with cross-impacts from other groups who aren't agile at all?" Yes! Yes, you can. In fact, agilists and the agile approach has a particularly strong set of tools for helping you manage cross-team interactions. These tools not only help you scale your "pure agile" project management approach, but also can help strengthen best practices in your "waterfall" PM approach, if you're working in a hybrid environment. So let's talk about that.
From https://eventioz.com/events/culture-and-projects-are-not-like-oil-and-water-th--2
First, a few myths that you might have heard, but I'm sure you agree aren't true.
  • Agile doesn't scale.  Um, wrong.  Agile Scaling has been around for almost as long as agile itself, discussed, for example, this year by Tom Grant, in his blog on Forrester, and supported for ages before that by well-known luminaries Scott Ambler (Agile@Scale) and Dean Leffingwell (Scaled Agile, Inc.).  Myths about non-scalable agile are just there to prevent poor, deprived enterprise IT people from enjoying their rightful standing in the world of agile.  You're falling prey to agile snobs who prefer to work on small teams for small companies with bean bag chairs, and they are successfully trying to make you feel bad for working in a big company.  Sometimes it's hard to be Goliath.
  • If you do planning before you start coding, in order to support agile at scale, that's not agile.  Wrong again, in my humble opinion, and of course that of many others.  
But let's say I concede the point, and agree that every single practical thing that you might do to make agile work at scale makes it not-agile.  Let's look at what you can do within a multi-stream project which has agile elements (that would not be possible in a classic waterfall implementation).

You can plan the optimum number of work streams/work teams for your project in the first few weeks after kickoff.
  • For the work you will be able to manage internal to the scope of your own project, and will therefore be able to handle in an "agile" manner, you have divided up the needed features into small enough pieces that you can see in a very granular way whether it's possible to create parallel work streams who won't step on each other by touching the same parts of the code base simultaneously, or ever.  
  • Agile release planning calls for partitioning the work across the teams after you understand the architectural direction and the full feature set, but before you even start detailed analysis.
  • If you have an insufficient number of people with analysis, development, or testing skills to keep development moving in multiple streams, you know that ahead of time, rather than hiding those details in the "batch" mentality of delivering all requirements before starting all development.  
You can plan integration strategy with all cross-impact partners proactively.   Effective agile teams will inventory their data interfaces during release planning, and for each interface, determine:
  • Is the integration partner already done?  In this case, we build to their specification.
  • Is the integration partner going to start work after we're completely done?  In this case, they will build to our specification, and we can document where we ended up later, so long as it's in time for their process.
  • If the partner is building in parallel with us, targeting the same release?  Then the next question is, is the integration partner doing their needed new work in an agile or waterfall methodology?  For waterfall partners, agile teams need to develop detailed requirements around the interface before starting subsequent work, so that the agile team can mock and stub the partner behavior correctly, even if the partner doesn't have time to collaborate beyond that.
  • But better, does the integration partner want to do proactive interface testing with you, and could that be scheduled ahead of the official "Integration Test" period for the release?  You and your partner teams can also make proactive arrangements for mutual stubbing or mocking of code, developing test sets reciprocally (you provide test strategies around your code as it interacts with their system; they provide the obverse to you).
You can still do meaningful program-level roll-ups showing progress across the disparate work streams, so long as you agree to use business-friendly metrics like "actual code complete" rather than "points burnt up."  And in fact, since the work streams which progress in an agile manner will get to the coding sooner, the program-level dashboard becomes a showcase for the delights of agile over waterfall.

Please don't let the agile-for-tiny-teams-only people get you down.  Corporate moguls running ginormous agile programs world-wide, unite!  You have nothing to lose but, hm, okay, well, it's actually quite good to be a ginormous corporation.  And agile scaling just adds to the benefits.

Comments

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica