Category Archives: project management

World Café – Scaling Highly Interactive Meetings


World Café is a fun, flexible, and scalable technique for group conversations that leads to creative solutions to complex problems. World Café has some similarities to Open Space Technology: both techniques work for groups ranging from a few people to a few thousand; both are frameworks that support individuals and interactions. World Café is useful for generating and communicating ideas, making decisions, and even doing hands-on work. We’ll be teaching product owners how to use it in our upcoming Advanced Certified Scrum Product Owner (A-CSPO) workshop.

How It Works

The facilitator breaks the room into groups, then sets them to explore a set of related topics, one per table. Each table has a host whose job is to stay with the table and provide continuity while the groups discuss the topic. The other participants rotate between tables on a regular schedule, perhaps every 15-30 minutes. The idea is that those who travel between tables will cross-pollinate ideas between the topics and bring fresh perspectives. By participating in each topic, the participants come to have a holistic understanding of the main issue, and are able to understand each sub-issue within this context. In the last round, people have the option of returning to a previous table so there is opportunity for closure and continuity.
Read the full article…

Share it!

What Is The Role Of Project Manager In Scrum?

This question came from a client: What is the project manager’s role in scrum?

In answer to your question about project managers, there is no project manager role in scrum. The duties of a project manager gets split between the product owner, scrum master, and the development team.

The product owner has the vision of the product and is the business representative accountable for making sure the business is kept up to date about the product, the schedule, and the budget. The product owner does this in multiple ways including:

  • Grooming and refining the product backlog
  • Understanding the development team’s velocity so he/she has a sense of when backlog items may be ready for release
  • Communicating frequently with the stakeholders
  • In the sprint review meeting, helping the team demonstrate new features and facilitating conversations with the stakeholders on the direction of the product and the product backlog
  • Sharing and maintaining a budget

Read the full article…

Share it!

Should Management Use Velocity as a Metric?

Many well-intentioned managers have a fundamental misunderstanding about velocity. They think it is a measure of how hard the scrum team is working. That’s not what it is at all. Velocity is a measure of the rate at which the team is delivering stories. If the team worked long and hard on 5 stories but delivered none, then their velocity is zero.

Because of this misunderstanding, I find managers who think that it is important for the team to work toward increasing their velocity. If management focuses on velocity, this will create dysfunction. Faced with a manager who wants to track velocity as a management metric, a scrum master needs to identify what the manager is trying to measure, and what business decisions they expect to make with that data. The scrum master can then help the manager find more effective ways to get the data they need to make their business decisions. If the manager wants visibility into how healthy the team is, or perhaps how productive they are, we can provide them much better metrics. Trying to use velocity for these purposes won’t work.
Read the full article…

Share it!

5 Reasons Scrum Helps Teams Become High-Performing Faster

Scrum masters and product owners know how hard it is to get their team to become high-performing. They can rest assured that they’re on the right track. Scrum helps teams become high-performing faster than other work methods. The reason is simple. Becoming high-performing is baked into the scrum recipe. In my experience coaching agile teams, I have observed over and over that teams that use scrum go from forming, storming, norming and ultimately to high-performing more quickly and reliably than teams that don’t. Here are five reasons why:
Read the full article…

Share it!

“Embrace change to add more value!” and other “aha!”s

Every time we run an Agile Project Management class we tweak it slightly, based on what we've learned in the last one. Inspect and adapt, as they say… err, I mean, as we say.

One thing we noticed happening over an intensive two days period is that people tended to generate many more insights than they can retain. "Aha" moments that seem memorable at the time have faded after the two day barrage of new information. How to capture the spontaneous learning as it occurs and preserve it, without disrupting the flow?

Our solution: Create an "aha!" wall where students can capture their immediate insights by putting up sticky notes at any time during the two days. These ahas formed a significant part of our retrospectives at the end of each module, and make a fantastic mnemonic take-away.

As we strive to structure our workshops to resemble agile projects as much as possible, we framed these ahas as representing the "learning value" the students were generating during each educational "sprint." Needless to say, this maps quite nicely to "business value" and demonstrates the beauty of incremental delivery in a tangible way.

This week we had thirteen very bright students show up for a two day workshop offered through the Bay Area chapter of the PMI, most of them PMPs, some with a high level of agile awareness, others new to the field.  Here are some highlights from their wall of over fifty "aha!"s. Reading over them, I think these could easily be chapter headings for a book on Agile Project Management:

Retrospective = lessons applied = improved output and flow.

Fail safely; fail softly!

Work becomes fun!

Things that are visable get more attention–and get done!

Embrace change to add more value.

If you won't need it, don't do it!

Responding to change means changing the plan.

Document to the extent that value is added to maximize ROI.

Focus on done, not doing.

Slow down to increase output.

Early delivery, early revenue = "compound interest"

A lot of the students in this class expressed an interest in returning for our upcoming Certified Scrum Master Training on August 12 & 13, which Chris will be co-teaching with the inimitable Jeff McKenna, which we have yet to formally announce. If you want to join them for some more ahas, save the date and either join our mailing list or check back early next week, when we should have details and a registration page.

Share it!

Yes you are comprehensively documenting your agile project–just not in English

If I were re-writing the Agile Manifesto and I wanted to express agile values in terms that spoke positively to the project manager's realm, rather than defining agile in opposition to it, I'd state the third value ("Working Software over Comprehensive Documentation") like this: The best documentation is the product itself.

How did I get here? We had a fantastic yesterday, delivering our Agile Project Management workshop to 13 quite knowledgeable individuals from all sorts of backgrounds. When the group is this experienced, we always learn as much as they do, and one of my "ahas" came when Lisa Winter expressed a pain point PMPs often experience during agile adoptions, especially when the organization is large and long in the tooth:

What do you do when you're caught between the rock and the hard place? ie, you need to run an agile project in an agile manner, but you also need to provide traditional reporting upstream. Do you make like Allen Stanford or the Mafia and keep double books? Or clone yourself and give the waterfall stuff to your evil twin? I hope not!

What Lisa wanted to know was, how can I cut down on this particular form of overhead? Where do agile metrics map to traditional metrics and where don't they?

So how do these things map? Take documentation. A great deal of confusion surrounds the nature of requirements and documentation in Agile, and it’s often put forth—mistakenly—that Agile eschews documentation. While it is true that in Agile development, working software is favored over extensive documentation, this doesn’t mean you don’t document requirements—it means that you and your team document these requirements quite comprehensively indeed at the end of every sprint–but you document them in Ruby, Perl or C++, not English!

This isn't some crazy cowboy agilista indulgence. In fact, there are industries built upon this notion of product as documentation, aka copyright law. And with the recent extension of copyright law to cover software it's no longer mere analogy. The code itself is the sole document on which basis protection is granted–just as the text of The Shining is the only documentation Stephen King produced to obtain his copyright. This is why I think that, while I heartily endorse it's intended meaning, the agile manifesto's implication that comprehensive documentation is frowned upon isn't an entirely accurate statement–what more comprehensive documentation is there, after all, than working software? And if it's proof enough for Uncle Sam, it might need to be proof enough for the VP of Product Development.

But, you say, this isn't documenting requirements exactly, because it comes after the fact. Does it really? Your first working software will be delivered months, possibly years, before a traditional requirements document would have, so maybe the working software really does fulfill the requirements model after all.

Maybe the answer to Lisa's question lies in translating Agile concepts and mapping them to traditional  values, if not practices.  It might be worthwhile to demonstrate to people who are, quite reasonably, invested in their own histories and bodies of knowledge, that despite radically different approaches, the actual values–quality, timeliness, transparency, value, etc., are the same.

Or am I getting it all wrong by implying that Agile means wrapping your ankle behind your ear to make a point?

Share it!

Agile Ontologies: Why the customer is always right, even when they’re wrong

Craig Brown voiced a common concern project folks have in "A Downside of Agile Development?" on his Better Projects blog, writing about his fears for his company's proposed transition to Agile:

I use a few online services, and you can tell which ones have adopted the philosophy of incremental product roll-out.

Just about every time you log in, there is another feature being promoted and presented to you for consideration.  Sometimes things you were used to have moved or disappeared.

This constant change makes some products less appealing than something that is more reliable.

There are valuable lessons to be gleaned here about what Agile is failing to communicate to customers. I like to think that the customer is always right, even when they're wrong, and if they're having a problem, then there is a problem. Brown is making visible a world view problem that is hindering agile adoption.

I left a comment on Brown's blog trying to reframe the question. Here it is:

This seems more like a web design  problem than a development problem to me. A product can be designed from the outset so that you can add to it without disrupting the work flows users have established. A top level menu system whose categories are general enough that you can fit almost any new feature under them, for example, allows you to release new features iteratively and allow users to discover what they need as the need arises. The problem may lie in treating each new feature as a "release" by shifting features around and making big front page announcements ala "Now with extra cleaning power!!!!" Constant improvement is not a series of events, and every addition doesn't need to be celebrated. Most of the time, it's enough to blog the new feature and move on. This is better than saving up features and doing a faux release. Why would you make an innovative new process mimic an obsolete process? Better to adapt how you think about the product instead.

I think I only captured part of my thought process in the comment, so here's the rest of it:

The takeaway is that often the resistance to Agile, or any other new way of doing, working or living, springs from underlying assumptions that aren't being unearthed and challenged. These assumptions are not ignorant–they are unconscious, and based on experience. As change agents, it's our job to challenge and persuade, not the other way around. For a customer who has lived through Vista or iTunes 8, and maybe a buggy beta or two of their own product, announcing happily that Agile will allow you to release every week will justifiably cause panic and soulful dread. Better to say, "We can make it so you never do releases. We build and test constantly behind the scenes, and add new features without disrupting your users' workflow. You'll never have a beta or a bumpy release to contend with."

Paul Graham wrote years ago that "…designing Web-based software is like designing a city rather than a building: as well as buildings you need roads, street signs, utilities, police and fire departments, and plans for both growth and various kinds of disasters." This high-level re-imagining is what Brown really needs to hear–he needs the shining city upon the hill, and for the leap of faith we're asking him to make in joining the revolution, he ought to get it.

Someone in the audience at the Scrum Gathering keynote last week reminded us that "A good trainer can lead a horse to water, but can't make them drink. A great trainer can make them want to drink." It's not enough to offer the customer better solutions and value, we have to offer them a vision of a better world; we can't focus on delivering processes and tools; we must focus on individuals and interactions.

Share it!