Process can be fun…gamification of Agile

When all but the most anal-retentive developers hear the ‘p-word’ (process) they feel immediate dread…that means documentation, time sheets, checklists, project managers….aaaargh!

But process can be fun!

While SVP, Engineering at Thismoment, I was delighted when the team (with a strong background in digital media and social engagement) was open to introducing gamification into their adoption of Agile.

Instead of the usual ‘Teams’, ‘Stories’ and ‘Sprints’, we opted for the terms ‘Guilds’, ‘Quests’ and ‘Raids’.

Each Guild had a name and identity – the Momenteers, Stormchasers, Goodfellas (cross-functional delivery teams) and the Assassins (TechOps.) In addition to the teams, we also had NPCs (non player characters) that included the Lead Architect, CTO, etc. These individuals each play a role that extends beyond any individual Guild. Of course, this also made me the DungeonMaster! Each Guild created a fun logo that was posted above their physical scrum board.

To make sizing and resizing (not to mention completing Quests on time) more rewarding, Guilds earned ‘Loot’. We bought ‘gold’ coins and a dry erase prize wheel from Amazon.


As each story was completed, the Guild was awarded Loot totaling the (resized) story points completed. The story teams divided up the coins (we let them decide how to share the loot; after all they are self organizing).

At the end of the Sprint (typically after the Retrospective), and each person could ‘spend’ their Loot to buy a spin of the wheel and win a prize. The more points, the more spins, the more prizes.

With a limited budget, we kept the prizes small, quirky and fun ($25 Starbucks card, ‘get out of fixing a bug free’ card, $50 Amazon gift card, Thismoment swag, Spin again, Treasure chest to store your loot in, 100 extra coins, etc.)

IMG_6850And there’s more…When we placed the Amazon order for the ‘gold’ coins, they were addressed generically to the company not to an individual. After a couple of days of the package going unclaimed, our office manager sent out an all-San Francisco email asking “Has anyone ordered a unicorn head?” It turned out she had Googled the company who’d sent the package and they also sell unicorn heads! Not wanting to miss such a priceless opportunity, we also bought a unicorn head that is worn during the wheel spinning (often by the CTO!)

The introduction of gaming techniques quickly captured the hearts and minds of Engineering and increased company-wide interest in the Agile process.

While process is often considered boring and stifling, by not taking yourself too seriously you can have fun and get great results!




Evolving Beyond Scrum

optimizing GGBWhile I recommend following the core tenets of Scrum Agile, I have designed and implemented extensions to the Scrum process that increase the effectiveness of Agile development  in product companies and reduce overall risk.

If you have already adopted Scrum Agile, you will be familiar with the following:

  • Self-organizing, cross-functional teams
  • Scrummaster to oversee and facilitate the process for all the teams
  • 2 (or at least, fixed) week Sprints
  • Relative sizing
  • Sprint Planning and Commitments
  • Breaking down committed stories into tasks of 1 day or less
  • Iterating development deliverables to QA in ‘QAable chunks’
  • Tracking status with physical and/or technology scrum boards and daily standups
  • Steering Sprints to a successful conclusion
  • Hosting Sprint Reviews and Retrospectives

Adapting for improved effectiveness

While the core principles of Scrum are highly beneficial in their own right, companies developing products or solutions that have to meet rigorous goals of scale, performance, backward compatibility, quality, etc. need to evolve their Agile practices to incorporate techniques that provide a basis for architectural evolution, design consistency, and team optimization.

Needs more information or NMI TM stories

Needs More Information or NMI stories are an extension to the Scrum process that account for research, architecture, design and prototyping activities that are often necessary before a large story or group of stories can be effectively sized. By spawning an NMI during Story Sizing (Backlog Meet and Greet) and prioritizing it high in the backlog (typically for the next sprint), Agile teams can increase their confidence that the implementation story (or stories) can be committed to and delivered upon.

NMI’s are expressed as a series of questions that need to be answered before the related story (or stories) can be sized.  NMIs are typically small in size relative to the original story or group of stories and can employ technical prototypes, white board sessions, architecture reviews, technical research, etc. to answer the open questions.

NMI deliverables include

  • Additional story breakdown (if the work is able to be broken down further)
  • Sizing of the story or group of stories
  • Task breakdown

Once the NMI is complete and the related story or group of stories are sized, the team can confidently commit to delivery based on their velocity in the Sprint Planning meeting.


In an effort to ensure a potentially shippable product increment at the end of each Sprint (and to optimize the team’s efforts) it’s important that all members of a ‘story team’  stay on the story until it’s ‘done’. This can at times result in team members being idled for periods during the sprint.

In the event that this is a developer, the last thing you want as an Engineering leader is for them to open another story and start checking in code that may or may not be QA-ed by the end of the sprint (since it will lead to more technical debt.) Instead, have your Developers, QA and Designers each create and manage a Slacklog. A Slacklog is a list of items that an idled team member can work on that does not create debt for anyone else. For example, writing or improving unit tests, prototyping with new technologies, writing QA automation tests.

While at first blush, having your team ‘idled’ during a Sprint seems counter-intuitive to productivity, the opposite is actually true. Creating some ‘pain’ in the process will help it improve. No-one likes to be idled, especially Engineers, and the team will find ways to optimize their efforts. For example, if Developers are idled because they held onto all the tasks until the story was almost complete – and now are waiting for QA to finish – they will seek ways to better phase delivery of the work. If QA Engineers are idled because they are waiting for something to test or for bugs to be fixed on a story, they and the Developers will be motivated to invest in unit testing and QA automation scripts. Trust me, it works…

Handling Unplanned Escalations 

In an ideal situation, Sprint Planning and execution would proceed without any surprises – and all committed stories would be completed in the Sprint. However, we live in a (necessarily) imperfect world. One where customers, partners and the vagaries of software and infrastructure often lead to unplanned escalations that the team has to deal with.

“Above the Line”

Rather than build in a bug fix contingency, I prefer to create a section at the top of the scrum board to track and manage items that are introduced after Sprint Planning. I call this section ‘Above the Line’. Stories, tasks and bugs can only be introduced to an active Sprint by the Product Owner or Scrummaster and are added ‘Above the Line’.

By following this model all unplanned items introduced after Sprint Planning will be very visible, allowing you to measure the team’s actual velocity, quantify the impact of unplanned work on committed stories, and most importantly, look at where the exceptions are originating from in order to reduce them.

Managing ‘Above the Line’ Work

There are two approaches I have found to be effective in managing unplanned work in a Sprint. The approach you choose will depend on the complexity of your product, the degree of shared code knowledge and your team’s ability to switch gears.

  1. “Swarming”

Leveraging the entire Scrum team to work on escalations carries the implicit understanding that work placed ‘Above the Line’ takes precedence over committed stories and could cause one or more committed stories to be dropped from the Sprint.

With this approach, ‘Above the Line’ items fall into two categories and should be treated differently to reduce context switching:

  • Critical – Fix Immediately: Developers and/or QA should drop whatever they are working on and immediately swarm to find, implement and test a resolution.
  • Fix In This Sprint: Developers and/or QA continue to work on their current tasks. As they complete a task and move it across the board, before they pick up the next task for their current story, they look to see if there is a task ‘Above the Line’ that needs to be picked up.

2.  “Assigned Resources”

Another approach to handling escalations is to assign ‘Above the Line’ to a small ‘swat team’ for the duration of a Sprint. In essence, you reduce the velocity of the team to allow for escalations to be handled.  While this approach dramatically reduces ongoing interruptions on the Story team, depending on skillsets/experience, it may require pairing with Story developers for knowledge transfer. Also, it’s likely that the ‘swat team’ will be idled at some point during the Sprint, creating an opportunity to work on Slacklog tasks.

Agile for Desktop IT, Build and Release, and Technical Operations

Teams that have a high degree of interrupt-driven work every sprint (a big part of their responsilbities is responding to exceptions), such as Desktop IT, Build and Release, or Technical Operations benefit from planning with a reduced velocity.

Begin by tracking and sizing all the ‘Above the Line’ items and maintaining an open mind to what was committed. When your team has completed 3-4 sprints, average the counts for ‘Abolve the Line’ and Story points. This will provide you with a reasonable estimate for the #interrupt points per Sprint and #availablevelocity. When Planning, use the #availablevelocity.

Taking this approach will ensure your IT, Build and Release and/or Technical Operations teams are able to respond in a timely way, but are not purely interrupt-driven. They are also able to move key initiatives forward in a planned and predictable way.

Terms ‘NMI’ and ‘Slacklog’ are trademarks of Shirley A. Foster

Succeeding with Agile Development – Part VI

In this final of this six-part blog series, Shirley provides practical advice on adopting Agile Development methodologies.

scalingAgile Development is a software development methodology based on incremental, iterative development, where requirements and implementations evolve through collaborative, self-organizing, cross-functional teams. Agile Development promotes product delivery as a time-boxed series of functional and potentially shippable product increments that enables teams to rapidly respond and adapt to change.

Part VI – Scaling


Velocity is the sum of the story points a team completes in a single Sprint. Velocity for any given team will depend on the team composition and the calibration used for relative sizing.

