Author: Robert Galen

The Agile Project Manager—Getting Out of Jail Free

Written by Robert Galen on February 6, 2012. Posted in Articles. 6 Comments on The Agile Project Manager—Getting Out of Jail Free

I was teaching a class just a few weeks ago. It was focused on agile basics, user story writing & backlogs, sprint planning and all of the basic operations to kick-off a set of Scrum teams. It was going quite well on the first day and I was fielding the myriad of questions that typically come your way in an initial class of this sort.

Then I got hit with a question that I struggled to effectively communicate a succinct and direct answer to. The question was simple on the surface:

If within a sprint the team can’t seem to get the work they planned done, don’t you simply put it back on the backlog for execution in the next sprint?

I muddled around for a bit trying to answer the question. I merged my answer with the notion of sprint failure and success. I also spoke about team commitment. Both topics I’ve recently blogged about

But I could tell the questioner was frustrated with my answer—that they simply wanted me to say yes. Yes, just slide it onto the backlog. And that certainly would have been the easier way out for me.

So, we left it that they were frustrated and I moved on. But I’ve been thinking about this since then, and I thought it would be helpful to answer the question in this blog post. Or at least discuss more of the nuance behind my broad and feeble attempt at answering it.

Let’s First Go To Commitment

The first part of my struggle surrounds the teams’ commitment of delivery towards the sprint goal. Please reference my previous post for much more background here. But the essence is—the team committed to delivering a body of work supporting their sprint goal and I want them to well…deliver on their promise! I don’t want it to be easy for a team to defer work out of the sprint. I don’t want them to whine about missed estimates or technical complexity. I don’t want them to get accustomed to breaking their promises. I want them to seriously plan, seriously commit, and then seriously deliver on their sprint goals. Period!

If they do encounter “unexpected turbulence”, then I want them to think really hard about how they might be able to adjust to the new found work. Think creatively and leverage the ideas of every team member. If they need to make in-the-sprint adjustments, they need to pull the Product Owner into the conversations. As they explore options & alternatives, they should put their commitment and the sprint goal front and center.

Turbulence, I Mean Discovery Happens…A Lot!

And we need to remember that “s**t” happens within Scrum sprints…all of the time! The teams often find that they:

Underestimated the work
Overestimated the work
Didn’t account for technical complexity
Didn’t truly understand the customers problem
Didn’t account for someone taking vacation
Or getting sick
Didn’t fully understand the stories
Didn’t groom properly
Don’t have the requisite skills or knowledge to do the work
Didn’t account for testing complexity
Didn’t capture the right acceptance tests

and this list isn’t exhaustive. Things come up every day within sprints, which is why I don’t want deferring work to be the automatic or default reaction. This sort of “get out of jail free” card isn’t the intent of agile nor does it align with the commitment they’ve made to their Product Owner and themselves to deliver on the sprint goal.

Now can they move work to the backlog? Sure, absolutely, you bet! But determining whether they should actually take that road is an entirely different question.

Another Assumption

Another implication of the question is that if something slips out of the sprint that it simply & easily goes to the top of the backlog for execution within the next sprint. But that’s not always true. Once something re-enters the backlog, the Product Owner has the responsibility to reprioritize it, but it’s their decision as to how to handle the ordering. And it may not be as simple as…reprioritize to #1.

For stories that are focused on features to be delivered, then the Product Owner may have made commitments to external customers that are difficult to break or re-frame. The other factor is that there may be embedded time constraints as part of the story—meaning it needs to be delivered by a specific date.

What about the teams’ quality values? Should done-ness be easily violated in these cases? Here’s an example to illustrate a point surrounding done-ness.

Example

A team has done-ness criteria established for story delivery. It states that a story will be delivered with no known bugs i.e., they’ll be fixed prior to story completion and acceptance.

So, the team is working on a two-week sprint. The #2 priority story is predicted to take nearly the entire sprint to complete in sprint planning. The good news is that the team was right on this one. It’s day #8 and the story is nearly complete. The code is complete and multiple rounds of testing have been done. The team is feeling really good about the story and demonstrates it to their Product Owner for acceptance.

The bad news is that there are 13 known bugs related to the story. They’ve fixed 4 of them, but they can’t complete the other 9 by the end of the sprint. And even more telling, they uncovered a refactoring effort that needs to be completed as part of re-designing the codebase to support the story. So they essentially hacked the story into existence and are recommending a 15 point refactoring story to “do it right” in the very next sprint.

The team feels they completed the story and due to “extenuating circumstances” on day #8 they let everyone know that 9 bugs and 15 points of refactoring need to be completed before this story is ultimately finished.

I have a few questions for you:

If you’re the Product Owner, how do you prioritize this new/additional work? How do you balance it against your pre-existing release plans?

From the teams’ perspective, did they really finish the story? If not, what should have occurred within the sprint to potentially deliver a more complete story—pun intended?

How would you react or feel if I said the team should have ‘swarmed’ around getting this story completed—no matter what?

And finally, should this sprint be considered a success or a failure?

I’m hopeful these questions generate some healthy comments…

Micro Adjustments & The Product Owner

The above example leads into a related idea. I’ve been using the term “micro-adjustments” a lot lately to illustrate the dynamic between the Product Owner and the Team during sprint execution. The notion is that the sprint goal serves as a measuring stick that the team can use continuously throughout the sprint to guide their minor scope adjustments and trade-offs.

And believe me—adjustments are certainly required. Actually, not required—they’re a fundamental part of the lean nature of scrum.

So instead of adjusting whole stories in or out of a sprint, I think the healthier view is for the team to engage the Product Owner as early as possible as discoveries are made within each sprint. For each potential adjustment, the PO and team examine the issue through the lens of holding the sprint goal intact. So every trade-off is relative to the goal.

If the team can hold the goal by reducing the scope of a feature, then so be it. Then it’s up to the PO to determine if that scope trade-off needs to result in an additional story to the backlog or not. But I don’t want there to always be a story produced. In many cases, micro-adjustments will result in “good enough” software being delivered at the end of the sprint, with the resulting trade-offs never needing to enter the backlog. In fact, they were never needed in the first place.

So the other nuance I was trying to address in fumbling my answer was this notion of micro-adjustments and not falling into the trap of looking at stories as fixed in scope. Instead, the entire sprint is an emergent exercise that is guided by the sprint goal.

My overall experience in sprints is that very little needs to exit the sprint and re-enter the backlog. Sure, there is the occasional bug or refactoring story. And yes, stories do occasionally “pop out” onto the backlog. But the majority of the time, the scope trade-offs are internalized and adjustments made that don’t ultimately impact the backlog.

Indeed, more often is the case where the team PULLS WORK from the backlog into the sprint because they’ve discovered more capacity versus the scope they’d planned on delivering. Now that’s agile!

Wrapping Up—so what is the answer?

To use my standard consulting answer with tongue firmly in cheek—it depends.

In fact there are no universal answers to the question. Sometimes it’s a perfectly healthy and balanced response to push work from within a sprint to the product backlog. It makes sense and the overall agile integrity of the team is not compromised.

But in many other cases, this get out of jail free card can have some bad side-effects. It puts the sprints success in jeopardy. It can undermine the teams’ commitment to results. And it can place the Product Owner in a precarious position. It also usually implies that the team isn’t operating with a full “agile mindset” within their sprints.

I would always rather that the team viewed “punting work” outside of the sprint as a last resort—one that they carefully consider and leverage infrequently.

Now if I only had a second chance to answer that students question…

Thanks for listening,

Bob

Don’t forget to leave your comments below

The Agile Project Manager—Do You TRUST Your Team?

Written by Robert Galen on January 4, 2012. Posted in Articles. 2 Comments on The Agile Project Manager—Do You TRUST Your Team?

bob1

bob2

As an agile coach, one of my favorite expressions in response to nearly any situation I encounter in an agile team is—“trust the team” or “trust the process”. So here are a few examples of what I mean:

If you think the team has underestimated their work and are leaving velocity on the table, “trust the team”…

– If they have underestimated they can always pull in more work. And you know, you could be wrong, so allow the team to sort through how they understand, size, and execute their work. They’ll appreciate the trust you’ve given them and will invest in doing good work.

– If you do see poor estimation or poor execution & adjustment, then bring this to the attention of the team within their retrospective. Give them examples, but allow them to explore the most effective way(s) to improve.

If you feel that the team isn’t working hard enough or are committed enough to their work, “trust the team”…

– Unless you’re a direct member of the team, it’s fairly presumptuous of you to assume they’re sand-bagging and not working hard. Or thinking that they lack commitment. Rather observe how hard they do work, handle their challenges, and deliver on their sprint commitments. Assume that the wonderful professionals you’ve hired are just that—hardworking, honest, and professional.

– And remember, just because people are putting in hours, that doesn’t mean they’re doing good work or working hard. It just means you have their butt in their seat…not their brain in the game.

If you feel that quality is poor and it isn’t improving sufficiently or you feel that the team isn’t taking product quality seriously, “trust the team”

– Ensure that your concerns are visible to the team and that they’re looking into root cause within their retrospectives. However, let them tailor their activities to improve deliverables each and every sprint. Explore objective data on their defect & quality deliverable trending with them. Give them clear and complete done-ness criteria. BUT, allow them to discover how to do a good job as a team.

