The Real Agility Program – Execution and Delivery Teams

In a recent post, Mishkin outlined the Leadership Team component of the Real Agility Program.  While the Leadership Team track focuses on developing leadership capacity for sustained transformation, The Execution track focuses on launching and developing high-performance project, product and operational teams.  This track is the one that most of our clients use when they run Agile pilot programs and is a critical component of getting quick wins for the organization.

Groundbreaking works such as The Wisdom of Teams (Katzenbach & Smith), The Five Dysfunctions of a Team (Lencioni) and Drive (Pink) have served well to distill the essential requirements of high-performance teams.  Scrum, Kanban, and OpenAgile are proven frameworks that optimize the value of teams and create the necessary working agreements to help teams reach that high-performance state.

The Delivery Team track of the Real Agility Program creates new, cross-functional, multi-skilled, staff-level teams of willing individuals.  These teams are responsible for delivering value—business results and quality.  Individuals are committed to the performance of the team and the organization.  Teams develop the capacity to self-organize and focus on continuous improvement and learning.  A team is usually composed of people from various roles at the delivery level.  For example, and IT project team might be composed of people whose previous* roles were:

  1. Project manager
  2. Business analyst
  3. Software developer
  4. Tester
  5. Database developer
  6. Team lead
  7. User experience lead
  8. Intern

* These roles do not get carried into the new delivery team other than as a set of skills.

The track begins with establishing pre-conditions for success including executive sponsorship, availability of team members and management support.  Team launch involves a series of on-the-job team development workshops designed to enable the teams to create their own set of values, working agreements and high-performance goals.  Teams are guided in the creation of their initial work backlogs, defining “done”, estimation and planning and self-awareness through the use of a collaborative skills matrix.  The teams are also assisted in setting up collocated team rooms and other tools to optimize communication and productivity.

Qualified coaches assist the teams to overcome common issues such as personal commitment, initial discomfort with physical colocation, communication challenges of working with new people in a new way, management interference and disruptions and appropriate allocation of authority.  This assistance is delivered on a regular schedule as the team progresses through a series of steps in the Execution track process.  Usually, these steps take one or two weeks each, but sometimes they take longer.  A team that needs to get to a high-performance state quickly might go through the entire program in 10 or 12 weeks.  In an organization where there is not the same urgency, it can take up to a year to get through the steps of the track.

The coaches for this Execution track also help management to resist and overcome the strong urge to manage the problems of the teams for them.  In order to develop through the stages of team development, teams need to be effectively guided and encouraged to solve their own problems and chart their own courses towards high-performance.

The goal of the Execution track of the Real Agility Program is to help the team go through the stages of forming-storming-norming and set them up to succeed in becoming a high-performance team.  Of course, to do this requires some investment of time.  Although the Execution track is meant to be done as on-the-job coaching, there is a 5% to 20% level of overhead related to the Real Agility Program materials themselves.

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: Your Product Owner creates and maintains the team’s Product or Release burndown chart

The Product burndown chart tracks the amount of work remaining in the Product Backlog Sprint-by-Sprint. This burndown chart is updated every Sprint and is visible to the Scrum Team and its stakeholders. This activity is part of the Product Owners duty to facilitate transparency around value delivered over time. The Product Owner is responsible for making the overall progress of the work visible to the Scrum Team and other stakeholders. This activity is part of the Product Owners job to satisfy stakeholders as it allows them to easily see how the Scrum Team is trending on planned deliverables. This information allows the team and the Product Owner to discuss any necessary adjustments to the team’s plans for the upcoming Sprints in a timely fashion. What happens if the Product Owner fails to create and/or maintain the team’s Product burndown chart? Most likely we will be unable to see if the team is on track, late or early in its delivery of value. In a traditional waterfall approach we would find out this information near the end of the project which is much too late. Also, without regular updates on the trend of the team it is highly probable that stakeholders and/or team members may slip back into an individualistic approach to work instead a team based approach.

To learn more about Product Owners, visit the Scrum Team Assessment.

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: Your Product Owner puts known defects at the top of the Product Backlog

The Product Owner has complete authority over the ordering of the Product Backlog. However, it is strongly recommended that the Product Owner put all known defects at the top of the Product Backlog so that the Team fixes them in the very next Sprint. By defects is meant features of functions of the system that have been built by the Team in previous Sprints where those features or functions do not behave according to the expectations of the Product Owner and where such mis-behavior is exposed to users of the system. There may be other quality problems with a system which are not categorized as defects (e.g. duplicated code). This prioritization of defects generally results in extremely high levels of quality in a system and a long-term reduction in costs for the system (total cost of the system) by making future features easier to add, and reducing effort spent on maintenance and support. Failing to put defects on the top of the Product Backlog generally leads to decreasing overall quality and in particular can severely damage the morale of a Scrum Team thus preventing them from getting into a high-performance state.

