3 More Questions to Ask During Stand-ups

Most everyone is familiar with the three traditional Scrum questions answered during the daily stand-up as presented in the 2016 Scrum Guide by Sutherland and Schwaber:

1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to help the Development Team meet the Sprint Goal?
3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The purpose of the daily stand-up is for the Development Team to review the previous day's plan and then arrive at a plan for the next 24-hours. In most cases, the Development Team can do this pretty well. The daily stand-up is a straight forward and simple meeting that focuses on the sprint goal but what could be done different to enhance the team's daily goals and daily commitments, commitments which the Development Team will hold themselves accountable for.
To help focus the Development Team on the day's planned delivered value, "What will I do today to help the Development Team meet the Sprint Goal?", it is helpful to expand this into 3 questions before taking about today's plan:

2.1 What is the customer value you'll deliver at the end of today?

2.2 Is there something you can show the Product Owner today?

2.3 Is there something you can do to help get the most important story done today?

Now these three questions are not simply the fantasy of the Scrum Master but are arrived at jointly with the Development Team. Each of the above questions have their roots in team retrospectives and, in the beginning, the team wanted the Scrum Master to ask them. It's very important that the team agree to any enhancements to the daily stand-up. For teams still early in their Agile journey, these questions will probably not seem unreasonable. However, for more mature Agile teams, there definitely needs to be a strong motivation to adopt them. In my particular circumstances, the Scrum Team was very mature and each of these 3 questions addressed a very specific problem the team recognized.

2.1.  What is the customer value you'll deliver at the end of today?

When the question is asked, the team provides an answer in terms of acceptance criteria/tests that would pass at the end of the day that currently fail.
I started asking this question of the Development Team several years ago when it was brought up during a retrospective that during the daily stand-up, the team was focusing on the technical aspects of the work more than the customer problem they were actually meant to be solving. It wasn't that the technical stuff wasn't important, it is, but we wanted the team to keep some focus on what why and who they're doing the work for. During the retrospective, the Product Owner said he was unclear of the progress of the user story, specifically the progress of the user story from a value perspective. More focus on the acceptance criteria and tests was a natural way to convey progress on value completed. The Product Owner was happy and the Development Team added the acceptance tests results as part of their daily planning.
This question provides an additional opportunity to further communications and collaboration between the Development Team and Product Owner. This is achieved by tying the customer, the acceptance criteria, and the solution together as a daily goal, a measure of value delivered each day.

2.2.  Is there something you can show the Product Owner today?

This question sprang from the Developments Team's observation that some work was being rejected by the Product Owner, especially user interface work, too late in the sprint to correct it. The problem was the team was waiting until the story was complete before showing it to the Product Owner. This usually resulted in a new user story being written and added for the next sprint.
During the retrospective, the team recognized that some user stories and the intended value were being missed during the sprint because of the delay in showing progress to the Product Owner. The Development Team and Product Owner quickly saw that viewing incremental progress was the answer but the Development Team needed to alter how they broke down the work into tasks to facilitate this. It was breaking down the work differently that was the real challenge for the team as it required some work to be done that would ultimately be thrown away. This was the occasional stub or driver code to get some display components looking 'right'.
This question provides an excellent opportunity to further collaboration between the Development Team and Product Owner. It serves to help focus on what 'done' means for a particular user story and helps reduce rework through a more collaborative approach to solving a problem. It can also make for a better product faster as the Development Team and Product Owner make any adjustments as a story progresses.

2.3.  Is there something you can do to help get the most important story done today?

This question got its start while 4 teams were working the same backlog and it was observed that new stories were being started while higher priority stories were still in progress sometimes with a large number of tasks in 'To Do'. Although this question came from a Large-Scale Scrum (LeSS) implementation, it scales down nicely to a single team working a single product backlog.
What the Development Team was trying to improve during a retrospective was their ability to swarm until done. When I was developing, I would prefer to work it alone, without outside help whether I could use it or not. The Development Team saw that this mindset tended to slow down getting stuff done and suggested that the question be asked during the stand-up to heighten awareness that getting to 'done' was important. The way it eventuated was tasks still in 'To Do' for the higher priority stories were picked up. It also helped in identifying tasks that needed further breaking down.
The question provided additional visibility to getting stuff done rather than getting stuff in progress. Getting work done quicker gives the Product Owner maximum flexibility in releasing or A/B testing of new features. Unfortunately, companies sometimes look at 6 developers and wonder out loud why there aren't 6 stories in progress.

Outcomes

After having the Scrum Master ask the 3 additional questions at the start, the Development Team began using the questions in context to their plan for the day and the questions themselves weren't asked after a time. These 3 questions helped the team find the deeper meaning to the question, "What will I do today to help the Development Team meet the Sprint Goal?"

Please drop me a line and let me know what you think and your results if you give this a try.

Tweet

Agile: Don’t Sell It, Demonstrate It

There are many things you can sell including some ideas but you can’t “sell” behavior and you should not try to sell Agile to people. Both of these are learned and become part of what you are; they become the standards of behavior by which you live. Because these are learned, try substituting “demonstrate” for “selling”. This is not to say you don’t persuade your C-Levels of the merits of Agile so you can experiment but selling alone isn’t going to be enough. If you approach your C-Levels about being Agile you might start at a disadvantage because, unless they're planning on becoming an Executive Scrum team, their main interest in Agile will most likely rest on results and outcomes, not theories. To put another way, if the business needs a hole, talking about the merits of using a shovel over a spoon won’t get the hole dug and won’t bring any value to the business. Instead, demonstrate a great and mighty hole can be dug quicker and more efficiently with a shovel, then do it again just to show it’s repeatable.

The Experiment

When I first started using Agile, the CEO & company were faced with a particularly challenging business opportunity requiring an innovative software solution in 3-months. The CEO asked if development could meet a hard commitment in 3-months but the answer was no. We followed a Waterfall paradigm at the time but we knew we couldn’t execute successfully in the short time available using our current methods and practices. Being in the right place (the business needed an alternative) and at the right time (we had just completed research into the various Agile methodologies), and of the proper Agile frame of mind (we were eager to experiment with Agile), I was able to implement a variant of Agile Scrum that allowed us to pivot 180 degrees and build a software solution within that 3-month window. Agile and Scrum made it possible for Development and Product Management to capitalize on our business opportunity quickly and efficiently. Did the CEO want us to do Agile? The simple answer was he really didn’t care what means or tools we used to be successful; what he wanted was for us to be successful. Adopting a flavor of Agile gave him and the business the result and success they wanted. And once he had seen a positive result, he asked why all the development teams weren’t using “that Agile thing”.

The Demonstration

The CEO was never “sold” the idea that Agile was anything special but instead we demonstrated that Agile could bring special results. The CEO, the board, and the shareholders want the company to be successful and profitable. If the way to achieve success is both repeatable and sustainable, all the better. If they had that success using Waterfall or Agile or any of the dozen or so other software methodologies, everyone would be happy. The R&D Manager and Head of Product Management suggested to the CEO that the only real possibility of success lies with using an Agile Scrum framework and practices. This was essentially the only executive coaching needed. The high visibility resulting from using Agile Scrum and Agile’s built in ability for the team to absorb changing requirements, gave the company a fighting chance to take advantage of the opportunity which, in the end, was met, exceeding most expectations.

To move the business at its highest levels often requires a demonstrable success. A business may still choose not to change after a demonstration (or two) but what are your chances for change if all you have are theories and anecdotal data from other companies?

Tweet

Product Backlog Flows

There are plenty of discussions in the agile community about how agile teams work and develop over time. Often neglected or poorly understood is how that work makes its way from the customer to the team. Below is a blueprint for creating an effective and efficient flow of work. I’ve included details but also left it flexible enough to be customized for your company’s specific circumstances.

- See more at: http://pragmaticmarketing.com/resources/product-backlog-flows#sthash.7ZvUkYFt.dpuf

Tweet

Self-Organizing Development Team

Definitions

·        Self-organizing teams are composed of individuals who manage their own work, pick up work based on need, and participate in team decision making.

·        Self-organizing teams must have a common focus, mutual trust, and respect.

By being self-organizing and self-managing, the team brings decision making to the level of the problem. This increases the speed and accuracy of problem solving.

Self-organizing and the Scrum Framework

The Scrum Guide gives the Scrum Master the role of coaching the Development Team in self-organization but doesn't provide insight or guide as how this is accomplished. So …

Tips For Management, Agile Coach, and Scrum Master to organize a team toward self-organization

·       Management (yes, management) must establish any parameters that the scrum team is required to work within. For example, usually only managers can hire and fire people. Otherwise, management should ensure they don’t get in the team’s way. Managers need to support the scrum teams rather than be a distraction.

·       Give a scrum team room enough to fail in order to allow them to succeed. Managers must not ‘step in’ every time they perceive the team is on the wrong track. The team may very well be on the wrong track but there are several inspect & adapt opportunities for the scrum team to correct itself. This is the big reason sprints are short, no more than 30 days, and most often 1 or 2-weeks long. I've seen a development team start a sprint, go down the wrong architectural path, discover it, do a re-design, re-do work they had already done, and still meet the sprint goal. True story. However, the chief architect had chewed his nails down to the knuckle while not saying anything. How proud was the development team after this? Extremely – they were trusted to get the job done and done right.

·       From the start, guide the team to do scrum (scrum guide). Shape the mindset and expectations from the start as this will be harder to influence and change later. Doing scrum by-the-book will not make you good at doing scrum but it will be easier for the team to later learn and adopt the nuances and spirit of scrum. 

·       Help the team become confident in their use of scrum early on. Use examples of how each inspect & adapt meeting can help improve the team’s work and their environment.

·       Remove any misconceptions the team has of scrum. Most teams will perceive that scrum is easy to do but it is actually hard to do scrum right day after day. Anticipate the development team’s reaction to this truth.

·       Use positive reinforcement and build a sense of achievement in the team by helping guide the team to successfully completing their sprints. Do not allow a team to over-commit in their sprint planning meeting based on hope alone. Guide the team to select a sprint goal that is achievable and don’t let ‘hope we’ll get it done’ be the team’s strategy. Hope is not a strategy.

·       Encourage ongoing adherence to scrum and agile practices. Watch for danger signs the team is reverting to older, non-agile ways of thinking and doing. For example, do they want to skip the daily scrum or sprint retrospective. Do they think only one person can do work in a specific area. Are they not forthcoming at meetings.

·       Get the customers and users involved in the process. Customers and users need to be engaged during requirement gathering but most importantly, must be engaged with the scrum team during the sprint review. If the customers or users are consistent no-shows at the sprint review or not showing interest at the sprint results, the development team will more likely lose their sense of purpose and possibly blame agile for their lowered self-worth.

·       Inspect & Adapt over blame. When someone on the team messes up, don’t say “Jane screwed up” or anything like this. I would try and restate it along the lines, “how was it the team allowed this thing to happen and what can the team do to prevent this from happening again?” Encourage the team to re-examine their team processes to see if something needs to change to avoid repetition.  Every effort should be made to make the team, as an entity, the focal point during inspect & adapt meetings and discussions rather than specific individuals. This will help reinforce that the everyone on the team is equally responsible and accountable for the results and outcomes of the team. This is along the “all for one and one for all” philosophy. While it’s important to know someone forgot to get their code, document, etc. reviewed, it’s more important to understand how the team allowed this to happen and to see if there’s something the team can do in the future to prevent it from happening again.

·       Identify team members who hamper or slow down the team’s productivity because of their personal characteristics and practices. Individual personality of team members can be considered more important than skill sets when selecting people for a development team. Work with the team and management to remove people who have difficulties adjusting to agile. This is a hard decision but one that needs to happen quickly; these are not ‘bad’ people but are people who can’t adjust to agile and scrum ways of thinking. Many believe the most productive scrum teams are open, honest, willing to change, and can see the team being greater than the sum of the individual team members. If a person doesn’t have or can’t quickly acquire these characteristics, then they may be an obstacle to self-organization and pose a threat to productivity necessitating their removal.

Tweet

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

Tweet

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.

 

Summary

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.

 

 

Tweet

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.

 

Summary

 

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.

 

 

Tweet

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.

 

Summary

 

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.

 

Tweet

Documenting Your Best Practices

I think it's important for the software organization to have documented Best Practices to provide a common starting point for all engineers, whether new or well-seasoned. The term Best Practice simply means this is the most efficient or simplest or greatest customer/business value, (I would stress the latter) way of doing something known to date. What Best Practice doesn't mean is that it's a rule. Rules change infrequently but Best Practices are always open to change.

The business may have a rule that an agile team must have a daily stand-up meeting visible and accessible to anyone who wishes to attend given the space available. How an agile team implements the daily stand-up meeting is subject to one or more Best Practice. There may be a Best Practice that has the Scrum Master facilitating this meeting, asking three questions: what have you done, what will you do and what problems are you having. There can be another Best Practice that has a different development team member facilitating the daily stand-up each day in a round robin fashion. Both these Best Practices can exist at the same time, in the same document, until one is proven better or, if they are equally beneficial, one is proven more popular.

I think that Best Practices are potentially updated after each agile teams' retrospective. One major pitfall of documenting Best Practices is these are never reviewed and updated. The business must guard against Best Practices becoming static and agile teams or the development manager need to ensure there's an ongoing effort to review and validate all Best Practices. If the Best Practices document hasn't changed in 30 days then maybe the agile teams are not trying to improve since most Best Practices are used in each sprint and subjected to retrospective review at the end of each sprint. If for example, all agile teams adopted the practice of having the Scrum Master facilitate the daily stand-up, having tried and rejected having a development team member facilitate, I would probably remove the Best Practice of having a different development team member facilitating the daily stand-up.

One last point, I don’t think there’s generally a great amount of detail in Best Practices as these are not always step-by-step procedures, at least not in an agile environment. If there’s a Best Practice to use planning poker in a sprint planning meeting (or grooming session) then there’s probably a brief description of what planning poker is and maybe a link to Wikipedia. Planning poker is a good example since there are at least a dozen different implementations that are almost but not quite the same. However, a code review Best Practice may be very detailed because there’s proven value in your company by following these detailed steps.

 

Best Practices document the way you do things now so you have something to use to measure improvement against. Best Practices become the organizations best training aid for new-hires and is the guide for all. Best Practices change all the time as agile teams experiment and replace outdated practices with new and better practices. Taiichi Ohno of Toyota Lean Manufacturing fame is quoted as saying, "There is something called standard work, but standards should be changed constantly. Instead, if you think of the standard as the best you can do, it's all over. The standard work is only a baseline for doing further kaizen. It is kai-aku [change for the worse] if things get worse than now, and it is kaizen [change for the better] if things get better than now. Standards are set arbitrarily by humans, so how can they not change?" All you need do is replace "standard" with "Best Practice".

 

 

 

Tweet

Retrospectives With Scientific Validation

During retrospectives, agile teams would benefit from following the Lean Startup concept of testing their improvement hypotheses using scientific methods. My experience during agile retrospectives has been that for most 'improvements', there's no deliberate validation that the change actually makes the hoped for improvement. The trick is to select quantifiable measures that can be directly linked to the 'improvement' i.e., cause and effect are firmly linked. In essence, the Scrum team conducts a scientific experiment to determine if for some action/activity/change they get a measurable improvement.

It's important that the team only do one improvement at a time so that any effects can be attributed to the improvement. For example, if you're introducing pair-programming to reduce acceptance tests failures but you've also introduced a new test harness to help increase test coverage, you might find it difficult or impossible to determine which of these two affected acceptance test results and by how much.

The retrospective process steps:

1. Problem Statement: Clearly state the exact problem the improvement will solve
2. Desired Outcome: Clearly state what the results will be with the improvement in place
3. Experiment Summary: Develop the falsifiable* hypothesis for the improvement
4. Measures: Identify the metrics and measures to collect
5. Data Collection: Identify how the metric data are collected. Identify how the collected data is presented
6. Results Validation: Identify how the team will know the hypothesis is proven true beyond a reasonable doubt. Identify how the team will know the hypothesis is proven false beyond a reasonable doubt

The information gathered above is the output of the retrospective. The team should place the falsifiable hypothesis for improvement [retrospective experiment] in a prominent location so everyone in the organization can understand the problem the team hopes to solve, what the experiment is to solve it, and the hoped for results of the improvement.

*A falsifiable hypothesis is a statement that can be proven wrong through observation or experiment. The structure of a falsifiable hypothesis is, "The team will [make this improvement] by [doing/not doing this action or activity]."

Tweet

Development's First Sprint: Things To Improve

There are many concepts of Agile and Scrum that new Development Teams may have trouble with in their first couple of sprints; daily builds not working, acceptance tests not automated, regression tests not automated, and on and on. These problems will pop up and the team will need to deal with them as well as anything else that comes between the team and a quality product they can be proud of. I've listed below some problems that by themselves aren't that big but I think have a long term impact on how well a Development Team becomes self-organized and cross-functional. I believe these are transitional problems that once solved, can help turn a group of individuals into a strong Scrum Development Team. 

Development Team isn't collaborating on designs and task identification.

The last thing a Scrum Master wants to hear at a retrospective is that team members couldn't help one another during the sprint because, "I didn't know anything about ___ ". This, or something like it, will happen in the Development Team's early sprints. The biggest reason for this is not everyone in the Development Team understands the high-level design or knows exactly what the tasks are about. This is usually the result of the walls people have built around technology areas or themselves. This behavior is often seen in a waterfall environment where the individual hero is praised and usually given the greatest rewards. However, the reason you and the company are most likely moving to Agile is to increase productivity, have more frequent releases, have happier customers, and increase profitability. The concept of  individual heroes now becomes a drag on these plans; no one can pick up the work of a hero if that person is sick, on vacation, or wins the lottery and leaves. Heroes also tend not to ask for help if they find themselves in some kind of trouble; that wall they built not only isolates the technology but it also hides mistakes and indecision.  Agile and Scrum welcomes these heroes into a Development Team but asks that they do two things: teach their specialty area to other team members and to learn the specialty areas of other team members. Having a Development Team that can do most any job, even if it takes 3 times longer to do it, will have profound benefits for the Scrum Team, the customers, and the company. A Development Team where everyone can collaborate on the design will result in the best designs. A Development Team that collaborates to find the simplest tasks to accomplish work will maximize the amount of work not done.

The Development Team's collaboration begins with the second part of the sprint planning meeting. This part of the meeting is for the Development Team to start "designing the system and the work needed to convert the Product Backlog into a working product increment." This is meant to be a collaborative effort by the Development Team to identify the work necessary for the first couple of days of the sprint. The Scrum Master should not only ensure this collaboration happens during the sprint planning meeting but should also ensure that the team does this throughout the sprint to identify the designs and tasks needed to complete each story.

Development Team feels estimating is a life and death struggle.

I was once at a sprint planning meeting where one person could not live with an estimation of 8 hours and insisted the 'correct' estimate was 12 hours. This person could not compromise on 9, 10, or even 11 hours: the correct estimate was 12 hours. I'm sure that in every company, every person estimating has experienced this in one form or another. There are going to be people in the Development Team who are afraid of being wrong or insist they're right. There may even be rumours that someone was let go because of poor estimations. Where I worked, this was a commonly stated 'fact' but even the smallest amount of research showed that this never happened; no developer was ever fired simply because they made an estimate that proved wrong. The Scrum Master can limit this by having the Development Team use story points and Planning Poker. Story point are just abstract enough to help the team reach consensus without getting too bogged down in precision. Another technique that can help is the Fist-of-Five for reaching a consensus. Use a 2 or 3 minute egg timer to hold debates over different estimations to a reasonable time limit will also hasten consensus.

The Scrum Master can show that there are no adverse repercussions with estimations by noting the estimates of tasks and stories and comparing the estimates with the actuals (don't attribute names to these). During the sprint retrospective ask the team to explain why some estimates differed from the actuals and let them suggest improvements to estimation techniques. The team will come to recognize that they provided the best estimates they could based on the knowledge they had at the time. However, the Scrum Master must be prepared to answer the inevitable suggestion that the Development Team do prototyping and design before doing story estimates and task breakdowns. The answer to this lies with the estimates Vs actuals. I had found Development Teams estimates are generally around 10% - 20%; a very good showing (the Nokia test has the goal of +/- 10%). It's likely that the Development Team does pretty well on their estimates but may have the occasional anomaly where they're off. Every time team estimates are off by > 50%, they should analyse the possible reasons during the retrospective. All of this analysis is done within the Development Team and isn't something that is made public although lessons learned are often shared with the organization. Outside the Scrum Team there really isn't any indication of estimation accuracy except maybe the team's velocity. However, velocity is an average over several sprints and won't be meaningful for new Development Teams until the 4th, 5th, or even 6th sprint. By this time, the Development Team should be less anxious over their individual estimates.

Tasks should be pooled and not assigned to individuals.

Development Team members may assign or take sprint tasks during planning and not concern themselves with other tasks not assign to them. Prior to adopting Agile, this is the generally accepted behavior but it will get in the way of a Scrum Development Team's being self-organized and cross-functional. The Development Team must exercise collective ownership of all work necessary to complete a story, after all, the team is held accountable to doing the work, not one individual. One thing the Scrum Master can do to help re-enforce accountability and provide cross-functional training is to have the Development Team members take the task from the person on their right and do that task instead of the one they announced during the meeting. This won't be popular with the Scrum Team and it probably won't be too popular with managers attending the daily scrum so don't do this too often; once or twice in each of the early sprints. This will drive home the lesson that there will be times when team members are sick, on vacation, or leave the company and the other members of the team need to step up and do work in areas they're uncomfortable with. In my experience, the discomfort is fear of the unknown rather than being technically incapable of doing the work.

The Scrum Master can also suggest that the Scrum Team do 1 week sprints. This forces the team to concentrate on just a few user stories, generally working on 1 story until it's completed before going on to the next. The Development Team members will often say that there isn't enough work on 1 story to keep everyone busy. My suggestion is for the team to sit down together and lay out all the tasks of a story showing what bits can be done in parallel and which ones have dependencies. This will generally result in a tasks for a story that are smaller and more detailed than the team would have previously done. Following a 'test first' philosophy, for both acceptance tests and unit/integration tests, will allow more people to work a single story and can even get the story completed faster.

Development Team is found skipping peer reviews and testing of software prior to delivery to repository.

This is one of those issues that occurs most often when the team feels pressure (real or perceived) to deliver something, anything by a specified time or date. If the Product Owner or management is exerting undo pressure on the Development Team, creating anxiety, the Scrum Master needs to re-educate them on the rules of Scrum, specifically, "Development Teams are structured and empowered by the organization to organize and manage their own work." It may be very hard or impossible for the Scrum Master to protect the team against excessive management pressure but the Scrum Master must try and convince management that the Development Team deserves the chance to be successful. Finally, if the Scrum Master is exerting pressure then you probably need to find a new Scrum Master, one better informed on Scrum.

I've also seen this problem because the developers are skipping reviews and tests on their own initiative. During a retrospective after a particularly embarrassing delivery to the customer, the Development Team asked that the Scrum Master double check the team's quality controls by asking for each completed task identified in the daily scrum: 1) was the new/modified code peer reviewed, 2) has all new/modified code been unit tested, 3) has the new/modified functionality been system tested, 4) have acceptance tests been run or partially run, and 5) has the product been regression tested in the affected areas. The scope and depth of testing is left to the Development Team's collective common sense. This actually worked well and after a couple of sprints the questions were no longer asked. What was interesting was how the developers reacted to these questions in the daily scrum. At first, some team members were sheepish and I got the impression that sometimes the answers weren't completely true but no one else on the team said anything. After a few more daily scrums with these questions, the other team members would occasionally question a team member's answer. Eventually the team members would question what was done before the Scrum Master could ask a question.

Tweet

Before the First Scrum: Development Team

The members of the new Scrum Development Team are usually drawn from the company's existing software development organization and have probably been following a waterfall methodology until now. If your company's planning on using a Scrum Coach, then most of what follows may not be applicable as the coach with have their own methods and techniques. However, for those organizations that will have their Scrum Teams self-start from within, here are some points on how to select the Development Team and prepare them for their first sprint.

Selecting the Development Team

The Scrum Guide lists the Development Team's characteristics as: self-organizing, cross-functional, having no titles other than Development Team member, equally shared accountability for the sprint, and no sub-teams within the Development Team e.g. database, test, GUI, etc. Although it's possible that your first Development Team will have these characteristics, it's very unlikely. These characteristics are what the Development Team hopes to achieve and it's the Scrum Master that will help guide the team as quickly and with as few detours as possible over the first half dozen sprints or so.