Measuring and understanding a team’s velocity is important for several reasons:

  • During sprint planning, use the team’s velocity to corroborate the cumulative story points being committed. Note: Target velocity for any given sprint should be adjusted to reflect  time that delivery team members will be absent (e.g. vacation, holidays).
  • As the team grows and/or invests in knowledge transfer, you can measure and take advantage of changes in velocity.

Story Size and Sprint Commitments 

Once you are measuring velocity, a good rule of thumb for successful sprint planning is not to commit to any story greater than 50% of the total velocity of the team (i.e. if the average velocity of the team is 75, no individual story should be 40 points or greater.) Taking on larger stories will impose unnecessary risk on the team’s ability to complete the sprint, since they could ‘blow up’ with unexpected additional work and extend beyond the boundary of the sprint. If your backlog contains stories that are  larger than the acceptable size for your sprint velocity, engage the Product Owner and Delivery team. Either break the story down into smaller stories with greater sizing accuracy, or refine the sizing with additional clarification from the Product Owner or by technical discovery (see ‘NMI Stories’ in an upcoming post on  ‘Extending the Agile process’)


While measuring your team’s velocity using the original story sizes is a major step forward, you can increase the quality of your velocity measurement – and improve the team’s ability to  size – by resizing stories when they are complete. Resizing should occur as close to the completion of a story (definition of done) as possible. Since resizing requires the involvement of everyone who worked on the story (developers, QA, etc.) I recommend resizing any stories that are newly  ‘done’ immediately after the daily standup. This is best done at the scrum board where the story team can see all the resulting tasks and should take no more than 1-2 minutes. Ask the story team to collectively review how the story implementation had proceeded and listen for things like “the API turned out to be harder to stabilize than I’d expected. I had to build a lot more sample code” or “the implementation was so much easier than I expected (developer). It was much more challenging to test (QA)”. Essentially, let the team reflect on their implementation experience then pose the question. Do you still feel this is an 8? (that is, less than 1/2 the size of this 20?) Let the team come up with their resized number and write it on the story card next to the initial sizing.

Having this data will not only allow you to better measure the team’s velocity from sprint to sprint, but will also provide you a way to gauge how teams are sizing overall (are some teams more effective/accurate at than others?) and work more closely with the teams who need additional help.

Burn Down Charts

Burn down charts are used to track the progress or health of a sprint. Days in the sprint are plotted on the X-axis and total points are plotted on the Y axis.

Screenshot 2014-03-06 14.23.52

Assuming a sprint or iteration progresses exactly to plan, the burndown would occur in a linear fashion, ending in 0 on the last day of the sprint.

Rarely do actuals track to the ideal scenario and, instead, points are added to the sprint, work takes longer than estimated, etc. While some Agile teams map their progress across all stories daily – by estimating how many points they have completed for open stories – I prefer to only burn down time when a story is complete – to avoid the risk of teams overstating the work completed. Plot your burndown using a single line for the ideal burndown and (most likely) a staggered line showing #points remaining that changes as stories are burned down completely.

If your burndown chart shows the team getting well ahead of ‘ideal’; burning down story points faster than planned,  consider adding stories to the sprint. More likely, if your team is running behind the ‘ideal’  (on an overall basis – not any specific story) use this as an early indicator that you may have to drop or reduce scope of incomplete stories in order to deliver a potentially shippable (coherent) product increment.

Don’t be surprised if your ‘actual’ burndown goes up, not down from day to day. This could be a case of a story being resized (more accurately) after sprint planning, or more likely that work has been added to the sprint. When this happens, it’s another indicator of risk. Use the data to help you and the team decide if they are on a successful trajectory. Renegotiate commitments, trade for smaller stories with the Product Owner or trim individual story scope to bring the team back on track.

Like many things in Agile, burndown charts are not an absolute indicator of success or failure. It’s your job to manage the overall delivery risk and the burndown chart is a useful tool in that effort. Burndown charts showing ever increasing points remaining, or a lack of any stories fully burned down is a key indicator that something is off-track. Get together with your team and review what’s contributing to the dynamics you are observing (it could be that 3 stories are about to be completed), if the risk is real and what can be done to steer the team to success.


I’m sure as you’ve read these posts that it’s become clear that I believe that Engineering leadership has two responsibilities:

  • Risk management/mitigation
  • Team success and recognition

Agile provides the framework and the insights necessary to identify issues early and to work with the team to achieve a successful outcome. Agile empowers the team, through relative sizing, self-organizing, sprint commitments and collaboration to control their destiny in complex and rapidly changing situations. And, it provides the ability to demonstrate progress to the rest of the organization and establish a regular delivery cadence.

