GeeCON Prague 2014*
The moose likes Agile and Other Processes and the fly likes Explain Agile to management in 30 secs Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Explain Agile to management in 30 secs" Watch "Explain Agile to management in 30 secs" New topic
Author

Explain Agile to management in 30 secs

Fintan Conway
Ranch Hand

Joined: Apr 03, 2002
Posts: 141
Hi Guys,

Do you have a short and snappy way to explain/sell Agile Development to management in ~30 seconds. I was caught off-guard with this question once and did the usual techie thing of explaining some of the ways of doing Agile development rather than focussing on benefits that would ease this guys problems. I would like to have a ready reply if this situation ever arises again.

Thanks,

Fintan

PS I think this may have been answered here before, but when I looked for it there were only 4 topics in "Agile & other processes", so apologies if I am repeating an already answered question :roll:
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Here's the crux of the thing to me these days ... It doesn't define agile and it doesn't have to be exclusive to agile. You could find this much under many different names.

Iterative Development: Frequent delivery of running tested features.
Frequent: Monthly, 2 weeks, weekly, daily, whatever you can manage
Delivery: Handed to customers for review, shipable if necessary.
Running.: Integrated into the full system, real code.
Tested..: High confidence that it meets requirements, no defects.
Features: Some amount of function that has business value.

Write up a list of features that are needed at a fine granularity. Sort these into business value order or some meaningful priority order. Draw a line at a point where there are enough features to be worth shipping a release - this varies from one to all of them depending on your business model. Take the first n off the list and build them in an iteration. Review the list, add, remove, change, re-order as needed. Repeat.

The benefit is delivering real business value into the hands of users early and often. Early is good because users can really start using it and getting the business value sooner rather than later. Often is good because users can try it and give feedback right away rather than at the end of the project. It's also good psychologically - frequent success is more fun than a death march.

This isn't all a geek exercise in how to code more productively or have more fun. It isn't an academic argument over which method is "better" for some obscure reason. It is a serious business exercise in delivering value for IT dollars. The metric that measures success is business value delivered over time.

That's maybe 2 minutes instead of 30 seconds. Is that the kind of thing you were looking for?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I think the point of Agile from a management perspective is that at the start of each week, you present the developers the list of top priority features you want them to implement and they tell you, how much they are going to tackle. At the end of the week, they give you a fully tested, deployable system with those features incorporated.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Michael Nygard
author
Ranch Hand

Joined: Jan 03, 2007
Posts: 40
If they've got a background in other businesses (such as manufacturing, retail, distribution, etc.) you can tell them it's "just-in-time for software development".


Michael T. Nygard<br /><a href="http://www.michaelnygard.com/" target="_blank" rel="nofollow">http://www.michaelnygard.com/</a><br /> <br />Release It! Design and Deploy Production Ready Software<br /><a href="http://pragmaticprogrammer.com/titles/mnee/index.html" target="_blank" rel="nofollow">http://pragmaticprogrammer.com/titles/mnee/index.html</a>
Balaji Loganathan
author and deputy
Bartender

Joined: Jul 13, 2001
Posts: 3150
Originally posted by Ilja Preuss:
I think the point of Agile from a management perspective is that...

How about adding a point that helps Client/Customer ?

Ilja wrote: At the start of each week, you present the developers the list of top priority features you want them to implement and they tell you, how much they are going to tackle. At the end of the week, they give you a fully tested, deployable system with those features incorporated which you can also get approved from client/customer.

Will that make sense ? It take 20seconds to speak above text, still 10 seconds left


Spritle Software Blogs
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
As I read Ilja's post, "you" is the customer, so "you" can approve it, give feedback, install it, whatever. He said almost what I did in 10% the space. Pretty cool.
[ January 04, 2007: Message edited by: Stan James ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
New post for a new thought ... when you cut it down to 30 seconds you don't have time to talk about the practices. Does that mean they are not a critical part of whether you're "agile" or not?

And another new thought ... when I have a white-board I draw this first ...

ideas ---> AD Team ---> Software

The Goal is to convert ideas to business value in production software quickly and accurately. Of course your IT managers will say that's always been the idea, but then ask where they focus their energies every day. It's probably in documents, meetings, checkpoints, signoffs, negotiations, contracts. No sign of software yet. Some management has critical scorecards on how well projects conform to process, schedule and budget but no scorecard for how they deliver business value. Huh? The business value of production software is the prime metric.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:

ideas ---> AD Team ---> Software


Reminds me of the "cycle time" measure from Lean Software Development. How long does it take you from "problem stated by customer" to "solution installed at customer"? They use Value Stream Mapping to find bottlenecks - quite cool.

In it's current state, Agile Software Development is mostly concentrating on the bottlenecks that have to do with the development side, as far as I can tell.

Another thing that has been missing from this dicussion until now are the *values* of Agile Software Development - Collaboration, Respect, Humanity etc. Frankly, I'm not sure how to get those across in 30 seconds without sounding touchy-feely...
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
ideas ---> AD Team ---> Software

I'd say I stole it from Goldratt: The Goal, but I'm pretty sure the word "ideas" instead of "requirements" came from the XP discussion group, maybe Beck or Jeffries. The Goal gives us a metaphor for AD

raw materials ---> Factory ---> money

Product produced is no good until it's sold. That's one place Lean, TOC and Throughput Accounting broke from traditional accounting. Inventory used to have value, now it's a liability, a non-liquid investment with no returns. Our team has proven that requirements, design documents and even code RUST when left on the shelf. Come back a short time later and they are worthless or worse - dangerously incorrect.
[ January 04, 2007: Message edited by: Stan James ]
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Some of this seems like the sort of discussions we had during the lean book promotion. My take on this is that "lean" and "agile" exist at different levels of the same system.

"lean" is a high-level view. It includes a lot more than software development and addresses satisfying the goals of the organization as a whole. Its value is that it does not immediately dive into assumptions or details.

"agile" is a set of approaches, practices and attitudes which have been observed to work well in software development teams. I don't think it's a co-incidence that agile methods developed alongside the idea of patterns. Agile could easily be considered as a "pattern library" for software development processes.

Returning to the original question with the above in mind, I think the approach to take depends on the roles and goals of the "management" you are pitching to.

For board-level management, shareholders and other investors, it seems that a focus on "lean" would be appropriate. Their job is to make sure the right things are being done, and could well be that some software projects would have different goals (or even not need to be done at all). The details of how things are implemented would be handled at a lower level.

For intermediate management, for whom the overall goals have already been set, it depends on how they view their role in the organization.

If the manager sees him/her self as a technical manager of a software project, then focus on the benefits of an agile approach in terms of flexibility in responding to changing requirements, tracking of real progress, error elimination through aggressive testing and a "deliver at any time" mentality. All of these things provide real value to the daily work of a software manager who could easily feel squeezed between demands from above and inertia from below.

If the manager sees him/her self as a people manager, then focus on these aspects of agile. Continual cross-training, avoidance of burnout, team loyalty and the values mentioned by Ilja. Agile approaches can build a team which works together to solve problems without technical micro-management.

If the manager sees him/her self as more of a manager of a department, with the software development only one aspect of the work, then it probably makes sense to bring in some of the things Stan has covered in recent posts in this thread.

The bottom line, though, is that there is no single thing called "management". There are people, and groups of people, with goals, desires, worries, problems and jobs to do. The more you can find out about what drives the person or group you are speaking to, the closer you should be able to target what you say and how you say it.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
It also doesn't help that the "Agile Community" has a hard time defining or measuring Agility. There's some backlash against existing definitions with some people using an emphatically lower case "agile" to indicate they have agility but are somehow not with Those Other Guys.

I have to admit I was influenced by a neat video of Ken Schwaber I saw recently that was all about business value at levels the financial officers of the company should care about. This discussion has not mentioned pair programming or JUnit or bullpen seating and so on. Those things are controversial enough to blow your 30-second pitch out of the water and are not the really important bits to start with.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
It also doesn't help that the "Agile Community" has a hard time defining or measuring Agility.


I'm not sure what kind of definition you are looking for. I think that Agility is very well defined by the Agile Manifesto.

I'm not sure what measuring Agility would be helpful for. Can you measure RUP?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
But reading the Agile Manifesto would not mechanically lead you to the points we've raised here - which I really liked BTW. The manifesto is a wonderful thing, but it's not a method. Am I "Agile" if I have 80% of the XP practices or 90% of Scrum steps or 75% of the Agile Manifesto values? An I "Agile" only if I do it exactly like Ron Jeffries or Kent Beck? Silly questions, but they point out the challenges in describing Agile in 30 seconds or in a book, or deciding exactly which practices each organization should try. I'm struggling to figure out how to make my team and larger organization more agile in the face of many barriers. We'll wind up with some flexible combination of old and agile things, but will it be Capital A Agile? Don't know, don't care so long as we're getting better.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
But reading the Agile Manifesto would not mechanically lead you to the points we've raised here


I think that's partly because the intent of the 30 seconds explanation is to "sell" Agile. For that, as Frank said, it needs to be tailored to the audience.

Anyway, I think that coming up with something "mechanically" is a reasonable expectation, is it?

But I'm curious - did you include the Agile Principles in your above analysis? To me some of them seem to be pointing quite directly at what I described in my blurb:


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

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

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

Working software is the primary measure of progress.




The manifesto is a wonderful thing, but it's not a method.


In my opinion, Agile Software Development *is not* a method. Even XP *is not* a method.

Am I "Agile" if I have 80% of the XP practices or 90% of Scrum steps or 75% of the Agile Manifesto values?


You are right, that question cannot be answered. I actually think being able to answer that question would have negative value.


Silly questions, but they point out the challenges in describing Agile in 30 seconds or in a book, or deciding exactly which practices each organization should try.


Not silly questions, but the wrong questions. I think there are a couple of quite good books on Agile out there, but you are right that they don't tell an organization what practices to use (although XP is quite direct about which practices to *try*, I'd think).

