- Agile Software Development Stands for a New Way of Working
- Paying Lip Service to the Agile Principles Is a Mistake
- Agile Feels Different
- Top Ten Signs That Your Project Is Just Pretending to Be Agile
- Agile Is Not a Silver Bullet
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Top Ten Signs That Your Project Is Just Pretending to Be Agile
So, given all of the above, here are the signs that your project isn't Agile.
The project plan has just been published by the project manager and it shows the first release happening 18 months after the start of the project. If this happens, you know the project isn't Agile. In Agile projects, the focus is on the planning activity, not the resulting plan. Planning causes the team to make decisions and set priorities so that something valuable can be released in a few months, and first release after 10 months practically dooms a project to failure.
The project manager is talking about the deliverables that the systems analysts will hand off to the application architects. Warning: Waterfall ahead! The next thing you'll see is the architects handing off yet more deliverables to the designers.
The systems analysts and application architects are proud of the fact that they didn't write any code on their last project. Bragging about not having written any code is a clear sign that the analysts and architects think that writing the code is a trivial and easy part of the project. With that viewpoint, it's only a small step toward valuing working software less than they value their documentation, a clear contradiction of the manifesto. Whenever any member of an "agile" team brags about being "above" another team member's activities, the team is just pretending; it has forgotten that the real goal is to collaboratively deliver working software.
The project is structured so that the programmers and testers are definitely at the lower end of the food chain. Agile projects start coding and testing much earlier than more traditional approaches, typically within weeks of starting the project. Putting the programmers and testers at the end of a long food chain makes it impossible for the project to be Agile.
The systems analysts keep trying to get users to sign off on the requirements document. Freezing the requirements might be a good idea in some circumstances, but the Agile approach is to collaborate with the customer to deliver what's needed when the software is released, not what was thought to be necessary when the contract was signed.
The development team complains whenever a change request manages to sneak its way through the change-control process. An instant giveaway. Agile projects expect and embrace change.
You're more than two months into the project and the project team still hasn't demonstrated any useful functionality to the users. PowerPoint slides or screen mockups don't count—have the users seen a real part of the application yet? Agile projects let users get their hands on the software really early, so that the users can let the rest of the team know what to do to improve the software.
The project leads consider the documentation to be more important than communication. This happens when the project is producing a copious paper trail, recording all decisions made to ensure requirements traceability—but in spite of that, nobody on the team seems to understand what's really going on. This isn't to say that documentation is bad—just that it has to be kept in perspective. If information is important enough to be written down in project documentation, it's probably important enough to get the attention of a professional technical writer. If making the documentation easy to read isn't a priority, you can draw your own conclusions about the project, but it definitely isn't Agile.
Testing and quality assurance are not an integral, respected part of the development team. All Agile approaches rely on early testing and validation for feedback about the quality of the software. As such, the testing and quality assurance activities are recognized as a vital part of the development process that have to start on day 1 of the project. Deferring testing or quality assurance activities until later in the project is a sure sign that the process is not Agile.
And, finally, the number one sign that a project is pretending to be Agile:
Tasks are assigned to individuals who take their work away to a quiet place and treat it as a solo assignment. Whenever "team members" are always seeking a quiet place to work, or wear headphones to block out the distractions from the rest of the "team," you can bet that the team leads don't understand collaborative development. If they don't understand the basics of collaborative development, you can be certain that the project is definitely not Agile, regardless of the posters that might be up on the wall.