Monthly Archives: January 2014

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!

Succeeding with Agile Development – Part I

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

at the top

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.


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.

  1. 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.)

  1. 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.