+972 52-548-6969
That Agile Thing
Agile introduction is an interesting problem. One that I have learned to avoid. I am not feeling comfortable standing up to a business owner and saying (paraphrased, of course), "if you will do it my way, your life will be better". At least, not about development methodologies, I have no problem saying that about techniques, design or tools. The reason that I don't feel comfortable saying that is that there are too many issues surrounding agile introduction to talk confidently about the benefits.
I usually never mention agile to the customer at all. What I am doing, however, is insisting on a regularly scheduled demo. Usually every week or two. Oh, and I ask the customer what they want to see in the next demo. Given that I have a very short amount of time between demos, I can usually get a very concise set of features for the next demo.
Having demos every week or two really strengthen the confidence in the project. So from the point of view of the customer, we have regular demos and they get to choose what they will see in the next demo, that is all.
From the point of view of the team, having to have a demo every week or two makes a lot of difference in the way we have to work. As a simple example, I can't demo a UML diagram, so we can't have a six months design phase. Having to accept new requirements for each demo means that we need to enable ourselves to make changes very rapidly, so we go to practices such as TDD, Continuous Integration, etc. It also means that the design of the application tends to be much more light weight than it would be otherwise.
In other words, everything flows from the single initial requirement, having a demo every week or two.
Once you have that, you have a free reign (more or less) to implement agile practices, as they are needed, in order to get the demo up and running. You get customer involvement from the feature selection for the next demo, and you get customer buy-in from having the demos at frequent intervals, always showing additional value.
Comments
So how do you handle charging the customer when you don't discuss with them (up front) that you are going to be running the project in this way? Usually they want to know before the project starts how much it'll cost and what they'll be getting for that money.
One often has to convince clients of the benefits of the agile approach before they'll come round to a different way of thinking.
Great post. The problem is that Agile is nebulous and means very different things to different people. Here is an article I wrote recently about the lack of clarity behind Agile development.
grahamnash.blogspot.com/.../...-lean-feedback.html
I agree fully that the idea of regular demos of working software, with the customer choosing priorities for the next demo, is the core driver for anything you can call agile. All the other practices (CI, TDD, SoC, etc) all simply help to achieve this.
I actually don't think that these practices are what make a project agile (is that heresy?). If a project is not regularly demo'ing functional software with customer-driven priorities, then I can't see that it can call itself agile, even if it has CC.Net+Svn+xUnit+whatever.
What is the customer buying? The program or the code? If former, than he shouldn't really care weather you do it agile or put all the code in main method, as long as you deliver.
grega g
to grega: well that's true but realize that once your project gets more complex than saying hello world, tools like unit tests or good decoupled design helps you to to deliver new changes faster and safer.
Yea, I know.
I was saying that as long as client doesn't see the code, he doesn't need to be explained about agile. Just use it.
grega g
Hi, this is a smart strategy to get an agile process up and running. You seem to have gotten the reason behind agile: deliver early, deliver often, get early feedback, react to changes in requirements.
I only wish I could do the same at the place I work, but unfortunately, I have a large system that is used by a trading desk, front office, back office, plus has integration with upstream and downstream systems. 1 week iterations are simply too short. Plus, we don't have 1 'customer', we have several stakeholders at our customer all with their own ideas of what is higher priority....
Do two weeks demos, if one is too short.
Get someone that has the final say in the matter. There has to be someone like that, even if they are just there to settle disputes.
to Domingos: is it possible to split your system into several parts with well defined interfaces so that you can deliver these components independently?
This is brilliant. It allows you to implement the heart of Agile by selling the direct customer-perceived benefits. If the customer is interested in more detail, they'll ask. Until then, they reap the benefits and you can pick your battles more carefully on ancillary issues as needed--giving you a free hand and ability to implement whatever methodologies you deem most appropriate.
@Neil Mosafi
I have been doing the indepedent contractor thing for 14 years and this is exactly how I work. I usually cut it even shorter. I ask for the next feature and upload daily builds. Whether they have time to review the builds or not is up to them.
Once a business starts working with a contractor this way they get spoiled and forget about the $$$ and start focusing on the value the software is delivering because they feel in control of the process for once.
It's a win / win because the business gets great software and the contractor feels great about what he has written - and most importantly, you get a repeat customer.
The best thing about repear customers is - you dont have to train them a second time. They know you you work and it's they love it.
This got me thinking about Kanban, where there is no such thing as iterations, but it's still Agile. How would you feel about using this approach instead of iterations?
Comment preview