Agile Richmond Slides

Late last month, I had the pleasure of presenting again at Agile Richmond in Richmond, VA. It's always a pleasure for me to visit Richmond, since I studied there several years ago at Virginia Commonwealth University, and love the city.

I presented a version of my Agile DC keynote at the Agile Richmond event, and have received some nice feedback. In response to requests to make the slides available, here they are.

Thanks to the organizers, and to everyone who attended. Hope you enjoyed the talk, and find the slides useful!

An Exercise in Flow: The Dice Game

photo by fyuryu

We do a lot of training here at LitheSpeed, and our exercises are consistently among the most popular parts of our courses. We’ve had many requests over the years from participants, coaches and other trainers to use some of these exercises when instructing teams, and since we’ve garnered many of them from the community ourselves, we tend to readily accede.

Here is one simple but powerful exercise that can be used to demonstrate several aspects of flow, value and teamwork: The Dice Game.

Materials:  Obtain 10-15 multisided dice per group of 5-7 people. Transparent dice and ones with un-inked numbers can help make the exercise more challenging (and realistic). You can get these at any store that specializes in board games.

Setup:  We are building an application, and each die represents one feature (or User Story) that our customer values. We’ll compare several different ways to perform this work, including a waterfall delivery method, continuous flow/Kanban, and Scrum.

Time limit: 2 minutes per round

Roles:

• ScrumMaster: Ensure rules are followed, add up points 
• Product Owner: Accept delivery to confirm receipt of points 
• Team: Each person on the team will turn the dice in a certain way to represent a specialized activity, such as analysis, design, development and testing.

Define an activity for each participant except for the ScrumMaster and Product Owner. For instance:

• Analysis would be performed by turning a die and placing it on the table such that the number 1 is facing up.
• Design would be performed by turning a die and placing it on the table such that the number 2 is facing up.
• Development would be performed by turning a die and placing it on the table such that the number 3 is facing up.
• And so on, ending with the Product Owner, who turns the dice one more time to accept them.

Feature Scoring:  1 point for every die that has been completed (proceeded through all of the defined activities by turning the dice through each number). You can also choose to give more points by die complexity (e.g. 1 point for 4-6 sides, 2 points for 7-9 sides, 3 points for anything more complex). This makes the Product Owner role more meaningful and challenging.

Release Scoring: 10 points for every complete set of one die shape (e.g. all of the cubes, or all of the tetrahedrons). You can also use similarly colored dice to represent Releases.

Delivery Method Variations:  Each team or table can represent a different method of delivery. We usually have everyone do this in parallel, working within the same two-minute timebox, and then we compare results at the end. Common variations include:

• Waterfall – Every person represents a different specialty (e.g. analysis, development, testing). Each person must flip every die before the next person may begin. 
• Continuous Flow/Kanban – Every person represents a different specialty as above, but only has to flip one die before passing it along, resulting in a steady flow of value. If multiple rounds are performed, teams can look for bottlenecks (where a few dice pile up consistently in front of someone) and adjust the amount of dice allowed to be in one’s “outbox” as needed to reduce these bottlenecks. For instance, the person representing Design may be able to place 2 dice in Development’s queue, but no more, while Development may be allowed to place 3 dice in Testing’s queue. 
• Scrum – The same activities must be performed to deliver a feature as above (e.g. turning each die through each defined number), but here teams are asked to design their own process, choosing how to address the “backlog” of dice and who will do what. It is allowed for a single person to flip a die through every stage, if desired; here, the metaphor would be that this person represents a cross-functional team by themselves. This variation works best across a few rounds, as teams can then inspect and adapt.

Debrief:  Several learning points tend to surface during this exercise. The instructor can ask each group many different questions to help cement these points, such as:

1. Did you feel like a team? (typically, Waterfall group: no, Kanban group: sort of, Scrum team: yes)
2. What would happen if something happened to kill the project 75% of the way through? (Waterfall: disaster, Kanban & Scrum: we would already have the presumably highest value features built at that point)
3. [For Kanban team] Did you see any bottlenecks forming? How would you deal with them? (people should help those performing downstream activities, requiring some skill overlap and sharing)
4. [For Scrum team] Did you change your process midstream at all? How would you change things next time to be even better? Did you encounter any dice that could not be processed? (e.g. if you have tetrahedrons, but there are 5 or 6 steps total, they will be impossible to finish, representing a technically infeasible feature; most people won’t realize this until already well underway, demonstrating that actually doing something is a quick way to learn about how to do it properly, whereas vacuum-chamber analysis often misses such things initially)

