Friday, March 20, 2015

The Scrum Master: Career Path or Career Oblivion

What is the career path for a Scrum Master?

That question was raised recently when I was asking people in the Development department if they thought they'd like to be a Scrum Master and whether they would apply for a Scrum Master role. Of course the question and answer related to their specific company but I've heard the same question asked at Agile meetups and Agile conferences. The short answer [to me] is: there's a clear career path for Scrum Masters. The key to this career path is growth.  Let me explain.

Those of you that work in Development are sometimes isolated from the business. This is not an insurmountable problem but let's be honest, work on products occurs in Development and the business of the company occurs in the sales/marketing offices of the various regions. You could think of Development having the intellectual property of the product, the brain, whereas the regional sales/marketing teams (Americas, Asia, Europe, Australia, Africa) form the heart. Neither can survive without the other and both are necessary for growth and vitality. The best scenario is that the brain (Development) and the heart (sales/marketing teams with their customer insights) work together in a seamless, symbiotic relationship. Establishing and maintaining a great communications link, having everyone working from the same page, and working toward a shared product vision are essential ingredients for growth. From a Scrum prospective, the Scrum Masters are the people whose role it is to find a way to make this happen.

In the Scrum Guide, Ken Schwaber and Jeff Sutherland imagine a world where the Scrum Masters, get the organization to understand and work with the Scrum Teams by:

  • Leading and coaching the organization in its Scrum adoption,
  • Planning Scrum implementations within the organization,
  • Helping employees and stakeholders understand and enact Scrum and empirical product development, and
  • Causing change that increases the productivity of the Scrum Team.