– Agile is not a magic formula. It cannot take a crappy product and, simply because you’re ‘agile’, remove all technical debt and bugs overnight. Improvement takes serious effort, commitment, and time. No silver bullets allowed!

If you’ve got a fixed date software delivery to make and you wonder if the team is going to get there, “trust the team” and “trust the process”

– First of all, solid agile teams make everything transparent. Secondly, they approach delivery in iterative chunks. Put these two together and you’ll actually get a heartbeat of how well the team is meeting your projections & needs. If they aren’t, then you get the chance to negotiate scope trade-offs with them.

– Agile projects can ALWAYS hit fixed date targets with fixed cost & quality goals. And they can ALWAYS deliver a set of your highest priority features. The variable in these situations though is scope—so you must be prepared to pare back scope via dropping low priority features and making micro-adjustments to other features—generally delivering Must-Haves over Nice to Haves.

If you feel that the Product Owner isn’t making good decisions surrounding feature priority, “trust the process”

– The Product Owner will get plenty of feedback in the Sprint Reviews as to whether they’re focusing the team on the ‘right’ features, at the ‘right’ time within the flow of the project. The key is to get stakeholders regularly attending and to encourage positive and constructive feedback.

– Quite often the Product Owner is a surrogate without real decision-making authority. That is NOT setting them up for success. Ensure your Product Owners are empowered to make decisions and have the seasoning and domain experience—to make the ‘right’ decisions.

These are only a few of the many real-world situations where we have a choice in how we actively demonstrate our understanding of agile principles and exhibit trust to our teams. You see, it’s not about saying you trust the team—it’s about truly trusting them and demonstrating that in in your words and actions. Next I want to explore a few, how shall I say it, trust anti-patterns or excuses that I commonly see.

bob3

There’s trust, and then there’s TRUST

Here are a few anti-patterns I frequently hear that indicate to me that the organization, leadership, project, management and other stakeholders don’t fully trust the team. I’m sharing them to broaden your thinking around trust and the ways we can frame it organizationally. By no means is this an exhaustive list, but more so a list that illustrates how our words don’t always necessarily align with truly trusting.

And of course this doesn’t apply to anyone reading this blog. So please just read it for future reference—in case you run into some of these anti-patterns…

Trust, but Verify

Of course I trust you, but I’m just simply verifying that what you’re telling me is true—as a simply checkpoint. Don’t worry about it, I’m just verifying…

Don’t be fooled, this anti-pattern isn’t about verification. It’s about distrust and the use of micro-management techniques to get into the heads of the team and control how they’re attacking the project. Yes, verification is important, but not daily. The Sprint Review is the ultimate verifier. Attend them.

The process is making me do it

Of course I trust you, but I need to get this information into the CMMI Level 3 artifact repository so that we pass our audits. Did you know that an audit was coming next month? Very serious stuff…

Another common anti-pattern is blaming distrust on the methods or process patterns that you’ve adopted as an organization. We’re CMMi Level 4, so I must have you fill out a detailed test results plan and sign at the bottom to confirm that you’ve tested everything you’ve said you’ve tested.

Sure, processes carry some weight and responsibility. But this anti-pattern extends that as an excuse to hover over the team and control approaches & outcomes.

I’ve been doing this a long time and I know this path will lead to a disaster

Of course I trust you, but in my 25 years of experience, I’ve never seen a team deliver on a large scale refactoring effort. I simply don’t think it can be done…

While your experience is certainly valuable, times have changed and contexts are different now. Your team is exploring their own experience and finding their way. They’re establishing their experiences, and need to do that largely on their own…as you probably did.

I’m paid to prevent us from making mistakes

Of course I trust you, but my job is to prevent us from making mistakes and to develop the best products possible. It’s actually in my job description that I lead the team by the sheer force of my will and experience.

That I’m responsible and accountable for all of the results my teams produce. That leadership is about leading—showing team the way forward in practices and approaches. Trust does come into play, and of course I trust you, but only so far. Only when I have a belief that the outcomes will align with our organizational goals and my bonus plans.

bob4

True Trust

I have a favorite story I use for describing effective delegation. It goes like this—

Delegating is easy when you know how someone will approach the problem you’re delegating. Or when they’ve been asked to do the task many times before? There is no outcome risk.

But what if they would approach the solution differently than you? Or what if they might try a novel, but risky approach? Or, what if you’ve seen them fail at this sort of problem many times before? You ‘get’ the idea…but you still delegate to them. To me, this delegation, regardless of outcome risk, or approach, is true & pure delegation.

