We welcomed Mike Birkhead, volunteer, to educate us about the software development process called Agile. He walked us through the history, the process, and the application of Agile in only two hours. Here’s a summary of his talk.
Agile: People Over Process
The impetus for Agile goes back to the early days of computing (c. 1950s) when software development was an iterative process and might take a decade to produce a working result—only to discover that software was obsolete…and yet, the final product still required support, even though the original developers had advanced to other positions or other companies, the hardware was out of date, and the manuals (primary source of support in those days; origin of the infamous RTFM admonishment) were not always readily available. The resulting scarce resources led to high maintenance costs; as much as 80% over the software lifecycle.
Fast forward to the late 1980s. A group of smart developers decided to try designing and developing at the same time—in parallel. The concept was tagged Scrum, a term borrowed from Rugby where the players all run down the field at the same time. Basically Scrum, now known as Agile, focuses on self-organizing teams, consisting of Product Owner, Team Member, and Scrum Master roles. The team takes priority over management, budget and delivery date. The goal is to monitor how the team is doing; if the team is doing well, that’s great because high-performing teams do the best work, produce the best results, and are happiest.
The Agile Manifesto
Moving forward another decade (to 2001), a collection of developers met at Snowbird and formalized their principles—or values—in the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Simple. Workable. Measurable. Scalable. Collaborative.
Simple. Apply Common Techniques
For starters, Agile employs a well-known technique: When you write down an idea, then read what you wrote, the information travels along a different path to your brain, triggering a review process, clarifying details, sparking different perspectives. And, other people can read and share your idea. The act of writing down your idea affords you—and others—the opportunity to take advantage of the collective perspective.
This technique has been tagged Kanban [“konbon”], a Japanese term meaning visualized board, or a card that goes on the board; a term that’s part of the Agile Toolset.
A companion form of Agile, Lean, focuses on getting rid of waste and managing work in a manner that makes people accountable on their own terms, not those of management.
The process for a Lean Kanban is ideal; however, the most frequently-used form of Agile is the Scrum.
Workable. Plan | Develop | Deliver | Test | Repeat
The Scrum cycles through the plan | develop | deliver | test process until the desired result is achieved.
Plan: Document the requirements.
Develop: Produce code.
Deliver: Present the product.
Test: Q.A. > Alpha Test > Beta Test -or- AutoTest using a product like Jenkins.
Repeat, as necessary.
In the tradition of Japanese Culture, Scrum has a couple of ceremonies to it:
1) Daily StandUp: Check-in with the team (e.g., five people on a 15-minute conference call) to make sure everyone is on track; facilitated by the Scrum Master who asks three questions of each Team Member:
- What did you work on yesterday?
- What are you working on today?
- Do you have anything blocking your progress?
The Scrum Master asks these questions to make sure something’s not holding things up, and then proceeds to unblock any impediments.
2) Retrospective: Look back and review the progress.
- Learn from mistakes.
- Improve the process.
- Was there too much work?
- Did the ScrumMaster do their job?
- Incorporate the results into next sprint.
Sprints: Transparently Tracking Progress
Managing—or tracking—an Agile project employs a spreadsheet-style chart, divided into time boxes representing an arbitrary time period (Cycle Time; commonly two weeks) to record and assess project progress: called a Sprint.
Metrics. Process | Story | Velocity
The overall Agile Process measures progress by assessing the overall value achieved, on a task by task basis, as the process moves through the cycle.
The Story—or progress—provides a way to rate individual tasks on a scale of 1-5. Totaling all the points for all the tasks determines the velocity for a particular sprint.
Velocity is the primary metric used in a sprint; measuring how many items of value (or, points) were delivered during the sprint.
The Velocity metric is a way to compare different teams. You can’t really have teams go head-to-head because each team is different—has different team members engaged in different activities—so you can’t measure them comparatively. The velocity enables each team to measure themselves by analyzing the results of their story estimates.
The velocities are averaged to get a threshold, called the Happiness Line; the line that we want to accept work within, in terms of our velocities.
Scalable. A Transferrable Process
The Agile model is scalable, from small to large projects, using either a white board or an electronic board to work through the tasks. The process usually takes about three sprints—three two-week time frames—for a team to get into the groove.
Collaborative. Teamwork Rules; No Heroes in Agile
The overall goals for Agile include:
- No overtime; someone taking on too much work, someone slacking off, whatever.
- Limit the W.I.P. (Work In Progress) to avoid context switching stress.
- Seeking a work/life balance.
- If someone has time left over, there’s the option to do some training (taking an online course to learn new skills, or giving a volunteer presentation to students).
- Building confidence in the team that enables them to come back refreshed.
The long-term objective is to get the team into maintenance mode, where:
- They already know the process.
- They feel good.
- They’re self-organized.
- They’re making decisions.
- They’re determining what tools they’re using.
- They’re understanding what their skill level is—and which skills are missing, so they can help management understand where they need to up-skill.
- They feel control over their work and life; that breeds happiness and that breeds high performance; a cycle we want to fulfill.
Agile: Chunk Tasks; Focus On People
Agile is about segmenting the tasks associated with a project into manageable components and masterfully distributing those components over resources (staff and time) to achieve maximum performance.
Thanks to Mike for delivering a very informative explanation of Agile; a process that, once implemented, clarifies and directs the design process to produce the desired results.
Here’s a link to Mike’s slides and some general information about Agile; posted on Dropbox.
Copyright © 2016, FPP, Inc. All rights reserved.