Archive for the ‘Product Owner’ Category

• SoCal Code Camp Fullerton

  Date: 2011.01.29 | Category: Conferences, Presentations, Product Owner, Scrum, ScrumMaster, Team | Response: 0

  It is time for Code Camp in Fullerton this weekend.  I will be speaking on Saturday on this two topics.

  • Scrum Roles in Action: in Scrum, there are three basic roles – Team member, Product Owner and ScrumMaster.  Each role is defined with some basic specific rights and responsibilities and filling in the rest of what one is supposed to do is left as an exercise for the participants.  In this workshop, we will review the rights and responsibilities for the Scrum three roles (plus stakeholders) and discuss what those roles look like when preformed well.
  • ScrumMaster Toolkit: are you just getting OK results with Scrum?  Has Scrum not delivered on the much anticipated quantum leads in productivity everyone had been promised?  One common source of lackluster performance comes from following routine behaviors and ordinary patterns of teamwork associated with the “old way of doing things”.  In this hands-on workshop, Carlton Nettleton will share powerful techniques from his coaching toolbox that breaks these old patterns, unlocks the potential of Teams and gets them moving toward high-performance.

• Scrum Bill of Rights

  Date: 2011.01.24 | Category: Extreme Programming, Product Owner, Scrum, ScrumMaster, Team | Response: 1

  One of the things I admired about Extreme Programming (XP) was the simplicity of the roles defined in the Green Book.  In XP, there are only two roles: Customer and Programmer.  When you are using XP, the Customer makes business decisions, Programmers make technical decisions and one role may not substitute their judgement for the other.  In short, Programmers do not make business decisions and Customers do not make technical decisions.  Kent Beck and Martin Fowler even went so far to add a Bill of Rights, which clarifies what people can expect for one another.

  Scrum does not have anything similar, so I decided to create my own (modeled on the XP rights).  Feel free to distribute and share.

  Every Team member has the following rights:

  • To produce quality work at all times.
  • To know what is needed from the business with clear declarations of priority.
  • To ask for, and receive, help from peers, management, and customers.
  • To experiment with new ideas, technologies and roles to grow both as a professional and an individual.

  Every Product Owner has the following rights:

  • To receive the greatest possible value out of every week.
  • To know what can be accomplished by the Team, when and at what cost.
  • To see incremental progress in a viable product proven to work by passing acceptance criteria they specify.
  • To be informed of schedule changes promptly in order to take effective countermeasures and reset expectations with the stakeholders.
  • To collaborate with the business on setting the future direction of the product.

  Every ScrumMaster has the following rights:

  • To try out different ideas, approaches and techniques to remove impediments which impede the flow of value.
  • To be given time for initiatives to take hold and produce change.
  • To take measured risks and learn from setbacks.
  • To be supported by senior leaders in the organization.
  • To be provided access to different parts of the business while identifying and removing impediments.

  Every Stakeholder has the following rights:

  • To receive regular status updates through interacting with a working product.
  • To change their mind, substitute functionality, and adjust priorities without paying exorbitant costs.
  • To cancel the product at any time and be left with a working product providing real business value reflecting the investment to date.

• Combining Scrum Roles

  Date: 2011.01.22 | Category: Product Owner, Scrum, ScrumMaster | Response: 5

  This question started an interesting exchange on the Scrum Development list at yahoo!

  The Scrum Guide states that a person can be “Team Member” and “Scrum  Master”, a ”Team Member” and “Product Owner” but emphatically rules out  ”Scrum Master” and ”Product Owner” roles by one person.  I understand that all these “role combination” lead to one person being  split between two set of duties that are required to be performed. But  why does only the “SM & PO” combination find particular mention as  not acceptable.

  The way I teach the Scrum roles is that the Product Owner is responsible for the business outcomes and the ScrumMaster is responsible to ensure the process is implemented correctly and improves the flow of value.  These responsibilities require very different skill sets and it is rare that all are in one person or that one person wants to learn them all.  When the two are combined, one is responsible for doing the work of two people in an 8 hour day – which is then a violation of the Agile principle of sustainable pace.

  IMO, I often see people wanting to combine ScrumMaster with Product Owner or as a Team member, i.e. continue as a contributor.  As a friend of mine pointed out to me, this desire to combine the roles often speaks to hidden assumption\perception that there really is not enough stuff for a fulltime ScrumMaster.  Some people look at the framework and think: “ScrumMaster facilitates some meetings (check), updates Burndown chart (check) and does self-organization (check), not enough here to justify 100% allocation.”

  Oh how wrong!  Being a ScrumMaster is a full time job.  First, one has to help the Team become self-organizing.  That is a lot of work, requires close proximity to the Team and many hours of observation.  It is not something you can “phone in“.  Second, as ScrumMaster you are accountable to the stakeholders to improve the flow of value and help remove the organizational waste, i.e. impediments.  A lot of that effort is building relationships with different stakeholders and participating in efforts to remove organizational roadblocks (sometimes called kaizen).  You cannot be writing code, doing design or however you contributed in the past, if your responsible for identifying and removing impediments.

• Scrum Roles Defined

  Date: 2011.01.21 | Category: Product Owner, Scrum, ScrumMaster, Team | Response: 3

  I do a lot of work with Scrum and the ones that struggle the most are the ones where the Scrum roles are poorly defined and\or not filled properly.  Scrum is a balanced framework and when the roles get muddled, the framework begins to adopt the dysfunctions of the organization and is not as powerful as it could be.

  In Scrum there are three roles – Team member, Product Owner and ScrumMaster.  Those three working together are called the Scrum Team (or just the Team).  I add a fourth role – Stakeholder – to recognize all the people who orbit a Scrum Team and influence them.  I define all these roles like this:

  1. Team: dedicated collection of self-organizing, interdependent, co-located individuals representing different functional roles with all the necessary skills to turn Product Backlog items into a potentially shippable increment within the Sprint.
  2. Product Owner: an empowered individual applying their personal and professional judgment to make decisions in the best interest of different,often times competing, business stakeholders to maximize the business value the Team produces each Sprint
  3. ScrumMaster: a dedicated individual responsible for improving the performance of the Team and the business by any means necessary.
  4. Stakeholder: any person who has a direct, or indirect, interest in the work of the Team.

  Keep in mind, these are role definition, not job descriptions and they are very loosely defined.  It is important that each role is filled.  In general, the Product Owner is concentrated on the providing valuable business outcomes to the business, while ScrumMaster is aiming his\her efforts at the execution of good Scrum and improving the flow of value to the customer.  Meanwhile, the Team remains centered on learning how to self-organize and deliver potentially shippable increments regularly.  Stakeholders provide feedback on the value of everyone’s efforts.

  When Scrum falters, it is often because people are not committing to their roles.  Other times, organizations chose to overload one, or more, roles in a single person, disrupting the balance of the roles.  Recall, the Scrum framework was designed to provide the maximum amount of flexibility with the minimum amount of control.  If these roles cannot be filled  with individuals who will fully inhabit them, or they are overload, the control mechanisms of Scrum become unhinged, visibility is diminished, accountability is lost and the framework loses its meaning.

  When Scrum is done well, there exists a natural tension between each role.  This tension exerts a force that tends to prevent the other roles from meddling in responsibilities that are not their own.  Since there are considerable gray areas on the role boundaries in Scrum, each role will eventually bump into one another as they discover what are the boundaries of their responsibilities.  This friction is an essential part of learning how to do Scrum and making it meaningful to your business.  Through the of process of inspect-and-adapt, the precise definition of each role – Team member, Product Owner, ScrumMaster and stakeholder – emerges as your organization gains experience using Scrum.

  One of the main reasons why I add a Stakeholder role to Scrum is because many Scrum implementations improperly keep these people out of the process.  Scrum was not designed to keep the Stakeholders from interacting with the Team.  In fact, Scrum was designed to bring these folks closer together.  What Scrum tries to do is give the Stakeholders a more meaningful, structured way to interact and provide the Team with feedback via the Sprint Review.  This is the opportunity for the Team to hear direct, unvarnished feedback on what they really think.  This is why Stakeholders have a dashed line connecting themselves with the Team, rather than a solid line.

• Reading a Release Burndown Chart

  Date: 2010.11.08 | Category: Agile, Communication, Planning, Product Owner, Scrum, ScrumMaster, Tools | Response: 1

  In Scrum, we use a lot of easy-to-understand tools to communicate status.  A very common tool is a burndown chart.  In this diagram, I am showing a sample Release Burndown chart for a Team with eight Sprints in their release and will talk about how this is commonly used on a Scrum Team.  At the start of the release, the Team estimated 130 units of work would be delivered in eight Sprints.  At the end of Sprint #1, they delivered twelve units of work (the green bar) and 118 units remained (the red bar).  As the release progressed, a little more of the Product Backlog was delivered by the Team in the next two Sprints.

  In Sprint #4, the scope of the release increased by thirteen units (the yellow bar) and the Team only completed three units of added functionality.  In the figure, one can see the velocity of the Team increased during Sprints #5 and #6, completing twenty and twenty-one units of work, respectively.

  At the end of Sprint #6, it was clear the scope of the release was too large for the Team to complete before the deadline.  The Team’s velocity of twenty-one units per Sprint and the concept of yesterday’s weather, indicated the Team would not burndown all the remaining work before the end of Sprint #8.  As a result of this data, twenty-five units of low business value Product Backlog items were dropped, or descoped, from the release by the Product Owner.  When Sprint #8 was completed, nine units of work remained, but it had marginal business value.

