!

An Introduction to Agile Performance Management

by Jeffrey B. Rothman, Ph.D. An Introduction to Agile This is a high level introduction to Agile -- a well known productivity framework for software developers and engineers. Non-developers often hear software engineers talk about Agile, but arent certain what it is. To solve that and help strengthen collaboration between business teams and software engineering teams, here is a quick non-technical synopsis of Agiles essential elements. Understanding Agile will (1) help business managers better work with software engineers and increase the performance of cross-functional teams and (2) the principles and techniques informing Agile can be applied to general performance management and predictable goal achievement. Why Agile? One of the frustrations for non-engineers (and engineers too) is a lack of predictability (features and schedule) for software releases and less than rigorous performance management. It can seem like an engineering team keeps promising a feature release in a couple weeks, but it takes months to release an incomplete version of the feature that doesnt fully meet customer requirements. Agile provides a software development framework for a more predictable process that meets customer requirements. In this guide, I discuss the specific Agile methodology Scrum, but it shares many attributes with other Agile methodologies, such as Extreme Programming and Kanban. The core concepts for Agile are timeboxing, planning, and commitment. The audience for this article is software engineers and product managers who are new to Agile, as well as business executives and other non-engineers who want to better understand the software development process.

Click here to sign up for a trial of EngineeringRevu!

Commitments
The commitment is the set of stories for which the teams has taken on the responsibility of delivering.

Timeboxing
Timeboxing puts time limits on the small and large events within the Agile lifecycle.

Planning
The xed time for taking stories from the backlog, investigating them, and evaluating their complexity. You then decide which stories to accept into the sprint.

Timeboxing An essential concept in Agile Scrum development is timeboxing. Timeboxing puts time limits on the small and large events within the Agile lifecycle. The iteration period for software development activities is called a Sprint. It is fixed (from one to four weeks, but most typically two weeks). During a sprint (1) planning occurs, during which specific features are accepted into the sprint which the team commits to, (3) feature development occurs, (4) the features are presented in a demonstration; and (if all goes well) accepted for release. Once the sprint begins, the set of features to work on is fixed (exceptions discussed below). Additional feature requests received by the software engineering team during the middle of a sprint are only considered for a following sprint.

Event Name Sprint Planning Meeting

Frequency/Duration 1-4 weeks, typically 2 once per sprint, 4-8 hours (at beginning) once per sprint, 30-60 minutes (at end)

Description Development period Team assesses story points for each story, turns stories into tasks; sets stories for the sprint A demonstration of the new features to the product owner and others invited to attend

Demo

Click here to sign up for a trial of EngineeringRevu!

Retrospective

once per sprint, 1-2 hours (at end) daily, 15 minutes (typically first thing in the morning)

Analyze what went wrong, what went right, steps to eliminate waste for the next sprint Surface potential issues and conflicts; spins off meetings for resolving conflicts for the relevant team members

Stand-up

The table above shows the various development, life-cycle events. Each activity has a fixed duration set by the team. Occasionally there are tasks with unknown complexity and durations. In those cases, a fixed time is set aside for researching these tasks. Then in the next sprint, the task can approached with a better understanding of its complexity and duration. Planning: Story points and velocity

Each feature is described by the product owner (typically a product manager) in a series of stories. A story takes the form of: As a user, I need a feature that does X, in order that I can do Y.

A story is not meant as a full specification, and should be very simple. Its the engineering teams duty to ask questions and get feedback during development so the feature meets users needs.

Click here to sign up for a trial of EngineeringRevu!

Each story is assigned a relative measure of complexity called story points. Each team will measure complexity differently, but within a team, the complexity measured by a story point should be consistent over time. The team determines how many stories they will be able to complete during a sprint, based on their analysis and previous history. The number of story points a team can complete in a sprint is the velocity. The velocity increases over time in a well performing team, as the members gain product domain knowledge and gel as a team. Once the team has decided which stories to implement (and committed to the stories) for a sprint, that is the entire scope of that the team will work on in that sprint. Any features or significant requirement changes are pushed off to a future sprint. In an emergency, the sprint can be blown up and rebuilt with new stories. But, this is rare. Swapping is more likely. An existing, but unstarted story is replaced by the story representing the new urgent requirement (with equal or fewer story points). Commitment means that a software development team holds itself responsible for delivering on what is promised. Since the team decided what to commit to implement during a sprint, and did not have commitments and schedules imposed on it, the team is more engaged and is much more likely to deliver. Team pressure and self-imposed goals are far more effective than external pressure for delivering a high quality product on schedule. By determining the story points consumed by each feature for a significant portion of the product feature backlog (release planning), its possible to determine a product release schedule with considerable accuracy. Release planning provides a reasonable determination of (a) the features that will be available by a given date or (b) the date by which a set of features will be available. Of course, the dates will change if the resources (team members) change over time.

Click here to sign up for a trial of EngineeringRevu!

The Agile Team

