Transitioning from Waterfall to Agile on a large SOA Project

Last week I spoke at the International Association of Software Architects (IASA) New York chapter’s monthly meeting on Transitioning from Waterfall to Agile on a Large SOA Project. Here is a quick summary:

Challenges

  • Changing business mindset that the project will be released in production as a single deliverable
  • Convincing the business to prioritize requirements
  • Enlisting your business stakeholders to be part of a unified team.
  • Maintaining the project plan within the context of agile
  • Making the case for following agile instead of the official development process
  • Preparing to address the fear, uncertainly, and doubt (FUD) factor with learning agile practices
  • Integrating agile with IT processes – iteration planning with program management specifically cross project dependencies, incremental releases with release management and incident management, and incremental design with enterprise architecture and governance
  • Adopting agile practices – which methodology to adopt? Which practices to follow?
  • Integrating distributed teams into the iteration planning and daily stand up.
  • Understanding the impact of integration with several systems and legacy processes
  • Identifying the right level of granularity to be added to the task list

Lessons Learned

  • Business stakeholders are more likely to buy into incremental delivery if it is explained in terms of faster return on investment, earlier end user feedback, and risk reduction
  • Collaborate with your business on identifying and prioritizing user stories. Focus on the absolute essential stories and ruthlessly cull the rest.
  • Timebox your iterations – the standard “2 week” sprints may not be enough for development and integration testing.
  • Engage with your QA team ahead of the formal testing phase. Enlist their support to develop more comprehensive test cases during development.
  • The project plan might never go away! However, the task list can be the primary source of input into updating the plan as well as help reflect true project state
  • Prototype – even if it is entirely paper based – by having business and technology together to foster joint problem solving and a sense of shared ownership
  • Include business participation in daily stand up meeting, iteration demo, and retrospective
  • Consider dedicated stand up meeting for remote teams – have reps for daily meetings
  • If you are unable to convince release management to be comfortable with continuous delivery have internal releases and align with published release dates
  • Adopt agile practices slowly – it is important to be consistent and disciplined rather than adopting several practices in a haphazard manner
  • Pursue continuous integration in an incremental manner – you don’t have to get multiple layers and technologies all part of the daily build from day one.
  • Strive to standardize tools in order to simplify tracking and reporting. Use a simple tool like a wiki before switching to a full blown issue tracking tool.
  • Keep a close eye on the iteration backlogs. You cannot only estimate and plan for new functionality

Candidate list of agile practices to start with:
Daily standup meetings, incremental design, done-done, iteration planning, continuous integration, retrospectives and iteration demo.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: