“Meet: Scrum”, the Diagram

Recently, in my work helping teams to learn and implement Scrum, I have deliberately not been using diagrams.  Having participants create their own ways of describing Scrum based on their own understanding is often a much more powerful approach to learning than showing them a diagram.  If you give someone a map, they tend to assume that all of the exploring has already been done.  If you give them a space to explore, they tend to create their own maps and provide new knowledge about the space being explored.  Maps and diagrams do serve a purpose.  They are useful.  What’s important to always keep in mind is that they should not be regarded as definitive but rather as one  contribution to a body of knowledge that can and should grow.

Anyhow, this isn’t intended to be a blog post about diagrams but rather as a post sharing a diagram that I have created.  One of the participants of a Scrum training that I recently facilitated asked me for a diagram and I said I would find one for him.  All of the other diagrams out there that I could find didn’t exactly convey my own understanding of Scrum.  So, I decided to create my own.

This is the first increment.  I am open to feedback and I look forward to finding out how this interacts with others’ understanding of Scrum.

ScrumDiagramTravisBirch

You can download it at this link: Meet: Scrum.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Great little presentation on Retrospectives… and a bonus download!

If you are a ScrumMaster or Coach or Project Manager or Process Facilitator of any kind, I encourage you to become a master of Retrospectives.  I just happened upon this great little set of slides and presentation notes about Retrospectives by a couple of people, Sean Yo and Matthew Campbell, done a couple months ago.  Very helpful with some practical information, some great links… I strongly recommend checking it out.  My only concern is that they limit the scope of retrospectives too much.  I have a list of topics that I think can and should be considered in a retrospective:

  • Technology / tools
  • Work space / physical environment
  • Corporate culture
  • Corporate standards and policies
  • Teamwork
  • Work planning and execution
  • Skill sets
  • Interpersonal dynamics
  • External groups
  • Personal circumstances and needs
  • The process you are using

 

This list comes from a presentation I used to include as part of my Certified ScrumMaster course.  (Now, in my course I teach three specific methods of doing retrospectives as part of an in-depth simulation exercise.)  Here is a PDF version of the Retrospectives Module.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Updated: Agile Estimation with the Bucket System

I have added a pdf download of this article about Agile Estimation with the Bucket System.  It’s just a handy, nicely-formatted document that can be used for quick reference.  It is now part of the materials I give out for my Certified ScrumMaster training classes.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Real Agility Program – Leadership Transformation Team

One of the main components of our Real Agility Program for enterprise Agile transformations is the Leadership Development track.  This track is a series of monthly leadership meetings with one of our consultants to help them establish their Leadership Transformation Team.  This team is based in part on the concept of a guiding coalition from John Kotter’s work (see “Leading Change“), and in part on Edgar Schein’s work on corporate culture (see “The Corporate Culture Survival Guide“) as well as our own specific experience on successful Agile transformations in organizations.

The very first thing, of course, is to establish who should be on the Leadership Transformation Team.  There are six major categories from which the team must find representatives:

  1. The Executive Sponsor, for example the CIO
  2. Business Management, for example an SVP of Sales or Product Development
  3. Process Management, for example the head of the PMO or Compliance
  4. Technology Management, for example VP of Technology or Development
  5. Human Resources, for example a Director of Staff Development and Training
  6. and Apprentice Agile Coaches / Agile Champions

In total, the number of people on this team should be no more than 12, but smaller is better.

Once established, this Leadership Transformation Team must execute on three core responsibilities in perpetuity:

  1. Urgency and Vision: constant, strong, repetitive, prominent communication of the reasons for change and a high level view of how those changes will happen.
  2. Lead by Example: use of an Agile approach to run the Leadership Transformation Team’s work – we recommend OpenAgile for the process, but Kanban may also be used.
  3. Empower Staff: focus on removing obstacles by making structural changes in the organization, helping staff master standard Agile processes and tools, and eventually, creating innovative Agile approaches customized for the organization.