In my not so humble opinion, one of the main points of Agility is exactly that only the team itself can decide what practices to use, and that it needs to be adjusted over the course of the project anyway. It is not a "follow the book to the letter approach" by intention - because one of the basic premises is that such approaches are inapt for software development.

I'm struggling to figure out how to make my team and larger organization more agile in the face of many barriers. We'll wind up with some flexible combination of old and agile things, but will it be Capital A Agile? Don't know, don't care so long as we're getting better.


I think I do something similar, although I care about whether we are capital A Agile. I don't have a checklist, though - it's mostly a matter of gut feel on how well we live the Agile values, and discussions with the community. I don't think it could work differently.
Zoe Boston
Greenhorn

Joined: Aug 14, 2006
Posts: 7
For a larger company Agile alone is just one small piece of the development lifecycle. If you want to sell Agile to a company you call it Iterative development with short releasable iterations.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Zoe Boston:
For a larger company Agile alone is just one small piece of the development lifecycle.


Mhh, I have never thought of "Agile" as a "piece" at all.


If you want to sell Agile to a company you call it Iterative development with short releasable iterations.


That's certainly one way. Why exactly would it be a good way?

And should we want to sell "Agile" at all?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
For a larger company Agile alone is just one small piece of the development lifecycle.


That works for me because my whole team is only one piece of the machine. There are a half dozen other organizations involved in getting a new system out the door. Most of them don't care how we work as long as we meet some sync points with them.

And should we want to sell "Agile" at all?


