Process Peeves

Thoughts on simple optimizations that could make daily processes better…

All form and no (agile) substance?

Plus ça change, plus c’est la même chose

Jean-Baptiste Alphonse Karr’s warning reminds us that it is very easy to ignore the Manifesto for Agile Software Development’s value statements.

We might have done away with heavy project governance, premature or excessive planning, and documentation for documentation’s sake, but if we don’t remind ourselves why our team performs specific agile ceremonies, we are no better than our brethren toiling under the burden of traditional, one size fits all delivery practices.

Let’s start with sprints. Short time horizons should focus our efforts towards delivering value early and regularly while having fixed time boxes enables forecasting when we should be able to complete a release. But if we start treating sprints as phases (e.g. development, testing) or we batch work items within sprints in a waterfall manner, we haven’t really gained benefits from this approach. Similarly, if we don’t respect sprint end dates or we regularly modify the duration of our sprints we can’t forecast effectively.

How about your daily standups or scrums? These are meant to serve as micro-planning opportunities to align team members towards accomplishing sprint goals. They also provide an opportunity to surface blockers in a transparent, safe fashion to ensure these get resolved in an efficient and effective manner. But if team members are absent, we don’t start or end on time, one person monopolizes the discussion, or they turn into status meetings, why hold them at all?

Velocity enables teams to assess their throughput sprint over sprint. Used correctly and with the right underlying discipline on work sizing and backlog management, velocity can help a team forecast. But obsessing over velocity is as bad as focusing on percentage work complete in traditional approaches. When abused velocity leads to progressively reducing quality, erosion of team morale and unhealthy comparisons between team members or teams.

Showcases or demoes give a regular opportunity for key stakeholders to view what has been completed, to provide feedback to ensure that what is delivered meets customer needs, to maintain sponsor commitment and to provide a forum for visible recognition of the team’s hard work. But holding these ceremonies when there is nothing meaningful to demonstrate provides limited benefit to the invitees. Having the agile lead or other team member be the only person conducting the demoes doesn’t give everyone a chance to have their day of glory. And having team members get defensive when constructive feedback is provided about a feature which doesn’t quite hit the mark is just going to further the gap between the delivery team and the customer.

Meet the new boss, same as the old boss” – Pete Townshend

 

 

 

Categories: Agile, Process Peeves, Project Management | Tags: , | 2 Comments

Efficient project governance should not be an oxymoron!

red-tapeLook up governance in Merriam-Webster’s dictionary and you’ll find this definition “The way that a city, company, etc., is controlled by the people who run it“. This is certainly an appropriate meaning of the phrase when applied to corporate governance, but is not the most empowering vision for how projects need to be governed.

Most staff would view governance as a necessary evil. Governance is a great example of what a lean management professional would call business non-value add – those activities which don’t directly add value to a process but are required for legal or other compliance purposes.

After all, when was the last time you heard a project manager or executive sponsor demand “We need more governance over our project!”?

So long as governance is treated as controls exercised over a project team as opposed to practices supporting them it will continue to have negative connotations.

In many organizations, project governance introduces additional layers of administrative workload for the team in the form of checklists, presentations and formal reviews. It’s common to find financial or other objective-based thresholds supporting progressively greater levels of governance.

This approach generates unintended consequences. Teams and stakeholders chafe over the effort and costs of satisfying complex, onerous governance requirements and sponsors will go out of their way to keep their projects below a threshold.

The issue therefore is not with governance itself but rather how it usually gets implemented.

So what should right-sized governance look like?

  • Like good insurance, the perceived and tangible benefits need to significantly outweigh the costs. This means that governance should consume the core deliverables and other outputs of a project rather than requiring the creation or population of new artifacts or systems.
  • It needs to take complexity and context into consideration and not merely be driven by project costs.
  • It should be exception-driven focusing on tighter management of the few with minimal oversight over the many.

By doing this, project managers, team members and key stakeholders are more likely to welcome governance as a critical ingredient to achieving their desired outcomes rather than an impediment to project delivery.

 

Categories: Process Peeves, Project Management | Tags: , , | 1 Comment

No more initial estimates? NOOOOOOOOOOO!

homealoneIt’s unfortunately an all too familiar scenario.

You are assigned to manage a project and before you or your team have had an opportunity to start to chip away at the looming mountain of uncertainty, you get put on the spot to provide a cost or schedule estimate by your project sponsor or some other stakeholder. To make matters worse, your company’s project delivery methodology might insist that an estimate gets provided before work has even commenced.

We can support our estimates before we provide them with a long list of caveats and assumptions, but those qualifiers are forgotten by stakeholders a long time before the original estimates are. We can assign terms such as Rough Order of Magnitude or SWAG to these estimates but what we should really be calling them is pure guesses.

If only we had the confidence of Dilbert in Scott Adams’ 2010 cartoon below to stick to what we know is right!

dt100221

A preliminary estimate, once provided, anchors expectations and starts the project off on the wrong track.

If the estimate provided is too high, a valuable project might get scuttled prematurely if the sponsor gets cold feet or worse, the team will get a reputation as being inefficient.

Offer too low an estimate and not only will you set your customer up for an unpleasant surprise when Murphy strikes, you might also be dooming your team to a death march. Make this mistake this more than once and word will spread that you are an untrustworthy project manager. Expect to have your team members double their estimates before they provide them to you in the future.

Sometimes we see an oscillation between these outcomes.

Team members who are optimistic and provide aggressive estimates soon learn that this is only hurting them and will start providing heavily padded estimates. Becoming frustrated with increasing levels of estimate obesity, sponsors and project managers exercise Theory X practices such as eliminating contingency reserves or cutting estimates.

Instead of furthering the insanity, why not start by ensuring during ideation that there is a clear vision and opportunity definition for the project such that all key stakeholders believe it is worth doing? Then confirm that the customer has the capability and commitment to spend a small amount of seed funding. This funding should be enough to help the team clarify scope, develop solution options and perform sufficient construction to explore the scope elements which they believe will pose the greatest threat to project outcomes. Once this is done, have the team provide estimates and let the sponsor or customer decide at that time whether it’s worth further investment.

Mr. Miyagi – Best way to avoid punch. No be there.

 

 

 

Categories: Facilitating Organization Change, Process Peeves, Project Management | Tags: , , , , , , | 2 Comments

Create a free website or blog at WordPress.com.

%d bloggers like this: