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.
: 
: 
: 
: 
:
Leave a Comment » | 
Collaboration, Planning, Reuse, SOA, agile | Tagged: agile, SOA, software reuse | 
Permalink
Posted by vijaynarayanan
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.
: : : : :
Leave a Comment » | General, Planning, Reuse | Tagged: communication, software reuse, template | Permalink
Posted by vijaynarayanan
May 25, 2009
Using iTunes?
Just 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.
: : : : :
Leave a Comment » | General, Planning, Reuse | Tagged: podcast, software reuse, techniques | Permalink
Posted by vijaynarayanan
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.
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.
: : : : :
7 Comments | Design, Planning, Reuse | Tagged: agile, alignment, refactoring, software reuse | Permalink
Posted by vijaynarayanan
May 14, 2009
You want to make sure that you don’t spend an enormous time trying to build the perfect reusable asset. Be it a component, library, or service. Regardless of what you are trying to do accept that you won’t be perfect from the get-go. Instead design for reuse iteratively. In earlier posts I blogged about delaying commitment and gave an example of an iterative way to build a reusable asset.
Iterative design is needed to not only deliver incremental functionality over time but it is also a handy technique to address a key risk with systematic reuse – schedule risk. In a typical enterprise project there are a lot of moving parts – there are multiple stakeholders to satisfy, several teams including infrastructure, operations, production support staff to co-ordinate with, and ensure legacy systems and processes will not be negatively impacted. Given that most projects are delayed you don’t want a reusable asset to make matters worse. Designing for reuse is often mistaken for making software that is too generic or abstract. It becomes easy to slip into philosophical arguments about levels of abstractions and layers of indirection. It is tempting to lose sight of the business problem and pursue perfection for the sake of technical elegance.
Here are some warning signs that you need to watch out for:
- Your developers are debating endlessly about a possible future use case that a component or service needs to support at the expense of what is currently known and required
- More meetings are being setup to design the ‘right’ interface to make sure you are guarded against future changes to a service or component
- You seem to be bogged down trying to figure out whether or not to support variation for a particular product feature.
- Your developers are working on designing a business component that has no traceability with what your business user wants
- There are endless discussions about whether or not a piece of functionality needs to be made reusable
When you smell this sort of behavior, you want to pause, look back, and refocus on the deliverable at hand. Pursue iteration, not perfection.
Like this post? Subscribe to RSS feed or get blog updates via email.
: : : : :
Leave a Comment » | Design, General, Reuse | Tagged: agile, iterative, software reuse, tactics | Permalink
Posted by vijaynarayanan
