Category Archives: project management

World Café – Scaling Highly Interactive Meetings

WorldCafeGlobe

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:

1. Scrum roles – Each role plays a part in helping teams perform better

The Scrum Master is an embedded agile coach. The Scrum Master plays a direct role in easing teams through the forming and storming stage. They take a coaching stance and share behaviors that they observe are challenging the team’s ability to work together.

The Product Owner maximizes the value of the product and the Development Team. They point the direction for the team, which eases the team’s shift into norming.

The Development Team Members organize and manage themselves. They have the freedom to shape their own environment. This empowerment facilitates the move toward high-performance. And the supporting roles of Scrum Master and Product Owner are there to serve the Development Team to make the shift successful and sustainable.

2. Scrum events (Sprint Planning, Daily Scrum, Sprint Review, Retrospective)

Each Scrum event is meant for a specific purpose. They provide a minimal level of structure upon which the team can build. This is why Scrum is often referred to as a process framework. Here are some examples of how the Scrum meetings help teams accelerate to high-performance:

Sprint Planning: Team members avoid analysis paralysis. They don’t spend months analyzing requirements and designing solutions before producing something. They quickly put together something useful upon which they can iterate.

Daily Scrum: This is a short meeting meant to make it easier for a team to actively manage itself and coordinate its work. Each team member demonstrates their progress, which helps others learn to trust that everyone is pulling their own weight. It’s more difficult to ride on other people’s coattails when you have to stand before your colleagues each day and talk about what you’re doing.

Sprint Review: The team members share equally in the success or failure of the team. No one on the team wins unless they all cross the finish line. This reinforces the individual member’s commitment to the team, which facilitates the norming process. And once they become cognizant of this new reality, they unlock the door to high-performance.

Retrospectives: From the beginning, the team carves out time to inspect and adapt. This means they take a practical and thoughtful look at what went well and what didn’t. They search for ways to improve in the very next sprint. Talking about challenges, both task-wise and interpersonal, pushes the team to storm quickly, and with the aid of the Scrum Master, to ease into norming.

3. Scrum artifacts (Product Backlog, Sprint Backlog, an Increment of Something that is “Done”) – each artifact serves as a focal point around which the team can organize itself

Product Backlog: The Product Owner is empowered by the customers to order the Product Backlog by value, risk, priority, necessity, or other factors. This eases the pressure on the team to figure out what they have to do next. At the same time, the Product Owner and team collaborate on the details of the items in the backlog.

Sprint Backlog: The team collaborates to make a short-term work plan to deliver items from the Product Backlog. By planning and acting together, the team learns what it takes to produce valuable results and makes delivering those results the measure of progress.

Increment of Something that is “Done”, usually an increment of potentially shippable software: They trust their colleagues’ motivations because everyone has agreed to pitch in and deliver the next increment of potentially shippable software together.

4. Scrum Teams put the Agile Manifesto into practice:

“Individuals and interactions over processes and tools” The team members work more closely together. Cubicle farms are rare in a truly agile space. It’s also preferred to have the team members co-located instead of spread across the world. The team members speak with each other more often. Not only are conversations held face-to-face, but the act of conversing is preferred over comprehensive documentation.

“Responding to change over following a plan” When you make a big plan up front, you have less tolerance for mistakes because you can’t go back and change things without substantial disruption or cost. On the other hand, a scrum team is encouraged to make decisions as it goes along and limits its risk to the length of the sprint. If something doesn’t work, the team just fixes it in the next sprint.

5. Building high-performance through trust

The team spends very little time in the forming stage because the team members rapidly build trust through applying Scrum. From their very first sprint, they make commitments to each other and diligently practice keeping them. The team members learn each other’s talents and skills by observing them being practiced. They quickly see what others are capable of, and they gain a new level of assurance because they’ve seen their colleagues demonstrate their abilities.

Share it!

PMI Wine Country – Professional Development Day

PMI-Wine-Country-Professional-Development-Day-Features-Agile-Learning-Labs-Founder-Chris-Sims

Calling all Project Managers! It’s time to head to Wine Country! The Wine Country Chapter of the Project Management Institute will host a Professional Development Day on Saturday, August 27, 2011.

Head up to Santa Rosa for excellent networking and catch up on the latest trends in project management.

Highlights of the agenda include:

  • Workshop on Sustainability and Social Responsibility in Project Management
  • Workshop on Mind Mapping
  • Panel Discussion on Project Management Certifications and how they can help your career

Of course, that last topic is near and dear to the hearts of Agile Learning Labs since our founder and Chief Agile Coach – Chris Sims will be part of the panel. Up for discussion will be the newly minted PMI Agile Certified Practitioner (PMI-ACP) certification, as well as the Scrum Alliance’s Certified ScrumMaster and Certified Scrum Product Owner designations. If you have questions about how these certifications and others might harmonize on your resume – be sure to check out this event.

The best news – of course – is that the agenda is designed with plenty of networking opportunities and an unconference-style “World Cafe” to collectively discuss how to apply the concepts presented throughout the day.

Let’s all raise a glass and toast the PMI Wine Country chapter! See you there.

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!