Introduction
In this article, we will go through the process of Iterative Development implementation and some of my experiences. If you are new to Iterative development this document can guide you to over the facts you will need during the process.
By the time you finish this article you will learn the following:
Good luck and have safe journey!
The concept behind Iterative Development
Releasing the entire project within the approved deadline often leads to a tense development environment. It is being observed in several occasions that the end product may not function to customer expectations due to the tight delivery schedule.
No matter what little time is being provided to the development team, the client will absolutely not accept any fault in the application.
Besides raising the arguments to increase the delivery date, the Project Manager must conceive his own plan to deliver within the approved date.
One of the tested approach is the Iterative Development using the agile development methodology. When using this approach we divide the complexity of entire project into small time blocks.
There are further two divisions:
- Divide all of the functions of the project into customer�s expected priority known as Client Driven Iterative Development.
- Divide the functions into Risk factor known as Risk-Driven Iterative Development
Choose any of the above techniques and issue the expected finish dates of completed functions. Provide your client a chance to view each deliverable and post his feedback. There are many open source Issue tracker or Bug tracker available in the market.
Expectedly the end product grows incrementally with new features, iteration by iteration. This approach minimizes the risk of project failure and maximizes the risk handling which obviously increases the success factor of the project.
How to divide contents in the iterations
I mentioned earlier that the iteration contents can be decided by using any one approach Risk-Driven or Client Driven. If you are unable to decide which is best for your project, then consider the following chart:
|
State |
Risk Driven |
Client Driven |
|
Client satisfaction |
LOW |
HIGH |
|
Team satisfaction |
HIGH |
LOW |
|
Client realization if deadline slips |
LOW |
HIGH |
|
Risk Management |
LOW |
HIGH |
Whatever approach you choose; always consider the iteration as a self-contained small project.
Client Driven
This is the most appreciated approach as the client will drive the progress and view the functionalities as develop. Client prioritizes the functions and the coordinator divides them accordingly into different time blocks.
There can be some dependencies among the functions, so be careful when you assign the functions into the iterations. Never totally depend on the client on division of iterations. The team must have a careful look into the division also.
Some clients do not want to involve in the process and want to see the entire product functioning at the end, try to avoid this as it may lead to an un-satisfactory ending. It is being observed that the most accepted projects are those in which client has a close interaction with the development team.
When client sees the progress iteratively and he realizes that the product is taking shape gradually, it gives him more confidence on the team. It also helps if your project deadline slips.
Risk Driven
In this approach the functions are being divided based on their risk factors, usually the most risk oriented functions are to be handled first. The team lead sits with the team and put down all of the functions on the table. They divide the functions into the time block and issue the release date of each iteration.
I believe that every thing which my team have not done before or don�t know how to do it is a risk. For a quick check, you may consider the following points as well.
- You do not have proper technical expertise of the function.
- You do not have resources, for example some hardware.
- Your team understands the function but not sure how to do it.
- Your team could not understand the function or the requirements are vague.
- Your client is unable to express his requirements and the more meetings are due, but the client wants to start the development ASAP.
When you divide the functions, I agree to put the most challenging one in the beginning this way you have long time to investigate and tackle them. However never assign all of your team members in finishing the risks. Use at least 35% of your resources on other functions.
Always consider each iteration as a self-contained small project, which starts from:
- Requirements understanding of the tasks ahead.
- Designing the development strategy.
- Identifying the risks associated with the tasks.
- Identifying the side effects with the tasks finished in the previous iterations.
- Programming and reusability design.
- Designing test cases and assigning them to the right candidate.
Sometimes, hiding the actual final date of the iteration from the team members makes you less shaking while listening surprises during the development.
How to maintain your pace in parallel Iterations
Your team may not be the only team, which is busy in the iteration; there might be other parallel iterations in progress however the goal for each team at the end is an iteration release. The release must be a stable, integration capable and tested system. Team leader is also responsible for the Integration with the other iteration releases.
In parallel iteration process, a formal meeting between the team leads often reduces the integration problem at the end. It also helps to explore new design techniques and coding practices between the teams.
Besides, it is not just to finish the iteration. The team lead must consider the integration constraints during the development. The release must not take longer time to integrate with other parallel releases.
How to assign and track tasks within the team
Your team members are your tools; let's suppose that you are being given a toolbox to open a motorbike engine. If you are not familiar with the skills of each tool you will end up with a mess.
Learn the skills of each member before you meet them, then prepare following before the meeting:
- Estimated time which will be consumed by each task.
- Start and end dates of each task.
- Divide the tasks based on their skills.
- Add a small time buffer at the end of each task.
- Add a time buffer to test each task.
- Add a small time buffer for release documentation.
Present the above 2,3,4 and 5 during the meeting and ask each member for the estimation of his/her task, if their estimation is less than or equal to yours, then accept them with appreciation and if it exceeds from your estimation, tell them to recalculate as we won�t have much time. Make your team members accept the division and estimation of the tasks.
I sense in many occasions that the team lead always find plenty of arguments while discussing the estimation of use cases. Only the experienced developers can estimate accurately. But this practice must be followed by each team lead to get the estimation of the task from the developer before he puts his hands on it. Never let the developer work on a task without freezing the finished time.
Make a casual visit to each team member once in a day; start the discussion with some friendly talk and get the progress of work.
The common problem with the developers is that they are code freak, if some of the logic in their code is not working properly, they will fight with it, again and again and again this is good to have their dedication. Always keep an eye on similar situations, the developer will probably spent entire of his time to explore, learn or to solve the problem while the clock is ticking. It's your responsibility to make him work according to your priorities. I had a similar experience listed below:
|
We were in the end of our project initiation phase when I asked one of my team member |
|
I asked |
�Hi Dennis! You already finished your task in time, let me give you a small assignment now� |
|
|
Dennis |
� I had some fixing to do in the last task, let me finish that first� |
|
|
So I allowed him to go back to the first task. Two days passed. |
|
|
I asked again |
� How is it going Dennis? Every thing on track?� |
|
|
Dennis |
� Of course, it seems I will use some more time� |
|
|
I replied |
� Never mind! Do your best judgments� |
|
|
When two more days passed and he appeared to be busy in the task, I asked again |
|
|
I asked |
�How is the day today Dennis? Still problem? |
|
|
Dennis |
� Yah, it is not solved yet, I will let you know when I will fix that� |
|
|
I asked |
� Let me see! Maybe I can learn something new� |
|
|
Dennis |
�Alright, actually I am trying to create an abstraction layer before the persistence layer� |
|
|
I asked |
�Why are you doing this?� |
|
|
Dennis |
�Because, if in future the persistence vendor changes, then the client will have less difficulty to change in the code. |
|
|
I was surprised |
�But the client will never change the vendor, not in next 20 years and this is not in the specs either � |
|
|
Dennis |
�But this is a good feature to have, to reduce the compatibility problem� |
|
|
I insisted |
�But if the good feature is never required nor used then?� |
|
|
Dennis |
�But you should talk to the client and tell him about that, he will be happy about that� |
|
|
I replied coldly |
�No, you should have talked to me before about that, I already had a discussion with the client about that, he will never change the vendor, as this is not an open source project, client have spent thousands of dollars to buy the license specially for this project. Beside, there are other tasks defined in specs. Please close this research and come to my chamber, I have other more important tasks for you� |
|
Consider the above experience, there is a breed of developers who spent a lot of their time in similar tasks. They don�t consult accordingly to the team lead or project manager. You need to be quick to identify them to save valuable time.
How to handle Team Meetings
A number of developers meetings should be conducted during the iteration. The team lead must make sure that the person has enough understanding of the task. It is useful sometimes to force someone to repeat his understanding of the task and believe me he won�t like that.
Most of the time, the meetings end up with lots of clarification requirements and questions by developers. It is totally up to the team lead to quickly coordinate with the client and clarify the requirements.
If the client is away and takes some time to reply to your questions, then you need to utilize this period. The clock is ticking and the team members are waiting for your response. Always list down all of the less priority tasks and use them in that period to busy the team those who are waiting for client clarifications
How to manage Risks and over Commitment
Almost all iterations contain at least one task identified as a risk. There are others, which are not being identified from the start, be very careful and let the client know about them quickly once you are sure.
These risks should also be discussed during the initial team meetings and log the developers' comments about them. Follow your own research to verify the comments. If the confusion persists then develop a detailed document, which explains the following:
- Why the task is a risk.
- Explain the critical level of the risk.
- What are the possible solutions.
- What is your recommendations.
- References of your research.
It happened many times that client has reduced or change his requirements and the risk is no longer a risk. If the requirements are unable to be reduced, then try to isolate the risk from the other tasks of the iteration so that it should not disturb the overall development progress. Allocate another time box to handle that risk separately.
Over commitment is very often in inexperienced teams. Problems may come when some tasks remain unfinished and they are related to integration module or being expected by other iterative teams.
The team lead must identify the tasks which are not expected to finish on time. This is itself a task as:
- Most of the developers often underestimate the requirements and always assured that the task will finish on time. It is only the last working days when the developer realizes the complexity of the use case.
- Some coding problem or vendor constraints.
- Shortage of certain skills took longer than the expected time.
The team lead must make sure before the delivery date to coordinate his superiors or to the client about what to expect in the release.
It is a bad idea to increase the delivery date for the sake of finishing all tasks in the release.
Always deliver on time even if the iteration contents are not what the client expects, coordinate with the client before the release. Obviously, it should not be the night before the release. Let your client know that the release may not contain certain features.
Clearly write down the release note about the functions, which are not finished along the expected finished date of these functions.
How to Release your Iteration
A good release constitutes the following:
- A release note, which enlists all of the finished features and testing status.
- If some of the features are not finished or not tested properly write them in a separate headings in the document. It will always be appreciated if you put down the expected finish dates of these tasks.
- Number of the details explaning documents of any constraints or limitations of the application.
Don�t forget to make a separate backup of all resources used in that iteration.
You probably won�t need that backup in source control environment but take a moment to think for those resources, which are not in the source control.
Summary
Iterative and incremental development process is proved to be the best in practice. Iterations provide a dramatic increase in feedback over sequential software development, thus providing much broader communication between clients and the team.
The nice thing about the process is that surprises are divided in different blocks of time, which always provide you a good time to manage and handle the risk separately.
