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.