It means you trust the individual enough to encourage them to try something new. You’re enabling their creativity and you’ll be there if they ask for your help or advice. But they ‘own’ the task you’ve delegated to them and ultimately the results.

Now THAT’S delegation!

Adapt this definition and re-focus it towards trust. Then accordingly, start trusting your teams more. For example, here are a few transitional trust adjustments you might need to make—

Trust that they are estimating work based on the best information they have—and that the estimates are accurate given their context
Trust that when they run into trouble, they’ll let you know; otherwise they are making progress and don’t need your ‘help’
Trust that transparency and Sprint Demo’s will give you sufficient progress information—both on velocity and quality of their efforts
Trust that the team knows best in how to solve product development challenges related to architecture, design, and implementation
Trust that your Product Owner is effectively driving customer value—and are making the best decisions balancing business needs against team capacity
Trust that your Scrum Master is emphasizing done-ness, quality, and working collaboratively as a team. That if something needs attention, they’ll raise it as an impediment
Trust that when the team recommends refactoring a component of your system—that it’s truly broken and needs attention
Trust them to trust your own judgment and skills; that they look to you for high level guidance, goal-setting, support, and impediment resolution.

Wrapping Up

True trust, like delegation, can be really hard. As leaders, many of us have engineering backgrounds and are natural problem solvers—so our efforts to engage the team with our ‘advice’ emerges from our own backgrounds, skills, and interests.

We’ve also been programmed not to trust our teams. The inherent dynamics of Taylorism and Scientific Management influences our behaviors when it comes to telling our teams what to do and hovering over them until they do it.

But trust is what a truly empowered and self-directed team needs from you. Of course you can inquire measure, establish vision and set goals, measure results, and provide feedback. Surely you’ve earned that right with your experience and role. However, try and give true trust as often as you can. You’ll see a huge difference in your teams’ performance and the results.

Thanks for listening,

Bob.

Don’t forget to leave your comments below.

The Agile Project Manager – Don’t Throw out the PMBOK!

Written by Robert Galen on December 7, 2011. Posted in Articles. 4 Comments on The Agile Project Manager – Don’t Throw out the PMBOK!

Dec7bob4 I must admit that I’m a fairly rabid agilist. Part of the rationale for that is the pain I’ve experienced in leveraging traditional PM techniques in software projects. Another influence is my experience dealing with traditional leadership and the dysfunction relating to driving projects and teams towards unrealistic goals.

What’s interesting though is a conversation I had with our Scrum Master team the other day. I asked them to act more like “traditional project managers”. To begin to—

be more prescriptive at times with their teams; demanding high quality, excellent software, and adherence to our agile principles
pay close attention to risks – planning, real-time surfacing and guiding team reactions
encourage the teams to improve at an accelerated rate; to set the bar high for improvement
become visible as leaders and spokespersons for their teams; to do a better job of socializing state & progress
take the role of impediment resolution to the next level; mining for impediments…and dependencies, then inspiring action
cheerlead for their teams; inspire and demand that the Product Owner does the same

What I was trying to convey to them was the ‘mindset’ of a “good Project Manager”…or at least the ones I’ve seen and collaborated with in my journey. You see, many agilists use the role of Project Manager as a bit of a verbal “punching bag”—implying that there is no need for them in an agile context. By the way, you see these same folks trivializing other roles too—functional managers, testers, and business analysts to name a few.

I can’t disagree more with these folks and that position. I think solid Project Managers can find a place in agile teams…a place that makes a HUGE difference. Yes, they might need to reframe their style and behaviors for an agile context, but please, please, please don’t throw away all of your approaches. Your teams absolutely need and will appreciate your skills, as long as you reframe appropriately without throwing out your essence!

The “Agile Way”?

An anti-pattern that often shows up in agile teams relates to managers and project managers losing their way when it comes to knowing when and where to engage their teams. Knowing how to effectively handle the fuzzy and scary notion of a “Self-Directed Team” it turns out can be quite challenging.

A common reaction is to treat the team as if walking on egg shells. If you see the team heading for a cliff, you can’t really say anything—as they’re “self-directed”. Of if you do say something, you must whisper…quietly…hoping that someone might hear you.

I once coached a team in Toronto. As is my typical practice, I gave them a quick Scrum overview, then planned and kicked off their first sprint. I stayed for a few days to ensure they were going in the right direction, and then I went home. I came back at the sprint transition just to see how things were going. In my first morning Scrum upon returning, one of the developers sort of “yelled at” their functional manager who was attending as a ‘Chicken’.

The team was stuck at a technical impasse and she said: “You better step in and tell us how to handle this, or I’m going to scream”. I was taken aback and after the stand-up I asked her what was up.

