Great video shared by Robin Dymond:
Great video shared by Robin Dymond:
Great article by Mike Griffiths: http://leadinganswers.typepad.com/leading_answers/2015/10/agile-talent-management.html
Question from Meredith:
As a product owner, what are the best ways to record technical debt and what are some approaches to prioritizing that work amid the continuous delivery of working software?
Hi Meredith! This is an interesting question. I’ll start by answering the second part of your question first. The two most common ways of handling technical debt, quality debt and legacy debt are:
In both approaches, the business is paying for the debt accumulated, and the cost includes an “interest” fee. In other words, the sooner you fix technical, quality and legacy debt, the less it costs. This approach to thinking about your product/system is essential for long-term sustainability. One organization I worked with took three years working on their system to clean it up without being able to add any new features! Don’t let your system get to that point.
Now to the first part of your question…
As a Product Owner, you shouldn’t really be making decisions about this cleanup work. Your authority is limited to the Product Backlog which should not include technical items. The only grey area here is with defects which may be hard to classify as either fully business or fully technical. But technical design, duplication of code, technical defects, and legacy code all are under the full authority of the Scrum Development Team. Practically, this means that every Sprint the team has the authority to choose however few PBIs they feel they can take while considering the technical state of the product/system. We trust and respect the team to make wise decisions.
Therefore, your main job as a Product Owner is to provide the team with as much information as possible about the business consequences of the work they are doing. With strong communication and collaboration about this aspect of their work, the technical members of your team can make good trade-off decisions, and balance the need for new features with the need to clean up previous compromises in quality.
A final note: in order for this to work well, it is critical that the team not be pushed to further sacrifice quality and that they are given the support to learn the techniques and skills to create debt-free code. (You might consider sending someone to our CSD training to learn these techniques and skills.)
Using these techniques, I have been able to help teams get very close to defect-free software deliveries (defect rates of 1 or 2 in production per year!)
Let me know in the comments if you would like any further clarification.
For many years, folks in the Agile community have been recommending that performance reviews be eliminated from the corporate world. In 2005 while coaching at Capital One, I remember many discussions on the awfulness of performance reviews. This was really my first understanding of the depth of culture change required to be Agile.
Now, this concept of eliminating performance reviews is gaining traction outside the Agile environment. Here is a great LinkedIn Pulse post by Liz Ryan in which she explains in depth about killing performance reviews.
From her article:
A little voice in the back of my brain nagged at me: “Despite your efforts to make them more compassionate and less uncomfortable for everyone, performance reviews are stupid from the get-go, Liz!
“How does one human being get to evaluate another one, when their personalities and perspectives may be radically different?
Consider using other techniques to help with improvement efforts among your staff. Lean has Kaizen. Agile has Retrospectives.
Real Agility means that learning is inherent in the culture of an organization. Performance reviews establish extrinsic motivators for learning… and all the research points to the idea that learning is much more powerful when it is intrinsically motivated.
Consider some other tools that might help your team to work more effectively, while maintaining intrinsic motivation:
Finally, consider that, at least in Scrum, the concept of a self-organizing, self-managing team makes it very difficult to do performance reviews. It is hard to apportion “blame” or “praise” to individuals. Each team member is dynamically deciding what to do based on the needs of the team, their own skills, and their interest. Team members are often collaborating to solve problems and get work done. Traditional roles with complex RACI definitions are melted away. Performance reviews are very difficult under these circumstances.
Many people have used a variation of Planning Poker to do Agile estimation. Here is a reference of 9 different Agile estimation techniques for different circumstances. I have seen all of these techniques work in practice, except one. Try a new one each Sprint!
Participants use specially-numbered playing cards to vote for an estimate of an item. Voting repeats with discussion until all votes are unanimous. There are lots of minor variations on Planning Poker. Good technique to estimate a very small number of items (2 to 10).
The Bucket System
Using the same sequence as Planning Poker, a group or a team estimate items by placing them in “buckets”. The Bucket System is a much faster Agile estimation technique than Planning Poker because there is a “divide-and-conquer” phase. The Bucket System can also be used with larger groups than Planning Poker and with very large numbers of items to be estimated (50 to 500).
For super-fast Agile estimation, the items to be estimated are simply placed by the group in one of three categories: big, uncertain and small. The group starts by discussing a few together, and then, like the Bucket System, uses divide-and-conquer to go through the rest of the items.
TFB / NFC / 1 (Sprint)
This Agile estimation technique is similar to Big/Uncertain/Small but puts a specific “size” into the mix, namely 1 Sprint. The categories are “Too F-ing Big”, “No F-ing Clue” and “1” Sprint (or less). I learned this one recently from someone in one of my CSPO classes.
Dot voting is usually considered a decision-making tool, not an Agile estimation technique. However, for estimating small numbers of items, dot voting can be a super-simple and effective technique. Each person gets a small number of “dots” and uses them as votes to indicate the size of an item; more dots means bigger.
Items are categorized into t-shirt sizes: XS, S, M, L, XL. The sizes can, if needed, be given numerical values after the estimation is done. This is a very informal technique, and can be used quickly with a large number of items. Usually, the decisions about the size are based on open, collaborative discussion, possibly with the occasional vote to break a stalemate. There is a brief description of T-Shirt Sizes here.
Items are grouped by similarity – where similarity is some dimension that needs to be estimated. This is usually a very physical activity and requires a relatively small number of items (20 to 50 is a pretty good range). The groupings are then associated with numerical estimates if desired.
Items are placed in a random order on a scale labeled simply “low” to “high”. Each person participating takes turns making a “move”. A move involves one of the following actions: change the position of an item by one spot lower or one spot higher, talking about an item, or passing. If everyone passes, the ordering is done. The Challenge, Estimate, Override and the Relative Mass Valuation methods are variations on the ordering protocol.
Divide until Maximum Size or Less
The group decides on a maximum size for items (e.g. 1 person-day of effort). Each item is discussed to determine if it is already that size or less. If the item is larger than the maximum size, then the group breaks the item into sub-items and repeats the process with the sub-items. This continues until all items are in the allowed size range.
Agile estimation techniques are collaborative. All appropriate people are included in the process. For example the whole Scrum team participates in estimating effort of Product Backlog Items. Collaborative techniques are also designed so that it is impossible to blame someone for an incorrect estimate: there is no way to trace who estimated what.
Agile estimation techniques are designed to be fast (-er than traditional techniques) and deliberately trade off accuracy. We are not trying to learn to predict the future… or get better at estimation. Instead, we recognize that estimation is a non-value added activity and minimize it as much as possible.
Most Agile estimation techniques use relative units. This means that we don’t try to estimate dollars or days directly. Instead, we use “points” or even qualitative labels and simply compare the items we are estimating to each other. This takes advantage of the human capacity to compare things to each other and avoids our difficulty in comparing something to an abstract concept (such as dollars or days).
Check out my recent “Agile Planning in a Nutshell” article.
What Other Agile Estimation Methods Are There? Please let me know in the comments and feel free to include a link!
If you are a long-time reader of Agile Advice, you know I take interest in Agile methods used in non-software environments. My buddy Mike Caspar has another great story about the use of Agile in the classroom, and in particular, how he has had an impact as a coach.
Great article by Mike Cottmeyer: Dependencies are Evil. And yet, dependencies are one of the toughest things for organizations to overcome!!!
My friend Mike Caspar has another great blog post: Similarities between Agile Coaching and Flight Instruction. Check it out!
Great technique described by Shahin Sheidaei on his blog: Challenge, Estimate or Override (CEO) Game for Effective Estimations. It is much quicker than the Planning Game, and probably a bit slower than the Bucket System.
Agile methods such as Scrum, Kanban and OpenAgile do not require long-term up-front plans. However, many teams desire a long-term plan. This can be thought of as a roadmap or schedule or a release plan. Agile planning helps us build and maintain long-term plans.
The steps to do this are actually very simple:
Agile planning allows a team to update estimates at any time. Therefore, the techniques used above should not be thought of as a strict sequence. Instead, as the team and the business people learn, the estimates and long-term plan can be easily updated. Scrum refers to this ongoing process at “Product Backlog Refinement”.
In order to use Agile planning effectively, people must be aware of and support the principles of Agile planning:
The team decides on how much work it will do in a Sprint. No one should bring pressure on the team to over-commit. This simply builds resentment, distrust and encourages low-quality work. That said, of course teams can be inspired by challenging overall project or product goals. A stretch goal for a Sprint is just a way to 100% guarantee failure. Even the team should not set its own stretch goals.
There are a few interesting principles that apply here. For example, the Agile Manifesto mentions sustainability:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
The Agile Manifesto also points out the importance of trust:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Stretch goals are incompatible with both of these principles from the Agile Manifesto.
There are two types of stretch goals. The first type are those assigned by outsiders to the team. The second type are those which a team sets for itself. Both types are bad.
The worst extreme of this type of stretch goal is also the most common! This is the fixed-scope-fixed-date project deadline. In this type of stretch goal, the project team, doing Scrum or not, is forced to work backwards from the deadline to figure out how to get the work done. If the team can’t figure this out, managers often say things like “re-estimate” or “just get it done.” (Note: another thing that managers do in this situation is even worse: adding people to the project! Check out “The Mythical Man-Month” by F. Brooks for a great analysis of this problem.)
My anecdotal experience with this sort of thing is simple: quality suffers or sustainability suffers. I once worked with three other people on a mission critical project to help two banks with their merger. There was a regulatory deadline for completing the integration of the two existing systems for things like trading, etc. Fixed-scope-fixed-date. Coffee and sleepless nights were our solution since we tried not to sacrifice quality. We actually ended up working in my home for the last few 24-hour stretches so that we would have access to a shower. Suffice it to say, there’s no way we could have sustained that pace. It’s anti-Agile.
A quick search for ideas and opinions about stretch goals makes it very clear that there is no commonly agreed “correct” answer. However, from an Agile perspective stretch goals assigned by outsiders are clearly against the principles of the Agile Manifesto.
The Scrum Guide states:
The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.
For emphasis: what it can accomplish – not what it (the Development Team) wants to accomplish, or what it should accomplish, or what it could accomplish if everything goes perfectly. A Development Team should be accomplishing their Sprint plan successfully (all Product Backlog Items done) on a regular basis. Of course, exceptional circumstances may intervene from time to time, but the team should be building trust with stakeholders. Here’s another story:
I had a good friend. We would always go out for coffee together. We just hung out – chatted about life, projects, relationships. Of course, from time-to-time one or the other of us would cancel our plans. That’s just life too. But there came a time when my friend started cancelling more often than not. There was always a good excuse: I’m sick, unexpected visitors, work emergency, whatever. After a little while of this I started to think that cancelling would be the default. I even got to the point where I was making alternative plans even if my friend and I had plans. I got to the point where I no longer trusted my friend. It didn’t matter that the excuses were always good. Trust was broken.
It doesn’t matter why a team fails to meet a goal. It reduces trust. It doesn’t matter why a team succeeds in meeting a goal. It builds trust. Even among team members. A team setting stretch goals is setting itself up for regular failure. Even if the team doesn’t share those stretch goals with outsiders.
Stretch goals destroy trust within the team.
Think about that. When a team fails to meet its own stretch goal, team members will start to look for someone to blame. People look for explanations, for stories. The team will create its own narrative about why a stretch goal was missed. If it happens over and over, that narrative will start to become doubt about the team’s own capacity either by pin-pointing an individual or in a gestalt team sense.
The importance of trust cannot be over-stated. In order for individuals to work effectively together, they must trust each other. How much trust? Well, the Agile Manifesto directly addresses trust:
Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
Here is my recent YouTube video about stretch goals… check it out and subscribe to our channel!
The Product Owner is a full member of the Scrum Team and should be present at all Scrum meetings (Sprint Planning, Daily Scrums, Sprint Review and Sprint Retrospective). As well, the Product Owner should also be available during work time. Of course, the PO also needs to work with stakeholders and might be away during that time, but these discussions should be scheduled outside of the team’s meeting times.
In one case with a team I was coaching at Capital One, the Product Owner didn’t show up for the Sprint Review and then didn’t show up for the Sprint Planning meeting. The rest of the team decided to delay the start of the Sprint until the Product Owner did show up. The director-level manager of the team, a deeply insightful individual, insisted that all team members take paid days off until the Product Owner was ready to attend the Sprint Review… kind of like a mini-strike. It only took two days for the Product Owner to clear his schedule to attend the Sprint Planning meeting.
The Scrum Guide defines the membership of the Scrum Team as follows:
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team…. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
As a member of the Scrum Team, the product owner should have the same level of commitment, courage, focus, openness, and respect (the five Scrum values) as any other Scrum Team member. The Product Owner needs to collaborate actively with the Scrum Team. One way to gauge the involvement of the Product Owner is in the Sprint Review. If the Product Owner is giving feedback to the rest of the Team in the Sprint Review, it’s too late! The Product Owner should never be surprised by the product increment shown in the Sprint Review. Instead, the Product Owner should be leading the discussion to get feedback from customers, users and other stakeholders during the Sprint Review.
There are some interesting exceptions to the Product Owner being present. Here are some of the most common:
The latest version of the Scrum Guide also puts the Daily Scrum meeting in a special category. The meeting is for the Development Team (the subset of the Scrum Team that excludes the ScrumMaster and the Product Owner). Former versions of the Scrum Guide and other official Scrum documentation have changed this rule in various ways. As a personal comment, I believe this is a serious internal contradiction in the definition of Scrum. If the Scrum Team is self-organizing, then the Daily Scrum should include the ScrumMaster and Product Owner. I have seen this work successfully. The Scrum Guide says nothing about other people observing the Daily Scrum. I strongly recommend that the ScrumMaster and Product Owner observe the meeting even if you wish to follow Scrum strictly and restrict their participation.
If you decide to allow the Product Owner to participate in the meeting, then the Product Owner should restrict their comments to changes in the Product Backlog that require the team’s help for refinement. For example, the Product Owner could report in the Daily Scrum as follows:
“Yesterday I met with Sanjay at Deal Maker Industries and he suggested that we add a feature to allow car manufacturers to ping various stakeholders about risks and options. I think that will mean adding several new user stories to the Product Backlog. I need help from the team to write and estimate the new PBIs. Today I also have a re-prioritization meeting with three key internal stakeholders. My only obstacle is that I still can’t get a meeting with Karen about the marketing of the features from our last few Sprints and I’m worried that will delay our next release.”
In this example, the team and the ScrumMaster are kept apprised of key developments at the product level and know that there will be some extra work during the day to work on Product Backlog Refinement. The Scrum Guide says:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Ideally, the Product Owner would spend an equal amount of time with their Scrum Team and with outside customers and users. The Product Owner is the key conduit of information from the market to the Development Team. Not being present with the Scrum Team can hinder this flow of information and cause quality problems and unnecessary rework. Again, the Product Owner should never be surprised in the Sprint Review.
This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.
The ScrumMaster is like a fire-fighter: it’s okay for them to be idle – just watching the team – waiting for an emergency obstacle. Taking on tasks tends to distract the ScrumMaster from the job of helping the team follow the rules of Scrum, from the job of vigorously removing obstacles, and from the job of protecting the team from interruptions. Let’s look at each of these aspects of the ScrumMaster role in turn:
The ScrumMaster is a process facilitator. The Scrum process, while simple to describe, is not easy to do. As the Scrum Guide says:
Simple to understand
Difficult to master
The ScrumMaster helps the Scrum Team and the organization to master the Scrum framework. Helping everyone understand Scrum and respect its rules is a first step. Some of the rules are particularly challenging. In some companies, being on time for meetings and ending them on time is hard. Scrum requires this. The ScrumMaster helps the team do this. In some companies, meeting deadlines, even short ones, is difficult. Scrum requires this every Sprint. The ScrumMaster helps the team do this. In some companies, giving time to improving things is hard. Scrum Teams do retrospectives. The ScrumMaster ensures that the team takes the time for this.
Of course, following the rules is hard for people. Even just the concept of “rules” is hard for some people. Everyone has the right to do whatever they want. Well, if you aren’t following the rules of Scrum you aren’t doing Scrum. So for some teams, just getting to the point of being willing to follow the rules of Scrum is a big step. The ScrumMaster needs to help with motivation.
The Scrum Team is going to be working hard to meet a goal for the Sprint. As they work, they are going to work through many challenges and problems on their own. However, the team will start to encounter obstacles as well. These obstacles or impediments come from a few sources:
The ScrumMaster needs to work through these.
On a panel talk on Saturday one person said “the scrum master is an administrator, moving cards, updating the burn down. It is an easy job, I think my son could do it.” I then rebutted his remarks….
The ScrumMaster will tackle enterprise operations for their slow error prone deployment process, tackle Sarbox [Sarbanes-Oxley] compliance policy that has been way over-engineered to the point of slowing dev to a crawl, telling the PMO that 3 sets of reports is waste, exhorting the team to try to do unit tests in ABAP (SAP cobol), etc.
Robin Dymond, CST – (Scrum Training and Coaching Community Google Group, Sep. 23, 2009)
Every organization seems to have more work than their staff have the capacity to deliver. Staff are often asked to task switch repeatedly over the course of a day or even in a single hour. Sometimes people are “allocated” to multiple projects simultaneously. This breaks the Scrum value of focus. The ScrumMaster needs to protect the team from interruptions or anything else that would break their focus.
But what should the Scrum Team members be focused on? Simply: the goal of a single Sprint. And a single Scrum Team is focused on a single product. The Product Owner should be the point of contact for any and all requests for the time and effort of a Scrum Team. The ScrumMaster needs to re-direct any interruptions to the Product Owner. The Product Owner decides if:
There are no other options in Scrum for handling requests for work from the Scrum Team (or any member of the Scrum Team).
Any time the ScrumMaster starts to contribute to the product development effort directly, the ScrumMaster is distracted from the other three duties. Although simple, following the rules of Scrum is not easy. Getting distracted from the duty of helping the team follow the rules of Scrum means that the team is likely to develop bad habits or regress to non-Scrum behaviour. Vigorously removing obstacles is usually a huge job all on its own. Most Scrum Teams have huge organizational obstacle that must be worked on. Some of these obstacles will take years of persistent effort to deal with. The ScrumMaster cannot become distracted by tactical details of product development. Protecting the team from interruptions means the ScrumMaster must have broad awareness, at all times, of what is happening with the team. If a team member is interrupted by a phone call, an email, or someone walking into the Scrum team room, the ScrumMaster needs to notice it immediately.
Whenever a ScrumMaster takes on a product development task, focus on the role is lost and a condition of a simple conflict-of-interest is created. If the team has “committed” to deliver certain Product Backlog Items at the end of a Sprint, then that feeling of commitment may lead a ScrumMaster to focusing on the wrong things.
The time of a ScrumMaster is an investment in continuous improvement. Letting a ScrumMaster contribute to the work of the team dilutes that investment.
This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.
Although a cancelled Sprint is rare, it can be tempting to try and wait until everything is “perfect” or “ready” before re-starting. Teams should immediately re-start after cancelling a Sprint. One team I heard of was doing two week Sprints, cancelled due to a major tool problem, and then waited three months for the vendor to fix the problem before going back to Sprinting. Instead, they should have used their creative problem-solving skills to find a way to continue delivering value and restarted their Sprints immediately.
The Scrum Guide puts Sprint cancellation under the authority of the Product Owner:
A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.
It is important to note that older descriptions of Scrum will sometimes mention that the ScrumMaster or the Development Team can also cancel a Sprint. This is no longer part of the core definition of Scrum.
A cancelled Sprint can sometimes be emotionally challenging for a Scrum Team. There are three reasons for this difficulty:
Once people experience these emotional effects from a cancelled Sprint, they will want to be cautious to avoid them re-occuring. That sense of caution will lead people to make arguments to the effect of “let’s make sure when we start our next Sprint that we have everything right” or simply, “I don’t want to go through that again… we better get it right this time around.” In order for the ScrumMaster to avoid falling for these arguments, it is important for the ScrumMaster not to be a hands-on contributor to the work. In other words, to be emotionally detached from the work. Those arguments can be persuasive unless the ScrumMaster can remind the team about empiricism. The ScrumMaster must always support the Product Owner if the product owner believes that a cancelled Sprint will lead to the best business outcomes.
Scrum is an empirical process that allows for “failure”. Of course, it probably helps to not call it that. Instead, a Scrum Team and the organization around it need to think of every Sprint as an experiment. There’s a good analogy here with the various stages of drug trials. When a company wants to research a new drug, the drug will go through various stages of experiments. The early stages of research are based on chemical reactions in the proverbial test tubes – laboratory experiments. Subsequent stages of research are often based on animal experiments. After that come human trials. At any stage if the drug in question is showing adverse effects outweighing the therapeutic effects, then the current stage is cancelled. Of course, the research done to that point is not a waste, but nor does it immediately result in a useful drug with net therapeutic effects. In Scrum, each Sprint is like a stage in the drug trials. If the work of the Sprint will not result in a net benefit, it only makes sense to cancel the work as soon as that information becomes obvious.
The pitfall, then, is that after a cancelled Sprint a team will feel pressure to wait until conditions are perfect before continuing on the next Sprint. Scrum does allow for the team to do a bit of a review of the reasons that the Sprint was cancelled, perhaps even to do a retrospective, and then start another Sprint planning meeting. The Sprint Planning meeting might be a bit longer than usual. The ScrumMaster does need to be sensitive to the needs of the team.
One other factor may be a consideration: if the team is working with other teams on a larger-scale effort, there may be pressure to have all the teams with synchronized Sprints. For example, the Scaled Agile Framework emphasizes cadence and synchronization among multiple Scrum teams. In this case, a cancelled Sprint may mean that a team sits idle for a short time while they wait for the next synchronization point, as illustrated:
This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.
Subscribe to our BERTEIG / WorldMindware YouTube channel – we have over 20 more videos planned on the Myths of Scrum.