Co-Pilot

using agile methods to land IT projects smoothly

Till Bay, Benno Baumgartner, Matthias Hüni, Eva Jutzeler, Michela Pedroni

• Publisher: buch & netz
• Year: 2014
• ISBN:
  9783038051022
• Topic: Ciencia de la computación
• Subtopic: Tecnología de la información

This book describes the agile software development process of Comerge AG from Zürich, Switzerland. Founded 2008 as a startup with four employees, the team consists now of over twenty members. Embracing an agile approach from the beginning, the Comergers have developed a lightweight yet efficient project management toolkit which lead to the successful release of more than 280 projects for over twenty clients. Covering the SCRUM approach, the Co-Pilot helps you focuson efficient and elementary project management techniques. It serves as a guideline to keeping the customer in the loop and particularly focuses on the often underestimated "Testing" part of the agile software delivery process.

Projects

Process roles

Our software development process is based on the four roles: team member, team lead, product manager, and customer.

Team member

The main activity of a team member is to resolve issues. Issues capture things to do. They are sufficiently small grained to be solved in a short time frame (usually taking at most one day). Issues result from bug reports or enhancement wishes. Every issue can be assigned to a specific team member, who then is responsible for resolving it (see How to work with issues for more information on issues). The team members of a company may have any professional background (e.g., designers, marketing agents, assistants, education specialists), but in a software company most of them will probably be software engineers. A software developing team member owns a clearly defined portion of the code. As a code owner, she is responsible for her code and expected to be the expert.

Team lead

The team lead communicates with other teams and the product manager. He is responsible for assigning issues to his team members and for planning an iteration. The team lead should always know what his team members are working on and when they will be finished. He may redistribute work among them and thus balance the workload evenly. It is the team lead’s responsibility that his team achieves the goals of an iteration. The team lead reports the status (green, yellow, red) of the iteration during the weekly core meeting. The team lead is also a team member.

Product manager

The product manager is responsible for the entire product. She gathers the requirements from the customer and communicates these requirements to the team leads by using user stories and enhancements. She makes sure that the teams implement the enhancements as expected. Her goal is to find out how to satisfy the needs of the customer while taking into account the resources of the teams. The product manager keeps an overview of all teams and directs their work towards one common goal. Ideally, the product manager is a business manager with a technical background, and sometimes, she is an employee of the customer.

Customer

One important goal of the process is to satisfy the customer. In return, the customer pays the bill. Usually, there is one person appointed as customer representative. This person is an employee of the customer and has two main duties:

1. He continuously observes the progress of the product development and ensures that it is on track.
2. He protects the project teams against internal customer politics and acts as a channel to communicate customer decisions.

If the customer representative is not willing or not capable of fulfilling both duties, the product manager tries to fill the gap and supports the customer representative. If this fails, the product development may be carried out, but it is unlikely that the Co-Pilot will be able to deliver a product that matches the needs of the customer. Another process or customer should be considered in this case.

How to plan a project

A project is an endeavor undertaken to bring an idea to life by creating a unique product. In such a setting, changes happen frequently – thus, it is important to identify and plan the fundamentals of the project that remain stable.

Define goals and principles

What is the goal of your project? The product manager creates a project workspace on the Intranet and uses it to:

• Clarify the focus. This leads to stories.
• Document the resources (people, software, hardware, books, etc.) that are needed.
• Define success.
• Clarify principles or constraints. For example: Is the main goal to please the boss, stay within budget, or finish by a certain deadline?

Identify stories

Stories are simple descriptions of what the software should accomplish. These stories are developed by the customer and the developing team. Given a story, the team members create issues. This is an open process; finding the stories may rely on any useful technique like brainstorming or mind maps.

Note: Stories do not mention technical details. The gathering of stories usually happens at the beginning of every iteration.

• Define enhancements: The product manager breaks down the stories into enhancements, documents them as issues, and assigns them to teams and iterations. She also provides priorities and a rough chronological order for the enhancements. She then hands the iteration planning over to the team leads.
• Iteration: The teams carry out an iteration (see also How to iterate). This may lead to adapted or new enhancements and stories.
• Review the iteration plan: After each iteration, the team leads and the product manager gather to review it. This review discusses if the goals of the iteration were fulfilled. This review can be done as part of the retrospective meeting.

