Shadow Backlog

ShadowBacklog

The team was under pressure to deliver a rewrite of the flagship product after having been handed an agressive delivery date. In spite of the Scrum board and other information radiators in their area, the Scrum Master had to deliver progress reports to the CEO every day. The company president and vice presidents attended sprint reviews and grilled the team whenever a story was not closed or sprint goal not met.

One could easily argue that a fixed scope and fixed delivery date is in no way agile – end of discussion – but this still happens in organizations that use (at least partially) agile practices leaving Scrum Masters to navigate choppy waters.

Of course the team developed some coping mechanisms, the most insidious of which was kicking the can down the road.

Whenever the team encountered unexpected complexity or scenarios when working on a story, they said “this wasn’t in the story that we planned, so let’s call the current story done so that our sprint metrics will look good and handle the extra stuff sometime later.” Everyone except for the Scrum Master was happy – for awhile. Team velocities looked good. Stories were being closed as planned. On the surface it looked like features were being completed. The teams were going to deliver on schedule. The Scrum Master knew deep down that they were either going to deliver late or deliver an application with enormous amounts of technical debt. She also knew that the organization could not handle to truth so she soldiered on.

Then the bubble burst. The collective “oh crap” moment happened when people realized that the system should be production-ready but was not. Some features were incomplete. Bugs were still there from parallel testing that had been performed months ago. There was no room in the time before the expected completion date to resolve all of the open issues. Market launch would be delayed.

The ‘shadow backlog’ existed in the developers’ minds and in the list of open defects that were logged elsewhere from ongoing user testing. There were no product backlog items for them and no sprints in the release plan for addressing them.

Reflections:
– Make sure that all remaining work is visible. Create backlog items for stories, technical debt, and bugs. The backlog consists of Product Backlog Items (PBIs), not just user stories.
– Get user feedback during the sprint to avoid surprises later. Ideally users are integrated into the process via acceptance test driven development (ATDD). At a minimum they have an opportunity to see stories in action and provide feedback in the sprint. Any feedback and new ideas that cannot be incorporated during the sprint should be captured as real backlog items and sized/prioritized.
– Don’t be afraid to keep a story open if it was more difficult or took longer than expected when sprint planning was originally done. Better to take a little heat now rather than have the bubble burst later.
– Avoid ‘bucket stories’ near the end of a release that become a dumping ground for stuff that did not get completed in the sprints. Bucket stories can quickly grow exponentially and delay the release.

The Heartbeat of an Agile Team

What is the one focal point that catches every team member’s attention at the same time every day?  Of course it is their Scrum board. Some teams go through the motions and use their Scrum board because they are told to; for effective teams the board is a way to collaborate, manage work in process, keep track of impediments and know whether or not they are going to meet the sprint goal. Effective teams turn their board into a highly-visible collection of critical information about their effort. It becomes the heartbeat of the team and helps set the cadence for each sprint.

Their board might look something like this:

Board

 

Sprint Dates and Goal – as a reminder of the goal and the timeline. Seeing the sprint dates can be helpful if users who will be testing attend the standups so that they understand the sprint timing.

Columns for each step in their development process – This can be as simple or as complex as the team wants – it usually evolves as the team learns and tweaks its process to ensure a smooth flow of stories. In the example above, the team experienced issues with too many stories waiting for user testing. They created a column to show which stories are ready for user testing to make it clear to users when something is ready for them to test. During standups, the Scrum Master points out any columns where an excessive number of stories are piling up. Even with Scrum, the team may set limits for how many stories may accumulate in each column before team members swarm to address a bottleneck.

Sprint Calendar – during sprint planning the team members estimate on which days of the sprint they think stories will be Done and also when they will likely reach any other significant milestones in the team’s process such as being ready for user testing. This is a way of performing a sanity check for the sprint plan.  It is also a way for the team to gauge whether or not it is on track during the sprint. When user testing is part of the Definition of Done, it allows the users to plan when they will be performing this testing. Putting team members’ planned vacation days on this calendar avoids surprises in the middle of the sprint. It can also help to put key SME’s or users’ vacation days on the calendar if these could impact the sprint.

Impediments – unresolved impediments. Making these visible is a way to track them and may have the side benefit of prompting outside stakeholders who attend the standup or visit with the team to help the Scrum Master by finding other ways to resolve them.

Additional Stories – these are stories at the top of the Product Backlog that are ready to be brought into a sprint but that are not part of the current Sprint Backlog. These are posted on the board so that they are readily available in case the team reaches the sprint goal early and can complete some additional stories in this sprint. Note that these are not called “Stretch Goals”. That term can be perceived negatively by the team, almost as if they are not pushing hard enough in the first place to meet the sprint goal.

Release Burnup – the bigger picture of what the team is working towards. This help avoid the sense of being in an endless churn of sprints with no end in sight.

For teams using Kanban, many elements on this board still apply but may need slight modification. Note the use of colors throughout the board.  It is amazing how teams will adopt color schemes or symbols that communicate the state of their work, highlight important events, serve as key reminders, etc. One type of information not included on the example above is an area for Technical Debt.  Creating an open area on the board for this invites the team members to note it as soon as it becomes apparent to them.  These notes can then be translated into backlog items during grooming. This encourages open discussion about technical debt and surfaces this information rather than just having it in the team members’ heads.

A note for teams that use online/electronic Scrum or Kanban boards: additional information such as the PTO calendar, Impediments and release burnup can be captured in story cards and placed in a column dedicated to that background information. The sprint calendar can be captured by putting Due Dates on each electronic story card. On a physical or electronic board, the story cards can contain as much information as the team finds helpful. Typically the story number, title, and number of story points are included.

Reflections:

  • The Scrum or Kanban board can be used to communicate much more than just the status of the stories and tasks.
  • The information on this board should reflect each team’s personality and process. It will evolve as the team learns.
  • The Scrum Master can help the team during the standup by directing their attention to potential trouble spots on the board.

Bring the Work to the Teams

WorkToTeamAs new high-priority features surface on a large program it can be tempting to give in to demands from stakeholders to assemble a team of the best people from the existing Scrum teams to build those features. Typically someone will suggest plucking the best people from the various Scrum teams and forming a task force. If anyone tries to talk you into doing this, don’t let them. In agile, restructuring the teams should be done sparingly and carefully. It takes a team of people several sprints (and sometimes months) to learn to work together effectively. Reorganized teams also represent change and the range of human factors that come with change. Large scale agile is about bringing the work to the teams, not assembling groups of people for each package of work that needs to be completed.

Another consideration when someone suggests putting together a task force is that it needs a Product Owner, Scrum Master and the various cross-functional roles such as BAs, QA, etc. to be covered. Gutting existing teams to staff these roles leaves the other teams in disarray. And, of course, we would never even consider sharing people across teams, would we?

The next time someone proposes a task force, take a look at how this work can be done by the teams already in place. Chances are pretty good that the work will be completed faster and better by the established teams.

Evolving Team Structures Through the Product Development Lifecycle

One of the most fascinating management challenges is determining the best structure for Scrum teams based on the stage of the project. This does not mean the major waterfall phases like Analysis, Design, Construction, etc. When developing software for use by customers (especially niche SAAS products) and there is some level of customization or specific features for each client, there are at least a couple of distinct stages in the project:

  1. Develop the base product
  2. Develop client-specific features and convert those clients onto the system as those features are completed

Many agile writings suggest that the way to approach system development is to develop some features and put them in production right away so that clients can start using them immediately. In reality, this does not always work. For example, when an existing system is being replaced, clients cannot be put onto a new system that only has 20% of the functionality of the one being replaced. Of course, this does not preclude some form of testing of that 20% by users within the development organization (e.g. by internal client service reps who are also part of the user base).

Organizing for Base Product Development

Typically the base product development effort focuses on developing the major feature areas. The development teams can be organized along the lines of the features areas as depicted below.

Base Product Team

Organizing for Client Conversions and Onboarding

 As the base product nears completion and the teams start to work on client-specific features, the portfolio or program manager may start noticing that the client code complete date for one of the feature teams above is much later than the other teams because the bulk of the customization for that client falls on that one team. The net result is client on-boarding dates are further out in the future that delay realization of new revenue from the product. This is a clear sign that the team structures need to change. At this stage, the focus shifts to optimizing staff utilization while retaining the benefits of teams building features or feature slices from top to bottom. This is called Focused Balance. Work is focused as much as possible on one or a few teams to gain the efficiencies that come with understanding and ownership of the epic , but when necessary client-specific epics are spread across the teams to deliver them as soon as possible.

Client Onboarding Team

Restructuring the teams

When scheduling and work allocation issues require that multiple teams work on the same epic, the following should be considered when deciding who should be on each team:

  • Knowledge about specific feature areas of the system.
  • Technical skillsets. Rebalancing may be necessary when certain feature areas from the base development phase emphasized a particular technical skillset.
  • Technical leadership – most teams need a technical leader.

Cross-Training and Collaboration

Team members will need to step out of their comfort zones and learn other parts of the system. Product owners, who have become experts in the feature areas that their teams constructed in the initial stages of development, will be overseeing a backlog that contains features and stories that are outside of their current area of expertise. Recognizing and fostering the need for collaboration across the teams is critical to the success of this model. At this stage, the job of the product owner is to connect team members with subject matter experts rather than being the subject matter experts.

Reflections:

  • Team structure may need to change to optimize the schedule for client-specific feature development.
  • Restructuring and rebalancing evenly distributes system knowledge and technical skills across the teams.
  • The Product Owner’s role changes to be less of a subject matter expert for their team and more of a facilitator.

Introducing Scrum to a Team

GoFor a Scrum Master introducing agile to a team, there is a balance between implementing concepts and practices at a pace that does not overwhelm the team and demonstrating the benefits as early as possible to build momentum and support within the organization.

Each situation is different, but let’s assume that an organization wants to use Scrum and there is an experienced Scrum Master who has been asked to lead a team of people that are experienced with waterfall approaches and are new to agile. Also assume a reasonable level of management support. How should the Scrum Master go about implementing agile practices on the team? For an experienced agile practitioner, the practices are second nature so it can be tempting to try to introduce it all at once, but the reality is that it must be gradually introduced in bite-sized chunks. The key question is which practices should be introduced first and which practices must be implemented in the longer term? Here are some suggestions:

Groundwork

Before starting the first sprint, there are some things that need to be put in place:

  1. Secure a Product Owner (PO). In many organizations this might be a product manager or representative from a business unit. This requires a serious time commitment and product insight so it should not be an afterthought.
  2. Secure a team where the people will be dedicated just to this team, rather than juggling several different projects at once. This can be a big shift for organizations accustomed to managing project assignments via resource utilization/optimization models tied to specific skillsets.
  3. Educate the team (including the Product Owner) about agile principles and Scrum. Hiring a Scrum trainer to conduct a two or three day course is ideal, but if lead time or budgets do not allow this, prepare an overview that touches on the agile principles as well as the mechanisms and ceremonies of scrum. The Scrum Reference Card and Build Your Own Scrum  are good tools to facilitate this.
  4. Be careful in comparing agile to waterfall. Disparaging waterfall will not endear agile to people who have delivered successfully using waterfall.
  5. The new PO will require additional training about what the role involves.  If they were a product manager accustomed to working with a project manager (PM), they will need to understand the additional responsibilities that get transferred from the PM to the PO. To get them started, help them understand that they will need to work with the team on a daily basis.
  6. Change the team’s physical workspace to foster improved collaboration.  Sometimes it is as simple as taking down a few cubicle walls. Other times, it involves locating people in the same area if they are spread out around the building. Be thoughtful about this. Done wrong, too many people are jammed into a small area and they can’t move around without bumping into each other. This builds frustration and resentment that leads people to resist and question the approach that brought this change. Also, an area with plenty of wall space is best.
  7. Pick an iteration length. Start short so that the team can get used to the different ceremonies and rapidly learn from its experiences. This also quickly gives the team and the organization a feel for what happens before/during/after an iteration.
  8. Populate the initial product backlog:
    • Conduct a story writing workshop. Utilize a technique such as story mapping to organize the stories. Don’t get hung up on teaching story mapping techniques – just do it by organizing stories that way on the wall. It will actually be very intuitive to people who are accustomed to structured analysis techniques. A big challenge here will be in writing the stories. If a work breakdown structure (WBS) exists as a result of the initial business case or previous project planning that was done before deciding to use agile, it may be possible to use it as a starting point for populating the product backlog.  This depends on the extent to which the WBS aligns with product features vs. technical tasks.  The more aligned it is with features, the easier it is to translate. This is an opportunity to reinforce that product backlog items are features and not tasks. Also, team members may correlate this to the design phase of a waterfall project. The focus needs to be on “what” the requirements are and not “how” they will be implemented. Stories need to be written in just enough detail for sizing, not with detailed requirements.
    •  Get the PO to prioritize the backlog by business value. Don’t be surprised if every item is given a priority of ‘1’ the first time around.
    • Create a Definition of Done. This provides the basis for sizing stories. This should include user acceptance testing (avoid the use of “done” and “done done” at all costs!). This will be challenging for a team accustomed to a UAT phase after long design and development phases. Doing this reinforces that the team should write stories that represent testable feature increments rather than individual technical layers of the application.
    • Conduct a planning poker session where the team sizes an initial set of backlog items using story points. This can be a big change for teams accustomed to having senior team members provide the estimates. During this process, the Scrum Master needs to make sure all voices on the team are heard.  Planning poker is ideal way to do this. The Scrum Master solicits input from all team members, especially when there are significant differences in estimates. So that the team does not feel as though it needs to define every last detail of each story, help team understand that this is not the last time these stories will be discussed; detailed requirements will be covered in depth once the sprint starts.
    • This next step depends on the project and organization.  If the organization views the project as an agile incubator, the team might have the leeway not to commit to an overall release plan for the product until a few sprints have been completed and the velocity is understood. If not, you may need to use an old project planning approach to derive a delivery date to satisfy the organization until a release plan can be formulated. Be very careful about providing enough buffer for unknowns – any dates that are published may become the benchmark against which success or failure of the effort will be measured. If possible, characterize any release dates as preliminary until the team has had a chance to run a few sprints.

The First Sprint

  1. Plan the sprint.
    • Set firm start and end dates for sprint. Go with either a 1 or 2 week sprint. A 3 or 4 week sprint length is not recommended because it is harder to convince PO not to change the contents of a sprint if it is longer. Also, longer sprints involve larger numbers of stories for a larger team, which can be difficult for them to manage. A shorter sprint length allows the team to demonstrate results quickly.
    • Calculate the team’s hours of capacity to do work on user stories during the sprint, factoring in sprint length, time for meetings, vacation time, etc.
    • Conduct the sprint planning meeting. The first part should involve the development team and the PO. Review the user stories on the backlog starting with the highest priority items. The team should ask the PO any questions they need to help them understand how to task out each story. The PO can stay for second part if they want. Create tasks for each story. Make tasks granular enough (max 6-8 hours) so that it will be easy to have multiple people working on each story. Continue to add stories until team’s hours of capacity for the sprint are used up.
    • Ask everyone on the team if they are comfortable committing to delivering these stories in the timeframe of the sprint and if they have any concerns or reservations.  Go around the table and ask each person – it can reveal some insights that people might not otherwise volunteer.
  1. Set up a story/task board in the team area. Even though the team might have software for sprint planning, go with high-visibility, tactile information radiators. This is important because it helps the team learn that it needs to be self-organizing/self-assigning. The team should update the board throughout the sprint, not the Scrum Master. The Scrum Master needs to change culture of having the project plan buried in project planning software like MS Project and only being maintained by the PM. This also starts to build culture of transparency with stakeholders. Invite stakeholders to visit the team’s work area to view status of current iteration. Of course, be careful that they don’t interfere by trying to change priorities or introduce new stories.
  2. Start the first sprint.
  3. Do daily standups. Start by helping team understand the purpose and the basics.
  4. Some people on the team may have heard the agile myth about “no documentation”. This is the time to start establishing culture of lean, maintainable documentation that has value through the lifetime of the product. A new team will only be able to bite off so much new stuff at one time. If they are accustomed to some type of UX or use case document, use that artifact (during the first sprint) as a transition into user acceptance test cases.
  5. Coach team members that the first thing that they need to do when they pick up a new user story to work on is to get with the PO and applicable users to discuss detailed requirements (since the team didn’t hammer out every last detail of the story during grooming or planning, right?). Reinforce with the PO that they need to be prepared to work with team members on a daily basis.
  6. While the Scrum Master’s eventual goal is a team that limits WIP and individuals self-assign tasks, don’t necessarily expect that to happen in the first sprint. Remember – people on the team are probably accustomed to having their tasks assigned to them by the PM or tech lead via project plans.  Initially, the Scrum Master may need to ask for volunteers for tasks, or as team members report that they are wrapping up a task, the Scrum Master may need to ask them which task they will work on next. Team member will typically look at the next available story that no one is working on. Steer them instead to first look for tasks they can work on for stories that are already underway but not yet complete.
  7. Start tracking the team’s burn down and post in the team work area.
  8. Run interference if the PO or other business stakeholders try to change the stories in the sprint. This is another reason to keep sprints short (max 2 weeks) at first. It is easier to argue against changing the contents of a sprint when the next sprint is less than 2 week away.
  9. Conclude the sprint on the planned end date.  DO NOT extend the sprint under any circumstances, even if it will take ‘just one more day’ to finish all of the stories. It is important to establish this early as it speaks to the sprint commitment being firm and the importance of sizing/organizing the work so that it can be completed within the iteration.
  10. Do the retrospective.  Keep the format simple initially. “What went well, what did not go well, ideas for improvement” is an easy format. Do not allow anyone from outside the team to attend. Make sure the PO attends because they are part of the team and this meeting is an important way to build trust between the PO and the developers. Ensure attendees know that the Vegas rule applies. At the conclusion of the retrospective ask attendees if it is okay to share ideas that were generated with outsiders – stakeholders will naturally be curious.  Ideas that the team does not want to share are not shared outside the team.
  11. In preparation for the sprint review, prepare a sprint summary document.  Show the team’s burn down, stories committed and status of each story at end of sprint.
  12. Conduct the sprint review. Encourage as many people from around the organization to attend as possible. This is about
    • Demonstrating results
    • Team members taking pride in their work by showing it off
    • Showing the organization that the team is transparent

The development team members (developers, QA people, etc.) should conduct the demos.

The mechanics of the first sprint described above are relatively straightforward, but the reality is that this is all occurring against the backdrop of organizational change:

  • Team members are experiencing dramatic change.  Their physical work area has changed. They are being asked to commit to delivering something without detailed specifications. No one is telling them which tasks to work on.
  • The relationship between business and IT may be very different when using an agile approach. If the PO comes from a business unit and because of the organization’s culture there exists a lack of trust or poor communication between the business unit and IT, the lack of trust and communication issues will not necessarily disappear overnight.
  • The organization’s culture may not value or emphasize teamwork. Part of management and the Scrum Master’s jobs is to build a culture where teamwork is highly valued.

The Second Sprint

In the second sprint, the Scrum Master continues to emphasize agile principles and the mechanisms of Scrum.

  1. The Scrum Master continues to coach regarding self-assignment of tasks. As the Scrum Master backs away a little bit and the team starts to self-organize, others (such as the PO) may feel that the team needs to be directed and step in to direct the team and tell them what to do.  The Scrum Master must also coach them not to direct the team.
  2. The Scrum Master continues to encourage team members to swarm on stories by default rather than only when necessary. Lessons learned from first sprint (e.g. too many stories in progress at the same time) make the purpose of this apparent.  Swarming will not happen overnight, but the Scrum Master needs to keep encouraging it.
  3. Conduct user story grooming meetings during the sprint. In the meetings, continue the mantra of discussing features at “the right level of detail at the right point in time.” Use these meetings to size out the rest of the backlog and to revisit stories likely to be worked on in the next sprint. The product owner may be unprepared for these meetings because they are already overwhelmed by working with the team on the current sprint’s user stories. Sometimes it helps for the Scrum Master to meet separately with the product owner a day or two before a grooming meeting to survey the backlog and discuss the next set of stories to be groomed.
  4. Encourage the PO to regularly tend to the backlog – not just before grooming or planning meetings.
  5. Using the team’s velocity from the first sprint, begin working with the product owner to formulate the release plan. It may not be appropriate to go public with it yet. Velocity cannot necessarily be trusted after just one sprint, but doing a preliminary release plan is valuable to get the PO thinking in terms of using the velocity and backlog to formulate a plan.
  6. Start tracking the team’s burn up and also post in the team work area.  The burn up emphasizes that hours worked do not provide business value, only completed user stories do. A graph that shows a steady burn up of completed story points during the sprint (rather than a ”hockey stick” where most of the stories get closed at/near the end of the sprint) is the goal. Don’t necessarily beat the team over the head with this…at this point just introduce it to them and call attention to each story as it is closed during the sprint.