She said that ever since the sprint started that none of the functional managers were saying anything—nor providing any guidance whatsoever to their teams. And that she was sick and tired of it. She wanted help! I then asked the functional managers what was going on. They said that they were only doing what I’d told them—that the team was “self-directed” and that they were to keep quiet…being ‘Chickens’ if you will.

Ugh I thought as I smiled a wry smile to myself. Yes, I had told them that respecting self-direction is important. But that doesn’t imply that you don’t have a role and responsibility as the teams’ functional manager. You certainly don’t let them crash into a wall without yelling and warning them. You see, the managers missed the nuance of leading within agile teams, as many roles do. They mistakenly behaved as if they were marginalized and didn’t matter…when nothing could be further from the truth!

Dec7bob3

So—Which way do we go George?

It’s Situational & Skills Matter

Always remember that your agile PM role is situational. You’ll want to keep the values (Lean principles, Agile Manifesto Principles & Practices, Essence of your specific methods, Quality, and focus on Team) core in your thinking, but at the same time very much react to situations as you always have—with simply some ‘adjustments’.

As part of being situational, always remember that the teams’ skills & experience matter quite a bit in how you should react. If you have a brand spanking new team, then you probably want to provide more prescriptive guidance. If you have a master-level team, then your job is to softly guide & support them, but truly get out of their way. The Dreyfus model of skill acquisition is a good model to become familiar with to conceptualize the various team levels that you might encounter and to guide your adjustments.

Risk an Opinion

As in the above story, your teams still need leadership—leadership that provides clarity, vision, missions, and goal-setting. Leadership that is “in the game or trenches” with them. Leadership that endeavors to protect them and to shield them from major obstacles and mistakes. Leadership that is supportive and encouraging. Leadership that is in all cases, well, leading them…

In a word, you should evolve towards a more Servant-Leadership style. But you also need to share your thoughts with you team. Risk saying how you feel and what you’re concerned about, but then allow the team to take risks and chart their own paths. Risk telling the team ‘No’ if you feel they’re on a destructive path and be prepared to also tell them ‘Why’. Finally, risk ultimately becoming a part of the team and sharing their responsibilities.

Leverage your Instincts

As I’m writing this, my company iContact is making a fairly major release of our eMail Marketing software platform. We’ve been adding social capabilities for several months and are now exposing them via this release.

One of the things we struggled with was how we turn on our +70k customers. Do we do it all at once, or in a more measured way to mitigate risk and allow us to see how the new functionality ‘behaves’ under load. There were two schools of thought across the teams—release it ALL and release it incrementally. Most of the teams had an ALL perspective, as did our QA team members. However there were a few in the development organization that wanted a more controlled release and argued for that option. Initially they were considered naysayers, only reacting to FUD, but to our credit—we listened to them.

After much discussion, we opted for a controlled roll-out. While we didn’t encounter huge problems as we ramped-up, it allowed for us to better understand our usage metrics, plan for incremental use, and have time to fix a few lingering issues. In the end, it proved that our overall risk-handling instincts were the right way to go. I’m glad the few had the courage to “speak up” and that we trusted their instincts.

Ceremony & Reporting Matter

Remember that even agile teams still bear a responsibility to integrate back into the organization. They need to be transparent and communicative—and not simply in agile terms. It’s not sufficient to simply say “come review our burndown chart” or “just attend our Daily Scrum” if an executive or stakeholder asks you or the team for status.

Sure that is a mechanism or ceremony setup for this sort of communication. But what if that stakeholder doesn’t show up? Does that alleviate your communication responsibilities? Of course not! So beyond the information radiators, a PM can ensure the team is effectively communicating broadly across the organization.

Another important point is communicating in ‘terms’ that the business can understand. Whether it is reports, data, videos, or whatever it takes to represent the teams’ progress and efforts.

The PMBOK!

I’ll even go so far in this post to say that many of the ‘traditional’ principles and techniques from the PMBOK shouldn’t be “thrown away” from an agile perspective. Let’s take the notion of critical path for instance. In larger agile projects, with multiple teams, there still are plans that evolve. And within that framework keeping the critical path of work in-sight across teams can be a crucial visibility point.

As can asking the team to manage risks, or creating a project charter, or establishing effective milestones for cross-team integration. So please don’t throw away or ignore these skills if you “Go Agile”. Just transform them (and yourself) a bit and then trust your instincts in the situations that emerge.

Wrapping Up

I want to wrap-up this post with caution though—traditional Project Managers DO need to reframe themselves and their approaches in an agile context. Throw away your templates and checklists that prescribe a specific approach to all projects & teams. Instead you must become context-based and situational in your approaches.

You must also engage your teams, not as an execution monitor or policy cop, but as a true partner.

