Should we re-estimate?
Posted: July 31, 2012 Filed under: Estimation | Tags: Estimation, ProjectManagement Leave a comment“Our estimates were wrong, should we re-estimate?” It seems like a fair question and it is certainly a common question among teams I consultant with and coach. However, this apparently uncomplicated questions hides a concept that is not nearly as clear as it should be, that is, what do we mean when we say an estimate is ‘wrong’.
On the surface, most people seem to mean that an estimate was wrong when completing it took longer than estimated. However, this presupposes a traditional form of estimating user stories based on elapsed time. And, as always, when we ask a person how long it will take to complete something, we are actually asking them two unrelated questions. First, what is the effort associated with completing that task? Second, how many delays will slow or interrupt working on the task? For example, how much context switching between this task and other tasks will the developer need to manage? How much downtime will they have waiting for feedback from others? And how many times they will be interrupted by completely unrelated items?
One of the secrets of effective estimation is the realization that people, particularly developers, are very good at answering the first question (what effort?) and terrible at answering the second questions (how many delays?). The reason is simple. The effort question asks about something knowable, at least in a relative sense, prior to starting work. The second question asks about something that is nearly completely unknowable prior to starting work.
So rather than worrying about whether our elapsed time estimates are wrong in this sense, we should ask whether our relative estimates are useful. What is a useful estimate? One that allows me to project the pace my team will complete a scope of work.
So, if we decide to re-estimate, it should only be because our estimates on the completed user stories are ineffective in projecting future progress. And any re-estimation needs to be holistic across the entire scope of work we are projecting across in order to maintain the relative scale.
Of course many teams ask is it even useful to project completion? Some teams find they do not get useful information from estimates at all, so simply stop doing them. But that is a blog post for another time.
What are the Pennies in Your Process?
Posted: May 31, 2012 Filed under: Project Management, Team | Tags: ContinuousImprovement, Estimation 1 CommentI was intrigued and pleased to see that Canada has recently decided to eliminate pennies from the coinage system. Although not the first country to do so, Canada certainly will not be the last.
The simple reason to eliminate the lowest denominated coins is that they cost significantly more to produce and manage then they deliver in benefits to the economy. The raw cost of the metal added to the significant manufacturing and transportation costs means that “it costs the Government of Canada 1.6 cents to produce each new penny.” These tangible costs to the Mint are substantial but the total costs to the economy are estimated to be even higher, perhaps as much as $150 million. All for a coin that most Canadians simply toss in a jar when they get home.
Eliminating the penny got me thinking about the nature of continuous improvement on a software team and the need to eliminate practices that were formerly useful but are no longer worth the effort. Said another way, what are our pennies?
One practice that comes to mind is high ceremony estimation activities. Even Agile teams that are doing effective relative estimation of effort can have time consuming estimation practices. Symptoms include long estimation meetings with elaborate planning poker techniques to evaluate each individual story. Like a penny, each question of “how big is this story?” may be small, but across a large user story list it adds up to a lot of extra time invested.
Is the investment in doing high ceremony estimation worth the value achieved? I would argue that most teams do get some value out of accurate estimations in the form of predictability, but many people challenge this. For new teams (or teams new to Agile) I would argue that value also comes from the conversation about the story during estimation as it helps increase understanding of the project backlog, helps establish a common domain language, and helps explore differences in implementation approaches between different developers. All in line with the old cliche that the plan is nothing, the planning is everything.
However, as a project team gels, it may find that high ceremony estimation delivers less and less value. A high performing development team should be able to provide consistent estimates quickly because it has a well understood relative effort scale. And the additional benefits are less important to the team as it already knows the user story list well, does lots pairing, and so on. So these teams should be able to greatly reduce their investment in estimation ceremony and estimate much quicker. Or even stop estimating altogether and just manage a flow of stories.
I see lots of teams approach continuous improvement from the perspective of fixing broken processes. The metaphor of eliminating pennies highlights a perspective that focuses on the value returned from the small, little activities that a team does over and over again. These practices are not necessary broken. The penny works perfectly well in the Canadian economy to deliver a very small amount of change. And some high ceremony team practices do provide some value. But is the level of effort worth the value received? A worthwhile question for more than pennies.
Are Burn Up Charts Additive?
Posted: April 2, 2012 Filed under: Metrics | Tags: ProgramManagement, ProjectManagement 1 CommentAs an Agile project manager with scheduled release dates, you are probably using a burn up chart to measure progress toward scope goals for the release. As an Agile program manager, you are probably reviewing burn up charts from multiple teams within a program. An example may look something like this, where the team is slightly ahead of pace.
Burn up chart for a team ahead of pace
Their scope is 80 points across eight iterations. Their velocity has consistently been a little over 10 points per iteration so the burn up is projecting an on time completion, perhaps even with some capacity to take on a new story or two.
Well and good for this team. But what if they are contributing to a program level delivery where there are other teams also delivering to the same release? Can we combine multiple burn up charts into a single view? The immediate appeal of this is obvious; it appears to give us the ability to see the combined progress toward program level goals. The traditional ‘are we going to make it?’ question of a burn up chart can then be answered for the program as a whole. To test this idea, let’s look at a second burn up chart, perhaps for a team that is slightly behind pace.
Burn up chart for a team behind pace
Again their scope is 80 points to be completed across eight iterations. But this team is slightly behind, completing slightly less than 10 points per iteration on average. So the burn up chart shows the team will fall short of completing the requested scope at the end of the eighth iteration.
So what happens if we take both sets of data and draw a single chart?
Combined burn up chart for both teams
Unfortunately, the difference in expected completion between the two projects is obscured. Because one team is ahead and one team is behind, together the program looks on time. But, if the program requires both projects to deliver at the same time, it will likely be late as the second team is projected to miss its deadline.
This highlights the importance of focusing any given burn up chart on a single queue of work. In the above example, a combined burn up might be valid if some of the work currently in the backlog of the second team could be transferred to the first team or if team members could be moved in the other direction without any loss of productivity. This last point is critical because any reduction in velocity caused by the transferring of stories or people will reduce the positive impact of the transfer. But even if we can transfer stories or people effectively, we still need to a keep a close eye on individual burn up charts to understand where teams need help.
This simple example is enough to prove the point but in real life the situation will be even more complex. One simplifying assumption above is that velocity is comparable between the two teams. However, velocities are usually not directly comparable between teams and this will further blur the truth about our program if we combine burn up charts.
So, as a program manager, it is vitally important that each individual team’s burn up chart is well understood on its own. Combining burn up charts may seem like a viable approach but reliance on them alone will obscure the truth about the program.
The Impact of Unsustainable Pace
Posted: March 23, 2012 Filed under: Team | Tags: ProjectManagement, Team Leave a commentSustainable pace is a key part of XP practices and any project manager, Agile or not, who wants an effective team over the long haul knows that you can only push them to work extra hours for so long. In support of this idea, a recent article by Sara Robinson in Salon (and quoted in Inc. by Jessica Stillman) outlines the futility of working more than 40 hours in a week to achieve higher productivity over anything other than a very short time frame.
Some might argue that their personal actual limit is more than 40 hours, and maybe that is true for some individuals. But an IT delivery leader should understand that there is plenty of evidence that the appropriate sustainable pace for your teams on average is going to be around 40 hours.
A team that violates this sustainable pace will need to deal with impacts on quality and productivity well discussed in the above article and elsewhere. In addition to the direct impact, I have seen just as much impact immediately after the long nights are over. Frequently the pain is felt on the next project, which has the unfortunate effect of setting the stage for the next push to work long hours.
Even command and control style managers intuitively know this but, perversely, they sometimes revel in it. I heard from such an executive recently who described a team pulling all-nighters to meet an imposed launch date for their new software product. His attitude was that this unavoidable because the team had let some things slip at the beginning. However, he was proud that they working so hard and was planning to take the whole team to Vegas for a weekend as a reward.
Of course, who would not want a weekend in Vegas? And at least there was some acknowledgement of the extra work. But buried in his praise was the criticism that the team should have been working harder early. He failed to see that his style of setting critical deadlines and driving teams hard to meet them is a contributing factor to that lack of urgency early in projects. After working killer long nights for weeks and then a fun filled weekend in Vegas, who on that project is going to be productive even at the pace of 40 hours a week for a few of weeks afterwards? The reality is they will be tired and emotionally drained.
And what does that mean? Well the next project is going to kick off slower and less urgently than necessary to hit the project timelines. Welcome to your next death march.
Is your PMO at the center or the periphery? Or where it belongs?
Posted: March 20, 2012 Filed under: PMO | Tags: Leadership, PMO, ProgramManagement Leave a commentAs discussed in a previous post, the activities of Project Management Offices (PMOs) differ significantly between organizations. PMOs also differ in how they fit into the official and unofficial hierarchy and power structure of an organization. By this I mean, regardless of where it is placed on the published organization chart, the actual relationship of the PMO to project teams and company leadership will vary significantly. I see three main approaches: PMOs at the periphery, PMOs at the center, and the PMO as partner.
PMOs at the Periphery
The first is what might be called a PMO at the periphery, where a team of managers and directors are assigned to a functional group that sits outside the main structure of the delivery organization. In this setup, while the PMO is frequently responsible for staffing project managers to the rest of the IT organization, delivery and operations teams only have dotted line reporting relationship to the assigned project manager. The goal of this approach is to recognize project management as a specific and unique skill-set; often the term Center of Excellence is used.
On the surface this may appear to value project management skills highly but it usually has the effect of isolating the PM from the team members; the PM is not quite a member of the team and has ill-defined authority or accountability. Official authority usually resides with a software development manager who has line responsibilities for deliveries by the project team and management oversight of the team members except for the PM. This can create an adversarial relationship between the PM and the line software development manager where they do not agree on direction for the team, often putting team members in an awkward position.
In traditional organizations, where official hierarchies are critical to day to day activities, isolating the PM in this manner creates barriers to accomplishing the goals of the role. Particularly in enterprises seeking to transition to Agile principles, the lack of direct responsibility for a team too often means that the PM is not allowed to share accountability for delivery.
PMOs stuck at the periphery often fill their days with noncritical duties, such as process auditing or filling out status reports. Where this is the case, we often see the PMO ultimately reporting up to the financial organization, in charge of not much more than building consolidated program status reports that no one trusts.
You might ask how having a PMO at the periphery is different from not having any PMO? In the worst cases, the answer is no different at all except that it costs more.
PMOs at the Center
An alternate approach is too push the PMO into the center of the delivery organization’s org chart with real management authority vested in them by the CIO or similar senior executive. The PMO still assigns PMs but now with authority vested by the senior leadership and a prominent place in the organizational hierarchy. Issues of lack of clout are avoided. Gone too are the dual reporting structures for a team as everyone is managed by the project manager role. This approach sounds great to the busy executive who looks for single person to vest with accountability.
Unfortunately, in practice, too often this executive mandate encourages counterproductive command and control behaviors. Invested by the CIO with authority, the PMO inhabits an untouchable and out of touch ivory tower. And on the project level, the sense of being the key player in the delivery organization can drive behavior in a PM focused on downward only communication styles and “hero” project management.
One of the warning signs of an PMO artificially thrust into the center of things is what my colleague Ross Pettit calls a ‘reporting monstrosity,’ implementing onerous and useless status reporting requirement on delivery teams.
PMOs as Partner
In contrast, an effective program and portfolio function probably barely exists on the organization chart and certainly gets none of its authority or accountability based on its position there. Instead, the PMO staff gets out of the ivory tower and gets down to the nitty gritty with the teams
Doing so flips the responsiveness expectation from the team responding to commands from the PMO to the PMO providing servant leadership to teams. This is not to ignore the needs of executive management to understand the portfolio of work but focuses the PMO on actively helping to achieve critical tasks around coordinating dependencies and useful reporting.
Easy to say but what does it mean in practice? I will be exploring more of the practices in later posts but they fall into two rough categories: prioritizing the right projects and positively impacting teams’ ability to deliver those projects effectively. If a PMO is stuck at the periphery or has an inflated senses of its importance as the linchpin of delivery, it cannot deliver on these goals.
Team Tasking in a Retrospective
Posted: March 7, 2012 Filed under: Retrospectives | Tags: ProjectManagement, Retrospectives, Team 2 CommentsI was recently facilitating a retrospective with a team that I was coaching on adopting Agile principles and practices. We did a Starfish retrospective and then cycled through action items for the things we had posted on the wall.
For some of the items, it was clear who should be responsible for completing the task. As the coach, I took a couple, the project manager another one or two, someone else took responsibility for a technical task, and so on.
But for a few action items, we assigned the owner as ‘the Team’. We had an observer in the room hoping to learn more about Agile and retrospectives. He asked me afterwards how can we assign something to the whole group? Won’t human nature mean that no one will do it? Don’t we need someone individually assigned to the task in order to make sure it will be done?
The question struck me as a typical response for a manager struggling with the move from command and control project management to a style more focused on team empowerment and self-organization. Or stated another way, if we want teams to be free from command and control, they will need to be able to self-organize to accomplish improvements in the way they work as a team.
For example, when a team complains in a retrospective about something like ‘not enough knowledge transfer,’ they are really complaining about themselves as a team. I mean that in a good way, in that they have identified something that they need to improve on together.
As such, it’s really tough to whittle that down to a simple action item that can be assigned to a single person. Further, assigning a task like ‘pair more’ to ‘improve knowledge transfer’ to a single person would potentially allow the rest of the team to absolve themselves of responsibility, as in, “I don’t need to worry about that because so-so is fixing it.” This is the flip side of the human nature argument; assigning a task to single person may mean that no one else feels the need to work on the solution. And we consign one person to run around trying to guilt the team into pairing.
So, teams I work with frequently mark these kind of items as owned by ‘the Team.’ Note that action items owned by a team can still be measured and should be actionable. For example, In the example of a ‘pair more’ action item, we can use pair stairs to measure our progress.
This approach allows one aspect of an Agile project manager’s role in a self-organizing team to come into focus. It’s not about finding the one team member who the PM can assign tasks too, and blame when the task is not completed on time. Rather it’s facilitating the team in finding measurable action items and pushing the team at the beginning of the next retrospective to evaluate their own performance during the sprint. Even better, in this example, encouragin the team to update the visible pair stairs information radiator as part of each stand up.
The goal of retrospectives is to help the team improve. Some things can only be improved on if we have the whole team’s effort. That means we need to facilitate group tasking.
Sean Doran 