A Scrum Master will hasten the adoption of Scrum Values (from the Scrum Alliance
  • Focus - Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner. 
  • Courage - Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges. 
  • Openness - As we work together, we express how we're doing, what's in our way, and our concerns so they can be addressed.
  • Commitment - Because we have great control over our own destiny, we are more committed to success.
  • Respect - As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.

But how does this lead to a career path?

By improving lines of communications, by getting those in direct contact with customers communicating the pain customers feel, by getting the product development teams to have empathy with the customer, by understanding the impact of technical solutions on the customers, by keeping all aspects of the business informed of customer problems and potential solutions, by being transparent, by continually striving to improve, by creating a culture where learning trumps blame, by creating a culture where the question is not, "what have you done?" but instead, "how can I help you?", by doing all these and more, the Scrum Master will create the opportunity for the company to experience unprecedented growth. And when you have growth, you create more jobs and a larger product base and with that comes the need for more sales people, more marketers, more product managers, more products, more projects, and more Scrum Teams. I should say that Scrum Masters are almost never ever directly responsible for a company's growth. However, through the actions of the Scrum Master and many of the communication improvements and process streamlining, the inevitable result will most likely be growth.

Scrum Masters typically move into roles like product owner, product manager, head product owner, head of product management, program manager, project director, program director, agile coaching, development manager, technology manager, and others. Most of these roles may not exist today but with growth and expansion, some of these roles will come into being.

Whether your company or business has a global footprint or is a young Start-up, Agile and Scrum can be tools for growth and the Scrum Master role is positioned so that the results of good Scrum Mastery is company growth. Once there's growth, there almost always follows more and greater opportunities. Who is better positioned to move up and forward than the Scrum Master?

Your thoughts?

Thursday, January 1, 2015

Product Backlog Flows

A lot of focus and discussion in the Agile community is on Agile Teams and how they work and develop over time. I often find that how that work gets from the customer to the team is neglected or poorly understood. I would like to talk about this process and provide a framework for you and your organization to experiment with. I'll include some details but leave enough ambiguity for experimentation while you're creating a working framework.

Product Backlog Iceberg 

The Product Backlog Flow framework has three conveyor belts of work flowing simultaneously and independently of each other to bring customer pains and problems to the Agile Teams to solve. These conveyor belts can be visualized using Mike Cohn's Product Backlog Iceberg shown below.

  1. Future Releases: Collection of feature epics encapsulating real customer problems we feel are worth solving. Feature epics in the Future Releases bucket have a Business Model Canvas with potential problem, solution, and customers identified but these may not yet be validated. Cost and revenue are roughly estimated. These feature epics may need go through an approval process before being considered for a ReleaseRough feasibility will have been established with a technical Subject Matter Expert (SME) but detailed analysis of risks associated with implementation has yet to occur. The strategic and tactical business concerns are the prime focus while a feature epic rests in the Future Releases bucket. The number of feature epics in Future Release will generally match the company's product road map length. If the road map projects the next year then you would probably have a year’s worth of feature epics in Future Releases at a minimum.
  2. Release: Feature epics that are now tied to a specific release time frame. These feature epics would have been validated with customers and have acceptance criteria from the customer's POV. Feature epics in the Release bucket are reviewed and analysed by the Agile Team likely to implement the epic. The feature epic may be broken down to facilitate estimation or to isolate the riskier aspects of the feature. The desired outcome is for the Agile Team to confirm the feasibility of implementing the feature within a specific release window.
  3. Sprint: Sprint stories are generally very well understood by the Team and any outstanding technical or implementation questions have been answered through knowledge spikes and customer meetings. A team can target having few user stories that hold big surprises, i.e. issues the Team didn't know they didn't know. These stories meet the INVEST criteria, Independent, Negotiable, Valuable, Estimable, Small, and Testable.

These 3 flows are meant to operate independently and at all times but use Lean Just In Time (JIT) techniques. This means stories move from Future Releases to Release and from Release to Sprint at the last responsible moment. Try to not transition work up the iceberg too soon as features and epics have a finite Validity Runway. The Validity Runway is the time frame where Product/Market fit remains intact and the Product Owner and business feel the essence of a feature epic will not change. Due to the additional analysis work done in the Release and Sprint buckets, moving epics up the Product Backlog Iceberg too soon introduces the risk of re-work or wasted work if a feature epic is dropped for any reason,

The Experiment

Ideally, Agile Teams never stop sprinting. Work flows to them from the lower depths of the iceberg and each new feature epic introduced to the team during Product Backlog refinement (the act of adding detail, estimates, and order to items in the Product Backlog) could have its own goal and vision attached to it. This flow is possible because:
  • Sustaining Innovation for existing products and customers keeps new features and feature enhancements flowing from customers to the Future Releases bucket.
    • Set-up periodic customer interviews to get the latest problem(s) the customer is facing that you might be able to solve.
    • Set targets for incoming sustaining innovation ideas based on product line or customer segments. These will eventually become part of the product road map and Future Release bucket. 
    • Establish a Business Model Canvas for each idea (Ash Maurya's Lean Canvas might be an excellent place to start). Identify and validate problem, solution, unique value proposition, and customers first. 
    • Move new feature and feature enhancement epics into the Future Release bucket once Problem/Solution fit is attained. 
  • Adjacent and Disruptive Innovation continuously occurs as Product Management, Sales, and Marketing are constantly looking for new product ideas and new markets for existing products.
    • Establish a Business Model Canvas for each new idea.
    • Use Eric Ries' Lean Start-up methodology to validate your new ideas and hypotheses.
    • Timing for moving ideas into Future Release is contingent on how your company operates. The best scenario is for a small 'start-up' component within the company to take new ideas through Problem/Solution fit and begin establishing Product/Market fit before bringing these into the main production pipeline.
  • Product Managers, Product Owners, and other business stakeholders will review the validity and priority of feature epics in the Future ReleasesRelease, and Sprint buckets to keep priorities up-to-date and keep the Business Models relevant.

    • Use a Kanban board to manage and track all feature epics.
      • Set-up the Work In Progress (WIP) number. This number sets the maximum amount of work that occupies a column. To do this, select a uniform means of measuring the feature epics. I would suggest Ideal Days as feature epics will generally be of varying sizes negating a strict counting of epics. It will take a little experimenting to get the WIP numbers that suit your company. The numbers will also be influenced by the number of Agile Teams available, the sizing of the effort on the feature cards, and the maturity of your Agile environment.
    • Keep an open and running dialog with your customers, users, and potential customers from the initial problem inception through to implementation.
    • Review the business value and priority of each feature epic in every column including the Sprint column. You would review those feature epics in the Sprint column because a feature can become obsolete at any time e.g. a feature may no longer be viable if competitive advantage is lost.
    • Reorder feature epics on your Kanban board. Do not shy away from dropping a feature epic lower down the iceberg if business value and priority warrant it.
    • Manage the expectations of your stakeholders. Inform all stakeholders of any changes in business value or priority, don't wait for them to 'discover' the changes.
  • Problem solutions and the release cycle are disconnected
    • Establish a predictable release cycle based on a realistic assessment of how fast this can be in your organization and how quickly your customers can take on new releases.
    • All feature epics are prioritized.
    • Keep your development teams focused on solving customer problems. Don't let your releases disrupt these teams. Avoid the waterfall trap of:
      • Development,
      • Feature Complete date or Code Complete date,
      • Development & QA test period, and 
      • Release
    • Scrum Teams must deliver a 'potentially releasable' product at the end of each sprint. This must include any documentation (guides and such), marketing materials, etc.
    • Reduce the chances of the development team discovering major 'unknowns' once a feature epic enters the Sprint bucket. As a general starting point, I would suggest that feature epics are broken down into sprint ready stories with the following attributes:
      • Meets the conditions set in the INVEST acronym
      • Enjoys a shared understanding by the Development Team with a measurable uncertainty of < 10% (i.e. fewer than 1 in 10 user stories hold any surprises)
      • Has 3-5 Acceptance Criteria and Non-Functional Acceptance Criteria
      • All UX definition work is complete, validated with the customer or customer proxy, and is ready for actual implementation
      • Has an estimate using your team’s estimation technique and scoring mechanism
      • Can be completed by the Development Team in 2-3 days
    • Consider expanding your Feature Kanban board to include Problem Inception, Marketing, and Sales once the company is on-board with the continuous flow of customer problems from inception to post release.


In order to get the Agile Teams focusing on delivering the highest customer value in each sprint and delivering a ‘potentially releasable’ product at the end of the each sprint, the organization needs to switch their focus from Release Dates to Customer Value. This can be accomplished, arguably the hardest part, by getting the Agile Teams focused on Customer Value using the Product Backlog Flow process.


I'd like to explicitly thank the authors below for their pioneering research and studies.

  • Mike Cohn, User Stories Applied: For Agile Software Development, available here
  • Henrik Kniberg, engineering culture at Spotify, and
  • Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product, available here.

Thursday, June 20, 2013

Organizational Adoption of Agile

From Craig Larman - Larman's laws of organizational behaviour:
1.       Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and "specialist" positions & power structures
2.       As a corollary to (1), any change initiative will be reduced to overloading the new terminology to mean basically the same as status quo
3.       As a corollary to (1), any significant change initiative will be derided as "purist" and "needing customization for local concerns" -- which deflects from addressing weaknesses and manager/specialist status quo
4.       Culture follows structure.
i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that's why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture. John Seddon also observed this: "Attempting to change an organization's culture is a folly, it always fails. Peoples' behaviour (the culture) is a product of the system; when you change the system peoples' behaviour changes."
I think that those who believe Agile and Scrum are the way forward will be at odds with most businesses that have a deep institutionalized Command & Control structures that rests responsibility, but usually not accountability, within groups/committees while diverting responsibility away from individuals. In Scrum we rest most responsibility on the Product Owner and hold this person accountable for the business value delivered at the end of each and every sprint. It is often this simplicity Scrum provides that is in direct conflict with the ‘status quo’. So how to begin changes to the existing structures?
First and foremost, you must have an Executive Sponsor. Without Executive Sponsorship your attempt to directly adopt Agile will almost certainly fail. This is more than just having managers that agree to allow you to use Agile; this is a person who has the rank and status in the business structure who can influence the often many groups/committees who collectively and traditionally have controlled projects.  Agile is a movement that requires top-down leadership to say ‘this is going to happen, here is why it is good and we should all start rowing in that direction.’ The Executive Sponsor, along with possibly one or more Agile Coach specifically trained and experienced in agile adoption at the executive level, will be handing out the oars.
What if you have no Executive Sponsor or the Executive Sponsor’s influence is severely limited? Under these circumstances, full Agile adoption is very unlikely to happen. However, there is a strategy that could overcome the tremendous obstacles that are in the way but it does depend on you finding some in Mid to Upper level Management more interested in results rather than institutionalized processes. The ultimate result is usually a hybrid adoption of Agile where all or some of the institutional controls remain in place but an Agile sanctuary is carved out with fewer of these institutional controls than a traditional waterfall project. This hybrid Agile project is not truly Agile but neither is it true waterfall. The strategy follows a bottom up Agile Adoption approach that will take time, maybe a lot of time, to slowly chip away at the traditional structure and replace it with an Agile structure and Agile mindset.
The strategy is twofold:
1.       Target getting support from managers in the organization that are more likely to support Agile; and
2.       Target going around the organizational structure of “over seers”
The strategy includes targeting those executives in middle to upper management that are more likely to support an Agile process and have some influence on those in the organization who are stanch supporters of the institutional controls. The idea here is not to change these people completely over to the Agile mindset but rather get these targeted managers enthusiastic enough about Agile so they can see the possibilities and potential of Agile. Targeting managers who don’t have influence over supporters of the processes or targeting managers who are the stanch supporters of the processes is usually a tactical mistake. Targeting a manager who doesn’t directly influence those in control of the processes might be an easy convert but other than a quick burst of satisfaction, the real battles will still lie ahead. The manager who is a supporter of institutionalized processes is very difficult to convert; they probably believe in their familiar processes and controls much like you believe in Scrum, albeit for different reasons. A word of caution, because you’ve gotten some support for your Agile project, you must remember that “success has many fathers, failure is an orphan.” For those in middle to upper management who supported you earlier, to ensure their continued support of Agile and endorse its use, hybrid Agile projects must succeed and succeed “loudly”. If your project fails or succeeds but with only a whimper, some, most, or all middle to upper manages may forget that they ever supported Agile.
The second part of your Agile adoption strategy will be to identify all those organizational groups and individuals who traditionally sign-off on projects and find a way to exempt the Scrum project from these. These groups are those who sit on gate committees, steering committees, technology committees, or any one of a dozen other committees that approve, sign-off or use other mechanisms of “over-seeing” a project. These groups are often a source of power and prestige for its members and are traditionally very difficult, if not impossible, to get around without an appropriately positioned Executive Sponsor. The best way to get around these groups is to make your project a separate business unit that answers to the CEO/board. This follows along how IBM built its PC division in order to get out from under the bureaucratic thumb of IBM’s corporate structure.  Another tactic is to chip away at the required process these groups require projects to follow. This can lead to some relief for the project but will probably not succeed at allowing full Agile adoption for quite some time.
Is doing a Hybrid Agile Scrum adoption good? The short answer is yes. By simply following the activities defined for Scrum, (Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), Jeff Sutherland has said that this will increase productivity by 20%-30%. However, the greater benefits of Agile are really attained through following of and embracing the deeper meanings of the Agile Manifesto, the Scrum Guide, and Scrum Primer. To become “hyper-product” would require everyone involved in the project (managers and scrum teams) to believe in and live Agile and Scrum. Unless the Mid to Upper level Managers of the business are only interested in results and don’t really care how you achieve them, your best approach to adopting Agile is incrementally, one step at a time.
Craig Larman is co-author of:
  • Practices for Scaling Lean & Agile Development: Large, Multisite & Offshore Product Development with Large-Scale Scrum
  • Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
  • Agile and Iterative Development: A Manager's Guide

Monday, June 3, 2013

Sprint Review Facilitation & Customization

The Scrum Sprint Review is a key Inspect & Adapt meeting where the Scrum Team discusses with Users, Customers, and Business stakeholders what was "Done" in the just completed Sprint. The Sprint Review meeting is short but must cover the agenda items listed below. The attendance by the Scrum Team is required. Attendance by stakeholders is optional but should be strongly encouraged for those key stakeholders most affected by the Sprint results. This article gives some advice on how to conduct the Sprint Review when stakeholders are unable to physically be present.
During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint and the Product Backlog is amended if needed. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. The Product Owner provides the stakeholders the likely completion date for the release based on the Development Team's velocity and work remaining in the Product Backlog. This is an informal meeting, and the presentation of the Sprint results is intended to elicit feedback and foster collaboration.
One hour Sprint Review Agenda includes the following elements:
  • The Product Owner identifies what has been “Done” and what has not been “Done” (suggest 5 minutes)   
  • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved  (suggest 10 minutes)
  • The Development Team demonstrates the work that it has “Done” and answers questions about the Increment  (suggest 15 minutes)
  • The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date  (suggest 10 minutes)
  • The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings  (suggest 20 minutes)
The feedback from the stakeholders, directed toward the Product Owner and Scrum team, is the most important thing to get out of the Sprint Review. The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Customization for Stakeholders who cannot be physically present at the meeting

A Scrum Team strives to ensure the key stakeholders, as identified by the Product Owner, are in attendance at each Sprint Review. The key stakeholders identified may differ from Sprint to Sprint based upon the work selected in each Sprint, but it is important to the success of the project that those identified feel compelled to attend the Sprint Review when asked. When a stakeholder cannot be physically present at the Sprint Review meeting, the Scrum Team loses out on viewing subtle hints on the reception of their Sprint results and future Sprint plans. Stakeholder body language and tone are indispensable clues to the observant Scrum Team which can be lost when stakeholders are not with the team during the Sprint Review. Unfortunately the realities of the business means that stakeholders are distributed across several locations and cannot always be physically present at the Sprint Review. Below are the options in order of preference.


Telepresence is the preferred method for stakeholder involvement in the Sprint Review when not able to physically attend. Scrum Master would schedule the telepresence rooms locally and at all remote locations if possible. The Sprint Review meeting should be conducted as if all people were in the same room.
      • Stakeholder sees what those present in the meeting room see
      • Stakeholder is not a disembodied voice but a real person
      • Scrum Team and other meeting attendees can see and gage stakeholder's reactions to product demo and artifacts
      • Scrum Team and other meeting attendees can see and gage stakeholder's reaction to comments, statements, and suggestions
      • Facilitator of the Sprint Review can better steer the Sprint Review back to the Sprint Review agenda when necessary
      • Difficult to overhear side conversations from remote stakeholders

Webex / LiveMeeting / Net Meeting / or other online collaboration tool:

Online collaboration tool is the preferred method for stakeholder involvement in the Sprint Review when not able to physically attend and access to a telepresence room isn't available.
Product Owner should specifically ask remote stakeholders for their input on the way forward for improving the product.

      • Stakeholder most often see what those present in the meeting room see
      • Stakeholders can follow and participate in discussions on the just completed work shown in the demonstration

      • All stakeholders will need the same online collaboration tool installed and available
      • Higher likelihood that remote stakeholders will talk over people in the meeting room
      • Higher likelihood that people in the meeting room will talk over the remote stakeholders
      • Easier to mis-read voice inflection and tone without seeing the body language
      • Difficult to overhear side conversations


Using only a speakerphone (no video link or web sharing) is the last option available for stakeholders who don't have access to collaboration tools and no access to telepresence equipment.
To give the stakeholder a voice in the Sprint Review, the Scrum Master or Product Owner, as appropriate, would ask those who are remote to provide their input before the Sprint Review meeting so the Scrum Team and stakeholders at the meeting can review their input together. This way the remote teams know that their input counts and will heard by all people in the room.
Product Owner should specifically ask remote stakeholders for their input on the way forward for improving the product.
      • Remote stakeholders have a proxy voice in the Sprint Review

      • Speakerphone stakeholders will not see what's being presented
      • Speakerphone stakeholders will find it difficult/impossible to follow discussions during the product demo and presentation of any related artifacts
      • Speakerphone stakeholders may find it difficult to collaborate with those in the meeting room without seeing the Sprint results
      • Higher likelihood that remote stakeholders will talk over people in the meeting room
      • Higher likelihood that people in the meeting room will talk over the remote stakeholders
      • Easier to mis-read voice inflection and tone without seeing the body language
      • Difficult to overhear side conversations

Wednesday, April 24, 2013

Developing a Sprint Goal

The sprint goal is used to help focus the Scrum Team on the objectives of the sprint, the higher purpose of why the sprint is necessary. The Scrum Guide has this to say about creating a sprint goal:

"After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

By the end of the Sprint Planning Meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment."

My team's Sprint Goal was, at times, essentially a summation of the user stories but the better Sprint Goals in my mind were those that served as a milestone for the development team, the customers, the business, or any combination of these. For example a Sprint Goal for the first sprint of a newly formed Scrum Team might be, "Show that we can add value to the customer using scrum." To achieve this goal the team would need to complete at least one story. You'll note that this Sprint Goal has two parts: one part is about adding value for the customer and the second part is about the Scrum Team realizing their own potential to deliver value using scrum.

In order to keep the development team motivated throughout the sprint,  I would suggest helping the team find a higher purpose and develop a metaphor to describe that purpose. Look for the benefit or who benefits from the sprint and coach the team to use this information in crafting their Sprint Goal.

During the daily scrum, I would ask the development team if any impediments might put achieving the Sprint Goal at risk. I would discontinue this once the development team themselves began alluding to the Sprint Goal in the daily scrum as they planned the day’s activities. My intent was to re-enforce the Sprint Goal as the primary focus rather than the stories, which served as a means to achieving the Sprint Goal.

The Sprint Goal and Shorter Sprints

If the sprint length is short, one or two weeks, then the Sprint Goal might not have the bite or grab the imagination as firmly as when sprints are longer. It could be that by the time the Scrum Team fully embraces the Sprint Goal, the sprint is over. The probable issue here is two-fold: 1), the development team, being technical in nature, will tend to associate themselves with the work rather than the reasons for that work, and 2), the Scrum Team may not be spending a lot of time developing the Sprint Goal for shorter sprints thinking time is at a premium.

