Archive for the ‘Scrum’ Category

• What is a ScrumMaster?

  Date: 2012.04.04 | Category: Class Design, Scrum, ScrumMaster, Training | Response: 0

  I have been working with a colleague to develop a new course for ScrumMasters (and other Agile change agents) and we were talking about possible objectives for this course, who would attend and what is missing from our current offerings that this class could provide.  As we discussed these ideas we started to talk about just what is a ScrumMaster and what are they expected to do.  In my CSM classes, I use Bernd Schiffer’s “42 Tasks for a ScrumMaster” to explain the concept a ScrumMaster is a full-time job.  This is very useful, but does not identify what roles the ScrumMaster plays and my colleague and I had a very interesting dialogue on the various hats the ScrumMaster is expected to wear.

  1. Visionary – has a specific point-of-view and is passionate about what they see as the future for their team and organization.  As a visionary, a ScrumMaster could be an evangelist or an individual who possesses the calm confidence of knowing what they really want.
  2. Facilitator - while a ScrumMaster must have a point-of-view of vision, when they work with a self-organizing team they must be neutral.  When they are acting as the facilitator, they create the space for collaboration and self-organization to occur and refrain from providing content.
  3. Leader – since the ScrumMaster works in the space of “no authority”,  they need to draw followers to them through the power of their ideas, the strength of their conviction and the ability to communicate their vision.
  4. Mentor – one of the strengths of a ScrumMaster is that they care and respect the people they come into contact with each day.  In order to excel as a mentor, a ScrumMaster devotes much of their day building genuine, personal relationships with everyone they interact with.
  5. Teacher –  ScrumMasters need to possess a deep understanding of Scrum, be knowledgable on the current set of Agile variants (XP, Crystal, DSDM, Kanban, Lean for Software, etc.) and provide thoughtful answers on how to apply Scrum outside the lines.  I expect a ScrumMaster to be comfortable explaining Scrum in a variety of ways, in a variety of forums, to variety of roles and to a variety of people with different levels of understanding about Scrum and Agile.
  6. Coach - sometimes people need “an answer” and sometimes people need help finding the solutions to the challenges on their own.  A skilled ScrumMaster knows the difference and can regularly create effective coaching conversations which produce actionable results.
  7. Change Agent – Scrum is much more than a set of activities or practices we do at work.  Scrum is about change.  As a change agent, the ScrumMaster brings change to all parts of the organization and socializes the impact of change with stakeholders.
  8. Expert Communicator – Scrum is about having the more interesting conversation, the conversation that we need to have and about fostering a dialogue about how to improve.  To support this, the ScrumMaster must model the crucial skills necessary to start and maintain dialogue.

  One of the things we noticed in our conversation was this role of ScrumMaster does not exist in organizations today and many of these roles are in conflict with one another.  In most businesses today, there is no one person who does all these things.  Some people might do some of these activities sporadically but no one does all of them all the time.

• Fourteen Observations of Good Scrum Practice

  Date: 2012.03.21 | Category: Agile, Certified ScrumMaster, Personal, Scrum, Tools | Response: 0

  My courses are deliberately designed to exclude PowerPoint presentations and focus on the peer-to-peer interactions, but I recognize that a significant number of students need something physical to take from the class and review later.  In addition, there is no possible way for me to cover every topic the same way in a two-day CSM class, so I needed something for the learners to refer to as a reminder on how to do Scrum well.  As a result, early last year I wrote a book on Scrum – Fourteen Observations of Good Scrum Practice – as teaching aid for my CSM classes.  From the learners I have spoken with, they find the book to be a useful summary of the main concepts in the class, a handy reminder of what we discussed and short introduction to Scrum that they can share with other people at work.  When you attend one of my CSM class, you receive a complementary copy.

  I have a lot of interest in helping the Spanish speaking Scrum community grow and there is\was a complete lack of books on Scrum written in Spanish or English language books that had been translated into Spanish.  Now no more!  Earlier this year I published a Spanish translation – Catorce Observaciones para la Práctica de un Buen Scrum - of my book.  It was a lot of work, but now there is a high-quality book on the subject for Scrum for my Spanish speaking friends.  My translator, Diana Perez, was awesome and did a great job.

  Finally, I want to thank Chris Sims at Agile Learning Labs for inspiring me to write my own book on Scrum plus explaining to me how easy it is to publish a book on your own.  Without Chris’s inspiration, this book would not be widely available.

   

