Mondays are no longer crazy workdays for the development team at
HighQ. Why, you ask? Well, now that the planning stage is over, we’ve
started working on executing our vision and plans.
It has taken more than six months to get to where we are now. We have not yet reached our management goal but we are moving towards it. There is clarity in our technical goals and what we are trying to achieve. The technical team is becoming aligned with business plans and can now react to changing needs.
We had been using wikis, emails, and meetings for gathering and documenting requirements, which meant that it took time and effort to translate these requirements from the business to the technical team.
Working in this way, we planned a major redevelopment of the interface for the release of Collaborate 3.0 with the intention of making it responsive. We achieved this goal, but bottlenecks in the process and a lack of coordination meant that we fell behind schedule.
Although we used various tools for requirement capture, there was no one application where everyone could work together. Subsequently, the development and management teams struggled to communicate changes and requirements with one another, which slowed the process down.
In January this year we decided to take some radical steps to transform the way development was being managed. Collaborate 3.0 had not yet been released and was still in active development, which gave us some time to organise and reform our development process for the next version of Collaborate.
It was clear that there were too many small-to-medium features to discuss and agree on in these planning meetings, so a smaller team was created to discuss and prioritise small-to-medium features as a continuous ongoing effort.
We also tried giving each consultant a quota of features they wanted resolved in the upcoming development; however, this did not seem to be the best way to prioritise features, so we removed it from the process.
The backlog was discussed and agreed in a wiki to facilitate input from all stakeholders. Once the backlog items were clear, they were moved onto a Kanban board. The Kanban board had various stages to cover all of the prerequisites for a features development. Once all of the required prerequisites were complete, the feature was moved to a separate development board.
We decided to find an industry-standard development methodology tool that would help us to manage the project consistently. This would require not just a change in tools, but also a change to our way of thinking.
After evaluating many options we decided to go with JIRA + Greenhopper as it gives us granular control and reporting, but at the same time allows us to manage the development on simple agile boards.
At times, this does mean that the sprint goals will not be achieved due to change in the work in progress, but that is acceptable as long as the critical issues are being addressed and do not have to wait until the current two week sprint ends.
Prioritisation and estimation are the key issues impacting the planning process. Estimations on epics (large features) can take time, so we try our best to be lean and not spend excessive time on getting accurate estimates.
We believe that once the team matures in the estimation process, their estimates will take less time and become more accurate, further facilitating the planning process.
It is essential to prioritise requirements that need to be estimated, specified and designed, however prioritisation requires significant time by the stakeholders. Without prioritisation, however, the sprint planning process fails in making good use of the development capacity and delivering the most required features.
Source: http://highq.com/making-agile-development-work-us/
It has taken more than six months to get to where we are now. We have not yet reached our management goal but we are moving towards it. There is clarity in our technical goals and what we are trying to achieve. The technical team is becoming aligned with business plans and can now react to changing needs.
Changing our methodology
We undertook a major transformation of our development methodology and planning processes after our most recent major release took substantially more time than was originally expected. The delay was attributed to a few factors, but one of the key ones was the absence of an agreed development methodology.We had been using wikis, emails, and meetings for gathering and documenting requirements, which meant that it took time and effort to translate these requirements from the business to the technical team.
Working in this way, we planned a major redevelopment of the interface for the release of Collaborate 3.0 with the intention of making it responsive. We achieved this goal, but bottlenecks in the process and a lack of coordination meant that we fell behind schedule.
Although we used various tools for requirement capture, there was no one application where everyone could work together. Subsequently, the development and management teams struggled to communicate changes and requirements with one another, which slowed the process down.
In January this year we decided to take some radical steps to transform the way development was being managed. Collaborate 3.0 had not yet been released and was still in active development, which gave us some time to organise and reform our development process for the next version of Collaborate.
Roadmap planning
We started by setting up a roadmap team, which specified the business goals. The roadmap team was made up of five people, each representing a business unit and jurisdiction, who met fortnightly. We used a workshop methodology to prioritise new requirements. This helped us to flesh out the key goals of the roadmap.It was clear that there were too many small-to-medium features to discuss and agree on in these planning meetings, so a smaller team was created to discuss and prioritise small-to-medium features as a continuous ongoing effort.
We also tried giving each consultant a quota of features they wanted resolved in the upcoming development; however, this did not seem to be the best way to prioritise features, so we removed it from the process.
The backlog was discussed and agreed in a wiki to facilitate input from all stakeholders. Once the backlog items were clear, they were moved onto a Kanban board. The Kanban board had various stages to cover all of the prerequisites for a features development. Once all of the required prerequisites were complete, the feature was moved to a separate development board.
Finding the right tool for the job
Our development team comprises of around 65 developers working remotely in India. The project managers in India report to the development managers in our London office. This meant that it was even more important that we found a simple-to-use, agile management tool which could cover all aspects of project management and reporting.We decided to find an industry-standard development methodology tool that would help us to manage the project consistently. This would require not just a change in tools, but also a change to our way of thinking.
After evaluating many options we decided to go with JIRA + Greenhopper as it gives us granular control and reporting, but at the same time allows us to manage the development on simple agile boards.
Development planning
Every Friday the London technical team conducts a Scrum planning meeting with the project managers in India. After some trial and error we have adopted a hybrid system in which new features are managed using Scrum, whereas urgent bugs and any immediate small-to-medium issues are pulled into the sprint.At times, this does mean that the sprint goals will not be achieved due to change in the work in progress, but that is acceptable as long as the critical issues are being addressed and do not have to wait until the current two week sprint ends.
Prioritisation and estimation are the key issues impacting the planning process. Estimations on epics (large features) can take time, so we try our best to be lean and not spend excessive time on getting accurate estimates.
We believe that once the team matures in the estimation process, their estimates will take less time and become more accurate, further facilitating the planning process.
It is essential to prioritise requirements that need to be estimated, specified and designed, however prioritisation requires significant time by the stakeholders. Without prioritisation, however, the sprint planning process fails in making good use of the development capacity and delivering the most required features.
Looking forward
Changes to the development process have helped us to release Collaborate 3.1.1 within good time. Although not yet perfect, we are certain that we are on the right track and continue to improve as we move forward. Some of the things we are focusing on are:- Improving the reporting process to give better management updates
- Striking a good balance between epic stories, small-to-medium tasks, and bug fixing for each release
- Changing the estimation process to a point-based system, which allows us to simplify the process by breaking them down into large, medium and small efforts
Source: http://highq.com/making-agile-development-work-us/
No comments:
Post a Comment