As scrum master, you can encourage the Scrum Team to think about the bigger picture and understand the benefits and who benefits from the forthcoming sprint. The length of the sprint fades into the background as the team concentrates on these benefits. The amount of time taken to develop the Sprint Goal is rewarded by the development team gaining insight to the customer's, end user's, or business's needs, and satisfying these needs or moving toward the satisfaction of these needs is the real intent of the sprint.

Technical Sprint Goal

When the Scrum Team first formed up, Sprint Goals tended to be a reflection of the specific stories in the sprint, that is, they tended to focus on the technical nature of the sprint rather than the beneficiaries. This is most probably due to the former way software development was run using waterfall techniques. In a waterfall environment, the development team was not always privy to the reasons behind the requirements and the product owner, often a former BA, product manager, or project manager, hasn't yet learned the benefits of having development team understand the driving force or purpose behind the requirements.

In this scenario the product is the principal beneficiary of the effort rather than any customer, user, or business. The scrum master needs to show the product owner, and quite probably the business, that having the development team involved with the customers, end users, and the business is necessary to getting a better product, increasing the number of customers, and growing the business. The development team needs to understand the customer, end user, and business so better for them to put themselves in their position and visualize the customers', end users', and business's point of view.

Unfocused Sprint

Sometimes the product owner has prioritized the product backlog to do several features or functions at the same time rather than concentrating on one at a time. This probably is another throw-back to the waterfall days when all developers were kept busy on several aspects of the project at the same time. The result is that everything is "in progress" but nothing is "done".
There are a couple of reasons that this approach can be considered flawed. The first is this kind of approach can be construed as going against the agile principle, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." By working several features at the same time over several sprints, the team runs the risk of not delivering value at the end of each sprint. A customer may not be particularly thrilled being at sprint review after sprint review without seeing a completed feature.
The second potential flaw is the lack of flexibility to release early with only a partial set of planned functionality completed. For example, if a planned release has 5 new features, it's entirely possible for the business to release the product with only 3 of these completed if it can be determined that the product in its current state achieves "product/market fit." In other words, the cost of completing the remaining 2 features is greater than the perceived value of the product if these 2 were completed. If the product owner elects to do all 5 features in parallel, then the opportunity to release early, and begin generating revenue sooner, is lost.

Not Meeting the Sprint Goal

The Scrum Guide states that if the Sprint Goal becomes "obsolete", then the product owner may cancel the sprint. Since this implies a sudden, massive shift away from the perceived business value of the work in the sprint, this will be a very rare occurrence.
It's entirely possible for a development team to not meet the Sprint Goal but this doesn't mean the team has failed or that the sprint should be cancelled. What this most likely means is an unknown factor has made itself apparent during the sprint causing a slow-down of progress or a change in direction regarding design or technology. Not meeting the Sprint Goal is something that happens to all Scrum Teams and shouldn't be taken as a personal team failure but rather as a call to understand the root causes and correct them. Usually missing a Sprint Goal is due to an insufficient understanding of the work pulled into the sprint or, with less experienced Scrum Teams, over-committing and taking on more work than the team can handle.


Select a Sprint Goal that focuses on the beneficiaries of the sprint using the work as a guide. As a team, try to develop a metaphor to describe what the objective of the sprint is. Avoid the temptation to develop a Sprint Goal that reflects the work, i.e. product, over the beneficiaries.

With shorter sprints the Sprint Goal may not have enough impact on the team. The team should spend the time necessary to develop a Sprint Goal that adds meaning to the sprint even if the sprint is one week long. All sprints, regardless of length, should add value to the customer, end user, or business and the work in the sprint is a means toward achieving this value.