Key Learning Points:

• Value is delivered more rapidly in small batches
• Steady delivery of features mitigates the risk of non-delivery
• Small batches reduce the impact of customer changes (you can demonstrate this by changing the activities or scoring mid-round at some point)
• Teamwork is more prevalent when activities are shared and when there is frequent interaction
• New skills can be built over time by frequent interaction between those performing neighboring activities, leading to more polyskilled team members and hence more fruitful collaboration 
• Work in small batches is less complex (e.g. flipping one die is easy, but it’s harder to keep track of the state of 15 dice at once) 
• Optimal release strategies can maximize the flow of value, hence the necessity of the Product Owner role

That’s it! We hope you find this useful in educating your teams, and if you have any great exercises that you’ve used yourself, we would be thrilled to hear about them. Until next time…

PMI Agile Contact Hours versus PMI-ACP PDUs

I get asked on a regular basis what the difference between a contact hour and a PDU is. When people come to my PMI-ACP exam prep class, they qualify to claim 21 Agile contact hours.  If they currently have another PMI credential, they could choose to apply those 21 hours as a PDU.

PMI Agile Contact Hours

When completing your PMI-ACP application, you are required to report (among other things) your "Agile" education. They will be referred to and measured as contact hours. To qualify to sit for the ACP exam, you need 21 contact hours.

   

Professional Development Units (PDUs)

PDUs can only be applied if you have a PMI credential.  If you try to claim a PDU and you don't have a credential, PMI will politely either tell you don't have permission to that area of the website (where you claim the PDU) or they will send you a friendly email. The image below is only viewable if you have at least one PMI credential.

 

 Hope this brief overview helps. If you have any questions, please leave a comment below.

Three Keys to Successful Product Ownership

The Product Owner is both one of the most important roles in Scrum and often the most difficult to fill. In this post, I will explore a few aspects of successful product ownership that are often done poorly or not at all.

Manage Both the Big Vision and the Small Batches

Keeping a balance between the development of product qualities that will fulfill the business case and the tactical execution of low-level features is perhaps the most important skill possessed by a Product Owner. The difficulty in simultaneously doing both of these things well often leads to an actual split in the role, where a “Strategic” or “Chief” Product Owner focuses on the big picture, and the “Tactical” or “Proxy” Product Owner works with individual teams attending to the details of execution. Tools like story mapping, product trees and personas are commonly applied at the big picture level by Strategic POs, while sketches, wireframes, process flows and various collaborative modeling techniques are generally employed by Tactical POs to help teams better understand and execute the details.

Strategic product ownership is focused on garnering feedback and testing the project's assumptions at the vision and business case level, while tactical product ownership should align the whole team against small batches of work within sprints to ensure the best execution possible at the detailed level.

Test the Project’s Assumptions

Business cases are often presented as foregone conclusions: Build the features, and they will come. However, there is no shortage of failed and unloved products to prove that this is nonsense. Projects are built upon more or less educated guesses of what the market and stakeholders need and desire, and it is the Product Owner’s job to test and refine these assumptions, thereby guiding change through objective data.

Techniques such as customer development in the "Lean Startup" approach focus on stating your assumptions in such a way that they can be tested, and then using feedback from these tests to adjust the project’s focus. The simple process of coming up with metrics that represent the product’s desired qualities and impact areas also can be of tremendous help when attempting to balance diverse needs across disharmonious stakeholders, as it forces a focus on overall project needs rather than individual features. In essence, the why must precede the how.

Use the Whole Team

When Scrum was first formulated, a joke cast the “team” as committed “pigs” while the Product Owner (along with general stakeholders) was dubbed a merely involved “chicken.” This is an unfortunate place to draw the line, because these two roles work best as a tight-knit partnership. Scrum teams already play an active role in design and feature elaboration, and the best products come from fully engaged teams, not ones that simply wait for their orders or ones design in a vacuum.

