Critical Paths

Critical Path

I saw one of our projects put into the usual tool for displaying a critical path.  After 5 or 6 boxes – the path ended in one big long box that really said “BIG UNKNOWN” and stretched into an end date.  It made me smile, and I waited.  The project manager got to that box and expressed to the group his immediate need to have the group break this down and detail the contents of that box.   Now although this particular person worked around 6 Scrum teams in an agile program; he was mapping to a tool, understanding the work in a way he could relate to.  He is also a really good guy.  I asked him to wait until we got a little closer and the teams would address everything that was big and unknown.

Get Closer to the Work and You Typically Have More Information. In Scrum there is a particular level of thinking that is appropriate to a story.  There can even be a level of maturity to a story… Is it well-formed? Does it have acceptance criteria? Are all dependencies addressed?  We estimate the bigness of the work.  We pretty much accept that the work might be ANYTHING.  We trust it is valuable.  Then, right before the team commits to doing the work, we task it all out.   We are now thinking at a more detailed level, appropriate to getting this work done in a time box we are used to. I call this disruptive innovation, because it can cause us to have a placeholder in time for that future work.  We estimate the size of it, which figures along with what the capacity of the team is for getting this work done.  In essence this is a risk assessment that the critical path diagram will never give you.  What is the ability of the team to address this work when they begin it?  Scaling on a larger level – what is the capacity for the organization to get this into the customers hands?  Ideally the end of the sprint work is potentially shippable, but reality of our situation may have additional transactional cost to move this into production.  We have not yet changed our organization into something that can accept this work and with immediate response and light weight  processes – use it.

There can be only ONE? Larger projects which coordinate several teams on a release can have soooo many pieces in motion that we emphasize constant prioritization, regular touch points, matched cadences, and set events with appropriate levels of scope and focus.  This also means that are critical things might be tasks, dependencies, knowledge, availability, …  not just time.  and Hey, we are delivering the right thing in the right way…. if not .. lets quickly adjust and iterate! I am also a student of probability – and if we address a problem in three or four different ways, or have three or four different people involved and swarming, or have mitigation/contingencies, and make this visible to a larger cross-functional group…  We have behaviors that will make our solutions better, appropriate, and acceptable.  No matter the hidden unknowns.  We can slice the work vertically through all the layers to get up to the user interface, or perhaps we need to build out a little bit of architectural runway.  We are emphasizing the actionable solutions.  A plan is great to have – but a teams ability to adapt and be flexible along the way is a much better indicator of whether the end game is achievable.

Emphasizing  at times the Destination and at times the Journey.  It is our own ability to adjust, respond that we look ever to improve.   The date will pass. Project management used to have time, scope, and resources… Time and Scope used to be fixed… Very often all three were changing and up in the air.  More than three independent variable might be something close to chaos theory.  In scrum we emphasize that time intervals are fixed, and these will aggregate.  The resources are fairly fixed, but the scope of the work changes.  Work is highly varied, and yet flexible.  How many ways are available to perform this work? Are we doing this in the most effective way possible?  Not only will we have the work done, but we will improve the organization around us, our tools and our processes.  More importantly, we will also emphasize the growth of the people and teams that perform this work.  You will never see that in a critical path.


Please leave a reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s