50 Developers Answer: What Do You Want Your CIO to Know About Agile?
Trying to explain the benefits of Agile Software Development to your CIO? Does your boss want some outside validation? Esther Schindler of CIO Magazine has done the hard work for you. She asked more than 50 developers and Agile practitioners one question "If you could get the boss to understand one thing, just one thing, related to agile development...what would it be? Why that?". Their responses have been grouped into seven categories:
1. Agile Creates Better Software
Kelly Anderson, technical lead at Sonic Innovations, says: "Poor quality costs money. Lots of money. Agile leads to higher quality, enough higher that it is cheaper." Cem Kaner, author of Lessons Learned in Software Testing and Testing Computer Software, notes: "Agile development can reduce the cost of late changes, making it easier for IT organizations to respond as stakeholders' needs evolve".
2. The Agile Mind-Set Is More than Processes
Agile is a collaborative way of working, says Mike Sutton of Wizewerx: "It challenges entrenched thinking. It's painful because it forces organizations and individuals to confront waste, inefficiency and shortcomings”. Agile development affects the entire organization. Support from the top is critical to making agile development succeed in an organization.
3. Agile Changes More than Development Workflow
Esther points out that, embracing Agile will—and should—change company culture as well as process. With frequent feedback and increased collaboration the organization will be forced to address issues that have existed but been ignored for a long time.
In addition frequent feedback means that the customer is able to see value sooner and the developers get feedback on their direction. Says Consultant George Dinwiddie, from iDIA Computing, "The feedback should be generated with as little delay as possible. Reducing the time between when a decision is made and when it is validated will pay off in reduced waste."
4. Agile Doesn't Mean "Chaos is Good"
Mike Emeigh, QA Manager at Deltacom, points out, good agile teams do requirements analysis and design: "They just don't waste a lot of time committing it to reams of paper [or] have a whole bunch of people who can't possibly grasp all of [the issues] try to study and understand it before they commit it to working software."
5. Agile's Benefits Are Worth the Wait
According to James Kricfalusi, service delivery executive at TEKSystems, the benefits may not be immediately obvious. Instead of expecting immediate results he recommends using the same time frame that applied to previous projects to judge progress.
6. Agile Isn't a Silver Bullet
Excellence requires care and attention to detail, as in any endeavor. "… teams need self-discipline, a rigorous approach to their work, management support and time to learn… the big gains people associate with agile development come from excellence, not mediocrity." says James Shore, an independent consultant and author of The Art of Agile Development.
7. Success Depends on People
Miano, the owner of Colosseum Builders, says, "Agile-type development also tends to be very personality dependent.... The people working in such an environment need to be able to ignore the personal quirks of the others."
Steve Reiser, a senior software engineer, says that a team's ability to respond quickly, with frequent periodic successes, makes team members empowered and happy.
There are many more responses to Esther's question in her article: Getting Clueful: 7 Things CIOs Should Know About Agile Development..
8 - Agile Doesn't Mean "Faster"
Gustavo Andres Brey
Re: 8 - Agile Doesn't Mean
I think that if CIOs want to know about agile, their best bet is to actively join in the agile processes. CIOs who want to experience the value of agile should join the planning meetings, attend the standup meetings, and use the product in real scenarios, so they can contribute to the collaboration in a meaningful way and see the results.
Re: 8 - Agile Doesn't Mean Faster
When you consider the Standish statistic that 40% of features are never or seldom used, you should be able to cut out roughly 40% of effort/time and deliver sooner, by delivering the most valuable features first. In reality, the customer is likely to think up new high-value features, now that he or she is free to introduce them early, so the project may end "on time" but with much more value delivered. It's hard to compare these apples and oranges.
That said, there are still those who will feel safer signing a contract up front, insisting on delivery of 100% of requested features, useful or not. In this case, of course, no time is saved.
In fact, a project could conceivably take longer, as Agile's transparency no longer allows developers to wave their hands and say it's "done" just because time has run out, when they know full well there are still holes and that some things won't be useable until the end of a subsequent release.