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.
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
We would love to hear your views and suggestions.
Stay tuned and we will share our experiences of the release of Collaborate 3.2, scheduled to be released early in the new year.
Source:
http://highq.com/making-agile-development-work-us/