Try and keep a tight focus on the sprint and Sprint Goal. Working one feature at a time can get value to the customer quicker than working several features at once. It is better to have one feature "done" than to have several features "in progress" at the end of the sprint.

Do not get overly anxious if the Sprint Goal will be or is missed and don't be tempted to abort the sprint because of it. Use the sprint retrospective to analyse the root causes and make the appropriate corrections for the next sprint.

Friday, April 12, 2013

Agile Project Manger or Scrum Master?

I find that there's a tremendous amount of prejudice against certain words in the Scrum community and "manager" is near the top. A business can and will give their roles any title they feel is appropriate. I would bet the farm that in some companies, the Scrum Master role is more aligned to a Project Manager of old and that Agile Project Manager role is more aligned to the Scrum Guide’s definition of the Scrum Master. So far no help, right?

Most businesses that are or will be transitioning to Scrum will have an Agile champion on board to guide the transition. I was this person at my previous company and after some time the role of Scrum Master was identified and added to HR’s list. However, before that happened, the person in the Scrum Team coaching and helping the developers and product owner was known as “Scrum Master”. This happened due to training and coaching the software and product management departments received during the transition to Scrum. The internal view was that the servant-leader of a development team was called “Scrum Master”. The external view of the role as projected by the HR department, possibly following 10 – 20 years of tradition, might have still have the role listed as “Project Manager” but now with the added term “Agile” plopped in front. This shouldn’t be too much of a surprise as the adoption of Scrum starts within the software department and will only spread once the successes due to the application of Scrum are recognised. As the Agile champion, my focus was on the software department and not HR, (in the beginning). After a couple months and Scrum had an obvious foothold in the company, efforts to re-align HR roles and role descriptions (Scrum Master, Development Team Member, Product Owner) began.
As a practicing Scrum Master and I saw a job ad that said, “Agile Project Manager”, I would apply with the knowledge that the role is most likely that of a Scrum Master for a company in transition (or possibly stuck in transition). I might find out otherwise at the interview but that’s the point of the interview: the prospective employer and prospective employee determine if there exists a common understanding of expectations and responsibilities surrounding the role. Some may see this as waste but as the interviewee, I see interviews as a learning experience even when the ultimate outcome is no job.

