Getting agile – should we?

Agile girl

Should we adopt an agile process for our team? Methods and Tools has posted a two part article titled Adopting an Agile Method. In thier article, they explore five areas of consideration. We provide our thoughts on each area.

Five areas to consider (from the article)

  • Our organization’s culture
  • Our customers and how they prefer to interact with us
  • The types of projects we do
  • The tools and processes that we currently use
  • The strengths and weaknesses of our software-related staff

They go on to make points in each area. Here are our thoughts on them

Culture

The toughest hurdle for any organization with going agile is adopting the notion of dynamic planning. With an Agile project, our expectation is that we do not know what the end state should be when we start the project. Some writers create an outline first, then fill it in. Others just start typing and “let the story tell itself.” Moby Dick is a classic example of a story telling itself. Mellville starts the book with a lot of emphasis on Bulkington, intending him to be a major character. On the day the Pequad sets sail, Mellville changes his mind and washes him overboard. Ahab takes the main role from there. [Analysis by Ansen Dibell in Elements of Fiction Writing].

In the debate between Cooper and Beck, Cooper charges that Agile processes are designed to make changes tolerable. Beck contends that they are inevitable.

If our culture is uncomfortable with the expectation that change will happen, then Agile will be a struggle.

Customer involvement

Agile processes require customer feedback and involvement throughout the process. Without feedback from customers, incremental delivery becomes incremental construction. We would still get the development-efficiency gains from iteration and introspection, but we would lose the much larger gains that come from redefining our objectives to focus on the right requirements.

Types of projects

The article promotes Agile as being more applicable to smaller projects subject to excess change. We think Agile, if adopted, can be applied to any project. We would ask, which projects are better off discovering that the wrong requirements were implemented after the project is complete, instead of in the middle? An understanding of sunk cost makes this all but self-evident. The less money spent on implementing the wrong thing, the more we stand to gain.

Current process and tools

The article points out that effective Agile processes are dependent both on automated testing and good source code control. Without either, the overhead associated with each iteration makes it too expensive to be Agile. We have to be able to automate testing (both technologically and culturally). We also need to be able to version and branch our source code. If we are in a code-freeze-test-debug cycle, we will get crushed by the burden of additional testing that comes with incremental delivery.

Staff skills

The article talks about the need for higher absolute capability from Agile team members. We think that this isn’t true. A more rigorous attention to process is required. People who forget to run the tests before promoting their code hurt every project. The pain is more keen for Agile projects, that depend upon a presumption of a valid baseline as a starting point for enabling more aggressive refactoring.

Summary

We talked about the benefits of being agile yesterday. To make Agile processes work,

  • We have to have people capable of following process.
  • They have to be equipped with the tools to automate testing and reduce release-overhead.
  • We have to have stakeholders and customers that can be engaged throughout the development cycle for feedback.
  • We have to have managers who are willing to plan on changes to the plan.

We also need to watch out for the top ten mistakes of adopting agile processes.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.