This leadership support is a critical success factor for an Agile Transformation.  One of the first steps in our program for this team is to help with the creation of the team’s plan for the transformation.  This plan can be derived from an number of sources including assessment work, but includes a number of standard items that must eventually be addressed for a successful transformation.  At a high level, these include:

  • Hiring, performance evaluation and compensation
  • Reporting relationships
  • What to do with project managers, business analysts, testers and certain middle managers
  • Key metrics and processes for measuring progress
  • Technology and physical environment
  • Vendor relationships and contracts
  • Compliance, regulation and documentation

Many of these items are multi-year change efforts that need to be closely guided and encouraged by the Leadership Transformation Team.

One final point about the Leadership Transformation Team needs to be made: the work they do must not be delegated to subordinates.  If something is part of their three core responsibilities, it must be handled directly by the members of this team.  Therefore, the team members need to allocate a significant percentage of their time to the effort.  Usually 20% is sufficient to get started.  The proportion may wax and wane slightly over time, but if it gets too low, the Leadership Transformation Team will lose touch with the transformation and the risk of it going bad increases substantially.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

User Stories and Story Splitting

In Scrum and other Agile methods, a common way to manage feature requests is with User Stories.  I’ve been teaching people about User Stories and doing workshops with teams for a long time.  Out of that work, I’ve created a very simple PDF User Stories and Story Splitting reference sheet that might be handy.  Please feel free to download it and share it.  This document is something that I explain in-depth in my Certified Scrum Product Owner training seminars.

There are a number of sites out there that include some details that are left out of the reference.  Please see, for example, “Patterns for Splitting User Stories” by Richard Lawrence.  See also the great foundational article on “INVEST in Good Stories” by Bill Wake.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: Agile Coaching Patterns Wiki

Coaches for Agile teams and organizations is a growing profession.  I’ve been coaching for a long time, and I’ve used/invented/learned-about many different techniques or interventions for coaching in the context of Agile teams.  I have recently started a Wiki to capture some of this information.  (Originally, I was hoping to write a book, but I don’t have the time to do it on my own or even to coordinate a multi-author effort.)  This is an open invitation to participate in the wiki.  I won’t make it fully open (like wikipedia), instead, it will be by invitation.  Connect with me on LinkedIn and mention you would like to contribute, and I will set you up with an account… and then you can go nuts :-)  If there end up being several contributors, I’ll make a block on the front page for links to contributors and/or their organizations.

Check out the Agile Coaching Patterns wiki.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Estimation with the Bucket System

Estimation – The Bucket System [pdf] – printable reference version of this article.

The “Bucket System” is a way to do estimation of large numbers of items with a small to medium sized group of people, and to do it quickly.  The Bucket System has the following qualities which make it particularly suitable for use in Agile environments:

  • It’s fast!  A couple hundred items can be estimated in as little time as one hour.
  • It’s collaborative.  Everyone in a group participates roughly equally.
  • It provides relative results not absolute estimates (points vs. hours).
  • The results are not traceable to individuals and so it encourages group accountability.
  • Works with teams to estimate effort or with stakeholders to estimate value.

BucketSystem3

The Bucket System of estimation works as follows:

  1. Set up the physical environment as per the diagram below.  Ensure that all the items to be estimated are written on cards.
  2. Choose an item at random from the collection.  Read it to the group.  Place it in the “8″ bucket.  This item is our first reference item.
  3. Choose another item at random from the collection.  Read it to the group.  The group discusses its relative position on the scale.  Once consensus has been reached, put the item in the appropriate bucket.
  4. Choose a third item at random and, after discussion and consensus is reached, place it in the appropriate bucket.
  5. If the random items have clearly skewed the scale towards one end or the other, re-scale the items (e.g. if the first item is actually very small and should be in the “1″ bucket).
  6. Divide and conquer.  Allocate all the remaining items equally to all the participants.  Each participant places items on the scale without discussion with other participants.   If a person has an item that they truly do not understand, then that item can be offered to someone else.
  7. Sanity check!  Everyone quietly reviews the items on the scale.  If a participant finds an item that they believe is out of place, they are welcome to bring it to the attention of the group.  The group then discusses it until consensus is reached and it is placed in one of the buckets.
  8. Write the bucket numbers on the cards so that the estimates are recorded.

