Inspired by the Toyota Production System, Mary and Tom Poppendieck describe the seven wastes of software development as: partially done work, extra features, relearning, handoffs, delays, task switching, and defects. In this video from the February Scrum Professionals MeetUp, Kim Poremski explores the seven wastes and introduces tools and techniques to overcome the seven wastes and unlock organizational agility and scalability.
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…
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
Scrum Retrospectives With Cathy Simpson
Our own Cathy Simpson talks about how to do an agile retrospective with your scrum team in this video. The 5-step retrospective agenda she talks about comes from the book Agile Retrospectives: Making Good Teams Great.
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 or how much they are producing. Neither of these is correct. Velocity is a tool for predictability.
Because of this misunderstanding, many managers think that the team should work toward increasing their velocity. If management focuses on velocity, this will create dysfunction. Imagine that your manager wants to see the team’s velocity increase. This is very easy to achieve; the team can simply increase their story estimates over time. Velocity will climb as high as anyone wants. This won’t correlate to any change in productivity or business performance, and the manager won’t get what they wanted. Worse, the team has just lost visibility and control of their schedule. What’s a scrum master to do?
Is this airhead your product manager?
On the bright side, you definitely can’t call him/her a stuffed shirt…
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…
PMI Wine Country – Professional Development Day
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.
Read the full article…
“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:
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.
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?