Last week, Scrum.org and leaders in the Kanban community published a new guide. This guide helps articulate how Scrum teams can use Kanban to complement the Scrum framework. I blogged about this guide on the Agilethought site. Read my post, debunking three misconceptions about Kanban and Scrum.
Imagine that you’ve read the Scrum Guide’s description of Product Owner role. You see that in order to be effective, a Scrum Product Owner needs to
That takes a lot of time and energy. You realize that the role is so involved that you can’t possibly have your current “product owner” fulfill the Scrum duties as well. You are contemplating using a “Proxy” product owner to fulfill the Scrum Product Owner’s duties. The Proxy Product Owner will not be the real product owner, but they represent the product owner and have the responsibility for communicating the product owner’s perspective with the team.
To fulfill these responsibilities, of a Product Owner, the individual in the role must have the
Can a Proxy Product Owner be effective? Is it a good idea? Will that work? Let’s explore it a little bit.
Overworked Product Owners can neither keep the backlog groomed nor be available to the team.
An Indecisive Product Owner can kill the team’s momentum.
What is the danger of having a Proxy Product Owner? The danger of using a proxy is that it often masks organizational problems with the way the role is set up. Many times when I hear “Proxy Product Owner” used, it is used as a euphemism for one of these other types of Product Owner dysfunctions:
| The Ignorant Product Owner | They lack the knowledge necessary to fulfill the role. They are constantly having to go out and gather understanding from someone else who truly has it. Or, worse, they guess at the answer and inject wastefull activity into the team. |
| The Impotent Product Owner | They have no power to make decisions. They have to go play "mother may i...." with people who really make decisions. This delay negatively impacts the team. |
| The Indecisive Product Owner | They have all the information and authority to make decisions, but they're still incapable of deciding. The causes of indecisiveness vary, from fear of punishment for wrong decisions to over-analysis. |
| The Overworked Product Owner | This person simply has too much work for one human to do. It is impossible for them to keep the team supplied with a properly groomed backlog, leading to frustrating and ineffective Sprint Planning and delivery. |
A “proxy” is someone who can make decisions on behalf of another. If the person filling the Scrum Product Owner role can completely and truly fill all the responsibilities outlined in the Scrum Guide, then you truly have a Scrum Product Owner.
If the term “Proxy Product Owner” is sometimes used when somebody else in the organization has an existing title of Product Manager or Product Owner. When an organization adopting the Scrum framework already has a position description with the title “Product Owner,” role confusion can emerge. In those cases, it can be valuable to differentiate the Scrum Product Owner from the other duties that are wrapped into the existing title of Product Owner. In those instances, I prefer the term “Scrum Product Owner” versus “Proxy Product Owner.”
Regardless of the name for the role, make sure that the position is fully capable of fulfilling the responsibilities outlined in the Scrum Guide, allowing that person the best chance of being effective in the role.
What do you think? Please feel free to comment and let me know what your experience has been.
Have you ever wondered if what you are doing is “agile?” Sometimes the work you’re doing doesn’t feel like it has much “agile” to it, especially if you are being asked to do a specific set of work in a specific time frame. Damn you, iron triangle!
Your workplace isn’t “agile” or “not agile.” Certainly there are parts of your organization that will be aligned with agile principles, and there are some aspects that are likely not. This retrospective is designed to explore your organization’s alignment as it relates to agile.
Here is the outline of the retrospective. Feel free to adapt it as you see fit. If you do adapt it, please let me know what changes you made. If you use this retrospective, I would like to hear how it went. You will note that the general flow for this retrospective matches the outline in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen.
One word check-in. Consider something like “how did the last sprint feel?” This gets everybody to talk at least once.
The constellation exercise is a way to visualize the degree to which people feel a principle is present or absent from their work. Here is how to conduct this activity:
The facilitator reads one principle out loud, and then places it on the floor near the center of the room.
People then position themselves relative closer or farther from the statement based on how much they feel the principle is present in their environment (e.g., team, organization, company, whichever you chose). If somebody feels it is strongly present they would stand close to the principle you placed on the ground. If somebody feels it is not present or “anti-present”, they would stand very far away.
Give people a moment to observe the pattern and perhaps jot down anything they noticed.
Pick up the principle you just used, and move on to the next one. After all twelve principles have been read, move on to generating insights.
Ask people what they noticed about the constellations that took place during the Gather Data activity. Some question you might consider include:
Which of the principles were strongly present? Which were strongly absent?
What similarities or differences did you notice about those principles?
Which had the most disagreement amongst the group?
Which had disagreement by role?
Which had some individuals who felt differently than the majority of the group? What unique perspective might those individuals have?
I would encourage you to determine what kind of activity makes sense for your team to use for the “Decide What to Do” and “Close”. If you want to get more options for these phases, jump on over to the Retromat and give it a spin.
I didn’t want to do a deep dive on each of the principles. I was more interested in having the team see the constellation that formed for each principle, and then generate insights on a subset of the twelve.
Certainly, you could create an activity around the values in the Agile Manifesto. However, I have found that the values of the manifesto are a little too vague for this type of conversation. While the principles are more specific, they are still general enough to generate deep conversation.
Plan to use a room that is fairly open, leaving enough room for people to move about freely.
In preparation for this retrospective, print out each Manifesto principle on its own sheet of paper.
Have a note-card for each individual participating, so they can make notes about their observations. Maybe pre-print each Manifesto principles on a separate 3×5 or 4×6 card for each person.
It is very important for individuals, teams, and organizations to explore the principles behind how they operate, and not simply follow the rules of the framework-du-jour. The goal of this framework is to explore those principles. Please feel free to add your thoughts.
What are some keys to sustaining an Agile culture and organization? As part of our coaching, Susan DiFabio and I have been exploring sustainability as we iterate on our session for Agile 2012, entitled “Keeping the Dream Alive: Keys to Agile Sustainability”
As we prepared for the Agile 2012 workshop, we had the opportunity to share at the Agile Cincinnati June meeting. We promised that group that we would share some of the references that we used when creating the workshop. Those references are:
“The Reengineering Alternative” by William E. Schneider
This book describes the model of corporate cultures that was referenced in the presentation. It goes into depth about how the research was conducted, how the model emerged, as well as examples and opportunities for how to use this knowledge to help organizations leverage their strengths.
“Measuring and Managing Performance in Organizations” by Robert D. Austin
Based on his doctoral thesis at Carnegie Mellon University, the author presents the reader with many insights on what actually happens when humans are measured as part of an organizational system. Robert Austin’s book includes information from interviews with eight software measurement experts who represent a variety of opinions. “Measuring and Managing Performance in Organizations” provides important information for anyone who is trying to use measurement to guide organizational decision making.
Building Effective Teams: Miss the Start, Miss the End by Esther Derby
Esther is a thought leader in the area of organizations, team dynamics, and leadership. This blog post describes the manager’s role in creating an environment in which teams can become high performing. Susan and I have seen teams that have struggled, at least in part, because they lack the foundational elements of “real team” and “real purpose.”
To be agile, it is important to think well beyond the ceremonies and roles of a particular agile framework. We hope that this list of references helps you explore the topic of Agile Sustainability in more depth. We would also welcome you to let us know what materials you would recommend people study on this topic.
Lastly, thank you to everybody who attended the workshop in Cincinnati. We look forward to sharing with folks on Thursday afternoon at Agile 2012.
Honestly, it doesn’t matters. If it helps an organization create value for its customers in a way that allows employees to experience freedom while solving challenging problems, it doesn’t matter what label the method carries! But, that would be too short a response.
One way to decide if something should wear the label “agile” is to look at how it reflects the values stated in the Agile Manifesto. Of the Agile Manifesto statements, this is how Kanban values the “items on the left” over those on the right.
The visibility that Kanban provides to teams is a key contributor to facilitating interaction amongst individuals. The kanban board gives visibility to impediments that individuals are encountering makes resolving the impediment of prime importance.
Unlike Scrum, Kanban does not explicitly encourage generalization of skill sets. While Kanban does not force you to have a role for every queue, it is often easy to start by mapping the roles to queues and then inspect the bottlenecks and address those by helping the team develop more generalized skills.
Kanban is not a tool or a process that supersedes the importance of the individuals and their interactions. Yes, Kanban provides a lot of metrics that can be used to inform planning. However, the metrics are to facilitate interaction among team members, between team and stakeholders, and between team and customers.
When using Kanban to produce software, there are specific characteristics of Kanban that allow you to value working software over comprehensive documentation; small batches, WIP limits, measuring and managing flow. Perhaps your workflow will have a step or steps related to creating documentation.
Kanban does not prescribe working software, other than through mapping your value stream. If the last step in the value stream is working software, you can use Kanban as a tool to make sure you do that.
Kanban encourages customer collaboration through the prioritization of the backlog. Prioritization of the backlog is an ongoing process. Agile Kanban practitioners often use user stories or minimal marketable features (MMF). Use of either of these approaches supports customer collaboration in creating those items. The person who provides the detail on the stories or MMF is also available to the team to respond to questions.
As in Agile, daily standups are also present in Kanban. Unlike Agile, only people with issues speak in the daily standup. The standup meeting is an opportunity to speak up, whereas in Agile the traditional “three questions” are often present. This gives the team an opportunity to elevate issues to the Product Management representative’s attention, allowing them to be a partner in the process.
Silver Bullet Policy (see slide 20 for a brief overview) allows the customer to swap out an extremely high priority item for the current work in progress. There needs to be a swap so that WIP limits are not exceeded. Silver Bullet Policy may never be used, but can give the business the feeling that if there is an emergency, they can use this policy.
Agile teams often plan on a regular cadence. In Kanban, planning events can be triggered on an event. For example, your team may have a rule as follows: When the backlog backlog has dwindled to ten stories, a planning event will be held.
Unlike Scrum or XP, where the teams try to identify a piece of stability to work on for a period of time, Kanban allows the team to re-prioritize the backlog at any time and take something new off the backlog. This allows the team to respond to change sooner than if they were locked into a set sprint duration.
While Agile is primarily focused on software, Kanban is more focused on developing a lean organization . In fact, the business-oriented language that surrounds Kanban may make it an easier Agile model to embrace than Scrum.
While an organization or team can claim to be using Kanban and use it in non-agile ways, that will not be the case when done well. If the team and management use visualization, set WIP limits, and iterate on the value stream, Kanban is an excellent option for Agile teams.
There are lots of excellent resources on Kanban. My favorite reference is a book called Kanban – Successful Evolutionary Change for Your Technology Business. Thank you, Eric Landes, for loaning me your copy for a while. For further reading, check out the InfoQ version of the Kanban and Scrum Book.
A special thank you to Eric and Susan for co-authoring this blog.
“If you don’t know where you are going, any road will get you there,” said Lewis Carroll. Not only does this statement apply to individuals, but also to teams. In either case, you might not like the destination when you get there.
Stephen Covey’s second habit is “Begin with the End in Mind”. Before you can effectively create the physical manifestation of the product you want to create or the team you want to be, you have to first create a mental representation of that end state.
One exercise he proposes for helping to clarify what is supremely important to you is to visualize your own funeral. When you visualize your family, friends, or coworkers speaking about you after you have passed, what would you want people to say? As helpful as this visualization exercise can be for individuals to recognize what is important in their lives, it is also important for teams to determine what is important to them.
If an article were written about your team and preserved for the future, what would you want people to know about your team, about how you treated each other, and the way you went about your work? To help determine what is important to your team, consider your team’s ultimate goal. What do you want people to say about you, your team, and your work. Consider your teammates, your Product Owner, your stakeholders, and your customers. What about your functional manager? Consider involving your stakeholder community in the discussion.
Going through such an exercise can result in identifying a common view of what the team wants to become and how they want to operate. Without agreement on what the team values, the urgent demands of the project can keep you from becoming the team you need to become. Symptoms of teams without a compass may be that your team becomes myopic, focused on creating features to the detriment of sustainable pace or maintainable code. Alternatively, your team could become paralyzed by analysis and architecture debates, not recognizing when the analysis is sufficient to allow it to move forward.
To create your team vision is to “begin with the end in mind.” It is more than an elevator statement that captures the 30-second pitch for your product, and it is also more than a list of user stories that you intend to complete within a particular timeframe. What you want to distill from this exercise is a set of principles that can inform the decisions that you and your team will have to make through the course of your work. Take the information you collect and use it to create a mission statement for your team. When creating your mission statement, ensure the involvement of all team members; perhaps have a facilitated discussion led by somebody from outside the team can help ensure that all voices are heard. As Mr. Covey puts it: “No involvement, no commitment.”
Make your mission statement visible in your team room, on its wiki, give printouts to each team member, and anywhere else you feel is appropriate. If somebody is violating the mission statement, inquire about the deviation and determine if the mission statement has become outdated or if the behavior is perhaps not correct. Include a review of the mission statement as part of your retrospective.
Remember, if you are on an team and don’t know where you are going, you won’t get anywhere you want to be. Keeping the end in mind and using the mission statement as a team compass can help the team stay on track toward its desired goal.
This blog introduces a concept that I will build on in subsequent entries.
Perhaps Stephen Covey’s most popular contribution to personal performance management is the concepts he shares in his book The 7 Habits of Highly Effective People. Long before I heard about Agile, I was part of a professional services company that had Franklin Planner training as standard training element for its employees. I still remember the instructor’s name, Rory Aplanap; a name like that is easy to remember. Rory taught the class with enthusiasm, articulating the principles and the practices that the 7 Habits book lays out. He also taught us how to use the Franklin Planner system to support the 7 Habits.
For those who are not familiar with the 7 Habits, they are:
I see some strong parallels between the 7 Habits and high performing Agile teams. Here is a quick preview of some of the correlations I will expand upon in future posts:
Be Proactive – Teams are responsible for themselves and their work. As one example, this behavior manifests itself in teams making iteration commitments in Scrum and team members stretching beyond their traditional roles to help realize that goal. Teams decide how they are going to function and how to respond to stimuli from both within and outside their team.
Begin with the End in Mind – This concept is present in planning that begins with a product vision, and is then unfolded to become releasable increments, stories and tasks. All this work takes place in the context of some shared vision that the team is working to bring into reality.
Put First Things First – We strive to ruthlessly prioritize, and to maximize the amount of work not done.
Think Win/Win – The objective is to find a path by which multiple parties meet their objectives. It is not about one side winning and the other losing.
Seek First to Understand, Then to Be Understood – For an Agile team, it is not about blindly following along in a task list that somebody has created for you; it’s about really understanding what is needed, and then sharing your perspective and concerns.
Synergize – Think about the collaboration between the Product Owner and the Team that results in a solution that is better than if the parties had worked independently.
Sharpen the Saw – This might be in the form of learning new engineering practices, having time to investigate a new and interesting technology, or simply celebrating as a team.
As I mentioned a the outset, this is simply an overview of the topic, and I will expand on it further in upcoming entries.
One of my teams been involved in a bit of a discussion as to whether or not defects in the product backlog should be sized using Story Points, just as we size stories. Mike Cohn has a very good blog about “Story Points for Bug Fixing.” As I read his post, I believe it is specific to the scenario where a team has inherited a set of defects from a prior release or a legacy product that they are going to attempt to work through in the midst of delivering new features. Mike’s recommendation is that defects be sized, much like stories would, and that the resulting completed work would count toward the team’s velocity. I agree with that approach. I believe the scenario that we’ve encountered is a different one, and thus a different approach may be more suitable. The scenario I would like to explore is one in which defects found in the current release’s earlier iterations. Should those defects be sized and be included in the team’s velocity?
Consider a scenario where the features set to be delivered consists of 100 points of work, and that the team’s average velocity is 20 point per iteration. The figure below shows what a release burndown might look like under these conditions. Prior to iteration 1, there are 100 points of work to do. At the end of iteration 1, we have completed 20 points of work with high quality and there are 80 points remaining. Finally, at the end of iteration 5 the backlog has been reduced to zero*. The burndown in this scenario is “Backlog Points Remaining after Iteration – Scenario 1”
This burndown shows the points remaining after each iteration is complete. Each iteration, the team completes 20 points of work on stories that are in the backlog.
In another scenario, we identify defects from earlier iterations, size them, and include them in the iteration’s velocity. So, in scenario 2, each iteration still shows a velocity of 20, but the burndown does not reach zero after the five iterations are complete.
This burndown shows the points remaining after each iteration is complete. Again, the team completes 20 points of work each iteration.
Without the proper visibility to the information feeding this chart, it appears that the product manager is growing the backlog. However, if you were to decompose the velocity into its constituent points (illustrated below), you see that in the second scenario the contribution of defects to the team’s velocity grows throughout the release cycle. The assumption that the effort put toward defects will grow is reasonable; if there are defects being introduced early on in the release and nothing changes to address the root cause, the defects will continue to be introduced and their contribution will become more and more significant. Without transparency to what made up the velocity, the team can feel that they have executed with their ‘expected velocity’ and the product owner can feel like she is getting asked to make unreasonable concessions due to quality problems. Do you think it is reasonable that the product owner would remove scope because the quality of earlier deliverables was not high?
This view shows the points that were dedicated to stories in the backlog compared to points assigned to defects.
So, what to do?
I do agree that bugs from prior releases should be sized by the team and prioritized by the product owner, much like a new story. In that case, defects from prior releases would be included in the velocity, and the product owner could determine what new features could be completed if work toward resolving legacy issues was suspended.
If defects introduced in earlier iterations are going to be fixed in subsequent iterations, their contribution to the team’s velocity should be made big and visible. Only if the information is visible will it get the proper attention so the team and product management can work to figure out the root cause of the defects. If the team is not going to make the effort put toward resolving defects visible, I would suggest that it would be best to not size the defects and to merely let the ongoing reduction in team velocity be the canary in the coal mine. Unlike the scenario that Mike spoke about, the team cannot reasonably suspend defect resolution to deliver additional features.
Lastly, if the team’s anticipated velocity includes an allocation to fixing defects that are yet to be introduced, this needs to be accounted for as part of release planning, as well.
Ultimately, it is critical to identify the root cause of the defects and to address the root cause. Without addressing the root cause, we are left with an ever-increasing allocation of time to resolving defects that we are introducing as we build new features.
Conclusion: Sizing defects that are introduced as part of the release that you are currently working on can produce a misleading velocity. If you do want to size defects and have them contribute toward the velocity, segregate the points from Defects and Stories so that the effort toward each becomes plainly visible.
Footnote:
*For the sake of illustration, I have simplified the scenario. Indeed, there is often some variability in velocity from one iteration to the next. This scenario also assumes that the product backlog is constant throughout the five iterations.
So, you have the opportunity to deliver a overview presentation on Scrum. Creating slides sure can take a lot of work, especially if you want them to look good and flow naturally.
Fortunately, you do not have to reinvent the Scrum presentation. Mike Cohn has made a Overview of Scrum presentation available on his web site. The presentation can be customized and used under the Creative Commons license 3.0.
If you have the opportunity to introduce Scrum to an audience, save yourself a lot of time and energy. Check out the Overview of Scrum presentation.