Bucket SystemSome important points to consider:

  • Multiple items can be in the same bucket.
  • Items cannot be placed “between” buckets to represent a more precise estimate.
  • If the distribution of the items is skewed to either end of the scale, then during the sanity check step the group should also discuss if the items can and should be spread out more evenly along the scale.  If so, then the group does it collectively.
  • The facilitator should watch to make sure that no one moves items that have already been placed until the “sanity check” step.
  • The division of items among participants does not need to be exactly equal – don’t worry about “dealing” out the items.  Instead, just divide them up roughly.
  • If the “divide and conquer” stage has one or two people working very slowly through their items, it is acceptable to suggest that they share their remaining items with people who are already finished.
  • It is not acceptable for an individual to completely abstain from the process.  If someone desires to abstain, they should be counselled that this means they will not have any future say in the estimates.
  • During the “divide and conquer” stage it is critical that absolute silence is maintained.  In particular, there should be no bilateral discussion of items.  This is to protect the anonymity of individuals placing items as much as possible.

The Bucket System

 

The bucket system is a good alternative estimation method to try instead of Planning Poker.  It is much faster than Planning Poker and still gets reasonable results.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I do not track my hours or my “actual” time on tasks

Scrum considers tracking the time individuals spend on individual tasks to be wasteful effort.  Scrum is only concerned about time when it comes to the time boxes of the Sprint and Sprint meetings.  Scrum also supports sustainable development, which implies working sustainable hours.  When it comes to the completion of tasks, the team is committed to delivering value.  The tasks in the Sprint Backlog represent the remaining tasks that the team has identified for delivering on its committed increment of potentially shippable value for the current Sprint.  The tasks themselves have no value and therefore should not be tracked.  Scrum is only concerned about burning down to value delivered.  Time spent on individual tasks is irrelevant.  What if I track my hours or my “actual” time on tasks?  This promotes a culture of “bums in seats” – that it is more important for people to be busy at any cost instead of getting valuable, high-quality results.  This also promotes bad habits such as forcing work into billable hours even though it is not.  Overall, time tracking in a Scrum environment does much harm and can undermine the entire framework.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: No member of my team reports to me

Inside the Scrum Team, including the Product Owner and the ScrumMaster, no individual should report to any other individual.  The team reporting structure should be flat.  This does not necessarily mean that all Team Members are peers in the org chart.  For example, one team member could be quite senior, and another quite junior.  However, for the Scrum principle of self-organization to work effectively, individual Team Members should have no concern about what their “boss” wants them to do.  Instead, within the Scrum Team, there should be a completely safe environment for individuals to volunteer for tasks, raise obstacles, provide candid feedback to any other Team Member, and have a mutual sense of commitment to the work of the team.  If the Scrum Team is absent of reporting relationships then it has a much higher chance of becoming a high-performance team.  If there are reporting relationships within the Scrum Team there are often significant obstacles to full openness and self-organization and this, in turn, will significantly hamper the performance of the team.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I never tell any other individual team member which task to work on next

All tasks done by individuals on a Scrum Team must be chosen voluntarily.  If one Team Member, in any way, tells another Team Member what task to work on, this breaks the principle of self-organization that is essential to creating a high-performance Scrum team.  Team leads, project managers, functional managers and other people in roles of authority to assign tasks must give up that authority completely when it comes to the people on a Scrum team.  This self-organizing behavior allows individual team members to consider their own talents, capacity, interest, motivation etc., when choosing a task.  All of those inner conditions are not as well known by other people and so assigning tasks tends to be sub-optimal.  When a Team Member considers those inner conditions about him or her self, and also takes into consideration the needs of the team, an optimal task choice can be made.  If someone in a position of authority does assign tasks, it creates a habit of deferring to authority which quickly destroys any possibility of a high-performance team developing.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I attend every Sprint Retrospective Meeting in-person