• New Offering – Innovation Games®

  Date: 2010.09.02 | Category: Agile, Collaboration, Design Excellence, Games, Innovation Games, Product Owner, Scrum, Tools, Voice of the Customer | Response: 1

  On May 6^th and 7^th, I attended an Innovations Games^® consultant’s class hosted by Luke Hohmann.  Innovations Games^® are collaborative games designed to help business people develop and prioritize new product ideas.  In the context of Scrum, these games are tools the Product Owner and product designers can use to engage the customers and different business stakeholders in defining the requirements for a product and thinking about product roadmap and multigenerational release plan.  Not a lot is written about the “fuzzy front-end” for Scrum teams and Innovations Games^® fill that significant gap in way that is consistent with the Scrum values and principles.

  It was quite instructive to hear about the games and how they work from Luke.  From the different case studies discussed, we really illuminated the dynamics involved with selecting the right game for problem.  In addition, a few of my misunderstandings about the purpose of the games and how they are played from reading the book were cleared up as well.  What I liked most about the class was in addition to talking about the games, we played a lot of them in the course of two days.

  1. Remember the Future (played)
  2. Prune the Product Tree (played)
  3. Speed Boat (played)
  4. Product Box (played)
  5. Buy a Feature (played)
  6. 20-20 Vision (played)
  7. Show and Tell (played)
  8. The Apprentice
  9. Start Your Day
  10. Spider Web
  11. Me and My Shadow
  12. Give Them a Hot Tub

  Below are pictures of the Product Box I created for Look Forward Consulting announcing the new service available.  I look forward to using these games more and helping Scrum teams with improving prioritization and collaboration with their customers.

  

  

• Why I Want to be a Certified Scrum Trainer

  Date: 2010.07.26 | Category: Personal, Product Owner, Scrum, ScrumMaster | Response: 2

  I am very excited about this post because it represents a new direction and a deeper understanding of what I want to do with my business.  As many of you may be aware, the process to become a Certified Scrum Trainer (CST) has been undergoing some change lately.  It has been interesting to watch the process evolve and I wanted to make my intentions public after completing two of the five co-trainings suggested by the process.  It has been a great honor to co-train with Tobias Mayer and Lyssa Adkins and I have learned a great deal about training, communicating effectively, improvisation and being authentic.  Thank you very much for your mentoring, time and sharing.

  In 2007, as an internal coach for a large biotech company in San Diego, I was asked to create two-day ScrumMaster training modeled off the Certified ScrumMaster (CSM) curriculum.  In this class, I covered the basics of the Scrum framework and some common tools\add-ons used by Agile teams like user stories, estimating and release planning.  Over the course of eighteen months, I trained over forty people on the Scrum framework and coached a number of Scrum internal teams.  While I was able to teach the rituals, roles and artifacts of Scrum, I felt something was missing.  For the longest time I was puzzled why many of the students were just not embracing Scrum in their day-to-day work.  Clearly they had a problem, but it was just not obvious where it originated from.

  Recently, I have come to a new understanding of what Scrum means to me and reevaluate what I had considered valuable in the past.  After some reflection I have come to realize the problem did not lie with the students, but with the information the instructor provided them and how they were instructed.  At the time, I had thought Scrum was simply an effective framework for getting things done, just another another bag of tricks for good project management and it was taught as such.  Today, I understand that Scrum is about cultural change and establishing new values in an organization.  If Scrum is about values, then the focus of the education should be about the values and principles of Scrum.

  This has been a profound change in my thinking about Scrum and has altered the way I interact with Teams.  In the context of the CSM class, I have revamped the curriculum away from the standard Powerpoint presentation describing the Scrum rituals, artifacts, roles with me as the center of the course to a participatory, collaborative exploration of the Scrum values and principles, making connections to the Scrum framework with the learners at the center.  The result of this change is a CSM course that concentrates on the Scrum values of respect, openness, courage, commitment and focus, generates discussion of how those values are important to the learners and assists the students in making connections of these values to their lives and Scrum.  When the conversation shifts to instruction about the Scrum framework, roles and commonly used Agile tools, they are explained in the context of the Scrum values and as further illustrations of the values in action so they become real and tangible for the participants.

  In my opinion, the role of the CST in CSM, or Certified Product Owner, class is to guide the learners through a series of collaborative exercises and discussions to examine what the Scrum principles and values mean to them, why they are important to the framework and begin to connect the participants to the meaning of Scrum.  I feel the students bring with them a great deal of knowledge and life experience to each class and my job as a CST would be to create an environment where they can self-organize around their own knowledge and then guide them into a fuller understanding of how Scrum works based on their needs.  The peer-to-peer learning environment I am trying to create provides students the opportunity to learn from each other, respects and draws upon their years of professional and personal experience and turns them into active participants in their learning.  Essentially, I see myself as the participants’s ScrumMaster in learning.  I feel this learning experience better equips the students with the ability to facilitate and improvise Scrum in their organizations because they operate from a definition of Scrum that matches their own life experience, not the instructor’s.  In addition, this instructional model where the instructor leaves the center and allows the learners to take this space, allows the participants to observe how the role of ScrumMaster is done well.

