Succeeding with Agile Development – Part VI

In this final of 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 VI – Scaling

Velocity

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’)

Resizing

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.

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.

Summary

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.

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.

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.

Swarming

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.

Swimlanes

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!

Succeeding with Agile Development – Part I

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

Agile Development is a software development methodology based on incremental, iterative development – where requirements and implementations evolve through collaboration across self-organized teams. Agile Development promotes product delivery as a series of functional (and potentially shippable) product updates, enabling teams to rapidly adapt to change.

Moving Beyond Best Practices

There are a litany of books, blogs, websites, consultants and training courses aimed at helping companies adopt Agile Development and yet most companies struggle with moving beyond Agile “best practices” to a “common practice” that’s adopted throughout the organization.

To ensure success, Agile should not be seen as a way to “make engineering better” but as a strategy to streamline a business. Agile adoption should have executive visibility and support, and the benefits should be explained to and embraced by the entire company.

Part I – Preparation

Before starting your first Sprint it’s important to “set the stage” for success.

Educate and evangelize.

Take every opportunity to present the benefits of Agile to members of your organization. Let’s look the benefits you should present to different stakeholders.

1. Executives: Better development predictability, accelerated time to market, greater alignment with business objectives.

2. Product and Engineering: Increased collaboration, closer alignment with business objectives.

3. Sales and Marketing: Competitive leadership, faster time to market, confidence in product delivery dates.

Cross-functional teams

The key tenets of Agile Development include iterative development, continuous integration and testing and self-organizing teams; resulting in a ‘potentially shippable product increment’ (hyperlink). This cannot be accomplished by a silod, functional organization.

Rather than impose an Agile structure on your Engineering organization, use this as an opportunity to model self-organization. Set the parameters (including number of teams, need for a balanced skills composition, etc.), stand back and let them organize. It may not come out exactly as you’d expected, but it will create a strong sense of empowerment and begin to signal how things will be different.

Backlog

Work with product owners to rework outdated MRDs and PRDs into a prioritized sprint backlog of stories.

Follow a disciplined approach, and the standard format: ‘As a …I would like to … so that I can …’

Note : The ‘so that I can’ is what defines the scope of the story and informs QA of the underlying intent. (you will be pleasantly surprised how this will help to flush out unclear or key requirements that may have been overlooked previously)

Scrum boards, Scrummaster, Post-its

1. Identify or hire a Scrummaster. It’s important that this person is an impartial facilitator. Their role is to help uncover and remove impediments for the team. Don’t appoint the Director or VP of Engineering to fill this role unless you can be sure that no one on the team is concerned about sharing openly with them. If your Scrummaster does not have prior Agile experience, I recommend investing in a Certified Scrummaster (SCM) course.

2. Create physical scrum boards. Even though most companies will adopt an online tool to manage their agile process, nothing beats the visibility, transparency and visceral pleasure of moving post-its on a physical scrum board. It also creates a place for the team to assemble and hold daily standups or daily scrums.

Start with at least 6 columns on your board (To Do, In Progress, Ready For QA, In QA, Verified and Done). As your process matures, you can re-draw the board to include more granular activities (such as Unit Testing, Code Review, etc.)

3. Invest in ‘super sticky’ post-its. Whether your scrum board is a white board, a section of wall or foam core board, if you use regular post-its they will likely fall off and disrupt your sprint.

Establish and Communicate Core Principles

Decide what’s important for the success of your Agile Development process and socialize them as core principles. For example,

• Fixed 2 week Sprints, starting on a Monday

• Aligned Sprint boundaries (all teams start and end their Sprints on the same day)

• Sprint commitments are made during Sprint Planning based on the Product backlog

• Task breakdown is completed for all committed stories on the first day of the Sprint

• Tasks are broken down to 1 day or less

• Sprint deliverables are ‘potentially shippable’ product increments

• Daily stand-ups use Scrum board to track progress

• Self-organizing teams

• ‘SWARM’ on a single story  where possible (remember, the goal is to get more stories completed during the sprint.)  “It’s better to have 80% of the stories 100% done, instead of having 100% of the stories 80% done.”

• Minimum of 1 developer and 1 QA per open story

• Do not exit a sprint with code or QA debt

• Everything worked on MUST be on the board

Now It’s Time to Start your First Sprint…

The next in this series will help you introduce the Agile process and begin to establish the foundation that you and your teams will build upon.