Saw this post on Wall Street Journal about GE going more Agile. It states that GE:
Started down this path several years ago and IT organizations within various divisions are making the transition to this approach at different rates... this methodology let the IT department complete a project around business analytics for the finance department, from start to finish, in a year, far less than the 18-24 month time frame its consultants and vendors would have taken using a more conventional approach.
The goal of the project was to make it easier to slice and dice financial information so that executives would have better information with which to make decisions. The project involved taking information from different systems and making sure the data could be read by the new software. The team also worked with partners in finance to determine their needs, and included review and testing phases to make sure the software was giving accurate results.
It goes on to elaborate how GE held internal conferences with big name Agile industry gurus as well as hiring Rally software to consult for them on the Agile transition. Interestingly and telling, was a comment left on the article by a reader who states that GE Healthcare is hardly Agile as it proclaims:
GE Healthcare leadership may proclaim that they are adopting Agile development methodologies, but this is certainly not the case in the Healthcare IT division that builds software for hospitals and physicians.
Projects are still required to meet “technical feasibility,” which allows the company to spread development expenses over several years. Unfortunately, this means that 100% of the detailed technical design has to be completed at the beginning of the program before any work can be done. This design can not be changed.
In this environment, if a customer’s needs change immediately after “technical feasibility,” the product design is not allowed to change to accommodate this new information. Basically, the needs of Accountants take priority over the needs of the customer and the judgment of the product developers. Not surprisingly, this results in commercially unsuccessful products that don’t meet customer needs.
It is difficult to build successful and innovative products when a bureaucratic culture makes it so difficult to respond to the needs of the marketplace.
My feeling is that the truth lies somewhere in between the two claims, though I do lean towards the comment left by the reader as being more truthful. I say this because in the companies I've been involved in, Agile is usually practiced in name only. This is especially the case with large strong marix and/or functional based companies such as GE.
If your in this type of situation, the best advice I could give is to see if you are following at least a few of these principles:
-
Working more interatively and incrementally, rather than trying to define everything upfront then executing all the work at once
-
Adopt a way to continually improve the quality of your processes and deliverables
-
Being more transparent to help clear problems more quickly
-
Your stakeholders may claim that every requirement is a high priority, but only a few are actually are and you get someone to work with them to get the top priority items done first
-
Change is inevitable so you plan and execute in iterations cycles that can both accomodate the changes yet still stick to the overall plan
I think if you're doing at least a few of the principles above regulary, you can claim to be on your way to true Agility. What are you doing to become more Agile?
Iterative incremental
work tends to be more effective than massively detailed plans.
Clean up after yourself continously.
High visibility helps clear problems quickly.
There is always only one top priority: your biggest bottleneck
GE Healthcare leadership may proclaim that they are adopting Agile development methodologies, but this is certainly not the case in the Healthcare IT division that builds software for hospitals and physicians.
Projects are still required to meet “technical feasibility,” which allows the company to spread development expenses over several years. Unfortunately, this means that 100% of the detailed technical design has to be completed at the beginning of the program before any work can be done. This design can not be changed.
In this environment, if a customer’s needs change immediately after “technical feasibility,” the product design is not allowed to change to accommodate this new information. Basically, the needs of Accountants take priority over the needs of the customer and the judgment of the product developers. Not surprisingly, this results in commercially unsuccessful products that don’t meet customer needs.
It is difficult to build successful and innovative products when a bureaucratic culture makes it so difficult to respond to the needs of the marketplace.
Posted on: June 11, 2012 01:00 AM |
Permalink