Transitioning from Waterfall to Agile on a large SOA Project

May 31, 2009

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

Software Reuse Quick Tip #11

May 28, 2009

Tip #11 Document Capabilities as well as limitations of reusable software assets

When documenting a reusable software asset donot only capture only capabilities. Be sure to document limitations as well. This is important because limitations directly influence refactoring work. When trying to match a user story with an existing asset the limitations will determine the extent to which you need to update the existing code in order to implement the story. Limitations are not a bad thing per se especially since you want to prioritize overcoming them within the context of a real user need. This exercise is made a lot easier when you capture the limitations ahead of time – this way you don’t have to review your code or ask several developers in order to come up with the refactorings needed.

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! : :


Communication Plan – Simple Template

May 28, 2009

Here is a simple communication plan template that I use to keep track of communicating reusable software assets. It is very lightweight and can be easily put up on a wiki or a web page and kept upto date.

Feel free to customize it to suit your particular needs. Here is how I use it:
Date – Target date when a particular communication going to be delivered
Channel – Channel of communication (intranet, newsletter, email announcement, formal meetings)
Audience- Audience for the communication (managers, developers, architects)
Purpose – Purpose of communication might be to increase technical design knowledge, metrics/investment rationale, teach/educate, increase awareness, a call for participation/action etc.
Reusable Asset(s) in focus: List of reusable assets (template, pattern, library, component, service, etc) being communicated

Like with everything else it is more important to be disciplined about this exercise rather than anything else.

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! : :


New Episode on the Software Reuse Podcast

May 25, 2009

Want to listen using iTunes?

Using iTunes?

podcastJust posted the fifth episode of the software reuse podcast series covering why reuse efforts fail and introduces domain relevance and business alignment as key strategies to pursue.

Enjoy!

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! : :


Continously Align Your Software Assets To Be More Reusable

May 24, 2009

Thank you for giving me your vote on the hurdles for software reuse. From the results, it is clear that the number one reason for not being able to build reusable software is the lack of time in the development process. This isn’t surprising at all and reiterates the core message that I have been communicating in this blog. Agility and refactoring are your friends with reuse. Take a very pragmatic approach to the reuse effort and you will increase the odds of success considerably. The strategy that I have successfully used with reuse is to pursue continuous alignment.

What exactly is continuous alignment?

The idea of continuous alignment is very simple – place value on moving towards your target state with every iteration, every release, every project. You may not get there day one and that is perfectly okay. Align your software assets closer and closer to a desired state using relentless refactoring and code reviews. Do this often and over a period of time you will transform your codebase.alignment

Let me provide a simple example to illustrate this idea. Let us say you have a piece of code that sends email but is coupled with email addresses stored in a legacy database. You get a user story that wants alerts to be sent via SMS. Your initial iteration might implement this send SMS message without being aware of the existing email component.  Why? Because you may not have time to pursue this and get the other stories implemented within the iteration window. In your subsequent iteration you refactor the legacy email code by making it generic so it can take any email address and removing the tight coupling with the legacy database. You take the code for this new reusable component outside your application codebase and update the SMS code to use this new email component. Be sure to add automated tests to your regression suite.

Now, this might be done in one, two, or multiple iterations. If you cannot get it done you add it to your list of known refactorings with your backlog of tasks. When the next iteration comes around and you get a similar story you go back and work on the known refactoring.

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! : :


Emerging trends in software dev and impact to SOA based services

May 20, 2009

Here is a small presentation on some emerging trends in software development and discussion points for impact to SOA based services.

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! : :


Software Reuse Podcast New Episode

May 18, 2009

Want to listen using iTunes?

Using iTunes?

podcastJust posted the fourth episode of the software reuse podcast series covering the template method design pattern.

enjoy and would be great to hear your feedback!

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! : :


%d bloggers like this: