Wednesday, August 25, 2010

To Agile or not Agile, that is the question

Following are the principles of Agile I like to incorporate into projects:

• Organizing phases into 2-4 week iterations (Sprints) so that there is distinct product or deliverable assigned to each iteration.
• Performing User Acceptance Testing (UAT) early in the system life cycle, rather than the end of the SDLC, to gather business user feedback early and often.
• Designing the system with the expectation of change. This allows agility and flexibility. I assume that the services we build will need to be dynamic with the changing business climate and will need rapid.
• Maintaining an On-going "Product Backlog" which is ranked and prioritized list of requirements. The list is constantly re-ranked and prioritized and the top candidates are inputs into the next Sprint iteration.
• Brief daily Status meetings (Scrum) to check progress, roadblocks, and planned activities.
• Collaboration amongst the team and amongst the business team is key to vetting solid and practical frameworks
• Keep it Simple. Making governance frameworks and patterns overly complex runs the risk of limiting adoption
• Business Processes are the foundation of what applications have as an objective, and in Agile the business stakeholders are a key to driving the development process (having a Product Owner).
• Governance requires Multi-stakeholder team, consisting of representation from various IT and business teams.
• The use of a Burn Down Chart can help all stakeholders track progress of the overall initiatives.
• Rapid. Using Agile will force teams to get working services and deliverables in a quicker fashion and forces accountability across the team.. This also has a good impact to team morale (developers tend to enjoy the Agile process)
• Good for creating a Knowledge base to capture "lessons learned" early and often for continuous improvement.
• Agile reduces waste; Captures bugs early, avoids goldplating, committed team members

Some of the more radical Agile principles that I don't necessarily prescribe or apply include:

• Limitation of documentation. In projects, especially around governance, certain documentation is key such as patterns, SLA's, contracts, frameworks, etc
• Self-organizing teams. I feel that leaving the teams to self-organize can be a bit optimistic and instead I feel a project sponsor is best suited to help organize the team, with our strategic input on personnel skills and capabilities.
• Documenting User Stories (Requirements) on stick notes. While this is good for collaborative working group sessions, I find it is very important to electronically capture and publish the User Stories for all team members to view through an online, browser enabled tool
• Individual iterations over processes and tools. I feel its important to follow a disciplined process and using the right tools to build services and applications is important as well.
• Not following a plan. I feel it is important to have a high level Roadmap for tackling projects, and maturity model that outlines milestones to achieve adoption and capability achievement.
Posted by at 6:38 PM
Reactions: 

5 comments:

  1. Good points. What are your thoughts on build automation, dependency management and overall release planning as part of Agile project management for SOA applications?
    ReplyDelete
  2. Rajesh-- I am a big fan of "Continuous Integration" techniques of automating build and end-to-end testing. Some of the principles around doing this daily and NEVER breaking the build I find a bit optimistic if not radical to try to do that on daily basis with SOA and expect the build to never break. I would favor "don't break the sprint" vs. "don't break the daily build". Also, that automation is a lot more complex an initiative with SOA than an application because there are more moving parts and systems to coordinate for automation, but its certainly doable! The bigger challenge is convincing and budgeting for this...the value is there, its convincing tight pursue strings the value can be tough, but doable as well!
    ReplyDelete
  3. Hi Jordan, those are my thoughts as well, in fact, I like to extend that same latitude to other agile areas, especially when it comes to enterprise SOA.

    For example, it is not practical to expect production ready code at the end of 2-3 week sprints when integrating complex enterprise apps using SOA. For this reason I prefer the definition of done to include one complete aspect/functionality of a given service and then have a set of "hardening" system test sprint cycles to create production ready code.

    Similarly, realities of product development require thinking through an entire product release instead of re-planning entire product backlog at start of the sprint.

    Will try to post a blog on this soon.
    ReplyDelete
  4. Thanks for sharing, I will bookmark and be back again

    Scrum Process
    ReplyDelete
  5. Nice Points discussed Jordan.

    I am in a project of Oracle SOA suite based Web Service development and we use automated test bed for IT Testing. Two major problems we faced in adopting Agile is its fixed Sprint length (2 weeks in our case) which has created re-work on testing side. If a service takes 4 weeks, breaking it up in 2 sprints mean testing it 2 times, at the same time at the end of 1st sprint it is really not ready for consumption as it is 'Partly complete' and consumers in demo meeting is hardly concerned how development team has progressed as they can not consume after 1st sprint.
    Secondly, in middle tier technology when you are buildign service you are not only keeping in mind the first consumer but also all the future consumers and trying to build a real moduler service. Having said that product owner is mostly the middle tier Architech/Designer rather than a true consuming side Business Owner. Do you see it as aberration?

    Your thoughts pls.
    ReplyDelete

Subscribe to: Post Comments (Atom)