• The Perfection Game

  Date: 2012.03.06 | Category: Agile, Communication, Scrum, Tools | Response: 0

  I recently came across an awesome and challenging book – Software for Your Head by Jim McCarthy.  There are so many interesting things about this book.  One of the key tools I discovered I can use right away while reading the book was an amazing tool to provide feedback called the Perfection Game.

  The Perfection Game has two main gains.  One, to achieve perfect results by thinking and telling one another what you like and what would make the results perfect.  Two, to give feedback to another that is an affirming learning opportunity.  Since the Perfection Game comes from the Core Protocols, there is a very specific way it is played.  Here are the rules:

  1. The requester asks a responder(s), “Will you play the Perfection Game with me?”
  2. Next, the requester asks, “On a scale of 1 to 10, how would you rate [the item, action or event being considered].”
  3. The responder tells the requester what was good, or what they liked, about the requester’s item, activity or action that earned the score in the form of “What I like about it was [a… b… c…].”
  4. Next, the requester ask the responder, “What would have made it perfect?”
  5. The responders then tells the requester what specific actions are needed in the next iteration to make the item, event or activity perfect in the form of “What would have made it perfect for me was [x… y… z…].”
  6. Finally, the requester looks the responder in the eyes and says “Thank you.”
  7. Repeat steps 1 to 6 for all responders.

  As I stated earlier, following the protocol described in the Perfection Game is extremely important.  Purely or partially negative feedback (“constructive criticism”) is not allowed at any point in the Perfection Game.  As a responder, you must give the feedback to the requester verbally – there is no written feedback allowed.  If you cannot think of anything that will help the requester improve, the default score in the Perfection Game is a perfect 10.

  A word about the scale in the Perfection Game – the scale of 1 to 10 is not about dislike to like, where 1 is “completely dislike” and 10 is “completely like”.  Rather, the scale goes from “the object has no value” to “I can’t think of anything that would make it better”.  Keep in mind that as a responders if you give something an 8, you are saying that it is 80% perfect and as the responder you can tell the requester exactly what they need to do in order to gain the missing 20%.

  Finally, Jim and Michelle McCarthy also have a very interesting podcast discussing the origins of The Perfection Game and how they think about it.  Be sure to check it out and start playing the Perfection Game.

• The 4C’s

  Date: 2011.10.20 | Category: Certified ScrumMaster, Class Design, Scrum, Training | Response: 0

  Right before Agile 2011, I had the opportunity to co-train a CSM course with an awesome candidate to join the ranks of Certified Scrum Trainers, Karen Greaves.  One of the reasons why I was interested in training with Karen is that she has been applying many of the Training From the Back of the Room (TFBR) concepts that I have been very curious about and looking to apply in my course.  I was curious to see how another practitioner would take these concepts and use them to teach Scrum.

  The most visible benefit of my collaboration with Karen was for me to “4C” my training plan for my CSM course.  4C is an acronym that stands for “Connection, Content, Concrete Practice, Conclusion” and they are framework for an instructor to help design their class that  leverages TFBR and Accelerated Learning.  The 4C’s are described in more detail below:

  • Connections: This is the beginning or opening of a training.  It can also include pre-training time as well.  During the Connections step, learners make connections with what they already know, or think they know, about the training topic.  They also make connections with what they will learn or want to learn with the other learners in the training group, and with you, the trainer.
  • Concepts: This is the direct instruction, lecture or presentation part of a training,  During the Concepts step, learners take in new information in multi-sensory ways: hearing, seeing, discussing, writing, reflecting, imagining, participating and teaching it to others.
  • Concrete Practice: This is the active review that usually follows information delivery.  During the Concrete Practice step, learners actively practice a new skill using the new information, participate in an active review of what they have learned and again teach others what they know or can now do.
  • Conclusions: This is the wrap-up or closing part of a training.  It can also include post-training time as well.  During the Conclusions step, learners summarize what they have learned, evaluate it, make a commitment to use it at work or in their lives and end with a short celebration of their learning experience.

  From my experience with Karen and applying the 4C’s on my own, the framework offers instructors two powerful advantages:

  1. Your course immediately becomes modular.  Each learning objective  is achieved by connecting the learners to the topic, teaching them content, allowing them opportunities of concrete practice to try out the material on their own and closes with a conclusion before moving to the next learning objective.  Your course then becomes just a series of 4C’s that knocks down one learning objective after another.
  2. The 4C’s provide a fantastic diagnostic tool to help you improve your course.  Since the class is now modular, if a connecting activity is not working, you can switch it.  Content section is too long?  Move to concrete practice sooner.  As instructor, I felt that I had really good content and concrete practice exercises, but my courses were weak on connections and conclusions.  Look to Sharon Bowman’s book – The Ten Minute Trainer – for over 150 exercises and activities that help with these areas..

• Visit to Auckland Agile

  Date: 2011.10.06 | Category: Agile, Presentations, Scrum, Tools | Response: 0

  Just finished a trip to New Zealand and had a chance to speak at Auckland Agile on September 29th.  The session was another run of my “Removing Impediments with Drawings” that I have presented numerous times in the past year (the most recent at Agile 2011 in Salt Lake City).  I am not sure exactly, but I think we may have had about 40+ people in this session.  A lot less people than Agile 2011 and I thought the outcomes were better.  Glad I had a chance to meet with this group and share some ideas that might not have made it to their part of the world.

  I want to send a special thank you to my hosts for the evening Carolyn Sanders and Stephen Reed (@ScrumMasterNZ).  They completely took care of arranging for the venue, meeting me and taking me out for drinks afterwards.

• Upcoming Conferences

  Date: 2011.05.04 | Category: Agile, Conferences, Innovation Games, Presentations, Scrum, Tools | Response: 0

  Been really quiet these past months, but I wanted to share some upcoming places where you can see me in action.

  1. PMI San Diego Annual Conference – On May 13th, I will be giving a class on Estimating and Planning.  On May 14th, I will be giving a short tutorial on how to use Innovation Games to prioritize.
  2. San Francisco Agile Conference – my colleague and friend, Angeline Tan (@agilemeister), invited me to be a speaker at this conference she has been working very hard to organize.  On June 16th, I will be presenting Improve Flow Through Prioritization.

  You can still register for both the PMI San Diego Conference and San Francisco Agile Conference.

• 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.