Irresistable Force meets Immovable Object

This is one of those ‘tree falling in the woods’ philosophical conundrums which looks great on paper or at some party, but gets a bit out shape when you hit the real world.

To be the pedant – which I do so often – no object is immovable. Newton sorted that out – a = F/m. In short, an object will move if a force is applied. Small object needs a small force to get going, and the greater the force applied then the greater the acceleration. So a big object will move even if a small force is applied – it just won’t move very much. Likewise with ‘irresistible force’. Well, every object with mass has inertia, at least in this Universe so I guess what this boils down to is ‘huge amount of energy hitting something massive that isn’t going to move quickly.’

However, for this post I’m considering something a little more metaphorical; Fixed Fee contracts  and Agile projects.

Most vendors don’t like fixed fee engagements as this means that the uncertainty that may risk an overrun can equate to reduced profitability or even loss on a project. Their preference is T&M – time and materials – so, if there is an overrun, the vendor will just keep billing for the hours worked.

Most clients don’t like T&M engagements for the exact same reasons. The thought process is that we’ve brought you in as the expert, so you should know this stuff. You should be able to generate an accurate number so if you get it wrong, you will carry the can.

In the Waterfall world, this wasn’t as much of an issue since you’re applying a known process for a mature and understood product.

However, once we start looking at complex projects that have a high level of uncertainty and almost guaranteed to change, then who carries the cost of the uncertainty? Clients and vendors point the finger at each other.

One route is to identify the key features of the new product and group them as:

  • M – MUST: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.
  • S – SHOULD: Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.
  • C – COULD: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.
  • W – WON’T: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.

This is the MoSCoW prioritization technique. From this, we can list the features in order from most to least important to begin planning. To get around uncertainty, a ‘feature buffer’ can be used. As Mike Cohn describes:

Creating a feature buffer is simple to do on an agile project. First, the customer selects all of the absolutely mandatory work. The estimates for that work are summed. This represents the minimum that can be released. The customer then selects another 25% to 40% more work, selecting toward the higher end of the range for projects with more uncertainty or less tolerance for schedule risk. The estimates for this work are added to the original estimate, resulting in a total estimate for the project.

(Taken from Agile Estimating and Planning).

The logic is simple enough; if we’re on target with our estimates you’ll get all of the ‘must haves’ and several ‘nice to have’ features (the 25% to 40% buffer). If we’re messed up and run over, then at least you’ll get the must have items. If we’ve overestimated then you’ll get the must have items, the buffer items, and a whole lot more.

Of course, assuming you get this agreed with the stakeholders, if a contract is involved then you’ll need to get it past their legal team.

This can often be painful if the legal department is not used to Agile projects and a good place to start at the Agile Contracts website and download the Agile Contracts Primer PDF. (This is based on the ‘contracts’ chapter from Practices for Scaling Lean & Agile” by Craig Larman and Bas Vodde.) The primer has advice on how to work with legal teams and suggestions for ensuring key points such as:

  • Confirming that the structural and legal aspects of agile-project contracts are the same as for contracts of more traditional development styles and how to explain the key differences.
  • That the legal team will need an understanding of agile and lean principles and systems thinking.
  • Just as successful projects are ultimately born from from relationships based on collaboration, transparency, and trust, then ‘successful’ contracts contain mechanisms that support the building of collaboration, transparency, and trust.

One interesting feature is that there are no sample contracts. Although the Primer covers common topics of Agile Contracts, the feedback that the team had from lawyers was that cut-and-paste between contracts causes more trouble than it saves. So although it touches on subjects such as change management, payments, and such you will still need to sit down with the lawyers and work with them.

It isn’t an easy read, but it is valuable and should go some way to ending the fear of fixed price contracts for Agile projects.

Posted in Uncategorized | Tagged , | Leave a comment

The Frayed Ends of Sanity

Complexity assessment graph Schwaber, Ken (2009-11-30). Agile Project Management with Scrum (Microsoft Professional) (Kindle Location 243). Microsoft Press. Kindle Edition.