Assigning team members

Generally, it is a bad idea to assign a team member to work on two projects at the same time in one iteration, because it requires a lot of discipline from the team member.

While it is possible to divide a week into two parts, each devoted to working on one project, work is in reality often fragmented. Fragmentation appears when the times in which the person needs to be in one place overlap with times where the person needs to be somewhere else. If it cannot be avoided (typically the case in startups where all employees share the workload and help each other), it requires very clear planning of the person’s resources.

Example

This example shows a user story and related enhancements.The overall goal is to develop a software that manages the customers of a company.

User story

Title: Opening a customer by customer ID

Description: As a call center agent, I want to open a customer by entering his customer ID, so that I can quickly access his data when he is calling the call center and identifying himself with his customer ID.

Enhancement for the frontend team

The web user interface allows quick navigation to a customer profile by entering the customer ID.

Task: Implement a number field that allows to enter a customer ID on all the pages of the software. Hitting the button “Go!” or the “enter” key opens the customer’s profile, if available. If the profile is not available, show a message stating that the customer does not exist.

Enhancement for the backend team

We need a way to construct a URL to show the profile of a customer given his customer ID.

Task: Implement the getCustomerUrl service, which constructs a URL given a customer ID or returns an error message if the customer does not exist.

How to iterate

An iteration is one cycle in the release process. Usually an iteration is 5 weeks long and has three phases:

• Planning: 2–3 days
• Implementing: ~4 weeks
• Testing: 1 week (see How to create a release for details).

The exact duration is up to the taste of the team. 5 weeks works for us, but we also heard from other teams that a shorter duration is practicable. We prefer our iterations to always have the same lengths, to ensure that the team is aware of it and embraces the rythm.

In the planning phase ...

... the team lead assigns the enhancements that were defined in the project planning to the team members. Additionally, the team lead also distributes tasks and issues to team members. Tasks are parts of an enhancement and can be used to break down an enhancement into a number of smaller pieces of work. Issues come from testing the software and from user feedback. In the planning phase, the team lead also assigns issues that were postponed from previous iterations to team members.

In the implementation phase ...

... all team members work on their enhancements, issues, and bugs. During this phase, no requests from outside of the team should be accepted (read below on how to handle asynchronous requests). During the core meeting, the team members report on their progress of the projects they are working on.

In the testing phase ...

... the software development is first frozen and then tested according to a test plan. See How to create a release for details. After creating the release the iteration is over and it is time to take a nice break, read a book, plant a tree, or have a BBQ.

Asynchronous requests

A customer or product manager approaches a team member with an asynchronous request in the middle of an iteration.

Generally this is not allowed. And thus, it is important that the product manager explains this rule (and the general process) to the customer at the beginning of the project, so that they understand why a request is pushed back. A team member that faces an asynchronous request may handle it in the following way:

• If it is the product manager that approaches a team member, then the team member may tell her to improve the planning next time and refuse to accept the request.
• If it is the customer, then the product manager explains to him that it is not practical for the success and quality of the current iteration.

If the request is critical and comes in before the freeze of the iteration’s milestone, the product manager may offer to trade the new enhancement against one of the enhancements that was planned for the iteration.

How to work with issues

Issues are one of the core concepts of the Co-Pilot. There are several rules to follow when dealing with issues:

• Every code change is caused by an issue.
• Every request for a code change must be filed as an issue.
• An issue can only be resolved as fixed, if it has an assignee and fix version.

It is important to track issues because of the following reasons:

• Issues can be viewed as a list of things that a team member needs to do. Filing an issue ensures that the “to do” is not forgotten.
• Issues may be assigned to a person. Once an issue is assigned, it is clear who is its owner and thus responsible to resolve it.
• It is often difficult to understand somebody else’s code changes and w...

Table of contents

• Co-Pilot
• Projects
• Meetings
• Tests
• Customers
• Glossary