Beyond

Over subsequent sprints, the Scrum Master should consider introducing some of the following techniques.  Of course each situation is unique so he/she will have to gauge whether or not the team is ready for each new practice.

  • For teams that are having trouble swarming and have too many stories in progress at the same time, reinforce the concept of WIP limits.  For teams that already have a task/scrum board with steps in the process laid out, the WIP limits can easily be established for each step. The team can decide whether they are firm limits not to be exceeded or soft limits that are triggers for conversations.
  • Help the team learn the finer points of writing user stories. A book study (e.g. “User Stories Applied” by Mike Cohn) is a good way to do this. Be sure to include the PO in this.
  • Test-Driven Development (TDD).  The benefits of this can be difficult for a team to grasp. Once the team (including the Product Owner) understands that it is okay to refactor and that it is simply part of progressive elaboration, the benefits of TDD become much more apparent.
  • Acceptance Test Driven Development, manual or automated.
  • Introduce additional retrospective techniques to help the team learn about itself and identify areas for growth. The Scrum Master will need to judge what type of retrospective is appropriate depending on how the sprint went.

In addition to learning new practices, the team overall needs to learn to be agile, not just to use agile practices.

  • Work with team members’ managers to help them develop a broader, t-shaped skillset that allows them to perform a larger variety of technical and non-technical tasks.  For specialists, this can be a big shift.
  • Help the team to develop an agile mindset by only learning enough about a feature to size and plan it and then really dig into the details of it once it has been pulled into a sprint. One of the most gratifying moments for a Scrum Master can be when the PO says, “We did not think of that aspect of the feature in when we discussed the story. We will just create a new story and handle it in the next sprint” – without taking the team to task for not delivering it in the current sprint.
  • When the Scrum Master has been steering the team towards new practices but the team has resisted using them, the Scrum Master may need to let the team fail for a sprint. The Scrum Master needs to help stakeholders understand that this is part of the learning process, and two-week sprints will minimize most of the damage if the team gets off-track.

Reflections

  • Every situation is different so of course there is no “one size fits all” approach to starting with agile. Organization and team dynamics impact the speed and extent to which agile is adopted.
  • As the team becomes more comfortable with the agile approach, the Scrum Master should adapt his/her approach to be in more of a supporting role for the team.
  • Occasionally the team will forget lessons learned from a few sprints ago and revert to old habits.  The Scrum Master can bring previous retrospective conversations back into focus to help the team avoid making the same mistakes.

Outstanding Standups

The daily standup meeting is one of the key agile practices. For teams that are beginning their agile transformation, this is an easy ritual to adopt.  For mature agile teams, it is an indispensable part of the day.

The daily standup usually goes something like this:

  1. The team gathers in the team room.
  2. Each team member answers three questions:
  • What did I accomplish since the last standup?
  • What will I accomplish by the next standup?
  • What things are hindering progress?

Daily Standup Ground Rules

  1. Everyone on the team must attend every day.  This includes the developers, QA people, the ScrumMaster, and Product Owner.
  2. Other stakeholders can attend but should not interrupt with questions or comments. Notice the absence of the “chickens and pigs” reference – that has been removed from the Scrum guide .
  3. It happens at the same time every day.
  4. Lasts for a maximum of 15 minutes – period.

Making it work

  1. Gathering around the task/Scrum/Kanban board helps to focus on accomplishments and work remaining for stories that are either in flight or coming up next.
  2. It is tempting to dive into solving issues or talk through requirements during the standup.  The ScrumMaster’s job is to remind the team that these discussions need to be taken off-line, ideally right after standup concludes. These types of discussions may indicate that the developers and Product Owners are not spending enough time together outside of the standup meeting.
  3. Since the Product Owner is a member of the team, they can be given some leeway to interject with questions, but it is important to recognize quickly if it is a discussion that needs to be taken off-line.
  4. Some teams fall into a rut where team members provide updates that are more of a “where am I with what I am working on” update rather than what has been accomplished and what will be accomplished.  This is gets to the crux of what the standup is really all about: team members re-committing to each other on a daily basis about what they will accomplish towards meeting the team’s commitments.
  5. Everyone actually stands up for the meeting.  This helps to keep it short.
  6. Rule of thumb: if people start leaning against the wall, then the meeting is getting off-track or running too long.
  7. If the standup becomes a free-for-all, use a token (e.g. a ball) that the speaker holds. When he/she has completed the 3 questions, they pass it to another random team member who has not had their turn.  Passing the ball randomly to the next speaker helps keep people tuned in rather than sequentially going around in a circle.
  8. New impediments that are identified in the standup should be added to the team’s impediments board immediately.

Reflections

  • The daily standup is an opportunity for team members to recommit to each other.
  • Everyone should attend, and the meeting should last a maximum of 15 minutes.
  • The discussions should remain focused on the three questions.

Are You Being Agile or Doing Agile?

The GoalThe starting point for adopting agile is for a team to learn the mechanics of an approach such as Scrum.  They write user stories instead of use cases, do daily standups dutifully, and replace their lessons learned meetings with sprint retrospectives. Eventually the rest of the business comes on board, and the Product Owner takes over writing the user stories and maybe even attends the retrospectives. The product backlog gets populated in time for the next sprint planning session.  The team might spend some time talking about some of the upcoming stories before the next sprint.

A novice golfer often focuses too much on swing mechanics and less on the desired end result of putting the ball on the target.  In doing so, he is “doing golf” rather than “playing golf” and his improvement typically plateaus at a mediocre level. Agile teams can also plateau and fail to realize the full potential of an agile approach by “doing agile” rather than “being agile”.  Here are some of the smells of teams that are doing agile:

Detailed user stories

One of the principles of the Agile Manifesto is that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Product owners who are accustomed to waterfall methodologies may still be tempted to put all of the requirements in the user story rather than using stories as placeholders for conversations with the developers.  Detailed user stories are both inhibitors to conversation and wasteful since it makes more sense to capture detailed requirements as test cases.

Obsession with metrics

The first step in replacing traditional project management methodologies with agile approaches to is to stop equating hours worked with progress.  In agile, stories that are “done” are the only true measure of progress. As such, it can be very tempting for an organization to put emphasis on user story completion rates as a key metric for judging the performance of agile teams. The danger is that when a team is considered a failure if it does not deliver 100% of planned stories for every sprint. The natural reaction is for the team to work very hard to eliminate all uncertainty and risk before starting a sprint. This can quickly lead to a culture of big, detailed user stories and excessive story grooming and sprint planning efforts in order to eliminate all possibility of not delivering 100% of stories in the sprint. In extreme cases, a team may spend an entire week planning a 4-week sprint!

Fear of building features over many sprints

The misconception that it is best to develop an entire feature in one fell swoop may still be present in some organizations.  Usually the rationale is something along the lines of building the entire feature in a single sprint makes the process more efficient by only having to test it once.  This misses the point of agile, which is to build feature and product increments, learn from user feedback, and make adjustments by adding to the feature in subsequent iterations. This brings to mind the old adage “Users don’t really know the requirements until they fail to be met by the software.” But what about having to regression test as increments are added?  Automated testing can eliminate alot of that effort.

Stories not considered done when new requirements discovered

New requirements will surface as the software comes to life in a sprint.  That’s good!  The key is recognizing these new requirements as new user stories rather than as defects that must be corrected in order to consider the story “done”. This requires strong trust between the users, Product Owners, and development team to recognize that the new requirements were not factored into the story sizing for the current sprint (remember – requirements are not detailed before starting a story).  If team starts to feels like story is a lot bigger than what they thought when they sized/estimated it, this culture of trust allows for a new user story to be created to handle that additional work in a subsequent sprint.  The “doing agile” version of this is where CYA kicks in and the Product Owner and team members run for cover to avoid the organizational fallout from additional work coming out of a sprint.

Reflections

  • Being agile allows a team to focus on building great software that delights customers rather than merely creating the illusion of progress.
  • Just like becoming a great golfer, this is often the most challenging part of an agile transition.