Sometimes considered a Wild West approach to project management, Agile methodologies in actuality can create order, not chaos. The key is being clear on what Agile means at your organization.
Take the example of General Electric, which had too many software development approaches across GE Energy. When Agile was introduced, detractors complained it would be a “willy-nilly” approach, versus a familiar structured approach, such as waterfall, explained Paul Rogers, executive manager of GE Energy’s Software Solutions Group (SSG).
However, as Rogers explained at the recent Forrester Research event in Boston, Agile practices brought order to GE’s SSG by getting teams across the organization on the same development page, following one documented and governed methodology.
“In waterfall, it appears that you’re going from step to step. The product requirements document is created and sent to the technical requirements folks. They decompose it and send it to the coders. The coders send to it QA/QC, and you get the perfect product at the end,” Rogers said. “The problem with that is that with each handoff there is a different interpretation of the specs down the line.”
That’s a pretty unpredictable development process, he said, and the main reason SSG opted to make Agile the official methodology. All SSG employees were required to learn the GE-branded curriculum and become certified in the same Agile methodologies. The GE-branded part is a key point, since a lot of people have a different opinion of what Agile is and is not, he said.
The BPM approach
Taking the guesswork and, yes, chaos out of project management can also be achieved by using business process management (BPM) software to introduce Agile methodologies.
When a new product or service is being considered at a company, BPM identifies which processes will be affected. If changes need to be made to a process to accommodate a new product or service, it can be done quickly. Also, if a business process can not be changed — for example, a given process may protect the organization from violating a regulation — then the decision can be made on the fly not to change it.
“Being able to identify how business processes may need to change and who in particular needs to make that change, versus getting 100 people involved to see if a change might violate a standard or regulations, allows [project] teams to be Agile and flexible, and recognize where Agile is not possible,” said Mathias Kirchmer, executive director of Accenture’s BPM practice.
Yet another example provided at the Forrester event of Agile methodologies reining in a major project was Dan Simpson’s business transformation effort while CIO of Physicians Mutual (he joined Trustmark as CIO this month).
As Simpson told the audience, he was brought in to get rid of legacy systems and create a new set of modern services focused on customer needs and buying habits. His go-to solution was SOA. In the end he created services that could be reused time and again when a new application or service was called for by the business or customers. The main benefit? He delivered on his promise to create a single information view for the customer … and introduced Agile methodologies in the process.
“We decided to implement close to 40 new projects as part of the business transformation effort over a period of years,” Simpson said in an interview with SearchCIO.com. “Iterative development using Agile methods was our ’Agile version‘ for those projects. [That iterative method] was how we determined if user requirements were actually being understood during the development process, rather than us implementing something and finding out users aren’t satisfied.”
Agile saved them a lot of grief in terms of having to correct mistakes and redirect projects.
One takeaway from both Rogers and Simpson? Agile methodologies are going to vary from company to company, but you need to come to an agreement as to what Agile means in your particular situation — then document it, educate everyone and stick to it.