One of the responsibilities of the Scrum Master in the Scrum Guide is, “Leading and coaching the organization in its Scrum adoption”. This is where it can be argued that the Scrum Master is charged with aligning the roles and role descriptions in HR with the roles and descriptions found in the Scrum Guide. If the Scrum Master(s) are unsuccessful in doing this today, then it means they try again tomorrow, and the next, and so on. As long as the internal application of Scrum roles is correctly aligned with the Scrum Guide, then this view external of the Scrum Team might be an annoyance but not necessarily a terminal problem.


In the final analysis the Agile coach and Scrum Masters need to pick their battles with an eye on impact and results. Getting management and the Scrum Team following the Scrum framework is to me, job one. Pulling the rest of the corporate structure in line with Scrum role descriptions i.e., HR and management, is of secondary concern in my view.

Friday, April 5, 2013

How To Recognize A Self-Organizing Team During Sprint Planning

As a Scrum Master, one of  the ways you serve the development team is by coaching them in self-organization.  Several [hundred] definitions of self-organizing exist on the web but I'll use the Scrum Guide and add a point or two.

"Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. ... No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality." - Schwaber, Ken and Sutherland, Jeff. "The Scrum Guide", October 2011.

The Scrum Guide definition focuses on the development team understanding and undertaking the work they do during a sprint. The Scrum Guide specifically wants the development team to control how they do the work of the sprint. I would add to that definition two points: the development team acts as their own technical (not line) manager and the development team displays strong professional bearing, unity, and are respectful of others. This manifests itself with the development team understanding and anticipating the technical actions required to implement scrum in the most efficient and expedient manner and the development team working very closely with the product owner (PO) throughout the project.

Self-Organizing During the Sprint Planning Meeting

The Scrum Guide suggests time-boxing the sprint planning meeting at 2-hours for each week of the pending sprint but as the development team becomes more self-organizing, the amount of time necessary for planning should greatly decrease. The two main reasons sprint planning can become shorter are:
  1. The development team has a very good understanding of PBI's coming into the planning meeting primarily due to helping the PO develop the PBI's and conducting product backlog grooming sessions.
  2. The development team and PO work very closely together, discussing customer wants and desires, customer requirements, and customer expectations throughout the project.

Sprint Planning Meeting Part I

The first half of the sprint planning meeting has the PO presenting the ordered product backlog to the development team and the development team forecasting what they can do in the upcoming sprint. In an ideal first half, the self-organizing development team "pulls" off the top x items from the backlog the PO presented and adds these to the upcoming sprint. The development team and PO have already discussed the PBI's during previous grooming sessions but the PO may have made some changes since. The development team and PO review the selected items and any changes made by the PO since the last grooming session. The development team and PO then conjure up a sprint goal and the first half of the sprint planning meeting is done, probably in less than 20-minutes.

Sprint Planning Meeting Part II

The second half of the sprint planning meeting has the development team figuring out how to deliver the PBI's for the sprint. The self-organizing development team will identify enough tasks for the first few days of the sprint. The development team may re-negotiate with the PO if they determine that they cannot do all the PBI's in their present form (i.e. a need to reduce scope) or the development team may find they can do more PBI's and "pull" in these from the product backlog. The second half of the sprint planning meeting now concludes and the sprint starts.
The elapse time for the sprint planning meeting should be less than an hour, under 30-minutes for a two week sprint, when the development team takes on the responsibility to groom the product backlog and understand PBI's to the extent that these PBI's are "sprint ready" i.e., ready to be worked with only minimum review and recap.

