How We Learn
I am not sure why it is so hard for Software Professionals and Project Managers to understand iterative development, and iterative software solution implementation.
If you mention the name RUP or USDP then everyone agreeably nods that they have heard of it, tried it, has its own version of it, or is certified in it. Somehow though, they still think iterations is something you do after the project has gone live. It is something you use if you have to dig yourself out of a defect hole. Frankly, some software project managers think it is something a customer has after a suspect curry!
Now, admit-tingly not everyone knows their Grady from their Booch, and with new flavors called “You Ain't Gonna Need It” (YAGNI), “Worse is better” (New Jersey Style), “Dynamic Systems Development Method” (DSDM), and what else, one doesn’t always know you “KISS” from your “Quick-and-dirty”. Throw in ITIL, MOF and PMBOK, and everybody is running for cover!
In this blog, I consider what I believe to be the fundamental ingredient in each of these iterative approaches to IT solutions delivery - “learning”. I make the case that we need more of it, but we need to consciously plan it into our budgets, and into our IT Professional day.
Getting IT Right The First Time
Every IT solution is unique in some way. Every client has unique and particular requirements for their business. Every project is made up of different people with different skills and capabilities. Amongst all this diversity, we are trying to build quality solutions, as per requirements, at the most affordable rate.
In my career to date I have implemented a fair share of solutions. I admit, almost all of them have been software solutions in the online space. Never in fifteen years have I been part of a team with a designer or IT software architect that could get the design of a solution right the first time. Yes, I have worked with some outstanding brilliance. The people’s competence was not the problem.
There are many reasons for this phenomenon. All these reasons have one common denominator - learning. Client learning and the learning of the implementation team and its members. If it was not the client learning what their real need is versus their initial perceived need, then it was the software that had to be learned by the technical people. If it was not the software that had to be learned it was the process for implementation that had to be worked out. And so, every time the design, development and implementation of a solution has gone through a number of cycles or iterations, before it finally saw the light, and the customer was happy with the result.
If you read the above, you will probably agree with me that this is all fairly reasonable and simple. It is not out of the ordinary that good things take time, and sometimes you need to try a few times before you get it right.
When you learned to walk, you fell a few times before you got your balance finally sorted. When you first tried to catch a ball, you missed it a few times before you got the hang of it. I can elaborate on many skills we acquired over time, that necessitated us to learn and work out how best to do or conduct ourselves.
Why then, when we plan and cost IT solution implementations do we think we are going to get it right first time? I can hear you say: “The way we manage our risk is that we build in contingency reserves. We know we will have to rework some of the deliverables.” This is valid, however, reworking some deliverables is different from iterating it until it reaches an acceptable state or maturity for deployment and beyond.
I see many solution project plans daily pass over my desk with all the right terminology except the one called: ‘Learning Iteration 1, Learning Iteration 2, etc.”. I guess customers are just not too keen to know that they are going to pay for mistakes, rework, failures, errors, blunders and bloopers. Yet, it is these exact matters that are called experience, and that customers are quite prepared to pay for under this different banner! Every customer wants to be sure they have the most experienced team - this way they can minimize their rework and ultimately their cost.
Iteration Equals Learning
This argument is taking a scary turn if one equates iterative methods of delivery only as a way to allow for learning from one’s mistakes.
The methodology gurus will tell you there are much more value to be found from this approach. Granted, iteration allows the project deliverables to be successively refined. It is a way to address a project's highest risk items as the highest priority task. It is a great way to allow greater customer feedback, and it helps developer implementers to remain focused on the end result. Yet, in the end, it is a great way to leave room for learning.
So how do you do iterative delivery? You are welcome to go for all the books and the web sites dedicated to the subject. If you want a short and practical version in thirty seconds flat, then consider the following ten steps:
Step 1: Be very clear on the problem you want to solve, and why you want to solve it.
Step 2: Consider all the possible causes, and select to eliminate the one cause that may be the largest contributer keeping you from your goal.
Step 3: Consider all possible solutions. Select the one that will give you the greatest benefit in eliminating the one cause considered to be the greatest contributer to your problem.
Step 4: Be prepared for the fact that your first attempts to solve the problem, and your initial solutions, may not give you the desired result.
Step 5: Nevertheless, have a go at implementing your solution (Iteration 1)!
Step 6: Once you had a go, record your outcomes, and observe the elements that took you closer to your objective.
Step 7: Adjust your solution to eliminate defects, and have another go (Iteration 2).
Step 8: Observe your results, and make adjustments to your solution.
Step 9: Have another go and include some more features, while eliminating a few more defects (Iteration 3) and observe your results.
Step 10: By now you should be close to getting your solution right and achieving your objective of eliminating your problem. But wait! Check back at Step 1 and 2. Are you still meeting your objective of addressing your problem by eliminating the cause? If you are, refine your solution further if needed, else start again with Step 2. If your problem has materially changed, then start at Step 1 and repeat the whole process again.
And there you have an iterative approach to a solution deployment! Not so difficult is it? Fact is, it comes naturally to each of us. It is the way we solve our problems every day, instinctively and through perseverance adjusting our approach until we reach our objectives.
How Do Clients Feel
Granted, clients are not always open to the idea that you are going to have a few tries to solve their problems. But hey, if they could do it themselves they probably would have done so already. Chances are, they will probably have to give it a few tries themselves. And you know, anyone else selling the probability that they will solve the clients problem completely and get it right first time, is really gambling on the clients money and testing their good-will!
Oh yes, there is one more benefit in doing things iteratively. Your client can see results soon in the process, and he can stop spending when the problem is sufficiently solved (which does not necessarily mean it is completely solved).
Because you know, tomorrow it will be a new problem, caused by a new issue, and it will all start again. Only this time, you have some experience on your side that should allow you to get to the end goal of problem solving by using a few less iterations. Now you are a Professional (with experience)!
Have fun iterating. Please share your ideas with us on how to make this even simpler and more useful to fellow IT Professionals. To those that are struggling with something that IS inborn: Try, and then try again, until you get it right.
Hendrik van Wyk
No comments:
Post a Comment