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:

1. We had staff with practiced skills (not just knowledge or any certification).
2. We had to have knowledge about concepts, plans, hardware, and business considerations to do the work and apply our skills.
3. 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.
4. We had to work hard but smart, and run scared. We trusted our developers but verified their work as testers.
5. We had to evolve and customize our agile skills and practices.
6. Management, customers, and engineering all had to work together to provide leadership.

These instances showed the positive side of agile. Every project should be working to become better or use agile ideals that might help improve their software, but in this next story, I consider some of the negatives of agile.

At a recent agile conference, an agile founding father bemoaned that agile had started as a developer movement and now has become a management movement. He pointed out that developers and testers have started to “move on” to skilled craftsman concepts. I have read opinions that as few as 10 percent of agile development teams reach “high performance” levels. I am not sure I believe these numbers or think that agile project performance is this bad, but I have seen agile groups not reaching the successes they had hoped for. I also see agile conference agendas being dominated by management presentations and fewer sessions covering technical concepts in analysis, design, coding, testing, and support areas.

A larger concern for me is what has happened with many “management movements,” e.g., CMM, CMMI, quality awards, etc., that projects and managers have implemented because they were cool or good for marketing. However, the movements were paid only lip service, and actual project performance did not improve. Not being completely serious about agile may be in part why only 10 percent of teams were said to reach high performance—or may be responsible for the reported failures of agile.

Here are some specific reasons I have seen agile teams “fail”:

• Expecting agile to be magic (having an irrational exuberance about the agile ideals)
• Using the agile label as a cover for bad practice
• Not allowing for small failure, and when they fail, not learning from the failure
• Not figuring out how to work within limitations every project has, e.g., customer demands for products, a sufficient budget, realistic schedules, etc.
• Management interference in concepts such as sprints and Scrum teams
• Generally bad communication between teams, customers, managers, and other stakeholders
• Teams did not have a safe work environment (i.e., they had fear, lack of support, the wrong tooling, no chance to learn and build skills, no understanding of what agile really is, and unrealistic resources)
• Teams or management did not understand that projects need to be staffed by the right people with the right skills and practices
• Not understanding the critical tasks, risks, or components to allow prioritization of work

Organizations should not adopt the agile label just to be cool or for marketing reasons. Don’t fool yourself. Instead, try to understand where your team and projects are and ask what ideas can encourage improvement. Take a risk, but be willing to work change when needed. I don’t care if you call yourself agile or something else; I care if projects develop skilled people, focus on customers, and deliver products that delight the users.

We can all lie to ourselves and put on a label or certification on some practice, but this will not make projects successful. Making software is hard—it’s maybe the hardest thing humans create. Thinking agile or any concept can make software development easy so that it can be done by unskilled people is foolish.

Groups I have worked with that worried less about labels or names and cared more about doing good work with a customer focus were successful. These teams “ran scared,” thinking the software had to work or we’d lose our jobs, and focused on the uniqueness of the project. We knew what worked and what we needed to work harder on to improve. We practiced agile but knew we could always get better, and we knew the label of “agile” was not as important. As agile grows out of its teenage years, teams should worry less about a label and focus more on doing good work.