Current Development Process Overview

Figure 1.1

Feature IceBox

Feature icebox is used to store a list of features required by the client facing team. This list can hold all features that might be requested by the clients or the team thinks can be useful. This list can be very long and detailed.

Members:

The client facing team comprises of consultants, sales and other stake holders.

Role in Model:

The IceBox is used to pull features into the backlog once they have been discussed with the planning team in a planning meeting.

Frequency:

The feature team updated the icebox regularly as the requests come in from the client, or they come across or think of a new item within the feature.

Backlog

Backlog holds all feature requests which will be considered by the planning team for prioritization. 

Members:

The backlog team comprises of consultants, sales and other stake holders. However only limited no of members, primarily directors have the decision to move items into the backlog

Role in Model:

Backlog serves as the source of items to be prioritized for roadmap creation.

Frequency : In planning meeting

Long term planning

Long term planning is used to manage and control the product roadmap, and prioritize items for development. A voting methodology is used to vote items for prioritization. 

Members:

The planning team consists of directors.

Role in Model:

The planning team reviews the items in the backlog and votes for prioritization taking into account the business goals. The prioritized list servers as input for the Sprint planning meeting.

Frequency : Twice a month

Regular planning

The regular planning meetings move the business prioritized items into active development, providing time estimates and technical input to further help in sprint planning.  Resourcing is managed according to the backlog.

Members:

Technical team and directors. 

Role in Model:

The regular planning makes sure that all of the prerequisites of the development and lined up. Any scoping, architecture, or design required for active development build is made available. Separate sprints are managed for the scoping, architecture and design process as input for development build.

Frequency:

Weekly

Current development

The production is managed within current development. The current development executes all the development process namely, scoping, architecture, design, development, QA and deployment.  If the planning has been done correctly the various teams should work in coordination, producing output intime for other team to consume it. 

Members:

Project specific technical team. 

Role in Model:

This stage consumes the input from all the planning phase, and provides output or reports of what has been achieved during the development process.

Frequency:

Weekly

Figure 1.2

Maintenance release Process Overview

After running the sprint planning for few months we realized that in order to manage critical bugs and urgent requirements which are generally addressed in a maintenance release we need an alternate process which is low on planning and fast in delivering the required solution. We turned to a Kanban process to plan for the maintenance release.

Our Kanban process heavily depends on swimlanes (categorization of similar tasks )  to automatically proritise tasks. This automatic allocation of priority helps the teams to pickup issues as soon as they are raised.

The swimlanes are organized in such a way that high priority critical issues raised by the clients are picked up first for resolution followed by internally raised critical issues and then the rest. However to makes sure that we do not work on issues that are not important we use a continues review process.

Daily Standups

We review the work in progress on a daily basis with the project management team. Any issues that require discussion or feedback are tagged with predefined tags a day in advance so that only the important issues are discussed in the planning meeting.

Figure 1.3

Process Controls

Visibility

Visibility of the development status is the most significant goal which Agile development methodology using JIRA Agile has provided us. At any point in time we as managers can view the status of Future version development or a maintenance release. Detailed granular allocation of individual tasks is readily available and proactive measures can be taken where there is a resourcing issue.

Daily Review

Daily standups raise any issues that are facing the development process, if any of the development task is blocked due to dependences or feedback it gets highlighted on a regular basis and proactive measures are taken to resolve them.

Weekly Sprint review

Sprint planning allows us to define targets for the sprint and a review of the sprint on weekly basis is a good indicator of how we are doing against our target. A weekly sprint review helps to determine what went well according to plan and what can be improved.

The above methods have helped us to confirm that the development process is working as expected. Any issues or problems with the development process get highlighted quickly and proactive measures are taken to rectify the problem in time.

Release Schedule / methodology

HighQ does multiple releases of the product in a year. These product releases can be distributed into two main categories.

Major version release

New and major improvements are included in a major release of the product they are generally characterized by a release number in the form of 3.3 to 3.4  etc. Major version released are done after every 5 months or so. So HighQ releases at the minimum two major releases in a year.

Maintenance release

The maintenance release only includes bug fixes and small to medium improvements. E.g a change in the version number from 3.3.0 t0 3.3.1. Maintenance release or minor version release is done after every 6 weeks. HighQ generally releases 4 to 5 maintenance releases between major version release.

Schedule of Development languages employed

Following development language are used by our products:

• Java 7
• HTML 4 / 5
• Javascript
• CSS 3
• C# (.Net) 4.5