Collaborative modeling techniques, where designs are created and refined by small groups rather than individuals, are common in such environments. Finding the right balance between giving the team a “final, approved” design to develop vs. involving them deeply in the design process itself isn’t automatic or consistent across teams, but it is the only way to maximize both the efficiencies so often touted in Agile methods with product innovation, effectiveness and quality.

I hope you've found this post useful. If you have any other questions about how to be an effective Scrum Product Owner, share them in the comments and I'll do my best to answer all of them in future posts.

What will it take to transform management? Look to the Polio Eradication Model.

In a few days, I'll be leaving behind the balmy weather in Chennai and heading to #Stoos in Switzerland. Our Stoos Gathering attendees will be deliberating on the issue of accelerating the transformation of management. We'll likely be asking questions like, "How can we accelerate the transformation of management away from creaky, dysfunctional models of the past and towards modern, dynamic in the present?"

Or "How can we catalyze widespread change in management to better meet the challenges of our turbulent times?"

Some days ago, I blogged about some of the models under consideration, and indicated that all of the approaches are essentially humanistic and systemic. So, whether we consider slightly older models like Jim Highsmith's Agile Project Management model or the Declaration of Inter-dependence; or more recent ones like Jurgen Appelo's Management 3.0 and Steve Denning's Radical Management, I believe the required transformation from current management state to future state is less about the mechanics, and more about the fundamentals.

How can we transform from older industrial-style management with its mechanistic command-and-control to newer "light-touch" humanistic management with decentralized or distributed control? In the agile world, we have certainly seen many companies initiate and sustain agile management and agile development transformations. The Forrester Group reports more and more organizations have initiated agile transformations world-wide. In my last blog post, I referred to this as creating a playground of productivity. In response, @stevedenning points out that the bigger question is, "How can we sustain the transformation?" I've spent the last few days in preparation for #Stoos: reviewing available models, reviewing the comments surrounding the Stoos gathering and perhaps most important, doing some personal reflection and retrospection on that very question.

While mulling the question, and perhaps enabled by my current surroundings, I recalled a very successful worldwide movement: the Polio Global Eradication Initiative. I first learned about this initiative when, on a flight to India some months ago, I sat next to a gentleman from Boston who was leading a U.S based team of volunteers from Rotary International. The goal of the initiative is to completely eradicate this often fatal and always debilitating disease from the earth.

Rotary International is one of the four spearheading partners in the initiative, and it is heart-warming to see volunteers from all over the world fund their own way, and team with local organizations and volunteers to help vaccinate children in the remaining hotspots.

The key partners: the World Health Organization (WHO), Rotary International, the US Center for Disease Control and Prevention (CDC), and the United Nations Children's Fund (UNICEF) have mobilized thousands of volunteers, and managed and coordinated and managed their efforts in alignment with clear strategy with four pillars:

1. Routine immunization
2. Supplementary immunization
3. Surveillance
4. Targeted "mop-up" campaigns

The results are impressive. Per UNICEF, over the past 20 years, there has been a 99% reduction in polio cases.

I think we have a lot to learn from this model that brings public and private organizations; and governments and individuals together to work towards a common goal.

My thoughts on using the polio eradication initiative as a model for a global movement to transform management coming up in the next blog post.

Large-Scale Management Transformation: How Can We Create a "Playground of Productivity?"

Something that has come up in discussions around the Stoos Gathering is the pivotal question, how does one create and sustain large-scale management transformation? The #Stoos participants have been engaging in lively discussions, and I thought it would be good to mull the topic as well.

So, I began looking back at some of the most successful transformations I've witnessed, two key factors emerged: a true business need and a willingness to experiment. From our archives, I found this post with my answers to 5Qs on Agile. Don't miss Bud Phillips' amazingly prescient conversation with our own Bob Payne on sparking and sustaining management change. I really like Bud's rhetorical question, how can we create a "playground of productivity?"

More on this coming up.

Merry Christmas everyone!

Want to Transform Management? Help Me Prepare for the #Stoos Gathering

On January 6-7, 2012, I will be in Stoos, Switzerland as part of a gathering of management enthusiasts. Organized by the core team of Jurgen Appelo, Steve Denning, Peter Stevens and Franz Roosli, we have a lofty goal: we are seeking to accelerate the transformation of management. As Steve Denning and Jurgen Appelo posit, the pace of change in the world of management has been – glacial. So now, there is much interest in catalyzing that process to accelerate change in this area.

In preparation for the gathering, Jurgen has prepared a short list of models, and others are adding their thoughts. Before we can begin looking forward, I want look back in Agile tradition to make sure we are taking the past into due consideration, and that we can build on and synthesize different models.

In my own book, Managing Agile Projects, I shared my three guiding management principles for agile teams and projects:

1. Foster alignment and cooperation
2. Encourage emergence and self-organization
3. Institute learning and adaptation

Most everyone familiar with agile methods is likely able to trace things back to the seminal Manifesto for Agile Software Development. However, lesser known, but perhaps a "nearer neighbor" to the world of management is the Declaration of Inter-Dependence. In 2005, several of us within the agile movement were convened by visionary leader Jim Highsmith and hosted by David Anderson in Redmond, WA and emerged from that gathering with these six management guidelines that constitute the DOI:

• We increase return on investment by making continuous flow of value our focus.
• We deliver reliable results by engaging customers in frequent interactions and shared ownership
• We expect uncertainty and manage for it through iterations, anticipation and adaptation.
• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
• We boost performance through group accountability for results and shared responsibility for team effectiveness.
• We improve effectiveness and reliability through situationally specific strategies, processes and practices.

©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent MacDonald, Polyanna Pixton, Preston Smith and Robert Wysocki

Alistair Cockburn's later commentary and explanation capture the thoughts of that group best, in my opinion. The DOI has certainly been my touch stone as I've applied Lean Thinking along with agile values and practices since then. I've found it especially useful when applying agile methods at the enterprise level, because of its lean-infused thinking and language. For example, phrases like flow of value, situation-specific strategies, and environment to make a difference help ensure that we simultaneously take both a humanistic and systemic approach to management.

That humanistic and systemic approach underlies the approaches postulated by both W. Edwards Deming and Peter Drucker, upon which we have built the foundations of modern agile management. Tellingly, at the core of Lean Thinking are these two fundamental principles: respect for people (humanistic) and continuous improvement (systemic).

Even if these principles are not yet manifested in a widespread fashion globally, there are certainly brilliant pockets of adoption world-wide. In North America and Europe, I've witnessed the power of agile methods to drive tremendous results, including some monumental agile adoptions. I'm now on vacation in India, and one model that has caught my interest here is the one practiced by Vineet Nayar at HCL Technologies, "Employees First, Customer Second." Definitely sounds like a humanistic and systemic model, doesn't it?

Finally, over the past year, since I was introduced to the concept by Jeff Sutherland, I've been captivated by the notion of wise leadership, as proposed by Takeuchi and Nonaka. Takeuchi and Nonaka recommend the quality of phronesis as the quintessential quality of wise leaders, and pinpoint these six abilities of a wise leader:

1. Wise leaders can judge goodness
2. Wise leaders can grasp the essence
3. Wise leaders create shared contexts
4. Wise leaders communicate the essence
5. Wise leaders exercise political power
6. Wise leaders foster practical wisdom in others

Earlier this month, as 2011 drew to a close, I was privileged to attend a remarkable event in Milan, Italy hosted by the PMI's Northern Italy Chapter (PMI NIC). Organized by Tiziano Villa and Walter Ginevri from PMI NIC and bringing in Victor Carter-Bey and others from the PMI Global, Tiziano later remarked that we were able to create a "ba," or place where relationships are forged and interactions occur as participants try to create new meaning.

As we usher in the New Year, I am now looking forward with eager anticipation to the trip to Stoos, and I'm hoping we can create a similar "ba" that helps accelerate the pace of management warming.

To reiterate the #Stoos gathering organizers' call to help transform management, please help us by sharing your thoughts in less than 100 words, either via the comments box below or by email at sanjiv DOT augustine AT LitheSpeed DOT com.

Thank you, and Happy New Year!