10 Ways to be More Agile

Share on LinkedIn0Tweet about this on TwitterShare on Google+0Share on Facebook0

Written with contributions from Michael Mariani, Tim Mattix, Ryan Finnamore and many others.

You might think the word “agile” is synonymous with “paralysis” to see some organizations react to the idea of introducing agile development principles to their traditional systems development lifecycle (SDLC). Concerns about introducing too much change to the organization can stop agility discussions with the business before they start.

But if the organization’s goals include increasing the speed of development, quickly uncovering defects, improving business-IT understanding and raising the level of overall solution quality, here are 10 agile ideas to consider. These are based on lessons learned from a team who transitioned to agile several years ago and has consistently refined their approach to improve their quality and productivity. They offer an incremental approach for introducing some very sound practices to your development process. Just be careful about throwing around the word “agile” and focus instead on the benefits to the users.

Ways to Increase Agility

  1. To baseline a project in 2 weeks or less, use a cross-disciplinary team to rapidly move through the planning and estimation process to gain early consensus on scope , schedule and budget. Members of this team need to carry a blend of methodology experience, business acumen and functional understanding, architecture, and project modeling.
  2. Create prominent visuals that everyone can see to communicate progress, deadlines, assignments, ideas and unresolved issues. Establish visual requirements early on in the process - spreadsheets, whiteboards, flip charts, etc.
  3. Create an environment that promotes direct and frequent face-to-face interaction (there should be limited need for email between analysts, architects, and developers). Understand that new offshore teams initially require elbow-to-elbow time with onshore constituents to breakdown communication and cultural barriers.
  4. Frequent stakeholder interaction minimizes re-work, builds trust, and establishes decision-making accountability. Set expectations early with them around a recurring review schedule and informal updates.
  5. Foster consistent interaction between the technical architecture and analysis teams when determining scope and completing requirements to minimize the risk of oversimplified or incorrect assumptions which eventually could have a drastic impact the ability to deliver the expected end result to the customer.
  6. When necessary, embrace traditional software development practices to mitigate quality concerns. We encourage code and story analysis reviews and software architecture modeling work before it gets into the developer in-box.
  7. Include QA reviews as a required step in the analysis sign-off process. Their perspective when reviewing functionality can unearth issues that otherwise would have not been discovered until too late in the project.
  8. Don’t under invest in automated test development. The shift to test-driven development is an absolute must when running multiple teams concurrently on a single code base.
  9. Schedule demonstrations to key stakeholders throughout the development process. Although there may be challenges with presenting incomplete functionality, discovering missed or incorrect assumptions as early as possible is worth the risks.
  10. Don’t wait for development of a feature to be 100% complete before starting to test it. Agile testing practices allow for incremental testing to occur while the software is still warm - a great benefit to the developer given course correction can occur while it is fresh in their mind.

What agile tips would you add to the list?

Image shared by chucklepix

Share on LinkedIn0Tweet about this on TwitterShare on Google+0Share on Facebook0
  • Pramod

    Good tips, indeed. Bullet #1 is the key - you have to have people with right skills, capabilities to kick-start Agile. One thing I would add is “Training”. Most of the organizations are still entrenched in Waterfall, RUP and such. Getting these organizations to Agile would be somewhat easier with training and showcasing the case-studies. Off late, companies are beginning to understand that they have to execute projects faster to gain competitive edge and show-case business benefits to management. I think Agile is one way to get there, if done right.

  • Pingback: 10 Tips to Agile Software « TechLedger()

  • 2 thoughts. First it that all practices that improve the early and continuous learning of the system / context are a plus! Second is the definition of DONE: doesn’t matter if a ‘feature’ (or whatever it is what you are giving to your customer) is complete, what it matters is that that part of the feature is considered DONE when is in use by the customer. This definition of DONE means feedback from the users that means feedback: so do it continuously!
    My 2€ cents,
    PierG
    http://pierg.wordpress.com

  • Pingback: The Agile CIO as a Business - IT Marriage Counselor — CIO Dashboard()

  • Wbroekhals

    What would be good would be to see living examples of these for example: Create prominent visuals, here are some powerpoint examples that show prominent visuals.
    I also see agility as meeting the changing needs of the business.

  • Pingback: Learning by Doing with Labs — CIO Dashboard()

  • Olivia

    Good points. It is clear once you embark on more agile development that the line between traditional “QA” and test driven development becomes blurred. Throughout the prototype delivery iterations (especially in a multiple system integration project) you will find that only development teams can complete system testing as the prototype is too immature for traditional QA teams to execute.

    Although the ideal mitigation against that would be a more time to spend documenting enough for QA to understand, this would negate the speed. I have found that correct architecture design and  engagement throughout the rapid development cycles will see a “self-sufficient” test driven development team. QA can then be brought in to assist towards the finalisation of the design and implementation.  This also improves the overhead of the project and not just the agility.

  • Pingback: Agile Development: The Next Phase — CIO Dashboard()