Complexity assessment graph (Ken Schwaber 2009)

A complex project with a rapidly changing dynamic ecosystem is basically borderline chaotic. As a PM, how do you measure progress in this ‘complex’ area?

The graph I’ve posted is from Ken Schwaber’s book on Agile Project Management and is a variation of Ralph Stacey’s Agreement and Certainty Matrix. Although this graph is often used in ways that Stacey may not agree with, I think for complex software or IT implementations he wouldn’t object.

Back to the initial problem: How do you measure progress once in the Complex area? Historically, this is where Waterfall was shown as deficient and Agile came to the fore with it’s focus on “empirical measurements“.

My initial thoughts are:

  1. This is highly reactive as you need to measure after the fact, and
  2. What we are essentially doing is stopping every so often to survey the carnage and count the bodies.

Larman covered the empirical approach and described it as follows:

In general, agile methods promote empirical rather than defined processes, a categorization used by industrial process experts. A defined process (also known as a prescriptive process) has many predefined and ordered activities to be followed during development. Defined processes are suitable for predictable manufacturing domains. Empirical processes are used for high-change and unstable domains; rather than many sequenced activities, they are based on frequent measurement and dynamic response to variable events.

(See Agile and Iterative Development: A Manager’s Guide)

At the beginning, I struggled with how to even get started in this area, which is why I invested in Mike Cohn’s book on Agile Planning. Even after reading this book, the idea of having to plan and commit up-front is nerve-wracking. People in general and managers in particular have a habit of hearing what they want to hear, even with all the caveats and ranges we give. A habit that has driven me to distraction in the past on several occasions.

Until Agile is established in an organization, the managers will always seek that (often false) sense of security that comes with a detailed plan with clear milestones and a fixed delivery date.

Having made the decision to transition to Agile, we should be aware that this is going to cause some stress to management and we also need to be sensitive that, at least initially, Agile planning gives senior management the heebie jeebies.

Posted in Uncategorized | Tagged , | Leave a comment

Justify your existence.

For all the charts, graphs, burn-downs, presentation decks, velocity tracks and steering calls, there is often an 800 lb gorilla sitting quietly in the corner.

Just one simple question…

Does This Project Still Make A Strong Business Case To Continue?

The PM doesn’t want to ask it, especially if they’re on a contract. A “no” means that they’ll have to wind up the project, close it out, and, well, you just closed your job early. Good luck explaining that to the bank manager.

The Project Sponsor doesn’t want to ask it. A “no” for them may mean that the project they fought tooth and nail for, that they may have expended a vast amount of political capital and personal credibility on, is a big, fat, hairy FAIL.

The team doesn’t want to ask it. No-one likes bad news, and the bearer even less. Why risk getting your head chewed off especially if it’s just before bonuses are being discussed?

Yet, the ROI is the heart of every project. Change happens, either to avoid failing or to move into a more profitable space, so we need to ask this. To its credit, the first principle of PRINCE2 is that there must always be a viable Business Case driving the project.

In PRINCE2, the Business Case is updated throughout the project, not just used to start the project up. At every transition it is reviewed and, if the factors underlying the Business Case change and the expected benefits evaporate, then the project should be closed.

No-one wants to pull the plug. We all become professionally invested in the work as we are judged by our last project. But, as a PM, we have to accept that as much as we want to chant the “Every Project: On Time, On Budget, On Scope!” or push “No Project Left Behind!”, part of our role is sometimes to call it a day and lay the project to rest. We can still learn from it and the plan is intact, in case circumstances change and the project becomes viable again. But, until then, an early controlled landing beats a messy crash-and-burn later.

Push the button and pull the plug. Say goodbye.

Posted in Uncategorized | Tagged , , | Leave a comment

When the chickens start to squawk

A Pig and a Chicken are walking down the road.
The Chicken says: “Hey Pig, I was thinking we should open a restaurant!”
Pig replies: “Hmm, maybe. What would we call it?”
The Chicken responds: “How about ‘Ham’N’Eggs’?”
The Pig thinks for a moment and says “No thanks. I’d be committed, but you’d only be involved!”