Sell may not be the right word, but if I want to try Agile where it isn't already understood I will have to convince the rest of my team to go along, management to let us, the project office to accept different metrics and reporting, ad naseum.

And I might want to encourage all those other organizations to play Agile with me so Agile can be the whole, not the piece.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:

Sell may not be the right word, but if I want to try Agile where it isn't already understood I will have to convince the rest of my team to go along, management to let us, the project office to accept different metrics and reporting, ad naseum.


It might be easier to convince them to try some practices by explaining the benefits, without even mentioning "Agile" at all.

After some time, it might then be a good idea to say something like "you know, a lot of what we have tried recently I have learned from the Agile community. Perhaps these other thinks they are proposing might have value for us, too."
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
without even mentioning "Agile" at all


Well, I have learned enough to never mention XP. I had hoped that Agile would be the kinder, gentler word that was OK to use.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:

I had hoped that Agile would be the kinder, gentler word that was OK to use.


I'm not sure that kind or gentle is the issue. I'd guess that most managers aren't interested in buying words, but in buying results. So that's probably what we should sell them...
Zoe Boston
Greenhorn

Joined: Aug 14, 2006
Posts: 7
I really like the spirit of what Agile tries to do. I liked it so much I tried to push this idea where I worked and it was easy for everyone to smile and say yet, but to implement was difficult. The biggest problem was Agile requires significant customer (sponsor) involvement as they are supposed to control what is built and approve the releases. Well, getting these people, that already worked 12 hours a day, to spend the significantly more time needed to do agile development proved very difficult. Going through the steps of Agile type development is not enough for it to work. The customer has to be heavily involved and that is where you hit problems.

So, I devised a more realistic approach of development which takes in the spirit of Agile and incorporate the best of other proven methods like Iterative, Prototyping, Staged, Timeboxing, XP, and so on.

Personally, I do not believe one size fits all. You need to first understand all the different methodologies and lifecycles then customize it for your environment.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Zoe Boston wrote:
You need to first understand all the different methodologies and lifecycles then customize it for your environment.

Absolutely.

As a side comment, though.

One thing which is often missed or misunderstood in attempts to adopt an agile approach is finding the real customers. By real customers I mean people who actually cares about the end product of the development effort, because it makes a real difference to their lives.

In my experience, most existing organizations have developed layers and buffers to actively prevent such people from being involved in decsisions. However much it may seem like it from the company org charts, a "delivery manager" or "client champion" or "account representative" or "project manager" or whatever is not a real customer. Such people inevitably have personal goals which do not line up with the actual value of the end result of a project.

This is my immediate thought when I read that "getting these people ... to spend the significantly more time needed to do agile development proved very difficult". If the project is really something they need, which will help reduce their workload and make their jobs easier/quicker/more efficient/more pleasant they should be all over it.

If you can find such a "real customer", and they still can't make the time to get involved with scope and priorities for development, then the project should probably be cancelled (or the goals significantly changed) anyway, because it obviously does not provide enough value to get the customer interested.

I'm sure there are other political pressures, too, so the "adapt and improvise" approach is spot on. But don't forget to keep asking the big question "should we be doing this at all?" along with "what would give most value right now?"
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Agile stuff is definitely a different mode of operation for customers as much as it is for AD teams. Some customers would like to give us a few weeks of intense attention, sign off on a pile of use cases, and then not hear from us again until the software is well and truly done. Agile requires customers to work with us continuously, with the expertise, authority and willingness to make decisions quickly.

I like the model Ken Schwaber describes that gives the customer responsiblity for success or failure. They set the scope and the date. They observe the velocity of the AD team. With a given velocity, it's their job to adjust the scope and date for success. Why would they let anybody else make decisions like that? Now that's a really different role for customers!

We have some remote customers who haven't entirely embraced the new mode yet, so we gave a few folks on our team responsibility to learn the customer position and act as "customer proxy." This is not something I'd recommend repeating.
Vivek S. kumar
Greenhorn