So what is it you're looking for when forming a Scrum Development Team for the first time? There's really only one thing that needs to be considered: the Development Team will need to have the technical expertise to do the work that the project's requirements demand. The company I worked at did exactly this when forming their very first Scrum Development Team and it proved to be a success. A step by step approach to select and prepare a Development Team for Scrum might look like this:

1. Review the project's requirements to determine the necessary functionality and necessary technical competencies needed for implementation. The review is probably done by Product Managers, Project Managers, senior architects, and team leads. The irony is that with the exception of Product Manager, these roles will almost certainly disappear as the software organization moves toward Scrum. The Scrum Team as a unit will replace the team leads, architects and project managers as they become more self-organizing.

My first experience with Scrum started this way. The company was doing waterfall when a new business opportunity came along. Once management, particularly Product Management and R&D Manager understood the requirements, it didn't take long to see that waterfall methods wouldn't be able to meet the contract dates. They concluded that a different development methodology was needed that could quickly implement a few hundred requirements but be transparent enough so unnecessary and problematic requirements could be dropped long before developers wasted a lot of time on them. Agile and Scrum provide the transparency and seemed a logical fit in order to meet the contract.

2. Based on these needs, create a list of 5 - 7 software personnel that will satisfy most or all of the technical competencies needed. Everyone in a development organization should be considered for membership in a Scrum Development Team. The only exception might be someone known to be totally unable to work in a team environment. Even then I would suggest placing these people in a Scrum Team as you might be surprised who fits in and who doesn't. Management should allow everyone a chance to succeed in Agile. Try to avoid putting only the very best software people into a single Scrum Team. It isn't necessary since the total of knowledge in a Scrum Development Team is usually greater than the knowledge of any one individual. And besides, if your company decides it will have 2, 4, or more Scrum Teams, the more experienced people can be seeded to every team rather than all in one team.

My first Scrum Team consisted of the most experienced people (team leads) in the software organization and were selected based on the technical requirements of the project. The project had 4-2 week sprints and was a great success. After the two month project ended, the Scrum Team split up. Although they did the principle Scrum activities; sprint planning, sprint, daily scrum, sprint review, and sprint retrospective, they didn't really do Scrum all that well. In my view, having only the most experienced or senior engineers in one team, the ones who have been doing waterfall the longest, will slow progress toward self-organizing and being cross-functional. These senior people will have to change the most to adopt Agile and Scrum. For example, during a daily scrum meeting it became apparent that one team member wasn't doing any of the tasks on the scrum board in his specialist area. No other Development Team member questioned this. When I asked what task he was doing he said it would take longer to explain what he was doing than to do it. He didn't ask his fellow team members for assistance but neither did any other team members offer to assist. The Scrum Team's team lead called in an architect to help on the problem and after working the weekend, the problem was resolved. In the post project review it turned out that because most everyone on the team was a fairly senior engineer and team leader, they felt that the Scrum Team's team lead would sort it out as they would do if they were the team lead. In the pre-Agile environment, the team lead had the responsibility for solving technical problems for the team and was generally held accountable for the team's success. In Scrum, the accountability for the success of a sprint rests equally among all the team members. This is a significant power shift for former team leads.

On the other hand, getting the more senior software people on board with Scrum through a short-ish project can have long term benefits. Once this team breaks up, they can go to other new teams and be champions of Scrum within their new teams.

3. The Scrum Master introduces Agile and Scrum to the newly formed Development Team. The focus should be the Agile Manifesto and the 12 principles. The Scrum Master should describe the Scrum Roles, the expectations of the Development Team as they relate to Scrum, and emphasize the Development Team's empowerment to find and implement an appropriate solution. I would suggest this be a short introduction; no longer than 60 minutes. Review the Agile Manifesto and Scrum Guide and then tell the Development Team that they're empowered to run the sprint as best they see. Start sprint planning that day or the next.

A short meeting (< 60 minutes) just to present the facts of Agile and Scrum will help the Development Team 'hit the deck running.' If you have a long, drawn out session, the conversation will eventually lead to discussing waterfall  which will invite comparisons between "the way we used to do it" and Scrum. This will lead the team members making choices between the two i.e. which is better. The purpose of this meeting is to familiarize the Development Team on Agile and Scrum and not to debate whether the company should be changing to Agile (I assume those discussions and decisions had already taken place). I suggest going through the Agile Manifesto first and then the Scrum Guide. When doing the Scrum Guide, relate the points in the Scrum Guide back to the Manifesto to help re-enforce the principles of Agile. An agenda might look like this:

1. Agile Manifesto
2. Scrum Roles
3. Scrum Principle Activities
4. Scrum Rules
5. New Techniques And Concepts [user stories, planning poker, acceptance tests, continuous integration, daily builds, ...]

4. Co-locate the Development Team removing any partitions, bookcases, or other office furniture that prevents the newly formed team from being able to make eye contact and hear each other talk. Get some whiteboards or have a wall located with the team where they can track their sprints (Scrum Board), add notes, do designs, document user stories and acceptance criteria, and plan the release. All this will help facilitate communication within the team. The Scrum Master and Product Owner should sit next to the Development Team's area where they can hear snatches of conversation and be summoned quickly but they shouldn't sit with the Development Team. Co-locating the Development Team, will help empower them to self-organize, makes it easier for the team to learn from each other (cross-functional), and fosters direct, face-to-face communications.

A few people, usually the shy or paranoid, will absolutely loath moving but the majority will be able to see the benefits. After a few sprints, the shy people will be noticeably more open and communicative and the paranoid people will be less fearful of their work being scrutinized.  Be sure to have plenty of white board space for the team.

5. Establish a Definition of Done for the Scrum Team (see the short paper Definition of Done: How to Ensure Compliance). The Scrum Master might want to assess the Development Team's capabilities for their first couple of sprints and allow the team to adopt a Definition of Done that offers the team a chance to succeed and yet has room for growth.  As the Scrum Team re-assesses their Definition of Done at each sprint retrospective, any weaknesses in the Definition of Done can be addressed and the Definition of Done modified to strengthen and improve the team's sprint results.

I found that the Scrum Teams had a terrible time adhering to their Definition of Done, especially in their first few sprints. I think the reason for compromising the Definition of Done is due to the long tradition of shipping products even when they weren't ready. The line goes something like; the customer would rather have something that almost works than to have nothing.  In pre-Agile you deliver something that doesn't always work whereas in post-Agile you deliver something that works but may not have all the features. This is a subtle difference but I think it's the key to Agile. The customer is meant to see new and working features and capabilities at each sprint review.

6. The team needs to develop the capability to generate daily builds before starting the first sprint. This phase is often called sprint zero. To take full advantage of Agile, the team needs the ability to generate workable builds on a daily basis.  This is part of continuous integration. Continuous integration is the practice of performing a clean build, conducting full integration, and running all tests every time a change is committed to the code repository. This is accompanied by frequent integration of each developer’s work into the code repository.

Working builds were a luxury during my first sprint but steadily improved during the subsequent sprints. This was a most import lesson learnt in our first venture into Scrum. At a minimum, the team needs to successfully run automated unit/integration tests on a daily basis to help ensure the quality of new code and ensure there's no regression on legacy code. The team needs to have a build notification message, usually emailed, that lets people to know what the build status is and exactly which feature was being delivered or what in a feature was being fixed.  The team should be striving to have acceptance tests automated and run on a daily basis. The team needs to get to the point where it is unacceptable for a build to be broken.  If the build breaks or the product regresses, the offending code is removed from the build and the daily build is then released.  The team must fix the bad code before any new functionality is added to the code base.

The Development Team should also automate their legacy acceptance tests and other system tests and have these run on the daily build. Legacy tests will most likely not be automatic but the team can add user stories to the product backlog to create automatic tests.

The Scrum Guide places the responsibility for educating and training the Development Team, along with the Product Owner, on the Scrum Master. Getting the Development Team together and ready for their first sprint is the easy part; the Scrum Master must now teach the concepts and intent of Scrum and Agile to the Development Team until they can do Scrum in their sleep. Hopefully, the day will come when the Scrum Master recognises that the Development Team really doesn't need a Scrum Master anymore.

Tweet