Project managers need to be comfortable with different estimation techniques. Foundational project management courses will teach you about analogous, bottom-up, parametric and three-point estimating. Take a course covering agile delivery and you'll learn about relative sizing techniques such as estimating poker or t-shirt sizing.
But have you heard of RBS?
I'm not referring to a Risk Breakdown Structure, a Resource Breakdown Structure (seriously, couldn't they have found a different name for one or the other to avoid creating confusion about which RBS is being referred to?) or any other type of breakdown structure, but rather Randomized Branch Sampling.
This technique was originally proposed by Raymond Jessen in 1955 for the agriculture industry as a method of estimating how much fruit would be found on a given tree (hence the significance of the word "branch"). This approach has been adapted by Dimitar Bakardzhiev for use on software projects following an agile delivery approach and could be similarly adapted for a traditional, deterministic project where a WBS has been created.
I would encourage my blog followers to read Dimitar's article but here is an overview of the process once you have decomposed your project to an appropriate level of details (e.g. epics & stories or control accounts & work packages).
This approach does require that your project is large enough to have at least a dozen epics or control accounts and does assume that the decomposition is clear and complete.
While you might be comfortable with tried and true estimation methods it's a good idea to use more than one estimating method. Certain techniques are appropriate at specific points in time over the life of your project based on stakeholder needs and the level of uncertainty remaining. There's also the benefit of being able to sanity check estimates when multiple approaches get used.
Learning new techniques such as RBS can help us become more effective project managers but only if we understand when and how to use them as well as their limits.
"A Fool with a Tool is still a Fool"
One of the more prevalent myths with agile delivery approaches is that the project manager should let the team develop their own working practices and rules of engagement to manage themselves. While this sounds great in theory, in many cases it will result in disaster.
No question, in times of crisis over usually fairly short durations a team of professionals can develop creative ways to work together effectively and productively to resolve the situation but this doesn’t translate well into the world of most projects where the sense of urgency or shared goal is usually insufficient by itself to encourage productivity and efficiency. While testing this hypothesis might make for a good social experiment and has been utilized regularly on reality TV shows such as The Apprentice, few organizations will want to take chances with their critical projects.
I’m not advocating the anachronistic use of rigid command and control practices on the part of the project manager. While a lack of attention and guidance to work practices and results may result in chaos, being a slave driver is almost guaranteed to cause project failure along with permanently damaged relationships between the project manager and team members.
As with other project management situations, this becomes a balance between the “what” and the “how”.
The project manager needs to ensure that the team had a clear, consistent understanding of “what” the expected project outcomes and benefits are as well as “what” the key deliverables and activities are. The project manager also should set expectations and require compliance with “what” he or she needs to develop plans and to track and report on progress for the project.
However, when it comes to “how” the work gets done and “how” progress reporting and other normal practices will be performed, the project manager should provide the team with the flexibility to explore and develop the most efficient method for them. This doesn’t mean starting with a blank slate or letting the team radically change directions on a weekly basis. It does mean reviewing the organization’s standard or de facto practices at the start of the project and educating the team on why these practices are important and then giving the team the opportunity to adapt these practices and to regularly review them during retrospectives.
Moving to a more “black box” approach to work management provides greater empowerment of team members without the risks implicit with totally abdicating management responsibility.
(Note: this article was originally written and published by me in June 2013 on my personal blog, kbondale.wordpress.com)
Demos, reviews or showcases as they are sometimes called, are a critical ceremony when they are run effectively as they address multiple project delivery objectives in a single event including:
But demos are just like any other project delivery practice in that their misuse could result in a worse outcome than if they had been skipped entirely. Here are some do’s and don’ts to help increase the value your organization gets out of demos.
While this article is applicable for teams who are using an agile delivery approach, it is equally suitable for traditional projects.
Dazzling demos will help sustain the attention and support from your customer and will focus your team members on value delivery.
(Note: this article was originally written and published by me in January 2017 on my personal blog, kbondale.wordpress.com)
According to John Kotter's model for leading change, the first step to overcoming inertia requires us to instill a sense of true urgency in those we need to support, implement and sustain the change. While it is ideal if this urgency is tied to What's In It For Me, at a minimum, we all want proof that committing our time and political influence to a particular initiative at this very moment is cheaper than the cost of doing nothing.
But the steps in Kotter's model, like PMBOK processes, are not to be followed in a purely sequential manner.
Significant organization transformations usually require a year or more to become "the new normal" and we are only fooling ourselves if we assume that those stakeholders who were focused and motivated to champion our initiative in its early days will continue to remain so for the long haul. Executives and mid-level managers are constantly juggling competing priorities and as long as it appears that a change initiative is not on fire, their attention spans are likely to be shorter than that of a goldfish.
As such, we need to iterate back to instilling that sense of true urgency at regular intervals. The specific cadence varies based on the complexity and duration of a transformation. Fan the flames too rarely and the spark will be extinguished. Do it too often and you'll be treated like the boy who cried "Wolf!".
But is reminding stakeholders that they need to support us enough to gain this support? Maintaining focus requires quid pro quo otherwise we are likely to hear "What have you done for me lately?"
This is why regardless of the nature of a transformation we need to inject agility into its delivery. We can follow adapted versions of key Manifesto principles such as:
Newton's first law: An object at rest remains at rest, or if in motion, remains in motion at a constant velocity unless acted on by a net external force.
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 (Sante - that's a 70's reference, just for you!)
(Note: this article was originally written and published by me in May 2017 on my personal blog kbondale.wordpress.com)