Log in

No account? Create an account
Previous Entry Share Next Entry
What does "Agile Development" mean to you?
[Not strictly aimed at programmers, this time -- I'm interested in hearing from anyone in the software field who has an opinion.]

I was in an interesting discussion on one of the Scala mailing lists last week, and we wound up off on a tangent about "Agile". My correspondent described how he strongly dislikes Agile, and why -- and the interesting thing to me was that his definition of Agile not only didn't match mine, it was in some ways directly *contradictory* to mine.

I've been starting to realize that, 15 years into the process-management revolution in software, the term "Agile" has become ever-squishier. This hasn't been helped by management consultants who sometimes spout complete nonsense, or more often take a specific dialect of the idea and say "This is what Agile means".

So here's a quick question, aimed at my many techie friends: what does the word "Agile", in the context of software development, connote to you? What are the two or three *most important* aspects of it? I'm not looking for answer just from the experts here -- I'm at least as interested in the viewpoints from the people who have only been reading about it in the trade press or blogs, and what impressions you have gotten. And I'm curious whether the viewpoints and priorities differ between, eg, the programmers and the project managers.

(I have strong opinions about this myself, of course -- I've been an active proponent of some of these ideas from almost the beginning. But I'd rather hear your viewpoints first, before I spout off...)

  • 1
On the positive side:
- nobody stops me when I write unittests;
- waterfall is frowned upon (can refactor);
- frequent releases instead of bla-bla-bla and void hopes.

On the negative side:
- idiots telling me I have to finish every thing in two weeks;
- a sequence of sprints turns into a marathon;
- nobody cares about anything a month ahead (that's a remote future);
- morning standup comedy

What does Agile development mean to me?

That some managers heard of this new-fangled development methodology that eliminates the Man-Month issue, causes all programs to be bug free, and makes the crappiest code seem innovative, and decided to force it onto development without changing how management interacts with development or modifies management expectations.


I'm a little bitter, I admit. One place I worked had to reserve a room for an hour for the '5 minute stand up meetings' each morning. Another had no scheduling made for unit tests nor a unit test framework. Almost everywhere rapid prototyping and iterative development got thrown out the window. Code reviews end up being brief glances from another developer, rather than actual line by line analysis. Old code never got eliminated, it just stuck around to rot and cause bugs.

There are some really interesting ideas in 'agile' development, and while I imagine some places can manage to keep to the general format, it falls flat way too often.

When someone says they work in an Agile environment, the next question has to be what they mean by that. Team programming, mandatory code reviews, short development cycles, appropriate goals for short development cycles, strict coding standards, test driven development, daily scrums, rapid prototyping, pessimistic budgeting, priority and feature bingo, Loosely coupled interfaces, etc. There are too many toggles for 'agile' to mean anything on its face.

What agile means to me: A series of small, well defined and testable tasks, aimed at producing a final product with regular reviews by a core team that includes the designers/coders and end users. Essentially the spiral model with time taken to test and alter requirements after each step with an integrated Customer and IT team performing the review.

What I actually experience in my day to day life: There are no resources in IT for testing, there are no plans to ever engineering test before release, even to see if basic functionality is broken going out the gate. Oh and the code is outsources to a team the customer cannot talk to, sometimes literally they don't speak the same language... There is no standard bug tracking too other than individual excel spread sheets. Testing, that is solely the customer's responsibility. IT will demand all sorts of sign offs to each one of their release gates and it is the customer's fault if we slip dates and miss one. The customer should have assigned more testers to find all of the bugs in time. Note the customer has a full five business days for the acceptance test... OK, usually four... In any case unless the customer strenuously complains, IT will just release a broken program and fix bugs in the production environment. After all no software is "bug free".

I would be ecstatic to reach "bad" agile practices...

Having never done "Agile", and only dealing with it from other teams that claim they do, these are the things that I have taken away from agile development:

1. No long term projects. All work must be done in a sprint, and longer projects must be splittable into deliverables that are sprint sized.
2. Daily (short) standup meetings.

Beyond that, I've never understood anything about agile being different; the teams we work with claim to be agile, but they do pretty much the same things our (non-agile) team does...

(Deleted comment)
My experience:

1. We're generally decently good at, except then they started making full specs for larger projects that got in the way of this.

2. Um, sort of.

3. Usually. Although you end up with scrums getting extended, or sequences of scrums, when things aren't going as planned.

4. We used various peices of shitsoftware. It did mostly work for burndowns, although it was irritating to use-the problem was frequently that programmers didn't update the software, instead too much of the standup was the PMs updating the burndown based on what developers said.

5. See 4. The chart did actually work, since it was autogenerated from the software.

6. This is -frequently- a problem, in my experience. Unit tests get abandoned, ignored, break, and then there's much less incentive to write new ones. Plus, unit tests for top-level processes are hard (also, arguably less necessary) and unit tests for db code assumes a framework and starting state that often isn't there and never gets written.

7. We did this a few times. Other times...not so much.

I'm mostly staying out of the discussion today, but one specific note:

4. A good way to track progress on a story. I have yet to see this.

I spent an *enormous* amount of effort at Memento, a few years back, coming up with a comprehensive list of Agile-development tools. It eventually transpired that supporting Team Foundation Server was a requirement, and we settled on Urban Turtle. Never regretted it -- it was a very good tool, and continually improving while we were using it. (I pushed us into it while it was still in Beta, and we used it for a couple of years.) It's only good for TFS, but it does solve many of TFS' worst warts.

(And there are other standalone options -- for example, while I didn't use it in practice, I rather liked the look of ScrumNinja.)

That said, you can only do fine-grained story tracking if you have adequately fine-grained Tasks -- if you do, keeping track of them is nicely easy. And you only get good Tasks iff the developers are sufficiently invested in the process. So as always for Agile processes, culture has to come first...

I'm going to crib off what votexofchaos said:

I was brought into an "agile" project after having been through many "six sigma lean" projects. This is what I was promised:

1. Stories that define the development, with specific tests to verify success/completion.
2. A well maintained priority list of this sprint's stories and beyond, that get reprioritized after each retrospective.
3. Short scrums.
4. A good way to track progress on a story.
5. A burn down chart that shows progress overall.
6. Unit tests that I can use to verify that my code works, and that I haven't broken anything.
7. A real retrospective, that talks about process improvements.

What I got was
1, hey, can you write down everything everyone does in their job functions as "user stories", but I've never done their jobs? that doesn't matter! you can just muddle through and see if you can figure out their workflow from how the system should work!
2, Your priority today is X, no, wait, Y, no wait, Do both of them as fast as you can as we are behind on Q (which I had never heard of)
3, Our Scrum meetings were on the phone and lasted upwards of 2 hours. A complete waste of time for most of us, as we just had quick updates to talk about, but there were always people who wanted to talk in detail about every little thing they found....... I was surprised when I told one of my friends about our scrum meetings that they were supposed to be 5 minutes, standing up.
4, Our progress charts generally got left for last to update, so generally we'd go in and highlight everything green in one big spree
5, see 2, and 4, this generally was very badly managed.
6, I wrote the testing protocols and ran them, my theory was use the scientific method to divine what had been build and how it worked, in doing so I found some seriously giant problems in the code and actually got the entire 3 year project scrapped because it was evident from my methodical testing that the updates (which were on top of bad, rotting code) would not in fact work.
7, This was by far the best part. I got to sit in on a meeting with the high ups and share how I felt the whole thing had gone. I'm still shocked no one was fired, including me.

The most important idea in Agile is that a project doesn't have a fixed "do or die" set of features and timeline.

Instead, you might set an initial idea of what the features and timeline are -- but you meet periodically, discuss where things are, and -adjust- the features and timeline to match what the user wants. Unlike earlier models, where it's someone's fault (or results in unsustainable work models that result in junk work as a result) when timelines get pushed out, etc, and you're generally only making that decision at the last possible moment, you're doing a constant cross-check of what's needed vs what you've done so far.

Now, that said, "agile" development far too often ends up in the hands of project managers who take the excuse to turn it into a constant cycle of useless, draining meetings that don't actually help any of the above. But that kind of agile comes with scare quotes.

(Deleted comment)
(Deleted comment)
It connotes the ability to handle sudden / frequent change gracefully / without breaking.

The change may be "change to the requirements", "change in the architecture", "change in who we're building this for", or maybe even "change in who's on the team", depending on what you care about.

"Gracefully / without breaking" is imprecise, but I can't think of a better phrase offhand. It refers not just to code, but to architecture, organization/process, and perhaps people. (Handling sudden / frequent change by burning out your coders is bad.)

"Gracefully / without breaking" does *not* mean "without cost"; you can never get the cost of change to zero. Minimizing cost-of-change / risk-of-change tends to be a strong objective - though that, itself, comes with costs.

Most everything else I associate with Agile are various means towards this end, which may work well or poorly depending on what other habits you pair them with, the environment in which they're used, etc.

I've never worked in a place which claimed to use Agile development. There was discussion of it at my last job, but while we borrowed a few notions from various Agile methodologies (eg: More Unit Tests, more frequent but shorter status meetings that my boss called Scrums), we never really went whole-hog. I think we'd have had real trouble with it, based on past difficulties getting time from stakeholders to even briefly look at what was being built for them, and upper management's desire to run Engineering at 100% utilization all the time (meaning no spare capacity for high-priority requests, leading to huge amounts of context-switching and large back-burnered task stacks).

Caveat: I work in IS, but I don't work in a software development company. I'm in the process of becoming an "Agile coach", and we have adapted some of the Agile concepts (so we aren't "pure Agile"). I may have to get back to you on this, but quick observations from seeing the transformation here:

The biggest difference I have seen so far is that the engagement of the "business customer" and how the team takes more ownership over what gets produced. In the past, IS has been regarded as a "service": Here's my list of requirements (wants), a budget, and a date. Get back to me when you are done. Using Agile, everyone on the team is engaged during the project and we get a more satisfactory result--even if the initial concept wasn't fully implemented, what does get produced is higher quality and the "business customer" is more satisfied. You don't need Agile to do this, but Agile provides a convenient way to force the behavioral shift.

Agile seems to require a lot more discipline, and there is more pressure--but when everyone is pulling in the same direction, that pressure is a lot easier to bear than being castigated for not producing what the customer "wanted".

Additional points:
- Traditionally, automated testing falls by the wayside because it doesn't benefit the immediate project (due to time & budget crunches when the project inevitably falls behind schedule). You get immediate benefits investing in automated testing with each sprint.
- You have to have the right people in the team and available at the right time for it to be effective. But that is true for any project! We've spent a lot of effort making sure we have that right mix.
- Outsourced development teams are a huge challenge--especially with offshore resources. Having at least one person from the development organization physically present with the Agile team who can take the lead coordinating those offshore resources reduces the challenge.
- Agile "resistors" can drag the team down. We spend a lot of time trying to educate them. Unfortunately, they are often the "brightest" people who get overly invested in their ideas or vision being "right" and have a hard time admitting they might be mistaken or failed to consider everything. That is more of a personality issue than a project methodology issue.
- If you have outsourced your infrastructure, contracts/agreements may need to be re-written in order to deliver environments in a timely fashion. This has proven to be a major obstacle to our some of our Agile projects and has required a lot of high-level intervention to resolve on a project-by-project basis.
- if you don't already have your business processes mapped out, you will end up with a lot of churn trying to discover them. Agile does not fix this problem!

  • 1