50 Developers Answer: What Do You Want Your CIO to Know About Agile?

Posted by Mark Levison on Feb 19, 2008

Sections

Process & Practices

Topics

Agile ,

Leadership

Tags

Management ,

Culture Change ,

Introducing Agile ,

Retrospectives

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..

1. Back to top

   8 - Agile Doesn't Mean "Faster"

   by Gustavo Andres Brey

   I don't know why Executives thinks that if you use agile methodologies the project will take less time and less resources. I thought that it only happened in my country (Argentina) but not, this feeling is everywhere, please CIOs, if you want to understand what agile means, stop thinking about software development as a factory... software development is a creative work, and engineers are not machines, we are professionals...

   Reply

2. Back to top

   Re: 8 - Agile Doesn't Mean

   by Virginia O'Connor

   Gustavo, I think you are correct. As a technical writer involved with an agile development team, I've seen how agile reinforces the creative work inherent in software development. I've also seen how collaboration makes developers better developers. Using this model, developers have more perspectives to collaborate with ... often they get the customer perspective (sometimes from actual customers, sometimes from QA and writer members of the team) and they can mesh that with their knowledge of the system and code to generate a truly unique and useful solution.
   
   Virginia xaware.org
   
   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.

   Reply

3. Back to top

   Re: 8 - Agile Doesn't Mean Faster

   by Deborah Hartmann

   I believe the difference is the shift from delivery of "a plan" to delivery of value. It makes it hard to gauge old vs new process speed.
   
   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.

   Reply

• Older >