Agile Development: Getting Started

As noted in our last post Is Agile Development Good for Health IT? Agile offers significant benefits to Health IT software developers. What may have come as a surprise is that many organizations that attempt to move from the traditional waterfall approach to Agile have trouble implementing it. Just Google “agile failure rate” to see estimated failure rates of 50% and higher. Some suspect corporate culture is a leading cause while others point to miscommunications between upper management and development teams.

Whatever the reasons for failure, many in the ‘Agilesphere’ agree that the key to Agile success is to start slowly. Scrum is widely recognized as the most popular Agile implementation as noted in the Agile Journal. Broadly, there are two ways to start a Scrum implementation:

  • Conduct a Scrum pilot
  • Water-scrum-fall: incorporating Scrum techniques into the waterfall approach

One key to conducting a successful pilot is to bring in an expert, or small team of experts, to guide the process. Experts can be hired or brought in as consultants depending on the organization’s budget and level of commitment to Agile. Certified Scrum Coaches and Certified Scrum Trainers are available throughout the world. The best pilot projects are smaller non-mission critical new applications or updates to existing applications. The more useful the project is to the user group, the greater the level of user participation – another key to success.

Whether bringing in experts or going the organic route, it helps to get members of your team familiar with Scrum just before or shortly after you start. The Scrum Alliance lists education providers that can provide Scrum training that relates to the different stakeholder roles or tailor training to your needs.

The Water-scrum-fall approach infuses Scrum techniques that complement waterfall methodologies into development projects. Two of the simplest Scrum techniques to incorporate into waterfall projects are the Scrum board and the daily stand-up meeting.

Scrum Board: One of the most popular places to start is the Scrum board – a visual representation of the project requirements, written on sticky notes, and categorized in columns according to their development status. The categories, to be named by the team, usually end in “Done.” It’s important to make sure the whole team agrees on what it means to be “Done”. The Scrum board offers an at-a-glance project status to all stakeholders and often becomes a popular gathering point which helps implement the next technique.

Daily Stand-ups: The stand-up is a 10 minute meeting each business day. Each developer provides a brief status of accomplishments since the prior stand-up, planned accomplishments before the next stand-up and any impediments to progress. All stakeholders are invited to observe. If issues are identified, stakeholders collaborate following the meeting to resolve them. Some project teams take a photo of the Scrum board after each stand-up to document project status.

Once these two processes are in place, sticky notes can be moved forward on the Scrum board during daily stand-ups. This tends to be very popular with stakeholders as progress becomes more tangible.

The Water-scrum-fall technique helps organizations begin their Agile journeys without changing the major SDLC components. All SDLC documents are still delivered. Requirements are documented up front and remain under strict control throughout the release as stakeholders have come to expect. This is often the most important difference between Scrum, where the requirements may change due to changing customer needs, and Water-scrum-fall. In order to manage stakeholder expectations, the Agile principal of changing requirements during the release can come later once stakeholders become more involved in software projects through Scrum boards and daily stand-ups.

Other Agile techniques that complement the waterfall approach include:

  1. Continuous software integration, which saves time and identifies code integration issues early in development when the cost of change is low
  2. Adopt the Scrum roles of Product Owner (sponsor), ScrumMaster (liaison between Product Owner and Team), and Team Member
  3. Create a product backlog if it doesn’t exist in some form already. This is a list of requirements to be included in the software eventually. Once created, work with the Product Owner to prioritize them.

Once these elements are in place, consider shorter release durations focused on the highest priority requirements. This aligns development team activities with business needs, shows success early and often, and creates the kind of software that users love.