Together, Agile provides the tools and techniques necessary for even the most complex software project to be managed successfully. Successful teams and also highly motivated teams. Celebrate every little win as you adopt Agile – from a task being moved across the board, to a story being completed, to the Sprint Review demo. Take the time to reflect on how rapidly the product is evolving and how far you’ve come as a team (remind them how things used to feel when deliverables were late, QA was overwhelmed, etc.) and recognize everyone’s efforts.

Lastly, enjoy seeing your Agile proteges evolve. Before you know it, they will be guiding others in how to adopt the agile principles and it will be hard to remember life before Agile.

Succeeding with Agile Development – Part V

In this six-part blog series, Shirley provides practical advice on adopting Agile Development methodologies.

optimizing GGB

Agile Development is a software development methodology based on incremental, iterative development, where requirements and implementations evolve through collaborative, self-organizing, cross-functional teams. Agile Development promotes product delivery as a time-boxed series of functional and potentially shippable product increments that enables teams to rapidly respond and adapt to change.

Part V – Optimizing

Backlog Grooming (or Backlog Meet and Greets)

When teams begin to adopt Agile practices, they are often faced with sizing and committing to stories during sprint planning – when they hear about the stories for the first time. This can lead to onerous Sprint Planning meetings (where the team often loses focus and reverts to any means to get the meeting over with), unclear requirements, increased implementation risk and over- or under-commitment (depending on your team’s propensity for risk.)

While this is inevitable in the beginning, the key to Agile success is to begin to develop a ‘story horizon’ that’s longer than a given sprint. Ideally, your sprint horizon should be either a release (a subset of stories determined to meet a particular customer or market need that justifies a release announcement) or 2-3 sprints. Grooming the backlog beyond this will often lead to discarded work as requirements change or evolve.

If your planning horizon is a release, I recommend taking 1/2 day for a Release Kick Off meeting at least 2 sprints prior to beginning the implementation. During this meeting (ideally held offsite) the Product Owners will walk the whole team through the goals, features and expectations of the release. This may include performance or scale metrics that must be met (e.g. must be able to handle n concurrent users or x,000 transactions/second). Once the team understands the overall objectives, the Product Owners will walk the team through the backlog as a series of high-level stories. The team will seek clarification and discuss possible implementation approaches. This meeting should not seek to fully understand or to size the stories, but rather to establish common ground and to uncover issues or questions (technical, requirements, etc.) that need to be addressed before a story can be sized.

Once the Release Kickoff meeting is complete, or if you are just working through a backlog of stories and releasing incrementally, you should plan to spend at least 1 hour per week grooming the backlog. During this time, the team will begin with a brief high-level review of the backlog before discussing and sizing (previously unsized or deferred) stories from the prioritized backlog. If issues arise that prevent a story from being sized, it will be deferred and flagged for the next grooming meeting.

Backlog grooming is an incredibly worthwhile exercise that sets aside time to ‘meet and greet’ upcoming stories in advance of their implementation. It provides developers and QA valuable time to consider upcoming stories, to discuss ideas offline and to improve the quality of their estimates. Schedule a fixed day/time every week for backlog grooming and make it a priority for the team (I prefer Wednesday mornings – since they avoid Sprint Planning and wrap up activities.) Despite their protestations of ‘too many meetings’ the team will quickly appreciate and value the impact of the investment.

Story Sizing

In traditional, waterfall, processes schedules often comprise developer and QA estimates (measured in hours or days). Data is then plotted on a Gantt chart that includes a contingency factor (%age overhead, based on prior experience of the team’s sustained productivity), vacation days, holidays, etc. Progress against goals is measured in %age complete vs. estimate.  Also, development time is often estimated individually per feature and separately from QA – with little or no accommodation for issues that will arise during integration and testing. This approach is fraught with difficulties that often lead to schedule overruns. One example is that when asked for an estimate of  %completed, developers often give an answer that is better described as %time spent: “I’ve spent 80% of the time, so I’m likely 80% complete”. This often has little or no bearing on the actual level of completeness (remember the old 80-20 rule?) and introduces the risk of discovering schedule overrun late on the project.

Agile follows a timeboxed approach, where the team makes a commitment to completing product increments (stories) within a given timeframe (see Establish a rhythm for the team).This is a significant shift in thinking for many teams and is often hampered by them regressing into traditional estimating and trying to plan the sprint duration using traditional methods.

To shift the team’s thinking, I recommend introducing the concept of relative sizing. That is, estimating the size of a story  (including everything required to deliver a functional product increment; Development, QA, Documentation, etc.) relative to other work. To get teams started, I  introduce relative sizing using a number series that closely resembles the Fibonacci scale (1/2, 1, 2, 3, 5, 8, 13, 20…) ). As a point of reference, I associate the smallest increment (1/2 point) with some piece of work that everyone in the room can grasp. For example, ‘1/2 point represents the work required to make the smallest change to an application’: think changing a label on a UI. The 1/2 point sizing includes code changes and check-ins, developer testing, QA setup and testing, and refreshed screen shots. The size of every other story is then calculated relative to this.

Progress is then measured during the sprint in completed stories (those that are ‘done’.)

Planning Poker

Planning Poker is an estimating exercise that helps to maintain the objectivity of story sizing by reducing the influence of any single member of the Scrum team on the sizing or others. You can purchase Planning Poker Cards inexpensively, or download a Planning Poker App. Just make sure that everyone committing to the sprint has the ability to contribute their size estimate (even if it’s just using a piece of paper with the number sequence, or fingers and toes!)

The team collectively discusses each story, seeks clarification from the Product Owner and formulates a high level approach to deliver the product increment. Technical or other risks are discussed and QA voices how they will acceptance test the feature. The Scrummaster then asks everyone to estimate the level of effort (using relative sizing) to complete the story and every member of the delivery team privately selects a ‘card’. I like  teams to countdown “3, 2, 1” to ensure that everyone is ready then ask everyone to hold up their ‘cards’ at the same time. Typically, there will be a lot of consensus in the room on the size of a given story. However, it’s important to look at the outsiders. For example, if the bulk of the team estimates 8 points but one member holds up a 20 and another a 2, there’s likely something interesting to pursue. Ask open-ended, non judgmental questions of the ‘outsiders’ “That’s interesting, why a 20?” to understand their reasoning. In my experience, their reasons are often very valid and affect the resulting points sizing. In the example, it could be that the extent of testing has not been considered by the bulk of the team and that the size needs to be increased to accommodate the additional work. Or, the effort to implement could be much smaller because it can leverage work thats already been completed that perhaps only one or two people are aware of. In either case, take the time to hear each of the perspectives, have the team discuss and re-size the story.

The insights gained during planning poker are often really valuable and will improve the quality of your estimating. The key is to remember that Planning Poker is not designed to force everyone to a common score, but to gain a common understanding of the work involved and to base the size on their best collective knowledge.

Identifying Latent Impediments

