Looks like this October i’ll be making my way east out to Winnipeg where I have the opportunity to present two sessions at the Software Developer and Evolution Conference. I’m very excited as not only will this be my second conference of the year that i’m presenting at, it’s also going to be my first time in Winnipeg. If you know of any fun family things to check out in Winnipeg please leave a comment!
My first session is about self organizing teams, participating on and leading. There’s a lot of things to think about when it comes to creating and fostering self organizing teams. I plan to talk about some of them from the perspective of a manager and leader, as well as a team member on the team. I’m also coming up with a good exercise that I hope will be fun and help illustrate my points.
The second session will be on iterative development. I did this session at the Prairie Developer Conference in Regina, and i’ve used the feedback I received from the attendees there to refine the presentation to hopefully be even better, and i’m also incorporating an exercise in to this one as well.
I’ll probably be making more posts on those two topics in the coming weeks, so check back for more.
When we’re building software, we often have a desire to deliver something that will blow people away. It makes sense right? Why would we want to deliver something that isn’t impressive, doesn’t work all that well, doesn’t look really pretty etc.
Well, it just so happens that there’s a good reason you’d want to do that, because it still delivers value, even in it’s often simple and unrefined form.
Consider this scenario, a client comes to you and asks you to build them a chair for their office. They want it to roll around, comfortable, adjustable height, nice arm rests etc, and they want it as quickly as possible because they don’t have a chair at all now.
Using the typical mentality of not delivering anything until you think it will blow people away, you go away and over the course of a month you build a fabulous office chair. You showed some pictures of it along the way to the client and they were pleased with the design, however they really wished they could have been sitting down at their desk while they looked at your designs…
The concept of fidelity is simply to deliver the simplest thing that provides value as soon as possible, and the move on to refine it. Using the chair example, the client wants a fancy chair, but the client also currently has NO chair, so obviously just having anything to sit on provides SOME value. Thinking in this way, the lowest fidelity solution that will deliver some value to the client might look something like this:
The client will obviously not be satisfied with a milk crate as the final product but it isn’t the final product, it’s the first iteration of the final solution. You would tell the client something along the lines of “here’s what we came up with in the first day, turn this upside down and it will allow you to sit at your desk, we’ll be back in a few days with an improved version for you. A couple days later you return with:
You tell the client that it’s a little more comfortable than the last delivery, and looks better as well. You will further refine the chair and be back in another week. After a week you come back in with:
The client takes a look at what you’ve delivered, sits in it, the padded chair is comfortable, it looks stylish, and they tell you this is my chair, this is what i want, don’t make any more changes.
So, what are the main differences here? The client ended up with an end product they were happy with in both cases right? The second method had a couple key benefits though. First of all, the client had results in hand and was able to use them (start sitting down) the next day, instead of having to wait for a month. Also because the team was delivering improvements regularly the client had many opportunities to suggest how they would like things changed. Finally, the client has the opportunity to stop the development of the product early for any reason and still be left with a usable product! So whether it turns out that the client is happy with less than they originally asked like in my example, or if the client just ran out of money and had to stop early, they are always left with something usable.
You could make the argument that this is just iterative development, and technically you are correct, however it’s important to remember the fidelity aspect which is that each iteration should provide a usable product that provides value. Consider another way to iteratively deliver a chair to the customer. In the first iteration you deliver fully refined wheels, in the second you deliver the adjustable chair post, in the third you deliver nice leather wrapped arm wrests, in the fourth a nice padded leather seat, in the fifth a nice leather chair back, and in the sixth you put it all together. That’s iterative right? You produced and delivered a piece of the product in each iteration and showed it to the client. The problem is that you weren’t delivering any value with each iteration. The customer doesn’t realize any value until the last iteration when you put it all together, which means if the project had to be stopped early, the client is left with nothing useful. Even worse, the customer can’t see how everything is going to work together until you put it all together for them, so they don’t have much ability to give feedback on your work.
Always deliver in iterations that provide value to the client, so they are left with something useful that provides value no matter how deep in to the project you are.
by: Chris Dagenais
Iterative development is a pretty basic concept. You just develop iteratively… Hmm pretty sure i read once that you shouldn’t use the word you’re defining in the definition. Lets try again.
Iterative development is the practice of developing software in small defined chunks of time. This is in contrast with the old-school method of starting a project and working on it over the course of months or years in one long chunk, or iteration.
Lets just dig in to the meat of why it’s important. Imagine you wanted to get a house built. You line up a contractor who has experience building houses. You tell him you want a 1200sq ft house with lots of windows and a double garage. He asks you what layout you want, where should the windows be, do you want a deck, what colors for the interior and exterior etc. You answer him by saying “I don’t know, I hired you because you’re good at building houses, so you just make sure it’s 1200sq ft and has lots of windows”. Can you see where this is going?
Six months later he calls you and says the house is done. You walk in and while the house is impressive, it’s not how you had envisioned it, and with the amount you are paying him, you want it to look how you want. Unfortunately now that all the work is already done, it will cost a LOT more to make changes.
Software is the same way, if somebody comes and says to you “I want a system that does X” but they don’t have any details as to how it should look or work, it would be foolhardy to believe that they are going to just be happy with whatever you deliver to them.
Iterative development helps with this by allowing you to break up the project in to small iterations, the smaller the better, ideally 1 or 2 weeks. This way you can show what you have accomplished during each iteration to the customer and see what they think, and get their feedback on what they would like changed. Even if they customer had no idea what they wanted ahead of time, you can bet that they will after they see what you have built. The sooner you get that feedback from them, the cheaper it will be to ensure the project turns out how they want.
One of the other big advantages of dividing work up in to short iterations is that it’s a lot easier to estimate what you can get done in 2 weeks than in 2 months. Once you have the project divided up in those iterations it also becomes a lot easier to see if you’re falling behind or not as well.
That should give you a basic idea of some of the advantage iterative development provides. I’ll go in to more detail in future posts of some of the other advantages.
by: Chris Dagenais