• Best Links of the Week – July 16th 2010

  Date: 2010.07.16 | Category: Agile, Collaboration, Links of the Week, Product Owner, Scrum, ScrumMaster, Team, Transitions | Response: 0

  Passing on some good summer reading.

  1. Core of Agile and Scrum – essential principles of Agile and Scrum that transcend the software development.
  2. Three Legs to an Agile Transition – George Dinwiddie looks at how teamwork, visible progress and continuous improvement are key to change organizational culture.
  3. Why Multiple Product Owners is a Bad Idea – read the article to find out how having multiple people setting priorities short circuits the role.
  4. Nobody Can Do Agile – Simon Bennett explains why Agile is about thinking, not doing.
  5. Agile Requires Cross-Functional Teams – Johanna Rothman discusses why cross-functional teams are essential for Scrum and other Agile processes.
  6. Sir, Please Step Away From the Team – common the changes in management style for managers when Agile teams start in your organization.
  7. Story Time! The hidden Scrum meeting – ever wonder when the requirements and the analysis happens on a Scrum Team?
  8. How Does a PM and SM Coexisit? – a reader asks Michelle Sliger how the role of the project manager changes with the introduction of ScrumMasters.
  9. Truly Agile CMMI – a short blog and video about a company that gets both Agile and CMMI.
  10. Millennials and Scrum, Made for Each Other – Lyssa Adkins talks about how the Scrum values and principles align with a new cohort entering  the workforce.

• Speaking at Orlando Scrum Gathering – Mar 9th 2010

  Date: 2010.02.23 | Category: Conferences, Design Excellence, Lean, Presentations, Product Owner, Pugh Concept Selection, Scrum | Response: 0

  Finally had a few moments to write about my upcoming speaking engagement at the Orlando Scrum Gathering from March 8th to March 10th.  I am VERY excited about the chance to speak at a Scrum conference and I was lucky enough to be selected to provide two presentations in Orlando.

  1. Prioritization with Pugh – this workshop is designed to provide Product Owners a new tool to help evaluate conflicting priorities and focus the discussion on factors that matter to the business by using a Pugh matrix.  Pugh matrices come from the Lean world and are an excellent collaboration tool to resolve conflicts from conflicting stakeholders.
  2. Insights Into Scrum Illuminated by Lean – this Pecha Kucha will focus on how we can learn more about the essential elements of Scrum by looking at the Lean principles embedded natively in Scrum.

• Best Links of the Week – Feb 1st 2010

  Date: 2010.02.01 | Category: Agile, Communication, Extreme Programming, PMI, Product Owner, Scrum, ScrumMaster | Response: 0

  Here are two weeks worth of linkie goodness for everyone.

  1. 4th Annual State of Agile Survey - VersionOne, an Agile project management tool, has published their annual survey on the adoption of Agile; a great source of industry statistics and window into how other companies are using Agile.
  2. From Waterfall to Agile – in this 16-minute video Ian Culling, the CTO of VersionOne, talks about the Agile journey and common pitfalls he has observed.
  3. Scrum for Managers – in this 90-minute talk Mitch Lacey, CST and (former) Microsoft PMP, gives an excellent overview of Scrum and the new role for managers.
  4. Protect People - Jurgen Appelo discusses the role of managers in creating a safe interpersonal environment so self-organizing teams can form and flourish.
  5. Tips for First-Time Scrummasters – pitfalls to look out for on that first Scrum project.
  6. Top 10 Estimation Practices in Agile – excellent, excellent summary of current practice on Agile teams today.
  7. Assessing Agile Readiness – a 20-minute video from Joshua Kerievsky discussing the process of kicking off Agile at your company.
  8. Getting Better Agile Transitions - Mike Sutton describes some factors to consider when selecting a coach to help your company become more Agile.
  9. 10 Rules for Better Management – a short checklist on ways to become a better manager; I like to item on control charts.