To learn more about Product Owners, visit the Scrum Team Assessment.

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: Your Product Owner never interrupts the team mid-Sprint with new “high-priority” Product Backlog Items

The Product Owner is involved with the other Team Members throughout the Sprint, but after the Sprint Planning meeting is completed, the Product Owner cannot add to the scope of the work being done during the Sprint. New Product Backlog Items, no matter how high their priority, must be put onto the Product Backlog for the team to look at in the next Sprint. This restriction is meant to allow the team to truly be focused and committed to the work of the Sprint and to allow them to make commitments and learn to keep them, thereby building trust. The Product Owner can, of course, collaborate on the details of the PBIs the team has chosen for the Sprint. If the Product Owner does indeed force a team to take on extra work during the Sprint, it breaks the focus of the team and can lead to the team’s failure to complete the work they planned.

To learn more about Product Owners, visit the Scrum Team Assessment.

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: Your Product Owner always lets the team freely decide how many Product Backlog Items to do in a Sprint

The Product Owner controls the order of the items in the Product Backlog, but not how many are done each Sprint. Instead, the team decides how many to do. This decision is made in Sprint Planning and, of course, should be made in collaboration with the Product Owner, but ultimately the Product Owner must let the team freely decide how many items are planned. This freedom allows the team to be truly motivated and committed to the work as well as being collectively accountable for getting that work done. If the Product Owner forces a team to take on more work than it feels is within its capacity, then that dis-empowers the team, moves accountability for getting work done to the Product Owner, and completely dis-ables the team from getting to a high-performance state.

To learn more about Product Owners, visit the Scrum Team Assessment.

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: Your Product Owner refines the Product Backlog so it is ready for each Sprint Planning Meeting

The Product Owner is responsible for maintaining the Product Backlog. This includes its ordering in terms of value and effort, its clarity, and identification of what acceptance criteria apply to each Product Backlog Item. It is also very important for the Product Backlog to be ready for each Sprint Planning Meeting so that the team can select the Items for the current Sprint and break those down into tasks. If this is done, the team is able to create an effective Sprint Backlog where it can volunteer for tasks and achieve quick wins each day. If not, the team will likely take on the work of refining the Product Backlog during the Sprint Planning Meeting which is wasteful and not focused. Having a ready Product Backlog helps the team focus during its meetings and ask relevant questions to the Product Owner.

To learn more about Sprint Planning Meetings, visit the Scrum Team Assessment.

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: Your Product Owner can veto the inclusion of an idea on the Product Backlog

The Product Owner is responsible for ensuring that the Product Backlog Items reflect and contribute to the vision of the product being built by the Scrum Team. Therefore, the Product Owner needs the authority to reject any suggestions for features, functionality or fit and finish that do not move the product towards that vision. This authority must be based on both the depth of knowledge of the Product Owner as well as formal responsibility granted by the organization. A Product Owner that does not have this authority to veto may nevertheless be able to accomplish the same thing by putting any unwelcome ideas at the very end of the Product Backlog based on authority to order the Product Backlog. The lack of this authority to veto can lead to a product with no integrity of vision, an erosion of the Product Owner’s authority to order the Product Backlog, and ultimately an erosion of the critical separation of powers between the Product Owner and the rest of the Scrum Team (the Product Owner with authority over “what to build” and the rest of the team with authority over “how to build it”).

To learn more about Product Owners, visit the Scrum Team Assessment.

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: Your Product Owner is knowledgable about the product and the business

The Product Owner’s job is to be the customer or the customer proxy. He needs to know the most current information about the product and the business that the team is working in. If this is the case, then the Product Owner is able to make relevant choices about the product and will be able to answer the questions of the team. If this is not the case, then he will have to find someone else for the answers (which will cause waste), make up the answers (which will likely guide the team in the wrong direction), or fail to give the team what they need.

To learn more about your Product Owner, visit the Scrum Team Assessment.

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: Your Product Owner uses the Sprint Review to help the team continuously improve the product

