What is the need of Agile Process Improvement?

It is commonly seen that a number of change projects are designed and published but none of actually goes into implementation. Most of the time is wasted in writing and publishing them. This approach usually fails. We should stop working with this methodology and develop a new one. Below mentioned are some common scenarios in the modern business:

1. Developing a stronger project
2. Changing the people working on it.
3. Threatening that project with termination
4. Appointment of a committee that would analyze the project
5. Taking examples from other organizations to see how they manage to do it.
6. Getting down to a dead project
7. Tagging a dead project as still worth of achieving something.
8. Putting many different projects together so as increase the benefit.
9. Additional training

-Drops in the delivery of the normal work always follow a change. 

-Big change projects are either dropped or rejected.

-It all happens because the changes introduced by such projects are mandatory to be followed.

-This threatens the normal functioning of the organization. 

-So, the organization is eventually compelled to kill the whole process and start with the old way of work again. 

-Instead of following this approach, a step by step process improvement can be followed that is nothing but the agile process improvement. 

Now you must be convinced why agile process improvement is actually needed. 

- The changes needs to be adaptive then only the process will be balanced. 

- An example is the CMMI maturity level. It takes 2 years approx. for completion and brings in the following:

1. Restructuring
2. New competitors
3. New products

-Only agile methods make these changes adaptive in nature.

-The change cycles when followed systematically produce results in every 2 – 6 weeks.

-Thus, your organization’s workload and improvement stay perfectly balanced. -The early identification of the issues becomes possible for the organizations thus giving you it a chance to be resolved early. 

-By and by the organization learns to tackle the problems and how to improve work.

-At the end it is able to adapt to the every changing needs of the business.

-The responsibility of the deployment and evaluation of the improvement is taken by the PPQA. 

-Whole process is implemented in 4 sprints:

1. Prototyping
2. Piloting
3. Deploying
4. Evaluating

-A large participation and leadership is required for these changes to take place.

-Some other agile techniques along with scrum can also be used in SPI.

-We can have the improvements continuously integrated in to the way the organization works. 

-The way of working can also be re-factored including assets and definitions by having an step by step integration of the improvements.

-Pair work can be carried out on improvements. 

-A collective ownership can be created for the organization. 

-Evaluations and pilots can be used for testing purpose. 

-In order to succeed with the sprints is important that only simple solutions should be developed. 

-An organization can write the coaching material with the help of the work description standards.

-This sprint technique helps the organization to strike a balance between the improvement and the normal workload. 

-In agile process improvement simple solutions are preferred over the complex ones.

-Here, the status quo and the vision are developed using the CMMI and SCAMPI. 

-Status quo and vision are necessary for the beginning of the software process improvement.

-SPI when conducted properly produces useful work otherwise unnecessary documentation has to be produced.

-An improvement in the process is an improvement in the work. 

-Improving work is what that is preferred by people. 

Phase 1 of Unified Process Life cycle - Inception

Unified process like any other process has got some phases through which the whole development process takes place. The unified process follows through the following 4 steps:

1. Inception
2. Elaboration
3. Construction and
4. Transition

Throughout this whole article we are going to discuss in detail the first phase of the unified process i.e., the inception phase. So let us a take a deep dive in to the understanding of the first phase “inception” of the project life cycle.

What is an Inception Phase

- The inception phase to say is usually short in most of the development cases but in some rare cases it can be quite lengthy. 

- But in an ideal project it is advisable to keep it short and simple other wise it will be required to divide in to much smaller iterations which in turn will be a complete waste of time.

- Furthermore a lengthy inception phase may indicate that there is an excess of up front specification which is something that is not in accordance with the principles of the unified process. - Every phase of the unified process has some pre defined goals that are needed to be satisfied in that phase itself. 

Goals defined for Inception Phase

- For inception phase the below mentioned goals have been defined:

1. To define and establish a scope for the software project.
2. To establish boundary conditions for the software project.
3. To establish a justification for developing the software system or application.
4. To outline the use cases for driving the design trade offs.
5. To outline the key requirements for the same purpose as the use cases.
6. To outline all the architectures those are to be implemented in the process.
7. To identify the associated risks.
8. To prepare a preliminary project schedule.
9. To estimate the cost of the whole software project.

When all of these mentioned goals are established then the inception phase is said to be concluded and completed. 

In short, what is inception phase is all about?

- The inception phase is all about developing a close enough vision of the software project, defining its scope and making the business case and providing an approximate estimate of the schedule and cost for the whole development project. 

- The inception phase seeks to build concurrence among all the stake holders involved in the development process on the basis of the objectives. 

- In an overall sense, the inception phase determines the feasibility of the solution that has been intended to build the software system or application. 

- In a way it helps the developers to understand what to build and risks associated with the project. - Another advantage is that the key system functionality can be easily recognized. 

- Due to some reasons the developers may be forced to have more than one iterations in the inception phase. 

- The possible reasons can be:

1. The project is so large that it is difficult to define its scope.
2. The system is unprecedented.
3. There are too many stake holders with complex relationships and competing needs.
4. Creation of proof of concept or prototype is required by the major technical risks involved.

- Over the inception phase sometimes counter productive patterns are observed. 

- In such situation a team may postpone providing estimate until the whole domain has been analyzed and documented. 

- But such behavior can lead to a condition called “analysis paralysis”. 

- Even the poor planning of the iterations of the inception phase can make the whole process go awry. 

- This can be avoided only if the iterations have been planned in such a way that they are risk driven and have been integrated and tested earlier. 

What is meant by risk-driven iterative planning?

So many approaches to iterative development and planning have been developed under the context of the agile software development process. Risk based iterative planning is one of such approaches and this is what that has been discussed in this article.

About Iterative Development

- The iterative development is based on the idea of carrying the development further step by step or incremental accomplishing one goal with each step.

- This is different from the normal approaches which take a momentary leap from the problem to the solution. 

- Such small development steps keep the development process on track and moreover it is much easier to test these small steps rather than testing the whole development process in one go.

- These steps are commonly known as the loops and are repeated throughout the development process.

- An iterative process may contain various loops depending on the complexity of the problem.

- Also depending up on the degree of the uncertainty of the problem and the situation, the looping can take various forms. 

What is Risk Based Iterative Planning

Below mentioned are the steps that are included in a typical risk based iterative planning:

1. Problem formulation: This step involves the defining of the following aspects:

(a) Time scope: the yearly programs are linked to their yearly budgets and other multiple time scopes are also defined.

(b)  Situation: the situation is defined and broken down in to smaller partial activities which are not interconnected with each other. A frame work corresponding to the budget of the problem is created.

(c)  Stake holders: the participation of the stake holders is identified and the decision maker is supposed to have full knowledge about the whole development process.

(d)  Risk: all the risks associated with the whole development process as well as the project are identified and the iterative plan is developed based on it.

     2. Information gathering: The information to be gathered regarding the project includes:

     (a) Strengths

     (b) Weaknesses

     (c) Opportunities

     (d) Threats

     (e)  Level of mobilization

     (f)  Stake holder identification

     (g) User response and so on.

     3. Vision Building: A vision is created for the development process which states how the goal can be achieved.

     4. Strategy Formation: A strategy or approach is defined to accomplish the purpose and the people involved are assigned different responsibilities and they are granted powers as per the contractual agreement.

     5. Implementation: To implement the plan power is granted to the participants and some times partnership is also formed.

     6. Evaluation of the development process: The development plan is evaluated based on certain factors like risk, reliability, stability and so on.

     

Always Remember about Risk Driven Iterative Planning

- Each iteration by itself is of no use! 

- It is only when all the iterations are put together that they become useful. 

- One point that you should always keep in your mind is that you should be as specific as possible while designing a risk based iterative plan. 

- Try to keep the length of the iterations as short as possible so that you can complete the iterative development in the allocated period of the time. 

- The most critical and difficult of the iterative planning is the generation of the tasks.

- The techniques you are using should have been stream lined to fit your time and cost budget. 

- You need to maintain a flow between all the iterations. 

- Remember that you may organize your development process in to iterations but that is not exactly what is called the agile development.

- The iterative planning is also called the sprint planning. 

- The iterative planning based up on the associated risks proves to be quite useful since it helps in avoiding many of the grave problems that can later hamper all the development efforts.