A Clue That The Development Team Isn't Fully Self-Organizing

During the sprint planning meeting, the product owner pushes the requirements onto a "dazed" development team.
Picture a sprint planning meeting with a team only recently introduced to agile and scrum. In the first half of this meeting, the PO is presenting product backlog items to the development team. A development team member asks why a story [feature, requirement] is in the upcoming sprint. The PO and development team spend considerable time discussing the necessity and merit of each PBI for the upcoming sprint. In this scenario, there's no indication the development team understands the product backlog items and are merely reacting to what the PO has presented.
There are a few reasons this kind of behavior might be present:
  1. The development team is in command & control mode and doesn't feel it's their place to "pull" work,
  2. the product owner is in command & control mode and feels the need to "manage" the development team,
  3. the development team is not grooming the product backlog with the product owner, or
  4. the development team doesn't understand the product backlog is ordered.
It can be the hard for a development team used to command & control to become self-organizing, especially if the team is transitioning from waterfall. Similarly, if the PO is formally a product manager or project manager, they may have difficulties letting go of the command & control aspects of their former roles. Either of these two is likely to occur and have much the same solution, the scrum master needs to train these people on the philosophy of agile, specifically agile principles:
  • Business people and developers must work together daily throughout the project.
  • The best architectures, requirements, and designs emerge from self-organizing Teams.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
These agile principles coupled with the rules and practices of scrum outlined in the Scrum Guide, can start the journey towards a self-organizing team.
The third reason the development team is not involved may be the team isn't working with the product owner to groom the product backlog. Product backlog grooming helps to develop an understanding of the requirements both technically and from a business value (customer) point of view. The scrum master should ensure the development team and PO do grooming and may need to facilitate the initial grooming sessions to make sure this happens. The scrum master can encourage the PO and development team to work together developing PBI's for the customer requirements, develop the acceptance criteria for the customer requirements, and to discuss any risks or issues associated with the customer requirements.
The forth reason a development team isn't "pulling" in work from the product backlog could be they don't quite understand how the product backlog is structured. The Scrum Guide states that the product backlog has the attributes description, order, and estimate and "is often ordered by value, risk, priority, and necessity." Although the PO can decide how to order the product backlog, the product backlog is not the private domain of the PO. There should be no secrets or surprises in the product backlog. The scrum master can help maintain the transparency of the product backlog by facilitating product backlog grooming sessions and by encouraging the PO and development team to break down and write the more detailed customer requirements together.


One of the ways the scrum master serves the development team is to coach them in self-organizing behavior. The development team will become more self-organizing as time passes and one way to see this progress is by observing the way the sprint planning meeting runs. As the development team becomes more self-organizing, one effect should be the swiftness of the sprint planning meeting. This will be primarily due to the PO and development team working in close harmony together as customer requirements are developed, broken down with details added, and the PO and development team sharing a common understanding of the value of each "sprint ready" requirement.