Joined: Dec 19, 2006
Posts: 25
even i m looking for something good about agile


"Make Your Own Rules and Rock The World"
Pj Murray
Ranch Hand

Joined: Sep 24, 2004
Posts: 194
Originally posted by Ilja Preuss:
I think the point of Agile from a management perspective is that at the start of each week, you present the developers the list of top priority features you want them to implement and they tell you, how much they are going to tackle. At the end of the week, they give you a fully tested, deployable system with those features incorporated.


The question is how to explain to management - and this is the closest to that in this thread so far, so apologies to Ilja for the rewrite:

Agile development allows the project sponsor to prioritize new features at the start of each iteration and have the development team commit to pre-agreed deliveries in terms of functinality, quality, and delivery date.


PJ Murray -
Frank Martinig
Ranch Hand

Joined: Oct 12, 2004
Posts: 59
I think that "lean manufacturing" applied to software development could be a good start/summary to introduce briefly agile. Poppendieck book gives practical advices on how to translate "lean" in the software development world.


<a href="http://www.martinig.ch" target="_blank" rel="nofollow">http://www.martinig.ch</a>
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
You might find that my definition is likely a pretty good elevator pitch for you.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Woody Zuill
Greenhorn

Joined: Apr 17, 2007
Posts: 1
I like the definition from the Practices of an Agile Developer book by Andrew Hunt and Venkat Subramaniam:

"Agile Development uses feedback to make constant adjustments in a highly collaborative environment."

I've been attempting to steer various development groups towards Agile for more than several years now, and find that sometimes the less said the better. Finding a clear and over-simplified one-senetence definition has been very useful for me on numerous occasions. It is important to understand that a "simple definition" can lead to unending questions, so you better be ready with answers to the hard questions or comebacks.

Some common "management" hard questions/comebacks include:
- How does Agile scale? I've read that Agile is just for small teams and that it can't scale because... (fill in the blank)
- Our customers are not going to want to do this. They come to us for solutions - we are the experts in their eyes.
- We need to know that everything will be done on time - Agile can't do that.
- How can we plan our resource requirements if we don't have accurate estimates?
- QA is not going to buy into this. How can QA do its work if we are changing things all the time?

I have notes on various converstations and could probably find over 100 questions of this sort that have come up (and that I've bothered to make note of), and I try to be prepared for any direction the converstation moves.

There are various Agile apologetics for any question I have encountered, but for me it often comes down to moving the idea forward with the hope that "planting the seed" will bring improvements. I have often been pleasantly surprised to find someone who was previously "anit-aigle" starts to become a proponent.

However, I have found little opposition to some points. For example, I have never had anyone make a strong argument against "process improvement" or "improving communication". A long time back I was taught by a brilliant salesperson that if you can get someone to say "yes" three times you've made the sale. Here is a (not so realistic) example:

Me - "I'd really like to see us improve our processes here so we can get things done a little faster, what do you think?"
VP - "Yes - that would be great!"
Me - "I think that if we can find a way to improve communication between the business team and the development team we could move things along more smoothly, but I'd like to hear what you think..."
VP - "Yes! Good idea - I've been thinking of that too, perhaps we could get everyone together weekly"
Me - "Also, if the QA team could be brought in a little sooner so they could get a jump start, do you think that would be an advantage?"
VP - "Yes - that seems reasonable."
Me - "Okay, we'll start doing Agile tomorrow and hire a whole bunch of Scrum Masters"
VP - "Ok. Agile it is. Here is a big check for training and hiring a top notch consulting group to guide us through the process".

Well... this is my reply and I can pretend anything I want to. The point is, get buy-in on the big ideas and the details can be worked out later. Perhaps.
[ April 17, 2007: Message edited by: Woody Zuill ]
 
GeeCON Prague 2014
 
subject: Explain Agile to management in 30 secs