The Artima Developer Community
Sponsored Link

Weblogs Forum
Agile Methods. The bottom Line.

17 replies on 2 pages. Most recent reply: Jun 24, 2007 7:43 AM by Scott Fraser

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 17 replies on 2 pages [ 1 2 | » ]
Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Agile Methods. The bottom Line. (View in Weblogs)
Posted: Oct 11, 2003 1:36 PM
Reply to this message Reply
Summary
What are Agile Methods really all about? Is it some new humanistic view of software development? Is it a social revolution? Or is it just plain good business? This blog makes the case for the latter.
Advertisement
How do you run a business? I'm a CEO of a small consulting company so I have some small knowledge about what it takes to run a business. Aside from a cast-iron stomach, and the will to make tough decisions, it takes something else. It takes data.

We look at our sales data every week. We have monthly goals and we compare our monthly achievements to those goals. The difference goes straight to the bottom line (which happens to be our paychecks). In short, we run our business very iteratively because the bottom line is directly connected to our pocketbooks.

I think every business is run iteratively. Regularly keeping track of the sales, revenue, cash, and payables is a significant part of what every business must do to remain solvent. And when those numbers don't add up to the right sums, then tough management decisions have to be made. Sometimes this means cutting costs. Sometimes it means layoffs. Sometimes it means new sales incentives, or price reductions. Sometimes it means new product offerings. But one thing is certain, you cannot make those business decisions without data.

Compare that to how most software projects are run. They begin with a date. Let's not kid ourselves, all projects start with a date -- probaly before they have requirements -- probably before they have a name. An endless stream of requirements follows. A project plan is put together, and then reformed and reformed until it meets the date. Then the project is launched, and from a management point of view it goes dark.

Managers ask "How's that project going?" The answer: "Pretty good." If you want a more detailed answer it will be something like this:

  • (10% in) "We're currently building data models. We're about 80% done with them.
  • (20% in) "We're currently building use-case models. We're about 80% done with them.
  • (40% in) "We're currently building class models. We're about 80% done with them.
  • (60% in) "We're currently building sequence design models. We're about 80% done with them.
  • (80% in) "We're implementing the necessary infrastructure and architecture components. Were about 80% done with that."
  • (90% in) "We're starting to implement the main features. They'll be a snap because we've got all the design and architecture built. We're going to make the deadline."
  • (110% in) "We're about 80% done with all the features."
  • (120% in) "We're about 80% done with all the features."
  • (130% in) "We're about 80% done with all the features."
  • Repeat until complete or cancelled.

I realize that this sounds flippant -- and it is -- but it also strikes too close to the truth for a vast number of projects. No real data comes out of the project, and so there is no way to make any management decisions. Projects that produce no data cannot be managed. Period.

By their very nature Agile projects produce data. That's the bottom line. Never mind all the hoo-ha about new social orders and egalitarian software departments. The reality of Agile methods like Extreme Programming (Especially Extreme Programming) is that they produce periodic reliable data about the progress of the project. They don't report progress on models. They don't report progress on infrastructure. They regularly report verifiable and accurate data on implemented features. In the case of Extreme programming these reports come at least twice per month.

Imagine you are the manager of a software project. On the wall you see two bar charts. The first shows the number of feature-points completed by the team in each of the last iterations. The second shows the number of feature-points remaining in the project, again for each of the last several iterations. See graphs here. Anyone, manager or otherwise, can look at these two charts and see the status of the project. You can look at that second chart and eyeball the slope to predict the end-date. If the end-date is later than the deadline, then Mr. Manager, you've got some managing to do.

Charts like these provide the data that allows a software project to be managed like a company. The data tells us when tough decisions need to be made. Perhaps we need to renegotiate the due date, or reduce scope, or add manpower. The decision may not be easy, you may need a cast-iron stomach to make it, but without the data it can't be made.

This data is produced as a matter of course in Agile Methods like Extreme Programming. What's more, the data is accurate. No feature can be said to be complete unless it passes the acceptance tests written by the business stakeholders (usually business analysts and QA). Agile methods start out producing data like this from the very beginning of the project, and don't stop until the project is over. In an Agile project there is no Analysis phase that cannot be measured, there is no Elaboration phase that cannot be measured, there is no design phase that cannot be measured, there is no infrastructure development that cannot be measured. Analysis, design, infrastructure, architecture etc, are all done in process while producing working features and reporting real progress.

The bottom line for agile methods is that they provide the data that makes managing software projects possible. They allow a software project to be managed like a business.


Girish

Posts: 1
Nickname: gutagi
Registered: Oct, 2003

Re: Agile Methods. The bottom Line. Posted: Oct 14, 2003 8:16 AM
Reply to this message Reply
In Agile methodologies, the project artifacts that are created during development, itself acts as markers or pointers for the project status. There is no need to create the graphs that you have mentioned to identify the project status. Since the teams meet on a daily basis (stand up meetings)to discuss on the issues that are adversely affecting the progress, there is no need for any extra data reporting to be done. Such graphs do not add any value to the project development itself and therefore need not be used.

Randy bielby

Posts: 3
Nickname: rbielby
Registered: Oct, 2003

Re: Agile Methods. The bottom Line. Posted: Oct 14, 2003 12:33 PM
Reply to this message Reply
Must be nice to work at a place with no managers. I think these artifacts are relevant, at least from a management perspective.

James Perry

Posts: 1
Nickname: jerkyboy
Registered: Oct, 2003

Re: Agile Methods. The bottom Line. Posted: Oct 15, 2003 6:01 AM
Reply to this message Reply
First, I have not read any books on Agile/Extreme Programming, so, clearly that's something I need to do.....but:

If you have a software project of some significance, it is conceivable that you will have weeks and/or months of design work. How is that measured by the 'QA' group? Maybe you can start code iterations on a sub-system, but, if there's any complexity to the system, how does Agile/Extreme deal with the reality of the need for design? I spend a large chunk of time cleaning up code-first, design second systems....it's not pretty.

In the past, I've skimmed some Agile/Extreme texts at BN/Borders...I don't recall coming across a clear answer to this....note,this post is not a 'dis' of this methodology, I just want hype/buzz removed, and real examples applied. Thanks.

Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: Agile Methods. The bottom Line. Posted: Oct 15, 2003 6:18 AM
Reply to this message Reply
this post

http://groups.yahoo.com/group/extremeprogramming/message/81084

has a good description of the fractal nature of design and feedback on the design in XP.

Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: Agile Methods. The bottom Line. Posted: Oct 15, 2003 8:20 AM
Reply to this message Reply
See also

http://groups.yahoo.com/group/extremeprogramming/message/81393

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Agile Methods. The bottom Line. Posted: Oct 15, 2003 3:39 PM
Reply to this message Reply
Interesting to see folk trying to apply manufacturing practice to software development once more. Tom Gilb has often said that his consulting career has been based on telling computer literate audiences about the Deming cycle:

Deliver something to a real end-user.
Measure the added-value to the user in all critical dimensions.
Adjust both design and objectives based on observed realities.

The sentiment should be familiar by now, although there are differences:

"we use the concept of selecting the potential steps with the highest user-value to development-cost ratio for earliest implementation. This is really like skimming the cream off the top of the milk."

And Gilb's concern for "clear and measurable multidimensional objectives... all functional, quality and resource objectives which are vital to the long-term and short-term survival of the system under development."

Tom Gilb, "Principles of Software Engineering Management" 1988.

Patrick D Logan

Posts: 3
Nickname: pdlogan
Registered: May, 2003

Re: Agile Methods. The bottom Line. Posted: Oct 15, 2003 10:40 PM
Reply to this message Reply
"Interesting to see folk trying to apply manufacturing practice to software development once more."

How is this applying manufacturing practice?

Jeremy Ferry

Posts: 4
Nickname: ferr0084
Registered: Nov, 2002

Re: Agile Methods. The bottom Line. Posted: Oct 16, 2003 9:26 AM
Reply to this message Reply
The ideas that Agile are built on originally came from a couple of little companys called Toyota and Honda. If you'll remember back in the 80's, Japanese car makers were producing very good cars very cheeply. The US car makers couldn't keep up, remember Chrysler's near demise? Well, the Japanese had adopted a new style of manufacturing that was dramatically more efficient, produced better quality cars, and gave them far more flexibility throughout the manufacturing process. It was called lean development. In the 90's, the US car makers adopted lean development ideas making them competitive in the market again.

Here is a summary of Lean principles (taken from Mary and Tom Poppendieck's book (http://www.poppendieck.com/ld.htm)Lean Software Development: An Agile Toolkit - a must read!):

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole

In their book, almost every point they make is illustrated by a real world example from project's they've worked on. There's far too much good info in this book for me to write about here but I can tell you that their message, as well as Uncle Bob's in his book Agile Software Development, have changed forever the way I approach software development. The arguments and experiences that they present are too compelling to ignore.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Agile Methods. The bottom Line. Posted: Oct 16, 2003 9:56 AM
Reply to this message Reply
Your project is probably funded by people who don't attend the standup meetings. These people would like to know if their money is being well spent. The charts are one way to provide them this information.

Team members who are working on iteration after iteration often lose track of the big picture. Standup meetings are a good way to communicate what's going on right now but don't suffice to communicate the longer term issues. Again, the charts are a way to keep this data in front of the whole team.

The data on the charts is the reason that Agile Methods make economic sense. They afford managers the ability to make decisions based upon real data.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Agile Methods. The bottom Line. Posted: Oct 16, 2003 11:34 AM
Reply to this message Reply
> If you have a software project of some significance, it is
> conceivable that you will have weeks and/or months of
> design work.

In an Agile project we spread that design work out over the entire length of the project. Each design conjecture is tested by implementing it as soon as possible. Design decisions are delayed as long as possible.

This may seem to fly in the face of conventional wisdom; but results have nevertheless been very good. We do not seem to wind up with spaghetti code or rickety architectures. This is probably because the testing and refactoring disciplines in Agile projects are much greater than in non-Agile projects.

> How is that measured by the 'QA' group?

A story (feature) must satisfy the following criteria:
1. It must be estimatable (in points)
2. It must have business value that the stakeholders will recognize.
3. That business value must be prioritizable in relation to the other stories.
4. It must be testable. QA must be able to write an automated test for it.

Clearly subsystems and designs don't qualify. Subsystems, designs, and architecture must be derived by the team as they build the system one feature at a time.

> Maybe you can start code iterations on a sub-system, but,
> if there's any complexity to the system, how does
> Agile/Extreme deal with the reality of the need for
> design? I spend a large chunk of time cleaning up
> code-first, design second systems....it's not pretty.

I have also spent a large chunk of time cleaning up code-first systems. Agile projects are not code-first. They are also not design-first. They are Test-first, with design and code being concurrent, and design and architecture evolving to meet the needs.

Agile project do not work on subsystems one at a time. Every feature involves many, if not all, subsystems. Developers working on a feature touch all the subsystems and evolve their designs.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Agile Methods. The bottom Line. Posted: Oct 16, 2003 2:48 PM
Reply to this message Reply
The ideas that Agile are built on originally came from...

Well, some of the ideas are-similar-to ideas that influenced the Kanban and Just-In-Time manufacturing (and Total Quality) movements of the 70s and 80s.

Those influential ideas were based on the Deming Cycle (aka Shewart Cycle):
http://www.netfact.com/nemgrab/mqc/news/otm/march_96/toolbox.html

So the manufacturing practice I was thinking about was continuous process improvement (Deming Cycle) applied as continuous software improvement (evolutionary software development - Tom Gilb).

There seems to be a risk that folk might get to wrapped-up trying to apply manufacturing analogies (should we really try to find a meaning for manufacturings obsession with inventory control mean in software development?) and forget the Deming Cycle.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Agile Methods. The bottom Line. Posted: Oct 17, 2003 7:30 AM
Reply to this message Reply
> There seems to be a risk that folk might get to wrapped-up
> trying to apply manufacturing analogies (should we really
> try to find a meaning for manufacturings obsession with
> inventory control mean in software development?) and
> forget the Deming Cycle.

I think it all maps, but the relative importance of things may be different. Inventory, for instance, maps to requirements. If you elaborate requirements far faster than they can be implemented, well, you really aren't making things faster and there is a good chance that they could go stale... not be the right thing to implement when you get around to it.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Agile Methods. The bottom Line. Posted: Oct 17, 2003 9:15 AM
Reply to this message Reply
There seems to be a risk that folk might get to wrapped-up trying to apply manufacturing analogies (should we really try to find a meaning for manufacturings obsession with inventory control mean in software development?) and forget the Deming Cycle.

> I think it all maps, but the relative importance of things
> may be different. Inventory, for instance, maps to
> requirements.

Looks like a good example of taking something concrete and tangible from one situation and bending it to fit in another quite different situation.

The important point is that in manufacturing there was a more abstract goal which actually is transferable to other situations: eliminate waste from every step in the process.
Inventory reduction was just one concrete instance of that overriding goal.

You've chosen to equate inventory to requirements:
- inventory ships as part of the product, do requirements?
- wouldn't software system requirements map to product requirements in manufacturing? (Things are manufactured to meet specified requirements...)

These are transferable:
- Deming/Shewart cycle
http://www.netfact.com/nemgrab/mqc/news/otm/march_96/toolbox.html
- Eliminate waste

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Agile Methods. The bottom Line. Posted: Oct 18, 2003 5:30 AM
Reply to this message Reply
> There seems to be a risk that folk might get to
> wrapped-up trying to apply manufacturing analogies (should
> we really try to find a meaning for manufacturings
> obsession with inventory control mean in software
> development?) and forget the Deming Cycle.

>
> > I think it all maps, but the relative importance of
> things
> > may be different. Inventory, for instance, maps to
> > requirements.
>
> Looks like a good example of taking something concrete and
> tangible from one situation and bending it to fit in
> another quite different situation.
>
> The important point is that in manufacturing there was a
> more abstract goal which actually is transferable to other
> situations: eliminate waste from every step in the
> process.
> Inventory reduction was just one concrete instance of that
> overriding goal.
>
> You've chosen to equate inventory to requirements:
> - inventory ships as part of the product, do
> requirements?
> - wouldn't software system requirements map to product
> requirements in manufacturing? (Things are manufactured to
> meet specified requirements...)

It's just a metaphor. Using it doesn't imply the two things are alike in all respects, it means that there is some insight that can get by viewing requirements that way. Namely, that requirements have shelf life and cost.

There's also the more subtle issue that when you stockpile requirements and revisit them often, you can end up with different versions of the same requirement (what the team talked about last month and what they talked about last week, for instance) and that can be just as confusing and error prone as having subtly different material on a manufacturing floor.

Just a metaphor. You can tell me how requirements aren't inventory, and be right, without diminishing the value of the metaphor.

Flat View: This topic has 17 replies on 2 pages [ 1  2 | » ]
Topic: Agile Methods.  The bottom Line. Previous Topic   Next Topic Topic: How Much Concurrency Should be Exposed in a UI Toolkit?

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use