From The Scrum crowd talk about pigs (the core development) and chickens (those around the project who are interested and/or directly impacted by the project.)

A key aspect of Scrum is that the development team have made an explicit commitment to deliver a working product with the functionality agreed to in the iteration planning. As a quid pro quo for their autonomy and ownership, they are now on the line to deliver on their agreed collective promise.

The daily scrum is where the pigs gather to ask three questions to each pig in turn:

  • What I have accomplished since our last daily Scrum
  • What I plan to accomplish between now and our next daily Scrum
  • What (if anything) is impeding my progress

In theory, the chickens listen in. If there are any questions or the Scrum Master needs to clarify any points then there is a short follow-up meeting after the daily scrum.

However, I have observed Scrums where the chickens started to squawk, and no longer remained as passive bystanders. There are a number of reasons that this can happen. The primary one I’ve seen is that some managers used to more traditional command-&-control mind-sets just cannot handle the transition to Agile. Some is just a force of habit, some is just a level of aggression, kicking mud around the sty, to assert their control over the proceedings.

To get around this there are a few approaches. The first step is to just tell them outright that their question isn’t one that will be answered on a Scrum, and the Scrum Master will deal with them afterwards. A mature development team will have no problem doing this and will move straight on without giving the chicken time to speak. A more inexperienced team might wobble, especially if the chicken has some authority or can influence their promotion/pay/bonus.

I’ve seen this handled in a more passive-aggressive manner by allowing the chicken to waffle on until the time-box ends at which point the Scrum Master cuts them off and say “Well, that’s it for today as we’re out of time.” This is probably the worst path; the chicken will be annoyed and – more importantly – the development team has been deprived of a key step in the process of tracking their work among themselves.

Just here is where the Scrum Master has to earn their keep as sheepdog to defend the team, because this behavior must be stopped early in the process to allow the Scrum to work. Depending on the personalities involved, you will need to tailor your approach. What I’ve found best is to talk to them one to one and find out what their real concern is. If it is project based, then they need to understand the roles of Scrum Master and Product Owner, and how they can use the regular iterations to get the information and encouragement they need. If it’s just a personality issue then you may need to take it above them and get a bigger dog to bark them down. This can be a doubled-edged sword so tread carefully.

However, if you agree to become a Scrum Master, then you should think this through as a what-if? By taking on the role you become the defender of the team and the process. It is your job to stop squawking chickens, so you may as well ask how you’re going to deal with this situation and then hope it stays hypothetical.

As an aside, I have another approach to dealing with noisy chickens. They get sent to a ‘scrum’ that is a scrum in name only. The Scrum Master and a couple of developers start talking about the work ongoing or just finished, and they are allowed to be interrupted left, right, and center. The chickens feel empowered that they are flexing their muscles and controlling the show. It’s a show only for their benefit as they don’t get to hear all the developers, or the 3 standard questions, or any problems the Scrum Master is fixing.

In short, this isn’t the daily scrum – that happens earlier and somewhere else. The chickens are not in the pigsty and don’t really know it. However, so long as they get to say their piece and cover their asses, they don’t actually care.

Sometimes arguing with people is a bit like mud-wrestling with a pig. You can struggle and fight as much as you like but after a while you realize that the pig is enjoying it.

Posted in Uncategorized | Tagged , , , | Leave a comment

When the helicopter never gets off the ground

A project manager has to fly an interesting route, where we have to stay at 10,000ft to maintain the vision, and monitor the big picture – when and where are the milestones, are any risks become more likely to occur, what report is next due – but at any point we can be called down right into the weeds and sweat the details.

Starting with the vision, I like how Jim Highsmith suggests we handle this by distilling the Vision down to an ‘elevator pitch’ (a brief statement that can deliver the project vision in a few seconds):

For (target customer) who (statement of need or opportunity), the (product name) is a (product category) that (key benefit, compelling reason to buy).

Unlike (primary competitive alternative) our product (statement of primary differentiation).

For example:

For a Senior Risk manager who needs to see their full Portfolio Risk exposure broken down by category, asset, trading desk, issuer, or custom tag, the ÜberRiskMasterBlaster 5000 stores multidimensional data in a bespoke OLAP Cube which in turn is analysed with a series of optimized MultiDimensional eXpressions (MDX) queries that will deliver a series of custom risk views and reports that can be sliced and diced as the user needs or desires and can also be exported to downstream Business Intelligence tools.

Unlike Nasty Corp’s RiskMangle Pro Deceive-Inveigle-Obfuscate module our product is optimised for real-time user analysis and dynamic custom views.

The idea here is that all the team should now possess this vision, that any one of them stuck in the elevator with a CEO asking ‘so, what are you working on?’ (ie. it’s 2 weeks before I decide the bonuses and lay-offs, justify your existence) could quickly, and succinctly, deliver this 30 second pitch on the ride between floors.

So with this in mind, we need to get a correct balance between getting the details and big-picture, between the tactical and strategic views. Of course, a lot of this will come down to the culture of the organization – are ‘managers’ expected to monitor and assign daily tasks -, the nature of the project style – Waterfall will need to be tracked at the task level, whereas Agile will be at a feature level and the team pretty much left to it during the iteration – and how well things are going – if the wheels start to fall off, or a potential risk is starting to move from potential to real, you’ll be down in the guts pretty damn quick – as well as personal style – a more hands-on PM living and breathing a single project is going to closer to their team than one running a team of PMs, or running a portfolio/program become extant.

As a general rule, I’ve found that although there is a requirement to get right down into the weeds at the start of the project, during the negotiations, the scoping, and the planning. Once the work starts, you need to get up to altitude to get the larger and more strategic route established. The work can be assigned in larger chunks, large enough that the team will be able to work through it without you micromanaging them. There will still be times you’ll need to get down into the details on a regular basis. For Waterfall, this could be for tracking completed tasks. For Scrum, you might be grooming the backlog or conforming iteration backlog items completed to track velocity.

For Waterfall projects, one method I’ve seen work is to simply decide whether a task is pending, started, or finished and to use 0% completed, 25% completed, or 100% respectively. There is little gain in trying to sweat whether task X is 35% or 45% completed.

For Scrum, the development team has taken a greater level of ownership and responsibility and so the tracking really only takes place at the end of the iteration when the Product Owner decides whether a feature that was agreed to be in the iteration is done or not. The only exceptions will be the backlog grooming meeting, where we dig into the features for the next iteration, or if the team request you need to dig into a problem they have or need you to chase the Product Owner to clarify a feature, assuming you’re in the Scrum Master role.

However, sometimes you can find yourself bogged down in the weeds. For example, if the client is concerned that the number of risks, issues, or actions are starting to grow, it is no-ones interest to stay stuck at ground level. This is more of a risk for Waterfall projects.

One method I’ve seen work here is to short-circuit the (usually endless) debate and agree with the client’s senior management team and key stakeholders that you will create a status document to detail a) the current status of the project, b) the known issues, how they will be addressed, and in what timeframes, and c) how we’re mitigating the risks. This gives them confidence that we’re in control, that there are clear milestones on how we’ll get things back on track, and d) they can read about it rather than sucking up more meeting time. A lot of this information should already be at hand in a Waterfall project so it isn’t too great a burden and a small price for getting back up to altitude to monitor the big picture.

Although you can live a project skimming at tree-top level, this is both exhausting and dangerous. Exhausting, as it requires complete focus and relentless attention. If you get distracted for a moment, it is going to get very ugly, very quickly. Dangerous, as you are totally reliant on the ‘map’ you drew at the start of the project. If the map is wrong, or the landscape changes, or something starts to go wrong then you will have less time and space to react, and virtually no opportunity to be proactive.

Posted in Uncategorized | Tagged , , | Leave a comment