The Sprint Retrospective meeting supports the Scrum value of Openness and the principle of inspect and adapt.  This rule of Scrum also aligns with the Agile Manifesto principles “at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”  In-person attendance of all Scrum Team members allows for the fullest level of openness among Team Members which in turn is necessary to use the Retrospective to find improvements in how the team functions.  If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the openness and inspect and adapt becomes compromised. Compromise on these principles yields compromised collective ownership of improvement efforts. Lack of in-person participation increases the likelihood that the team will fail to implement improvements because the openness and inspect and adapt will lack effectiveness.  This, in turn, hinders the team from reaching a high-performance state.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I attend every Sprint Review Meeting in-person

The Sprint Review meeting supports the Scrum value of Openness and the principle of inspect and adapt.  This rule of Scrum also aligns with the Agile Manifesto principles “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation” and “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”  In-person attendance of all Scrum Team members allows for the fullest level of openness among Team Members and effective communication of feedback from stakeholders reviewing the product increment.  If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the openness and inspect and adapt becomes compromised. Compromise on these principles yields compromised collective ownership. The successful delivery of the valuable software requires full commitment on the part of the whole team. Lack of in-person participation increases the likelihood that the team will fail to deliver on its Goal because the openness and inspect and adapt will lack effectiveness.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I attend every daily Scrum Meeting in-person

The Daily Scrum meeting supports the Scrum value of Openness and the principle of self-organizing teams.  This rule of Scrum also aligns with the Agile Manifesto principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  In-person attendance of all Scrum Team members allows for the fullest level of openness among Team Members.  If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the openness and self-organization becomes compromised. Compromised self-organization yields compromised collective ownership. The successful delivery of the Sprint Goal requires full commitment on the part of the whole team. Lack of in-person participation increases the likelihood that the team will fail to deliver on its Goal because the openness and self-organization will lack effectiveness.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I attend every Sprint Planning meeting in person

This rule of Scrum aligns with the Agile Manifesto principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  In-person attendance of all Scrum Team members allows for the plan to unfold with minimal communication overhead and for the team to keep the meeting within the short time-box.  In-person attendance also allows the team to effectively collaborate in the work of creating the plan. The efficiency and effectiveness of the Product Owner’s presentation of the Product Backlog is optimized as well as the Development Team’s ability to collaboratively assess and select what it can and will accomplish in the Sprint. It also allows for everyone to be clear about the Sprint Goal and why the Development Team is building the increment. In-person attendance also allows the Development team to efficiently and effectively come to a decision as to how it will build the increment of functionality. In-person participation of all team members also increases the likelihood that the team will create the right design for the increment.  If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the planning becomes compromised. Compromised collaborative planning yields compromised collective ownership. The successful delivery of the Sprint Goal requires full commitment on the part of the whole team. Lack of in-person participation increases the likelihood that the team will fail to deliver on its Goal because the planning will lack effectiveness. People are prone to estrangement from hazy goals reached through ineffective planning. In-person planning, therefore, is paramount to succeeding with Scrum.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I live the values and principles of the Agile Manifesto in my team

The Agile Manifesto is the founding document of the Agile movement.  It can be found at http://www.agilemanifesto.org and if you haven’t read it, it is strongly recommended!  Living values and principles is an act of striving for excellence.  There are no mechanisms in Scrum to force people to live the values and principles of the Agile Manifesto. Scrum relies on individual team members to strive to develop an understanding and practice of Agile values and principles in and of their own volition.  If Team Members do not live the values and principles of the Agile Manifesto in their team many other things will take priority such as creating a complex document.  The team could think of Scrum as a tool for project delivery, without really working to change the culture of their organization.  Since Scrum empowers individuals and makes obstacles visible, if the team doesn’t live the Agile Manifesto principles then they may be disconnected from the roots of Scrum and make it a lesser version of itself, sometimes known as Scrumerfall (where you blend some elements of Scrum with other elements of waterfall which provides little to no benefit).

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail