agile

One of the biggest problems in software performance today occurs when the people who write software are different from the people who are required to solve the performance problems that their software causes. It works like this:

1. Architects design a system and pass the specification off to the developers.
2. The developers implement the specs the architects gave them, while the architects move on to design another system.
3. When the developers are “done” with their phase, they pass the code off to the production operations team. The operators run the system the developers gave them, while the developers move on to write another system.

The process is an assembly line for software: architects specialize in architecture, developers specialize in development, and operators specialize in operating. It sounds like the principle of industrial efficiency taken to its logical conclusion in the software world.

In my previous post I asked the question “why doesn’t Agile work?”. I’m not sure the nuance of the question came over correctly.

I’d just like to highlight that the question I asked was “Why does agile not work”. It was not “Why is Agile rubbish“. I’ve said a few times in the past couple of weeks that I like the ideology of Agile and I am (and have been for years and years) a strong proponent of prototyping, cyclic development, test driven design and many other things that are part of the Agile or XP methodologies.

That distinction in the title is a really important distinction and one I’d hoped I’d made clear in my post. Looking back at my post though, I think it is clear I failed . I highlighted reasons why I think Agile does not work and in my head I was thinking “if we avoid these, Agile could work” – but when you write something down it does not matter what is in your head if it does not reach the paper.

I’m actually frustrated that in the last few years I have not seen Agile really succeed and also that this must be the normal situation, going on the response you get when the topic of Agile comes up with fellow technicians and comments on my own blog.

However, on that post about Agile two people who’s opinion I deeply respect came back at me to say “Agile does work!”. Cary Millsap, who many of you will have heard of as the “Method R” guy and the person behind Oracle Flexible Architecture. And Mike Cox, who most of you won’t have heard of but Mike taught me a lot about sensible development back in the 90′s. He’s one of the best developers I have ever had the pleasure of working with and I know he has had great success with Agile and RED. I’m not sure if they read my post as “Agile is Rubbish” or they are, like me, simply frustrated that it can work but so often does not.

So I’ve been thinking about this a lot this weekend and I was helped by Cary’s paper on the topic that he mentioned in his comment. I’d highly recommend downloading it as it is an excellent description of not only why Agile can help but describes how and some of the pitfalls {I’d started my own post on that, but go read Cary’s}. I should add, you can see Cary present his case for Agile at the UKOUG conference this year.

So where does this bring me to? Well, I think “Is Agile good or bad” has become almost an “IT religion” topic, people love it or loath it and it is based on what they have seen of the methodology in real life. No, that’s wrong, it is based on what they have seen that has been labelled with that methodology in real life. Or worse, it is based on anecdotal opinion of those around them. The thing is, if you look at what XP is supposed to consist of or what Agile Programming is supposed to consist of, most of us would agree that a great deal of it makes sense in many situations. I’d disagree with some of the details in Cary’s paper but overall I’m in strong agreement. Sadly, What Agile and XP is supposed to be is not well matched by what you see on the ground in most cases. So even if these methodologies are right for the situation, what has been implemented is not the methodology but probably more a slap-dash process that simply jettisons documentation, design and proper testing. This whole thread sprung from my lamenting the demise of database design and several of the comments highlighted that the introduction of Agile seemed to equate, at least in part, with the demise of design. As MIke and Cary say, and as I think anyone who has successfully utilized Agile would say, Design is an integral part of Agile and XP methodology.

Agile can and does work. But many things can and do work, such as taking regular exercise to keep healthy or regularly maintaining your house to keep it weathertight. Like Agile, both take effort but the overall benefit is greater than the cost. And like Agile, do it wrong and you can make things worse. If your window frames are starting to rot and you just slap a new layer of top-coat on them all you will do is seal in the damp and rot and hide the problem – until the glass falls out. Going for a regular 5 mile run is good for you – but not if you are 10 stone (60KG) overweight and have not run in years. A 5 mile run is also not a good idea if you want to be a long-jumper. Right training (methodology) for the right aim. Also, just like keeping healthy, house maintenance or anything that takes effort but works, proponents tend towards extremism – probably as a reaction to the constant {perceived} pig-headedness of critics or the failure of people to just do what now seems so sensible to them {think reformed smokers}. I’ll have to buy Cary and Mike pints to make up for that jibe now, and promise them it was not aimed at them personally…

Sadly, the reality is, Agile does not work 90% of the time it is tried. So, does that mean Agile is actually rubbish? Or at least, not fit for purpose, because many companies are not able to use it? Companies are there to achieve something and the IT systems are part of achieving that something. If Agile cannot aid that IT department then Agile is the wrong way for that department and company.

*sigh* I’ve gone on and on about this and still not got to my own main point, which is this.

- Can we identify reasons for Agile and XP Failing.
- Having identified the Reasons, can we fix them in simple ways?
- Can we create some simple guidelines as to when a project should be more Agile and when it should be more Up-Front design.

I’d love to know people’s opinions on those three points above.

Currently in Cary Millsap’s session about his agile approach on things called “My Case for Agile Methods“. Agile is (not yet) my thing, but knowing Cary, and he is in to it, when he is enthusiastic about something its probably one of those things which you should look into. If not even due to, as far as I know, the Agile context Cary is using is not the Agile context referred to I see being used out there. The “agile” thing out there is the one, is the one, I will joke about. But that said, a lot of methods are not bad at all, but people implement them wrongly so trying to keep an open mind, this session of Cary was more or less mandatory to get my vision about this back on track once more.

Cary also mentioned this emotion that probably mainly goes around in the DBA world. But as Cary mentioned during his presentation, “Agile is not undisciplined”, so if it gets the wrong emotional context, then is mainly due to people not doing it correctly. Could be thats it has to do with not being correctly trained in Agile or maybe incorrectly “managed”. So what is Cary’s feeling about this, that is, “Agile” as is…

Incremental Design… “Plans fail, bit there are ways to prevent a failed plan from failing your project…” so you can prevent this by continuously design, build and construct your project. The main key here is “continuously”. So for example, you don’t design your house and then leave the project, but should continuously design and iterate on your design as needed by a customer. This counts, is needed, for every stage, so the design, build and construct part.

Rapid Integration… “The worst software in the world? …90% complete, but nobody can run it yet…”. So if you want incremental design to be implemented quickly is really a step to support this continuous integration regarding bringing in all those improved, new, altered designs, build and construct tests

Test-First Programming… “Ever been afraid to improve your code?”. So how does test-first programming work?

1. Add a case
2. Add a test
3. Run all test (and check off all tests and see what fails or not…)
4. Write code
5. Run all tests (and make sure it now all succeeds)
6. Refactor

Pair Programming… Are you stuck? Not in the mood? Are you skipping steps? The fun part Cary here describing is that he is aware of how his office furniture is placed. It turned out that it is in such a way that its supports the buddy part where your buddy (wingman) can look at your code or comment on your code during your programming. Also your buddy can back you up when your stuck or tired. Of course its also more creative in the end due to the fact that you push each other in more creative and productive ways while doing your tasks, like programming.

Ten-Minute Build… This will mainly keep your energy up to create the best as you can do. You can’t continuously keep up the high level of concentration and if you can’t keep your pace your code level will deteriorate…

So keep in mind, if “Agile” looks stupid then most of the time its not the method that is “stupid”, but that it is implemented “stupid” by people. I indeed really believe that to make Agile work, that you need smart and disciplined people to make this work and a “customer” that continuously interacts with the team. Getting the hang of “it”, I indeed believe that most of the laughable stuff out there, is due to people, but then again, isn’t most IT/software/method out there based on what people do?. Its people, good people, that make it work, with a proper understanding of what the goals are you want to achieve…

I run into lately regarding a big project, if you are implementing very restrictive security rules in your development environment, then what is the “security goal” of doing this? If there is no balance into this kind of thinking, in the process, then its destructive to the overall goal. In such environment, probably, Agile methodology shouldn’t be applied in the first place. Think outside the box and give “Agile” a go, it might surprise you, but don’t underestimate the energy, flexibility, that is needed to implement it from each and every team member and the environment you work in.

There was more in Cary’s presentation, but have a look at Cary’s website, where most of this is way better explained anyway and a place to get into on topic discussions…

What’s the best way to make a presentation on Agile practices? Practice Agile practices.

You could write a presentation “big bang” style, delivering version 1.0 in front of your big audience of 200+ people at Kscope 2011 before anybody has seen it. Of course, if you do it that way, you build a lot of risk into your product. But what else can you do?

You can execute the Agile practices of releasing early and often, allowing the reception of your product to guide its design. Whenever you find an aspect of your product that doesn’t get the enthusiastic reception you had hoped for, you fix it for the next release.

While I was writing Brown Noise in Written Language, Part 2, twice I came across the word “agile.” First, the word “agility” was in the original sentence that I was criticizing. Joel Garry picked up on it and described it as “a code word for ‘sloppy programming.’” Second, if you read my final paragraph, you might have noticed that I used the term “waterfall” to describe one method for producing bad writing. Waterfall is a reliable method for producing bad computer software too, in my experience, and for exactly the same reason. Whenever I disparage “waterfall,” I’m usually thinking fondly of “agile,” which I consider to be “waterfall’s” opposite.

I did manage to publish a link to this blog post, 'Releasing early is not always good? Heresy!' at about 3:00 am on Jan 1st. The plan was that I'd close out 2009 by getting the last few posts related to Agile design off of my mind so I could start 2010 ready to return my focus to measurement. Fail.I woke up late that morning, drank my coffee and thought about problems in the design and

It's the day before the new year and I have two topics related to development that I am hoping to complete today to wrap up 2009. Then I plan to refocus this blog on its originally intended topic - measurement. I can't promise not to wander off topic again but I will do my best.A few weeks ago, Cary Millsap sent me a link to The Fable of the User-Centered Designer. It's short and an enjoyable

The past year has been well, many words come to mind but let's go with challenging. It's also been interesting, frustrating, enlightening, exhausting, but right about now, it feels like it was a very, very good year. Those of you that have read through the previous posts will remember that, right around the time I left for the Miracle Oracle Open World conference in October of 2008, I was

I think I've mentioned this somewhere on my blog before, but last year right before I left for the Miracle Oracle Open World conference, I found myself unexpectedly responsible for a new system. Up until that point, I was working in an 'advisory' role for the project - available to answer questions, offer guidance, etc. I had no authority to direct the work, it was just assumed that the other

If you're expecting something in favor Agile development, you're on the wrong blog. You'll notice that my 'agile' uses a little 'a' - I'm referring to the adjective agile, defined on answers.com as: 1. Characterized by quickness, lightness, and ease of movement; nimble. 2. Mentally quick or alert: an agile mind.or in the Merriam-Webster dictionary: 1 : marked by ready ability to move with