Agile is growing up and is now officially a teenager. It has moved from being a somewhat rumbustious child with some overzealous followers and a skeptical management crowd to something that is generally accepted by the mainstream IT community and particular management.
Has the agile community lost something? Are the founding members and early practitioners evolving the practice? Is this good? Well, the answers are yes, yes, and maybe.
Teenagers get rebellious and moody and can go in bad directions, but they usually grow into people who are worthwhile. Agile still has benefits for many projects and people to learn that can improve their practices, such as continuous integration with testing. However, agile may have lost some values. For example, I have heard people say, “Management has hijacked agile from the development organization,” and this may be not so good. So, there is a dark side to agile.
How dare I say something like that? Isn’t agile saving the industry? Well, agile and various aspects of software are still changing because “we” (those who develop or create software) are young, so we should all still be learning. This article outlines some of the directions and considerations for the agile process.
For many of us who were always working to improve software development, agile was a nice moniker that captured what we had been working on and added some ideals we had not tried before.
In the early days of agile, I got a notice from a friend about agile and how it was a going to be a major shift in thinking for software developers. I printed the manifesto and showed it to my managers and developers. They said, “This is us and what we’ve been working on.” “Well, congratulations,” I said, “we have a nice new label and some new ideas to work on.” And so the project continued our journey of improvement, with a nice title and some new ideas.But did it really change anything for our project? Was that nice new label really good for us?
The label was not important, but unfortunately, I have seen some projects and companies wave the agile banner as if it were going to solve all their problems. (Plus, it was “cool.”) Agile is not magic. However, our project did pick up some ideas and continue the journey of improvement.
Some of the ideas we adopted included:
- Working closer with customers and managers, including direct involvement
- Implementing more testing and analysis by developers (not purely test-driven development, but close)
- Teamwork in small teams with short development cycles (many people use Scrum as their primary example of this)
- Focus on code that was continuously integrated with early testing and the “right” level of documentation
- Continuous planning as the test group provided information about the nature of our product
These methods did help our development efforts, and if someone wants to call us “agile,” OK. We found the following essential to our software improvement endeavors, in order of importance:
- We had staff with practiced skills (not just knowledge or any certification).
- We had to have knowledge about concepts, plans, hardware, and business considerations to do the work and apply our skills.
- While we had processes and they were important, it was more important to know when and how to not follow the process, and this required expertise.
- We had to work hard but smart, and run scared. We trusted our developers but verified their work as testers.
- We had to evolve and customize our agile skills and practices.
- Management, customers, and engineering all had to work together to provide leadership.