I’m feeling guilty for being a little late on this post.  Went to a class last week and I’m getting ready to go on vacation.  Hang in there with me during June as I will be travelling.

I took a great class on being a Scrum Product Owner from SolutionsIQ in Redmond last week.  I want to share my class experience because it provided a great example of how agile is important to project managers who want to find the other side of risk.  Agile structures your work so you are constantly challenging uncertainty to drive out opportunities.

The class content was great, the instructors were engaging and knowledgeable, and the class was run in a way that allowed students to learn from one another.  At the end of the class, I was happy with what I learned.  But, I paged through my class notebook and saw lots of pages we didn’t cover.  They all looked like really interesting ideas.  Was the class a success from a project management perspective?  This is the project manager’s dilemma with agile.  How do we commit to scope, schedule, and budget to meet our client’s expectations?  Let’s look closer.

The class was run as an “agile” class.  We used the agile Scrum process to understand and decide on what we wanted to learn within the curriculum; and how we learned it.

Time and cost were fixed constraints.  We finished on time and the class cost exactly what it was supposed to cost.  We got a book of slides and articles at the start of class – the potential scope, but we didn’t cover all of them.  But, everything in the book seemed important.  Shouldn’t I expect everything in the curriculum to be covered?  Would we be successful if we didn’t cover all the slides made available?   How much scope we could complete within fixed time and budget constraints was an uncertainty.  Sound familiar? 

Agile is about making the most of uncertainty, not eliminating it.  It turned out that our agile class project delivered value that satisfied all the students.  We found our perfect journey toward our perfect outcomes one step, or sprint, at a time.  Here’s how it worked.

There were about 20 students in the class.  We had different expectations.  We started by documenting our expectations (our perfect outcomes) as high level “user stories” for the class.  We each wrote down our most important outcome from the perspective of the role we were learning about.  For example:

“As a Scrum product owner student, I want to learn how to represent a wide range of stakeholders in making decisions about what the product will contain so that the stakeholders are satisfied with the product and we reduce rework.”

This user story values some part of the course materials over others.  Some students had more “portfolio management” roles requiring coordinating of multiple projects.  Others were very focused on developing a discrete part of a product with few stakeholders to answer to.

We put our user stories on the wall and self-organized to prioritize the user stories using sticky dots.  We sorted, discussed, and prioritized.  Then, we correlated our student objectives with course material user stories.  We had to decide what course components would best meet the outcomes we documented and which ones to start with.  All the components that best met our objectives became our “product backlog.”

Then, we worked with the instructors to define the content of the first four hour block.  Our first “sprint.”  During “sprint planning” the instructor team had to decide what to do to meet our needs and how much they thought they could get done.  This part was up to them.  We all agreed on content and approach and off we went on sprint one.

At the start of sprint one, we had a plan, but none of us knew for sure how long each bit would take because the students were unique and the content was organized to meet a unique set of needs.  Each student had their own:

• learning needs
• learning style
• response to the instructors’ approaches
• behaviors for asking questions and working with others
• experience, knowledge, and frame of reference.

All these characteristics created uncertainty.  They would influence both what content could be learned and how it would be learned during the course.

The class and instructors had to balance the sense of urgency to complete all the components with the acceptance by the class that the component had been sufficiently covered.  Most of the course component user stories in sprint one were covered.  At the end of the sprint, we evaluated how much we had actually accomplished and what we had learned about how the students were learning.  Doing this two kinds of opportunities emerged: we had a better understanding of what learning and working methods best suited the students in the class, and we had a better understanding of how fast we could go.  We were defining the perfect journey to our perfect outcomes.  Our journey would effectively engage the class to ensure learning and to complete as much as was possible in the time available.

User stories were reprioritized and selected for the next sprint.  We agreed on process adjustments.  We followed this process to the end of the class.

At the end, all the students seemed very satisfied with what they got done and how it was done.  We acknowledged that there were still unaddressed user stories, but what we covered was probably the most valuable outcome we could have achieved from our time and efforts.  So, back to the unanswered question: Was the class a success from a project management perspective?  Yes.  In two ways.

First, the class delivered enough scope to meet the outcomes sought by the clients.  The scope was delivered in complete valuable components that informed the next sprint’s components.  The focus was on delivering the most value rather than on barriers to completing the entire potential scope.  It was clearly better to pick and complete each course component to the satisfaction of the students than it would have been to race through all potential scope just because it was there.

Second, the class learned about themselves and adjusted their approach after each sprint.  The journey taken by the students and instructors wasn’t rigidly dictated by curriculum and method.  They could learn about one another, express their needs, and frequently seek opportunities to improve their learning experience.  Not only did the students learn, they had an enjoyable experience that they helped define and deliver.  They will want to do it again.  Not only did the instructors deliver the content, but they had the opportunity to learn from their students’ input and observations.  All of us, and our organizations, were better off after our class.  Our agile Scrum class project sought a perfect journey to a perfect outcome that left us and our organizations better than when we started.  We found what could go right, one sprint at a time.

I think, using Scrum, we found the other side of risk.

Thanks for reading.

Copyright 2013 Glenn Briskin and “The Other Side of Risk”