Tag Archives: Task Breakdown

Succeeding with Agile Development – Part III

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

ggbover

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.