I’ll leave you with the following two charts that nicely illustrate some of the focus and tempo changes that occur between Traditional & Agile PM activities.

Dec7bob2 Dec7bob1

So, Project Managers—may you navigate these waters well and engage with your teams. They NEED YOU!

Thanks for listening,

Bob.

Don’t forget to leave your comments below.

The Agile PM—What’s the Big Deal about Commitment?

Written by Robert Galen on November 9, 2011. Posted in Articles. 6 Comments on The Agile PM—What’s the Big Deal about Commitment?

FEATURENov9th As I discussed in my last post, I’m a bit of an “odd bird” when it comes to certain aspects of coaching agile teams. For example, I like the notion of calling sprints either a success or a failure based on how the team swarmed around and delivered on their Sprint Goal(s). Many agilist’s struggle with using the word failure to connote team performance and delivery—some prefer avoiding it entirely.

Another term that causes angst within agile circles is the word commitment. Again, I personally like the word commitment. After finishing sprint planning, I like to ask a team to “commit” to their sprint goal. I like the visualization of going “hands-in” as a team—in formalizing their commitment. Sometimes teams even physically do it, which always makes me smile. I see commitment as being a bond within the team to deliver on a realistic goal that they determine as part of sprint planning. It’s a bond extended to the business and generates meaning and focus for the team. But again, I may just be odd and miss the true nature of commitment.

So, what does it mean to be committed?

Let’s start with a definition of the term. From wordreference.com I found the following definition:

the state or quality of being committed to a cause, policy, or person.

a pledge or undertaking

an engagement or obligation that restricts freedom of action.

Given that definition, project leadership is always looking for a team to commit to a project—to its target date/schedule, scope, and cost. They’re looking for guarantees from the team to meet the projects’ inception views towards completion targets.

On the surface that doesn’t sound bad—does it? Bringing it back to software development methods, there’s a perceived difference in how “committed” teams are in Waterfall variants vs. Agile variants (Scrum, Extreme Programming, Lean, Kanban, etc.).

Waterfall (is) Committed?

The thought goes that since teams plan their execution thoroughly in Waterfall, to a set of documented requirements, that when the project begins they’re in a clear position to fully commit to the project.

They’re committed to the date, to the scope, and to the costs they’ve estimated. And if there is any “negative discovery” along the way, the team will somehow figure out how to “suck it up”, working harder and longer to meet their “commitment”. No matter what happens along the way!

You’ll often hear management driving this behavior—reminding the team of their commitment and to work smarter and not harder. There might even be veiled and not so veiled threats, as to what might happen if they fail to…meet their commitment.

Agile (is not) Committed?

Conversely there’s a feeling that agile teams lack commitment. You hear this coming from nearly every executive, technology leader, and project manager who are adopting agile and struggling with forecasting project outcomes.

This comes from the basic tenet that teams commit to projects incrementally—as they gain more understanding of the work by implementing it in small chunks. That teams narrow in on their delivery target as they gain more understanding and collaborate with their customer. That teams can commit when they’ve made some progress and understand their delivery velocity.

In lieu of simply committing without knowing, agile teams focus on incremental delivery and incremental commitment; needing some time to truly understand the project complexity and their own capacity. Many misconstrue this prudence and transparency for a lack of commitment. But there’s also a truth to agilist’s struggling with the term.

nov9bob2

A quick diversion to the Scrum Guide

Ken Schwaber and Scrum.org publish something called the Scrum Guide. They recently (2011) published an update to the Scrum Guide changing the language used to reflect the team posture at the conclusion of Sprint Planning. Previous language had used “commit”, as in the team would “commit” to the work they identified and planned as part of their sprint.

The updated language changed the word “commit” to the word “forecast”—here’s a copy of the language change that I copied from the FAQ on the Scrum.org site –

Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.

This was one of six changes or adjustments that were made within the guide. I bring it up because it amplifies a common reaction in the agile community to the word commitment. At my core, I don’t understand the issue. It’s just a word.

Back to Waterfall vs. Agile Commitment

So are Waterfall teams more committed than their Agile counterparts? In the use of language around project targets and scope, it certainly appears so. But let’s get real. Waterfall projects rarely meet their commitments. I rarely do this, but I’ll bring out some statistics to make the point…

According to the 2009 Chaos Report examining the success rate of IT projects found that – 32% of projects succeeded, 44% were challenged or failed to meet some project goals, and 24% failed completely.

The key point here is the assumption that these were committed teams, yet literally 2/3 of the projects failed in some capacity. So I contend that commitment is simply a word. Not let’s look at commitment from a different angle—probably the right angle.

The Real Nature of Commitment

