Scrum Masters: How do you deal with carry-over?

On a recent project, I was conferring with another experienced Scrum Master when we discovered a small but significant difference between our thinking around how to manage carry-over stories.  I’d like to ask this audience – what is your preferred method – and why?

The Scrum guide tells us that teams must deliver “potentially shippable product increments” each sprint – but what happens when they don’t?  What should a Scrum Master do - in terms of planning - when a story has been worked on, but not completed?

Usually the story is still at a high priority and so is ‘carried-over’ to the next sprint – simple right? …but one question – what is the estimate for that story? 

When planning a sprint, the team should look to their capacity and select the priority stories that can fill that capacity. But what happens when a carry-over story is brought from a previous sprint? It turns out my friend and I had different methods. Let me illustrate these methods and their implications:

Method 1: The estimate is the same as before, no matter how much work was actually done in the previous sprint – e.g. if it began as 8 story points (sp), the estimate remains 8.

carryover1.png

Pros: don’t need to re-estimate, the product backlog doesn’t change – easy!
Cons: This doesn’t reflect reality i.e the velocity figures skewed. The team might not reflect on estimates, and their estimates may become devalued.

As the carry-over story will be completed quickly (only 1sp left), The team then can either
a)    plan more stories in the planning meeting (in spite of velocity)
b)    Wait until these stories are done and plan more at the end of the sprint
c)    Do nothing and let the carry over story cover a gap in their velocity this sprint.


While this seems the easier method, everyone has to remember that the 8sp was a carry over, and adjust velocities and release plans.  If you are using Jira or another tool, then this can be a pain each time you show a report etc.  There is also a danger that estimates themselves become devalued, as they don’t change when the story is replanned.  These are less than optimum behaviours here, which is why I don’t prefer this method (although I have used it).

Method 2: Re-estimate the work remaining e.g. 1sp – and use that to plan the next sprint.

 

Pros: accurate velocity (both average & individual sprints), burndown charts etc. reflect reality.

Cons: The team has to re-estimate what is left. The Product Backlog and release plans are updated.

This is the method I use as it reflects reality and keeps everything visible and gives an easy start to a conversation about the story, its issues, and its plan.  However, when I do use it, the team often feel they have ‘lost’ points: they worked on an 8sp story, but now only get 1sp. This is true – and it’s also fair and good discipline.  They may have worked on the story, but it is not delivered, and that means no points!

The Role of Scrum Master

One of the Scrum Master’s responsibilities for the team is to ensure Scrum is enacted well, and that the team is improving.  That relies on having transparency of both good and bad stuff that happens.  When a team has not performed as expected, reflecting on carry-over work is the opportunity to review their estimates - to uncover any issues with a view to improving them and dealing with any issues. 

The team may not like the fact that their work has ‘lost points’, but then that’s what non-delivery is – the team should be mature enough to account for their work and be held responsible.  This must not be seen as blaming, but of being responsible. After all, the team is given responsibility for the estimates and for carrying out the work.  If something goes wrong, it needs to be highlighted and addressed by the team.

These are the methods my friend and I discussed, but what does the wider Audience prefer, and why?  Are there other options?  I’d love to hear your comments – or click ‘like’ if you were interested in this issue. 

Agile Team Start-up

A few weeks ago, a junior Scrum Master asked me for a check-list of tasks for starting a new Agile project.  I'm not a fan of check-lists, but this topic seemed appropriate, and useful. It also is a good one to ask for feedback and additions - what would you add to this?

My starting point would be to imagine what a Scrum Master should ask or do when beginning a new, long-term engagement (at least 6 months) at a client location, with a team who don't know each other or Agile methods!  Here goes....

1.Basic Environment

  • What is the security, building pass, access times policies of the client location?
  • What is the Desk policy? What furniture is available - can you bring in more?
  • Can you use the client’s printers, scanners, video conference, rooms, stationary?
  • Network, Wi-Fi, Servers, databases infrastructure: Can you use the client’s or bring your own? Who supports them?

2.Team Environment

  • Can the team sit together? Who else is around? Can you control how hot/cold, bright/dark, noisy it is?
  • What can be used as a physical Scrum board? Can you stick stuff on the walls?
  • Do you have a TV or projector for reviews, etc.
  • Find a Talk token, Ÿget a notice board, hang posters, calendars, etc.

3.The Team

Assuming the team doesn’t know each other, it is important to create good social relationships first to then build them as a team with a shared understanding, culture and skill base to prepare for development work.  Try to get them from ‘forming’, through ‘storming’ to ‘performing’ as easily and quickly as possible…

  • Use team games for Introductions, get to know each other, team socializing
  • What snacks, food, music, dress code is acceptable? Not everyone welcomes donuts!
  • Collect and publish team contact info, locations (virtual and physical)
  • Agree and publish the team’s availability – including PO & SM
    • Agree working agreements
    • What are the core working hours of the team?
    • How to deal with holiday, illness, and absence requests, etc.
    • Coaching ‐”Shu Ha Ri”
      • This is a good time to offer some Agile coaching to the team to raise their awareness of their Agile journey, for example, through “Shu Ha Ri”.  This helps sets the culture of realistic expectations, improvements, coaching…
      • Training. This is also a good time to organize some basic / refresher training in the following topics to bring everyone to the same understanding.
        • How to behave as an “Excellent team”
        • Scrum
        • Effective Story breakdown techniques
        • What Tools will we use e.g. for CI, Jira, etc.
        • Values: Now the team is forming, what values will it embody?
          • E.g. Commitment, Focus, Openness, Respect, Courage?
          • Pick a Team name, create some culture
          • On-boarding. When new team members join, how will they be brought up to speed? Can the training, teams values be documented? Use a buddy system?
          • Future Retro: Now the team has formed, get them to start looking forward to the work ahead in terms of outcomes. A nice way to do this is to hold a retrospective looking forward to the future, asking “What would you like to celebrate at the end of the project?” The focus should be not only on what they deliver, but how the team delivers, how they behave when issues come along, what the client/users/managers will say about them. It also helps practice their first retro in a safe environment.
  • Practice review – PO and team: Similar to the future retro, hold a practice review to find out how to hold effective reviews.  Important stakeholders should be attending, so make it as good as it can be.  How are the team’s presenting skills? What room and setup is best?  What progress indicators will the team show?  The review subject can be all the activities the team has done so far. 

4.Ready to Sprint

After building a functioning, informed team, the final stage is to get ready to Sprint, to identify the specifics of Scrum and the vision and existing backlog of the project. These should be carried out by the team collaboratively:

  • Choose an Estimation scale (e.g. Fibonacci) and  Identify stories as references
  • Write the Definitions of Ready and Done, and publish them
  • Choose a Sprint length and schedule, including:
    • Sprint Start day
    • Planning location
    • Daily stand-up time and place
    • Review, retro
    • Backlog refinement
    • Product Vision, Features, Non-functional requirements.  This is where the Product Owner can now step forward and introduce the team to the specifics of the product, presenting the business situation, current backlog, risks etc.
    • Milestones, phases, release plan: How has the product schedule been planned – e.g. Discovery, Alpha, Beta?
    • What Metrics will the team publish? What is their audience, their ownership and frequency?

Round Up:

One of the key parts to a Scrum Master’s role is to guide the team’s success and productivity, and the most important part of this is when the members first come together.  Once these points have been met, the team will be in a great place to start development and negotiate the challenges during the lifetime of the project.

But is there anything more that should be included?  What would you add or change for your teams? please add your comments below.

Are you Theory X or Theory Y?

The Agile Manifesto’s most important guidance is its first line:

Individuals and Interactions over Processes and Tools

To get the best from our individuals, the 5

th

of the Agile principles is:

Build projects around Motivated people

Motivation is important -  it releases energy and creativity to gain high performance. 

Of course the question is, how are people motivated? And thinking even before that, what do people need to be functional?

Self-Actualization

Agile looks to the work of American psychologist Abraham Maslow in the 1940’s “The Theory of Human Motivation”. Maslow studied exemplary people, such as Einstein, as to how they were motivated, and formulated his now well-known pyramid of needs:

The cornerstone of Maslow’s theory is that people have an innate impetus to continually develop and succeed, and that they naturally move to self-actualization only once all supporting “deficient” needs are met. 

The fourth level, Esteem, means attaining self-esteem and self-confidence through competence or excellence in skills, abilities and achievements. Having self-esteem leads to a sense of contribution, of achievement and recognition. When esteem level is met, people will discover their full potential and become self-actualized. They can provide support and guidance to others.

Management’s Attitude determines Motivation

Maslow’s theory leads to, among others, Douglas McGregor’s 1960 book “The Human Side of Enterprise” in which he proposes that the manner of management’s interaction with employees is their primary motivator.  McGregor posits there are only two ways to motivate individuals based on Maslows lower and higher needs, which he named

Theory X

and

Theory Y

.

Management that uses

Theory X

treat employees as:

  • They are Lazy and dislike work
  • Require close supervision and control
  • Lack ambition without incentives
  • Avoid responsibility
  • Only work through threats and punishment
  • Have personal goals that go against organization goals
  • Their creativity and imagination are not used for work

Summary

: Focus on methods of control and punishment to drive productivity.

In Contrast,

Theory Y

managers see employees as:

  • Ambitious
  • Self-motivated and self-controlled
  • Treat work as a natural and normal part of life
  • Initiate their own learning
  • Accept responsibility and commit to organization objectives
  • Appreciate and respond to recognition and encouragement
  • Enjoy solving problems
  • Are demotivated when their talents are not used

Summary

: focus on creating the right conditions for employees to be self-directed

McGregor's conclusion is that management using Theory Y leads to better outcomes and productivity for the individual and organization.

But so much for the Theories – what actually works?  

Well, when it comes to culture, generally management get what they expect, and leaders set the example and standards for behavior in their organizations – which theory should be used for the IT industry?

We saw that the Agile Manifesto rates people to the highest position. That’s because modern software development is  team is a creative, collaborative activity, high performing teams, leadership and responsibility at all levels

Transitioning to Agile means a large and complex cultural change. Theory Y enables this, while Theory X blocks. 

So Agile leaders must adopt Theory Y management style

Conclusion:

In 2010, Dan Pink’s Drive highlighted that there are less and less job roles where Theory X would be appropriate, whereas theory Y has become a significant advantage for companies

The factors for highly motivated people are:

  • Autonomy: people desire to direct their own lives. Gain control over their work
  • Mastery: to become better. Need and environment where learning is encouraged and mistakes are tolerated
  • Purpose: a natural desire to be part of something bigger than themselves 

So ask yourself, are you theory X, or Theory Y?

A Scrum Weakness: The Product Owner Role

The principles and practices behind Agile and Scrum are demonstrably better in terms of productivity, quality and job satisfaction. In the past 10 years in the UK, we have seen the Agile movement go from a crazy idea in the depths of Shoreditch to the defacto method of choice for government IT initiatives.

But Scrum is not perfect; it has weaknesses that all its practitioners should be aware of.  In this short series of blog posts, I will aim to discuss these weaknesses (as I see them) and explore their mitigation.

The Product Owner Role

The Product Owner is one of the key members of the scrum team and a critical success factor to any Agile development project but the Scrum Guide gives barely half a page to describe the role. "

The Product Owner is responsible for maximizing the value of the product and the work of the development team. How this is done may vary widely across the organization

"

While the description is terse, it is powerful in what it 

does not

say. Its guidance: "

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the product backlog...

"

But here is where I perceive the weakness: The Product Owner role is key, but in reality it is seldom possible to find

one

individual who can fulfill the role and be available to the team full time (and it is a full time role). As Product Owner, their duties include:

  • Communicate product vision and mission
  • Continually manage the backlog
  • Manage stakeholders at all levels
  • Explore and Discuss solutions with the development team
  • Attend planning, stand-ups and review meetings
  • and a whole lot more

In practical terms, projects need to find solutions that allows the product owner to perform well with limited availability, and when projects scale to medium and large sizes. Here are my alternatives:

Solution 1: The (mostly) unavailable Product Owner

Sometimes it is obvious who in an organization should be the product owner - but very often that person has a day job that they cant (or wont) delegate, even temporarily. The project should appoint a

proxy

product owner to share the role by taking on the day-to-day tactical effort, with the final strategic and authority staying with the Senior Product Owner. 

Solution 2: Product Owner for multiple teams

When a project is of medium size (3 to 5 teams), the Product owner role can be shared between the teams - that is one product owner manages one backlog from which the teams select their sprint backlogs. Depending in the type of project and skill of the PO, this can be managed well. The main drawback is the workload of the PO is taken up by several planning meetings and reviews each sprint. A good idea here is to arrange the backlog into Epics which are assigned to the teams.

Solution 3: Scaled Product Ownership

For large projects, One product owner can no longer service all the teams, and so must delegate to other product owners. This is best done along epics to allow the minimum of dependencies and context changes for Product owners and their teams. Notice that the pattern of a single authority for a product owner is maintained - we don't create a committee of product owners.

NB:

There patterns can be used in combinations!

Conclusion:

Scrum and Agile lore has grown up quickly to support people to become good Scrum teams - developers and managers know about stand-ups, self-organizing, planning poker etc, but there is little common practice to help with the critical role of the Product Owner. To help with your unique situation, use the principles in the scrum guide to better organize your product owners.

I have used these patterns to good effect and hope they are useful in your projects.

How can we manage NFRs in an Agile project?

Non-functional requirements can cover a wide range of context areas and operating restrictions for delivering software systems, including:

  • Performance
  • Security
  • Usability
  • Accessibility 
  • Scalability


Representatives of these context areas are stakeholders in the success of the product and should be treated in the same way as business process owners in determining the content of an Agile project’s product backlog.

Non-functional Stakeholders may include, but not limited to, Systems Architects, Security directors, Marketing, Database managers, Support teams in addition to customers and users of the product. These stakeholders should to have their requirements identified and captured by the Product Owner for inclusion in the product backlog.

However, non-functional requirements, once identified, fall into two distinct types: NFR stories and NFR Standards.

  • NFR stories are very similar to functional requirements in defining how a particular function should behave. They are independent of other stories. E.g. “Passwords must be at least characters and include at least one punctuation symbol”
  • NFR Standards set a standard for the behaviour of many parts of the product. They are not independent but must be included into other stories. E.g. “All data access to the accounts database must be audited”, “All web pages must load within 2 seconds”, “All web pages must conform to W3C’s WCAG 2.0 standard”


Standard NFRs cannot be implemented in isolation. Rather they are rules by which other stories must follow.  Typically in Agile methodologies, they are captured as acceptance criteria and integrated into functional requirements and their design. The team’s definition of done can also be used to insure NFRs are met, for example, by determining that all stories must have support documentation written before being accepted as complete. Backlog management tools, such as Atlassian Jira, have several features that can support NFR management in this way.

The Agile approach promotes the idea of testing as early as possible in the development process, and crucially, this can be applied to NFRs also.  Once standard NFRs have been identified to a useful detail (not necessarily finalized), functionality can be tested for compliance with NFRs while it is in development.  In modern development practices, continuous integration systems can ensure the delivered product increments, even early in development, can be repeatedly tested against the defined NFRs.  Any functions that do not meet the NFRs will be identified as early as possible. The tests and their results can be made visible to those stakeholders who defined them as well as the team developing the product.

This approach of capturing and testing NFRs early has many obvious advantages and there are several important steps to implement this model.

  1. The Product Owner and team need visibility of NFRs as early as possible, ideally before development begins. 
  2. SMEs and stakeholders must be identified who can be responsible for defining NFRs.
  3. Suitable environments, data, test tools etc. must be available to allow any specific testing that is required – for example performance test environment.


We don't do "pure" Scrum here

"We don't do 'pure' Scrum here"

Unfortunately, I have heard this all too often in recent weeks while setting up a new scrum team.  Other parts of the organization are having good and long term successes with scrum, but a different team manager has shown some resistance.

While reading Richard Hundhausen's book "Professional Scrum Development with Microsoft Visual Studio 2012" I found a great analogy for just this attitude:

"You can think of Scrum as being like chess.  Both have rules.  For example, Scrum doesn't allow two Product Owners just as chess doesn't allow [a player to have] two kings.  When you play chess, it is expected that you will play by the rules.  If you don't, you are not playing chess.

It is the same with Scrum. Another way to think about it is that both scrum and chess do not fail or succeed. Only the players fail or succeed.  Those who keep playing by the rules will eventually improve, though it may take a long time to master the game."

and those who do not play by the rules will never master the game.  and in fact are playing a flawed game, at best an untried, patchwork game of rules that are cherry-picked with no evidence or experience of their effectiveness.

in short, there is no "pure" Scrum.  You either Scrum, or you do not.