Scrum Master
The scrum master (SM) helps facilitate meetings, keeps those meetings moving along smoothly, and handles any external difculties that team members encounter, for example, negotiating with IT to get additional resources, etc.

Product Owner
The product owner (PO) is responsible for (a) creating a story backlog for the software engineering team to complete, (b) keeping stories prioritized, and (c) sufciently dening stories for comprehension and use. The product owner also serves as a proxy for the feature end user/consumer.

Development Team
The team members consist of the developers and quality engineers working together to develop the features. Because some of the story details are not fully specied, its the teams responsibility to interview the stakeholders (PO, external and internal customers, managers, etc.) to draw out the requirements.

There are only a handful of formal roles for Agile (Scrum): the product owner, the scrum master, and the development team members. The product owner (PO) is responsible for (a) creating a story backlog for the software engineering team to complete, (b) keeping stories prioritized, and (c) sufficiently defining stories for comprehension and use. The product owner also serves as a proxy for the feature end user/consumer. Of course actual customers or other people can participate in refining features and answering questions, but in an informal manner. The scrum master (SM) helps facilitate meetings, keeps those meetings moving along smoothly, and handles any external difficulties that team members encounter, for example, negotiating with IT to get additional resources, etc. The SM is typically a software developer that devotes 50% of his time to SM duties. While the SM could be a manager, its preferred that she not be one. The team members consist of the developers and quality engineers working together to develop the features. Because some of story details are not fully specified, its the

Click here to sign up for a trial of EngineeringRevu!

teams responsibility to interview the stakeholders (PO, external and internal customers, managers, etc.) to draw out the requirements. Team members also get feedback from the PO and others continuously during the software development process. Prerequisites for Agile Success Agile is a great development framework with superb predictive capability, but it needs a commitment from the organization to make it work. Through trial and error, here are the necessary factors that must be in place for it to be successful: 1. The team must not be interrupt driven, and must be given sufficient uninterrupted time during the day to execute on its commitments. 2. The Product Owner (PO) must have a properly groomed backlog, sufficient knowledge about what she is asking the team to develop, and generally accessible to the team during the day for feedback. A PO should ideally be dedicated to one Agile team; worst case should be handling two teams. Having more than 2 teams will lead to poor outcomes. 3. The members of the development team need to be team players. Cowboy coders will inhibit team performance in an Agile environment, and should be assigned to other, non-Agile projects. 4. Optimally, all the team members are in near proximity, i.e., the same office area thats my strong recommendation. My experience has been that having team members in other locations really interferes with achieving high level performance and team cohesion; but other people have reported success with distributed teams. 5. The nature of each of the rituals needs to be understood and held with inviolable rules. Holding the meeting without understanding the purpose or benefiting from the outcome is a form of waste. a. Stand-ups arent for resolving problems, but for surfacing them. Its not meant to be just a status report. Spin off other meetings for the concerned parties around issues. b. Retrospectives are for improving the development process, not for laying blame for failures. They are used for reducing waste by doing more of what is working, and

Click here to sign up for a trial of EngineeringRevu!

removing unsuccessful steps from the process. There are always improvements to be made! c. Demos are held by the team solely for the benefit of the PO. Other attendees come only with the invitation of the team. It is absolutely not a dog and pony show for the business executive team. There should be minimal prep time for the demo, and it consists solely of showing off the new features, with minimal (or no) slides. 6. Information radiators, such as publicly visible charts of progress (such as burn-down charts) are a great tool for explaining and demonstrating to other teams the status of the sprint and instills confidence that the Agile process provides predictive value. 7. In systems with massive technical debt (e.g., poorly written code, insufficient automated tests), Agile often breaks down. There is too much uncertainty when one small change can ripple throughout the whole system. Theres not an easy solution, though often research spikes (timeboxed research effort) can be used to reduce uncertainty. 8. The developers need to get feedback from the PO (or the appropriate stakeholder) whenever there are questions about specs. There shouldnt be unpleasant surprises at demo time - the PO should have seen everything already. In the worst case, the PO might not accept some of the stories as complete, and that can cause a mess to pull the offending code out of a release. Summary & General Principles This Agile planning process is far more reliable in determining a schedule than any other mechanism that Ive seen during my professional experience. Its also important for marketers, sales and other teams to understand Agile so they can both synchronize their activities with the development process as well as incorporate Agile concepts into their own processes. For example, one of the big engines of Agile is getting buy-in by allowing the team to decide the how of a project (but generally not the what). By allowing the team to creatively work to discuss problems and provide their own solutions, they will be much more engaged with projects. Timeboxing is also a valuable tool for keeping meetings and projects on track. A semi-weekly retrospective can help

Click here to sign up for a trial of EngineeringRevu!

any team to eliminate time wasting activities and focus on improving their performance through teamwork. Agile can be a great framework for improving the performance management of any team.

Click here to sign up for a trial of EngineeringRevu!