I don’t think team commitment comes from a methodology or a planning process—particularly for highly complex, technology-driven projects, with tremendous up-side risk because your teams are creating novel solutions to your problems.

Commitment is created by many factors and I don’t pretend to be an expert on it. However, it seems to me that some of the following are crucial to support an environment of commitment—

Teams commit to work that they have planned and estimated themselves; factoring in their true capacity and not influenced by unrealistic or artificial targets from their managers or corporate leaders
Teams commit to a compelling leadership vision, which leads to understanding project goals, determines strategies, and ultimately measures success
Teams commit to each other; so fostering an environment of teamwork, mutual accountability, trust, and professionalism
Teams commit to exciting and meaningful work; so communicate the ‘why’ and ‘impact’ of their work to inspire them
Teams commit to solid leaders—leaders who trust them to do their jobs and who provide sufficient support for them to succeed
Teams commit to doing good work. Work that balances competitive delivery against solid designs, creativity, work-life balance, and high quality
Teams commit to providing total honesty and real-time transparency so that their leaders can make congruent adjustments; to leaders that can “handle the truth”.

Wrapping Up

So I still like to instill in agile teams that Sprints can either “Pass or Fail” depending on their efforts and behaviors and results relative to their sprint goal. And yes, I do expect a team to “Commit To” their plan to meet a sprint goal that they’ve established with their Product Owner.

I feel it’s not the word that is the problem. Instead, the question is—does the environment support the team in the areas I mention above in meeting their commitments? Point being—I don’t see commitment as a team only condition. I think the organization needs to establish a culture and an environment where commitment is supported. Where discovery and adjustment is supported, where honesty and transparency is honored, and where failure is tolerated.

If you have an environment that isn’t supportive, then yes, I can see changing the term and not using it. In that environment, then “forecast” would be a better term…as would dysfunctional. But I’m tremendously disappointed in the organization that can’t make congruent commitments across their teams and then deliver on those commitments.

So call me committed to An Environment of Commitment…

Till next time,

Bob

Don’t forget to leave your comments below.

References

Top 10 Agile Phobias – http://www.slideshare.net/visuri/agile-phobias
Chaos Report reference – https://www.projecttimes.com/wp-content/uploads/attachments/chaos.pdf
Scrum Guide reference – https://www.projecttimes.com/wp-content/uploads/attachments/Scrum%20Update%202011.pdf
Wonderful article on Estimation, Prediction, and Commitment – http://tynerblain.com/blog/2011/08/09/agile-estimation/

The Agile Project Manager—Viewing RISK Through a Different Lens

Written by Robert Galen on October 12, 2011. Posted in Articles. 6 Comments on The Agile Project Manager—Viewing RISK Through a Different Lens

bob1oct11

This post was originally made in June 2010. However, I wanted to make it part of my “Agile Project Manager” series, so I’ve updated and extended it a bit…hope you enjoy v2.

I often find myself teaching various classes on agile methods. One of my more popular sessions surrounds the mapping of traditional project management techniques towards the agile methods. I do this quite often in a wide variety of venues. One metric I’ve noticed is that the more PMP’s in the audience the more spirited the discussions become.

One of the core translation areas between traditional and agile project management relates to risk management. I often get a lot of pushback from the PMP’s telling me that the agile approaches to risk management simply won’t work. Their arguments are more based on traditional thinking, PMBOK guidance, and “we’ve always done it this way” pattern; rather than a situational response to individual project needs. I usually just leave it that agile risk management is “different” and move onto safer topic areas. But I usually want to add more flavor and this post seemed like a good opportunity to do so.

Traditional Risk Management

In this view, the Project Manager is managing the risk. The premise is that you need a highly skilled and experienced PM to adequately control and manage project risks. That risk can be anticipated, planned, reduced, avoided, transferred, positive, triggered, and mitigated.

One of the first activities with any project is to begin the compilation of a risk list so one can manage the project risks. These risks can be gleaned in a wide variety of methods—team brainstorming, speaking directly to key stakeholders, analyzing previous projects, and from the technology and business climate.

Once identified, teams often evaluate the size of each risk. A common mechanism is to gather likelihood and impact from the project team, then multiply the likelihood of the risk occurring against the impact the risk would have. So, something like the following table—

Potential Risk	Likelihood of Occurrence: 0 – minimal / none, 1, 2, 3 – Certain!	Impact of Risk: 0 – minimal / none, 1, 2, 3 – Project Failure!	Risk Priority
50% of technical team will leave for a competitive position	0	3	0
The open source LAMP stack will be acquired by Oracle	1	2	2
Chance we will deliver 100% of the agreed functionality?	3	1	3
System Performance will not meet requirement levels; only 50%	2	2	4
Business stakeholders will be confused on required features	3	2	6

