When is AGILE not agile?

Late last year, Telstra, Australia's largest telecommunications company, introduced Agile development techniques to its IT software development project teams. The theory is that smaller, self-managed teams will create better software, quicker.

As a certified Project Manager with business analysis and development experience, I love the idea that deliverables can be parceled out to a small empowered team. Unfortunately, I have also been engaged to "rescue" or "re-discipline" some of these teams who have either failed to deliver a viable solution, or have exceeded the project budget without delivering. In my experience, many "Agile" IT shops are using it as an excuse to not have any governance or project management at all.

Still, I think there is an opportunity for Agile to create quick, sustainable and cost-effective solutions for business and IT. The Agile Manifesto was declared in 2001 by a group of technologists who were struggling to fight the tiered management bureaucracy to create effective solutions.

The first paragraph of the AGILE Manifesto Principles is:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

A lot of emphasis is placed on "satisfy the customer" and "early and continuous delivery". But how do we define "valuable software?"

I pondered the Manifesto against my experience and came up with these Critical Success Factors for Agile Development.

CSF 1 - A succinct, defined problem

There is no doubt that a large problem such as "replace all legacy systems" cannot be Agile. Large problems require a big investment with commitment from a lot of people. Selecting small problems with tight solutions are key.  I've found that these work best for stand-alone web applications, or applications that collect or display data. Large implementations like ERPs and CRMs will never be agile, because you will never get a small enough base of knowledge, signoff, or commitment.

CSF 2 - A defined technical architecture

 "The best architectures, requirements, and designs emerge from self-organizing teams."

In this paragraph of the Manifesto, the term "architectures" must be defined. An application can only be efficiently managed if it conforms to the architecture investment of the organisation. For instance, if the shop builds all applications on Microsoft platforms, introducing a UNIX platform in the solution will not only delay the project, but increase on-going operational costs. Defined as "solution architecture," the team will create reusable code and objects that will make their lives easier as they add to the functionality of the software.

 

CSF 3 - Governance and measures

"The sponsors, developers, and users should be able to maintain a constant pace indefinitely." 

The Manifesto also ordains sponsors. This means that they will want progress reports. So before commissioning a team to solve the problem, we should determine how we will measure their success and report and approve their solution. Will we have an option to throw away the solution? How will we evaluate it before we spend additional money on additional functionality? How will we determine which functionality goes in which solution? At what point do we review the technical architecture and how information flows in the organisation?

"Working software is the primary measure of progress."

"Working software" should be defined as part of the problem definition. Is the solution designed for a single purpose or will the software be used for multiple problems?  How much functionality do we need before the software is considered "valuable?"

CSF 4 - Dedicated, empowered business users working with IT

 "Business people and developers must work together daily throughout the project"

Agile is not an IT methodology. It is a way for business people to solve their problem using the tool of technology. This requires a time investment of their most knowledgeable and trustworthy people. It means that only necessary staff should be on the team, and not political plants. If the "right" business people are not involved, then the software will not be valuable, because bureaucracy will again, takeover.
 

CSF 5 - Development and testing strategy and guidelines

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Good developers are not always good designers or architects. Identifying constraints and boundaries for technical architecture and design gives teams a framework for their solution. Tools such as Microsoft Visual Studio allow developers rigour and flexibility. Enough of both should be included in the guidelines.

"Simplicity--the art of maximizing the amount of work not done--is essential."

The team should strive to build a solution that will allow for additional functionality and minimize re-work.  Testing guidelines should include testing by uninvolved team members. When business people get involved throughout, they start thinking "happy path" just like the developers. Define testing roles up front with the business. Consider user acceptance testing as training for the users.

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly" 

Guidelines should be reviewed at the end of each scrum and recommendations made on what to change. The goal should always be to improve quality and speed, within budget and costs. The "amount of work not done" extends to future work that will not need to be done, or a conscious decision to include the work in a later release. The challenge for the team is to leave tidy code that is maintainable, and not just by the person who wrote it.

CSF 6 - Experienced IT and business users team members

"Continuous attention to technical excellence and good design enhances agility."

Inexperienced team members cannot make informed decisions about excellence and good design. They will likely take the quick and happy path to solution development, creating solutions that are difficult to maintain, enhance and integrate with other solutions. Team members should also be aware of good business analysis and project management principles, especially budget and time requirements.

Team members must be multi-disciplined and collaborative. Egos should be kept in check, with the solution a priority.

There's no guarantee that your Agile project will be a success, but if these are defined up front for all Agile project, I'm backing that you will have a better chance of success.