Agile Development at HP - Part 1: Defining the Process

This is the first in a series of five posts that describe the development methodology processes used by the HP Agile Manager team. Of course, we already had processes in place, but we knew that they could be improved. This post describes how we took a good look at our existing processes, and decided what we wanted to improve—without creating ‘regressions’ in the processes that were working well. The next post will discuss the culture and values of the team. We’ll then take a look at the release and sprint lifecycle, and the feature and user story lifecycle, and end with a summary of the roles and responsibilities of each member of the team.

 

Background

Very early on in the project, we took a long, hard look at our development processes, and realized that we weren’t running at our full development efficiency. We had some effective processes in place that we wanted to preserve, but we knew that there was plenty of room for improvement:

 

Processes.png

 

As we looked at the two lists, we found that we were asking more questions than we had answers to. We decided that we needed to analyze each stage of the development process in depth.

 

Defining the Agile Process

Our Project Manager (also known as Project Management Officer, or PMO) proposed that we create a list of topics that we needed to tackle. Once we came up with the list, we created small “work stream teams” for each topic, consisting of members of the Management team. These teams were responsible for analyzing the topic, come up with a set of recommendations, and present them to the rest of the management team. Each team would have an owner, who would ensure that the team met to discuss their items, and work on the conclusion presentation. The whole process was time boxed to a month.

 

We came up with an initial list of topics based on our existing processes, along with the expectations from the team that would work on that topic. We chose the owner and members of each team based on their personal experience with the topic to be discussed.

 

As the teams met to discuss their topics, we found that there were some topics that we hadn’t taken into account. We formed more teams on-the-fly to deal with surprise issues as they arose.

 

Here’s the final list of topics, and what was expected of their team by the end of the process:

 

Work Stream

Expectations

Roles and Responsibilities

Define the roles required in the team, and the responsibility of each role

Ceremonies/retrospectives

Decide who owns each ceremony, their frequency, when they’re scheduled, and the desired outcome from each ceremony

Definition of Done, Limit the Work in Progress (WIP), Sprint Commitment

- Agree on a ‘Definition of Done’ (DoD)
- Decide who defines the acceptance tests and when they are run
- Define how to measure the WIP, and ensure that it’s limited to the features and user stories selected for the release and sprint
- Sprint commitment:

   - Define how the commitment should be communicated
   - Define how the commitment’s progress should be measured

User Story development process (entry criteria for each status), Acceptance Test Driven Development (ATDD) and JBehave

Establish the criteria for each status that a user story can have

If a user story is to be developed using ATDD:

- Decide what should be automated/manual
- Determine who implements the tests
- Decide where the tests are kept
- Define how to measure the automated acceptance test progress and coverage

Feature development

Establish the process for feature design and review, and determine who owns the feature.

Backlog management and readiness

Determine how detailed the top of the backlog should be

Define how to manage new functionality versus defect handling, versus technical debt

Continuous Delivery (CD) Process

Identify and arrange hardware, source repositories and branches.

Decide on the frequency of pushes and gradual exposure/promotion to production.

Operations Review

Define the operational and performance parameters to be monitored in production.

Release Closure

Define the format and content of release notes, demo data, movies, documentation, ‘What’s New’ document and training.

Support

Define the workflow of incident management for the group

Security

Define the security test cycles, release criteria and the security criteria by which builds are pushed to production

Performance

Define the Key Performance Indicators (KPIs) and thresholds

Quality

Define the release criteria for each push and for each release

 

After our month-long ‘sprint’, the management team spent two days on an off-site meeting to consolidate all of the work.  Away from the pressures and distractions of the office, we were able to systematically go through all of the topics, with each topic owner presenting the conclusions of their team to the rest of the management team. 

 

Many of the work stream presentations were contested during the off-site meeting, and we couldn’t reach an easy agreement on most of the issues. Many of the conclusions were drawn as a result of last minute role plays that led to some really useful insights: we split into two teams, and simulated an actual release cycle, with each person on the team playing a different function. Both teams arrived at very similar processes. 

 

Even though many of the people were involved with two or more work streams, we still managed to keep to our one-month time box.  Best of all, every single one of the topics was fully addressed.  The off-site session gave us the perfect environment to discuss and consolidate the output of each of the topic teams into a coherent set of development processes. These processes helped us achieve our goals of delivering features faster with a consistently high level of quality.

 

But just having a set of processes is not enough to guarantee success.  The most important component in the mix is the people.  So in the next part in this series, we’re going to take a look at our culture and values, and how we emphasize quality and improved development efficiency.

 

UPDATE:  Here are the links to the other posts in this series:

 

Feel free to share your own development processes in the ‘Comment’ box below. 

 

This series of articles was written based on processes and methods developed by Lihi Elazar (Agile Manager PMO) and materials provided by her.  Thanks to both Lihi and to Asi Sayag (R&D Group Leader), for their help, guidance, and extensive reviews of this series.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Malcolm is a functional architect, focusing on best practices and methodologies across the software development lifecycle.
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.