Once you’ve accumulated a “complete” list of risks and analyzed their “priority”, then a plan is put in place to detect and mitigate the risks that are most likely to occur. Quite often, this is a very detailed plan that is formulated with all of the projects functional teams—expending quite a bit of time and effort towards these hypothetical risks both in upfront planning and in ongoing monitoring and discussion.

A Quick Point of Context

Oh, and I need to get this point out of the way. My primary context for this post is technology projects. If you’ve managed a technology-driven project, IT project, software development effort, or product integration project you will certainly agree that these beasties are “different” than other types of projects. And yes, their risks are different too. Rarely can you predict risks early on in these projects. Why? Because you simply haven’t done it before—so you have little to no experience with this specific type of project or technology within the team chartered with implementing it.

In my view, the variability in complex software projects is what undermines traditional risk management. We try to expend all of our effort in up-front risk management. Rather, we should expend most of our efforts towards figuring out what we know and don’t know with respect to our technologies–or specifically how do we design & code this particular widget. I.e. do some of the project work before trying to predict risk—so let the risks emerge from our design and coding efforts rather than trying to predict them.

It’s this focus on iterative, working code that raises agile software project risk management from conjecture to real-time risk discovery. So, let’s move onto agile risk management…

Reference for the diagrams

Agile Risk Management

The two diagrams nicely capture the essence of the difference in traditional (Waterfall) and agile risk management. In traditional projects risk essentially surfaces late—usually in the latter 20% of a project and sort of all at once. For agile projects, they’re much more front-loaded. Yes, for an identical project the same risks will probably surface in agile. So, it’s not a prevention mechanism.

This nicely leads into the essence of agile risk management being an emergent approach. First of all, you rarely hear the agile methods focus on risk at all. Why? Because we flip the notion of planning risk on its ear a bit. How is that? Well instead of guessing or planning for risk, one of the central themes of the agile methodologies is to deliver, real working software, in very thin slices of functionality via time-boxed iterations.

Realization of risk occurs quickly and abruptly. It hits you in the face as a team at the earliest possible moment. Quite often it surfaces in your daily stand-up meetings—so very little lag time.

Is it solely the responsibility of the Project Manager? No, in the agile case the self-directed team is primarily responsible for detecting, acting on, and mitigating risk…and here’s the important part, in real-time, as each risk occurs. It’s a whole-team and highly reactive stance towards risk.

The team often engages in strategies surrounding risk by how they approach iteration planning. They have the choice of what to build first, so very often the development strategy is to load risky items first—

To complete research oriented user stories well in advance of delivering the related feature story
To do early experimentation to see how the team will respond to technical challenges and the unknown.
To measure the velocity of the team to understand their capacity to meet business milestones.
To engage stakeholders in assessing requirements as they evolve…in real-time and on working software.

The Rework Balance

One of the most important aspects of agile risk management is effectively balancing your rework. This is one of the key indicators that your agile project is being run well or running off the rails. Agile teams have a tendency to either sprint too early, before they fully understand what they’re about to build, or they sprint too late, as they over-analyze the work.

Agile speed is a rework balancing act. If you have zero rework, then you’re playing it too safe. You analyzing everything in advance and taking no risk. For example, you deliver a fully operational messaging framework component for use without ever having sent a message through it. This is sort of that BDUF (Big Design Up Front) waterfall-esque approach to architecture. It appears less risky, but it isn’t. You’ve just delayed your information gathering on how well your strategy works.

But if you start too early, without even thinking about some of the dynamics of your messaging architecture, instead simply slinging code, then your rework is likely to be high. As you make discoveries in your testing you’ll need to go back and rework large swatches of your framework ideas.

So somewhere in between these two end-points lies an appropriate rework balance for each unique agile team. If they don’t think, then they’ll suffer from too much rework risk. If they go to slow, then they’ll not achieve the delivery and speed promises of agility. They’ll also still have rework—as they will not have anticipated every eventuality.

Wrapping Up

Now all of that being said, I don’t think we throw out all of the traditional risk approaches in agile contexts. For example, I think it a very healthy exercise for larger-scale agile projects to assess and understand the Top 10 risks they might be facing. In addition, to also look for more systemic or organizational risks and do a bit of up-front planning for them.

But don’t spend too much time there. Nor in exhaustive detection strategies or mitigation plans. Setup a straw man risk structure and then start leveraging the emergent nature of agile iterations to surface risks quickly. And once they surface, then ACT immediately on the risk that are real risks and not those you planned or anticipated.

Now for you traditional project managers listening in, I wonder if some of these agile approaches might be applicable in your current project contexts. I’d guess yes!

Don’t forget to leave your comments below.