The Sprint Review is a key meeting for the team to improve the product. There are three main purposes of the Sprint Review: inspect how the last Sprint went with regards to the product; identify the items that are complete and order any potential changes; and, integrate those changes into the Product Backlog. This meeting aids the team in inspecting and adapting the entire product increment and how the team is progressing towards any deadlines. The Sprint Review is a check point that helps the Scrum Team to know the product’s current state, compare to its desired state, identify gaps, and take the needed steps to improve. This meeting is also where the Product Owner challenges the Scrum Team to look at the product clearly (it’s not just for the stakeholders!). When a Scrum Team refrains from having and participating in this essential meeting, the is team is likely to become a Scrum Team in name only without any of the far reaching benefits that many other Scrum Teams have experienced. A demonstration of the Product Backlog Items completed in the Sprint is often a part of this meeting.

To learn more about the sprint review, visit the Scrum Team Assessment.

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: Your Product Owner is truthful about the condition of the product (its value scope and costs)

The Product Owner has the most recent and important information about the value and cost of the product being delivered. This information can greatly serve the team by allowing them to understand the product’s current state and how this affect where they will be going in terms of the vision of the product. If the Product Owner is able to carry this out then the team will have relevant information that will aid them in their decisions and execution of the product. If this is not carried out then the team will be in the dark – they will make poor decisions and struggle with the feedback given by the stakeholders since they have no transparency into the reality of the product.

For more information about Product Owners, visit the Scrum Team Assessment.

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: The Scrum Team Assessment

Over the past six months we have been working hard on launching a new product: The Scrum Team Assessment.  This tool delivers to you a valuable report full of practical advice on how your team can get better at Scrum… and deliver better results!  It’s like an automated Scrum coach.  All your team members will fill in a comprehensive survey, we collect the results, generate a report – and then we personally review it – and send it back to you.

For more information, please visit our Scrum Team Assessment site.

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 take direction for product vision and scope from my team’s Product Owner

As a Team Member, it is my job to figure out how to solve a problem or request that is stated by a Product Backlog Item (PBI), with the help of my team.  It is the responsibility of the Product Owner to give us the vision of the product and decide how much scope is to be done to satisfy the PBI.  One simple way to think about this concept is that the Product Owner is responsible for the “what” and “why” and the Scrum Team is responsible for the “how” and “who”.  If the Team Members decide on the product vision by themselves, they run the risk of misinterpreting features, moving down a path that is not valuable or even creating work disconnected from the needs of those who will be using the software.  If the Team Members choose their own scope they may do much less than is needed or much more than is required.  There is a balance in the Product Owner providing vision and scope, and the Scrum Team providing knowledge and experience in its execution.

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 know my product well and can quickly describe its high-level architecture

All Scrum Team Members, including the ScrumMaster and Product Owner, should understand the high-level technical aspects of the product that is being built.  As well, that understanding should be solid enough, that it can be communicated to other people.  This understanding helps the team members in many situations dealing with each other and with stakeholders.  Understanding the structure of the system is an aspect of Transparency.  This is essential for maintaining overall quality of the product. Development in one part of the product or system should never cause problems for any other part of the product or system.  If team members do not know their product in this way, it can cause significant problems in communication and in how Product Backlog Items are implemented.

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 know my product well and can quickly describe its high-level purpose

All Scrum Team Members, including the ScrumMaster and Product Owner, should understand the high-level business aspects of the product that is being built.  As well, that understanding should be solid enough, that it can be communicated to other people.  This understanding helps the team members in many situations dealing with each other and with stakeholders.  Understanding the purpose of the system is an aspect of both Focus and Transparency.  This is essential for maintaining overall quality of the product. Development should always be done in a way that moves the system towards fulfillment of its intended purpose.  If team members do not know their product in this way, it can cause significant problems in communication and in how Product Backlog Items are implemented.  Finally, and perhaps most importantly, understanding the overall purpose of work is critical for a team to become a high-performance team.  Without knowledge of this purpose, a high-performance team is impossible.

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: All PBIs are related to a single product (or system)

Scrum Teams work on one product at a time.  The Product Backlog represents all of the work that needs to be done on that single product.  The complete list of Product Backlog Items represents the goal of delivering all of the presently known features of a product.  Multiple teams working on a single product, therefore, work from a single, shared Product Backlog.  Working on Product Backlog Items from multiple Products causes the team to task switch into a different business domain and possibly into a different technical domain.  Task switching creates wasted mental effort and therefore causes a team to be less effective than they could otherwise be.  Having a single product to work on creates focus in both the business and technical domains.

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