While the Daily Stand up is intended to uncover issues that are impeding progress (“do you have any impediments?”, it’s often not as simple as asking the question.  Team members always want to show that they are doing their best to demonstrate progress. Admitting to being ‘stuck’ or ‘unclear’ can amount to feeling vulnerable, like they are letting the team down (this is especially true in nascent teams.) It’s the Scrummaster’s responsibility to uncover these ‘latent impediments’ and to help determine a path forward.

Key indicators of latent impediments are:

  • Tasks not moving across the board (remember, tasks are estimated to be 1 day or less – if they are not moving daily, you likely have an issue)
  • Developer or QA giving the same update in two or more scrums, often with the words “I’m about to reach a breakthrough”

When a latent impediment is identified (or even suspected), the Scrummaster can ask for a team member to help with  one or more next steps to accelerate a breakthrough:

  • Pair programming
  • Whiteboarding
  • Revisit Task Breakdown (it may be that issues or ideas have emerged since the original task breakdown that affect the implementation approach)
  • Code review

While it may appear that the Scrummaster does not ‘trust’ the process, the opposite is actually true. The process is highlighting the fact that a problem is building. Addressing it quickly will help keep the sprint on schedule and will continue to engender teamwork, trust and openness.

QA Automation

As a product matures, the effort to regression test existing functionality increases with every release. Manual (black box) regression testing becomes increasingly labor intensive and prone to error. Like Unit Testing, QA (functional) test automation will pay significant dividends and will allow your limited QA resources to focus on usability and ‘feel’ of the product, rather than performing repetitive testing.

I recommend using a scripted, data-driven test framework like Selenium or Watir to give you maximum flexibility.

Begin to make progress by adding automation stories to the backlog, prioritized based on risk and ‘bang for the buck’. That is, start with functional tests for the most fragile areas of code (those known to break often) or the most cumbersome parts of the regression testing (multi-browser, multi-setup). The key is to make at least some progress on QA automation every sprint to build out a portfolio of automated regression tests that can be run as part of every build to identify functional bugs at the earliest (and cheapest) opportunity.

Investing in optimizing your Agile process will result in greater team confidence and reduced delivery risk. It will necessarily require a commitment of time that will impact your team’s velocity initially. However, the increase in clarity and common understanding will more than compensate in the results achieved.

And, while you are implementing new ways to increase the productivity of the team, take a moment to reflect on how far you’ve all come. You’ll be pleasantly surprised…and it’s another reason to celebrate!

Succeeding with Agile Development – Part IV

In this six-part blog series, Shirley provides practical advice on adopting Agile Development methodologies.

ggb big picture

Agile Development is a software development methodology based on incremental, data-driven development, where requirements and implementations evolve through collaborative, self-organizing, cross-functional teams. Agile Development promotes product delivery as a time-boxed series of functional and potentially shippable product increments that enables teams to rapidly respond and adapt to change.

Part IV –  The Big Picture

As you continue to adapt to the Agile process and focus the team on getting stories and tasks to ‘Done’, it’s equally important look at the ‘big picture’. This will help identify issues early (possibly even before the team knows themselves) and help you to steer the sprint and the team to success.


Once Sprint Planning and Task Breakdown are completed and the post-its are on the Scrum board, it’s time to start the Sprint.

In my experience, Engineers want to work on the ‘next new thing’ and a fresh Scrum Board full of untouched stories can look like fertile ground. This is where you need to follow some simple rules:

  1. Swarm. Encourage the team to assign as many developers, designers and QA to each story as is reasonable (based on how well the work can be parallelized).

  2. Put stories on the board in priority order and make sure your team knows to open stories top down – not cherry pick their ‘favorite’ stories.

  3. Never open more stories than you have developers on the team. In fact, encourage the team to allocate at least 2 developers per story so that they can collaborate, pair program and solve problems together to expedite story completion.

Sprint Health

Since the goal of a Sprint is to deliver a potentially-shippable product increment, it’s important that stories are completed prior to the Sprint Review.

An early indicator of the wellbeing of a sprint is how the Scrum Board looks overall. While it’s important to track the progress of each story, it’s equally important to take a moment every day to step back and look at the board in its entirety.

A healthy sprint will show some subset of stories Done (or on their way to Done), some that are In Progress and others that are not yet open. Since the  progress should reflect the priority of the stories, the general trend should be in the form of a diagonal line across the board (see Fig 1). An unhealthy sprint will have all (or the bulk) of the stories open and in a partially complete state (see Fig 2)

Entering the final week of a sprint with too many stories open will necessarily prevent the team from getting to ‘Done’. It will lead to QA or code debt being carried forward to a future sprint and will impact the team’s ability to take on new stories.

Closely manage the team’s opening of stories. If your scrum board begins to look like Fig 2, pull the team together immediately and strategize on ways to get back on track. These could include backing out committed code (that cannot be QAed prior to the end of the Sprint), halting progress on lower priority stories and/or seeking assistance from another Agile team.

Fig 1: Healthy Sprint Scrum Board (diagonal line indicates overall progress)

Fig 2: Unhealthy Sprint Scrum Board (vertical line indicates too many open stories)

Continuous Integration and Unit Testing

It’s never too early to start investing in unit testing. Identifying and fixing bugs at the most fundamental (unit) level will pay huge dividends in overall product quality. ‘Building it right the first time’ (with unit tests) will enable your teams to focus their creative energy on delivering new features, not fixing old code. In a nutshell, they will be able to constantly take on new challenges and have more fun.

Of course, it’s unlikely that you (or any company) can afford to stop all development to go back and write unit tests for their existing code base. Instead, make a commitment that 100% of new and modified code will have unit tests and make it part of your process.

First, choose one or more  unit testing frameworks (e.g. JUnit, PHPUnit, xUnit) depending on your code base.  Create and prioritize one or more ‘developer’ stories (As a developer, I would like to…) to deliver a working framework and a set of illustrative unit tests that can be used as a reference by other developers. Work with your team to identify two developers to lead the unit testing effort (ideally, they will have a passion for or experience with test driven development) and time box the first deliverables to a single sprint. Ask the developers to pair program the framework and the initial tests. Like feature development, this approach will yield a higher quality result and will uncover issues that may be overlooked by a single developer. It will also create the inertia needed to get things off the ground.

Have the Unit Test leads host a brownbag to walk peer developers through unit testing  (why, how and when) and review the framework and existing tests.

Add a column to your scrum board  between ‘In Progress’ and ‘Ready for QA’ that is ‘Unit Test Dev”. Tasks should not move to QA until the associated unit tests have been written or modified to reflect the new functionality.

Note: Keep a close eye on unit tests that are commented out or disabled. If a unit test breaks when code is committed, it’s a pretty good sign that the check-in has broken something fundamental. Developers must modify the code and/or the unit test until the unit tests run successfully – and not be allowed to disable failing tests.

Continuous Integration (CI)

Building unit tests without a continuous integration (CI) tool will likely cause your unit testing investments to fail. Establishing a CI tool that runs every unit test against (at least daily) builds will reinforce the value of the investment and avoid unit test atrophy.

Select and implement a CI tool ( popular tools include Bamboo, Hudson, and CruiseControl). Identify someone in the Engineering team (ideally, they will self-select) to take responsibility for ‘Build and Release’ tools.

Setup your CI tool to execute the full suite of unit tests after every commit/build, or at least once daily. Report build and test failures to the team and list recent check-ins to help identify which one is responsible for the failure. Make it the team’s priority to ‘fix the build’ before continuing to work on open stories or tasks.

Measure your progress

While code coverage is a useful metric, it can be disconcerting for a team starting out when few, if any unit tests exist (i.e. starting at 2.7% code coverage can make it feel like a steep climb ahead). Instead, begin by measuring and reporting the total number of unit tests – and assess progress based on %increase each sprint.

However, don’t rely solely on the numbers. Using a strictly quantitative assessment, can incent the wrong behavior, with developers creating  unit tests to achieve the metric rather than creating effective tests.

It’s important to combine the quantitative unit test metric with a qualitative assessment by a peer developer. I recommend having developers pair program their first few unit tests with the Unit Test lead(s) and performing regular code reviews on unit tests.

Every team has to start somewhere and, by making unit testing a priority, you will reinforce the value and begin to see the investment pay off in higher quality code.

Succeeding with Agile Development – Part III

In this six-part blog series, Shirley provides practical advice on adopting Agile Development methodologies.


Agile Development is a software development methodology based on incremental, iterative development, where requirements and implementations evolve through collaborative, self-organizing, cross-functional teams. Agile Development promotes product delivery as a time-boxed series of functional and potentially shippable product increments that enables teams to rapidly respond and adapt to change.

Part III – Tuning

Having completed a few sprints and established the structure and rhythm of Agile, it’s time to begin tuning the process to increase predictability and to allow your teams to better handle complexity.

Enhanced Task Breakdown

To increase the confidence of the team in being able to meet their sprint commitments, it’s worth revisiting the task breakdown process to look for improvement opportunities. These could include:

  • More granular task breakdown (often, teams find that tasks expected to take <=1 day actually take longer)

  • Tasks that represent QA-able ‘chunks’. To streamline the process of getting stories across the board, engage the QA team to help break down the implementation into functional ‘chunks’ that can be QAed discreetly; rather than developer-led technical deliverables.


Improve the effectiveness of your scrum board by instituting (and managing) stories and sub-tasks into horizontal swimlanes using common-colored post-its.

Note: it takes some effort to buy sale-color post-its (thanks 3M!) but it is possible to get 4×4” post-its in the same colors as the 3×3” post-its and the swim lanes will make it much easier to observe and manage a complex sprint.

Broaden Code Ownership

While the fastest path to completion of a single task or story is often to ask the most senior/experienced engineer to work on it, this will dramatically limit your ability to scale the team and will create bottlenecks and frustrated, silod engineers.

Institutionalize knowledge transfer (even at the cost of slowing things down in the near term) and make your lead engineers responsible for increasing the overall effectiveness of the team by mentoring others.

Make it clear to the team that you are investing in an approach for the medium-term and recognize efforts to cross train.

Pair Programming

As mentioned in Part I, a key element of Agile success is collaboration. Many teams have not attempted pair programming, are skeptical about its benefits or are nervous about exposing their code to others. Start out slowly and make it easy. Designate a space for pair programming with multiple keyboards, multiple mice, a 27” (or larger) screen and a white board – so that team members can quickly setup and be productive. Encourage more senior team members to engage and mentor others. Use pair programming to facilitate knowledge transfer, for code reviews, for working on a particularly difficult piece of code or to break through an impediment (e.g. if a developer has been working on a task for more than 1 day and does not have a firm estimate for completion, suggest that they pair program.)

…and, while you’re busy tuning for success, make sure that you continue to focus on the fundamentals of Sprint Planning, Task Breakdown, Daily Standups, Sprint Reviews and Retrospectives. These will help establish a ‘heartbeat’ for the company that everyone will come to rely upon.

Succeeding with Agile Development – Part II

In this six-part blog series, Shirley provides practical advice on adopting Agile Development methodologies.


Agile Development is a software development methodology based on incremental, iterative development, where requirements and implementations evolve through collaborative, self-organizing, cross-functional teams. Agile Development promotes product delivery as a time-boxed series of functional and potentially shippable product increments that enables teams to rapidly respond and adapt to change.

Part II – Fundamentals

Start out simple and iterate; establish the fundamentals of the structure and process and, as each concept solidifies, introduce more sophistication.

Establish a rhythm for the team

  1. Decide on a sprint duration based on your appetite for risk. I recommend 2 weeks since most teams are well-equipped to collectively determine what work can be completed in a 2 week period. Remember, the greater your sprint interval, the greater the margin for error.

  2. Schedule recurring Sprint Planning, Task Breakdown, Sprint Review and Sprint Retrospective meetings

    1. The Sprint Planning meeting is held on the first day of the sprint and is focused on the team committing to delivering a subset of the prioritized backlog. Invitees should include the cross-functional development team and the Product Owner. Note: If you need to start early to get a jump on the week, bring in bagels or donuts and coffee – your team will thank you! (and they will be more likely to show up on time!)

    2. Task Breakdown should follow Sprint Planning and, done well, can take several hours. Take the time – it will pay off. I like to tell my teams that “even if we spend the first day of the sprint doing nothing more than planning and the last day doing nothing but wrapping up the sprint, the intervening 8 days will be so massively productive it will be worth it”. In fact, most teams find they have completed Task Breakdown by mid afternoon and are starting work on the highest priority stories by the end of the first day.

    3. Schedule a recurring 30 minute Sprint Review where the team demos all completed stories. I recommend inviting as broad an audience as possible to the Sprint Review since it demonstrates momentum and provides a forum for the team to celebrate what they’ve accomplished. Hold the Sprint Review at the same time on the last day of every sprint.

    4. The Sprint Retrospective follows the Sprint Review on the last day of the sprint and is an opportunity for the team to reflect on the prior sprint and identify opportunities for process improvement in the next sprint. It’s important that these meetings are focused on non judgmental idea sharing. I recommend writing down all suggestions in 3 categories: Start, Stop and Continue. Once all ideas are exhausted, have the team vote on the ‘top 3’ they will adopt for the next sprint. Document the Retrospective and review the prior ‘Top 3’ at each Retrospective to see a) if the team followed its own direction and b) if it helped improve the outcome of the sprint.

  3. Designate a time for the daily standup meetings. Hold the meetings at the same time every day (ideally at the physical scrum board), keep them to 15 minutes or less and be ruthless in tabling design discussions or tangential conversations. Every member of the team should answer 3 simple questions (remind them that they are updating one another, not the Scrummaster):

    1. What did you work on yesterday?

    2. What are you planning to work on today?

    3. Do you have any impediments? (Note: it’s the Scrummasters responsibility to capture and address impediments to maintain the team’s productivity)

Facilitate collaboration

In order to maximize the performance of your team, make it easy for them to collaborate. Require everyone to be in the office during ‘core hours’ (that is, hours when the entire team is physically in the office and able to collaborate.) I suggest core hours of 9:30am-5:30pm and allow for people to adapt their exact travel around commute hours.

If a team member(s) is offsite, use a Google Hangout or Skype for the Daily Standup so that they can see and be seen.

Define common criteria for ‘done’

Make sure that stories are not moved to ‘done’ unless all the criteria are met. For example:

  • Code checked in

  • Unit tests checked in and running

  • QA tests documented in the test management tool

  • QA complete and acceptance criteria met

  • Product owner has confirmed that the implementation meets the requirements

Steer for Success

Every Sprint begins with high expectations and, if everything goes to plan, all the stories will be completed on time and life will be wonderful. Of course, that’s not always the case. What’s important is ending the sprint with some subset of the stories ALL the way across the board to ‘Done’. This likely requires some ‘steering’ to accomplish.

Since there are often external forces at play (illness, escalated bugs that have to be fixed, etc.) make sure the teams work on the stories in priority order. As the sprint progresses, begin to query the team if the remaining stories are still on track to be completed. If the team feels strongly that a story needs to be dropped, work with the Product Owner to move the story to the backlog and/or identify a smaller story that can be completed. Strongly discourage the team from opening stories that may not be completed by the end of the sprint. The team’s goal is to deliver a potentially shippable product increment – and incomplete code will compromise this by creating code or QA debt (and associated risk)  that will have to be paid down in a future sprint.

Learn and adapt but stick to the principles

Every team is different. Be willing to listen to and incorporate the team’s ideas and suggestions for improvement that emerge during the Sprint Retrospectives – providing you are not compromising the core principles of the process.

…and most importantly, CELEBRATE often!

Look for opportunities to reinforce the benefits of the process; acknowledge when tasks are moved on the board, celebrate when stories are closed, and send the team home early on the last day of the sprint. After all, if they’ve completed all the committed stories, they are ‘done’ and have nothing to work on…until the next Sprint Planning!