Agile

Introduction

The term Agile was popularized back in February of 2001 through the book, “Manifesto for Agile Software Development”. Since then it’s been adopted by many; big and small companies alike.

I love the agile development process - when it’s done right. But getting Agile right is hard. And that’s simply because it’s very easy to misunderstand what agile is. Agile is not a protocal to follow. It is a box of tools and guidlines to help each unique software development team learn to work optimizally in their own way.

I’ve heard engineer complain, “Nah Agile not for me - the meeting are way too long.” …then work with your team to make the meeting shorter! Agile encourages us to constanly evaluate what were doing and improve it - but more on this later.

Over the course of this post we are going to break Agile down to better understand what tool it provides us with!

Part 1: So what exactly is agile..?

In the past, software was typically developed the same way a bridge was built. It followed a highly structured methodology known as the Systems Development Life Cycle (SDLC) or as it’s more commonly known “Waterfall”.

Waterfall takes a predictive approach - we plan as much as possible at the start (budget, scope, steps, etc) and avoid any deviation from this plan moving forward. It’s broken down into 5 main steps:

1. Planning - the preliminary investigation, involves documentation such as system request, feasibility study, etc..)
2. Analysis - deliverable is more documentation (system requirements and solution description)
3. Design (Logical and physical) - deliverable is even more documentation! (system design specification)
4. (finally) Implementation
5. Maintenance (i.e. updates, security bumps)

Waterfall was strong in past because for the first time, software development had documentation standards, a timeline and budget, replacable roles, and an opportunity to review the process at the end of each stage. It worked for tradiational engineering, so why not use it for software engineering?

Well.. alot of reasons.

• System requirements “locked in” after being determined
• Limited user involvement (only in requirements phase)
• Too much focus on milestone deadlines of SDLC phases to the detriment of sound development practices

• Measured how well we meet our deadlines

  • Going back is therefore avoided as much as possible, so even if problems occur they are pushed to meet budget and time constraints

At the end of the day when the user or client finally sees the product, they often wern’t happy with it. Think about how many times you’ve been working on a project and as you dive deeper in, the plan shift or new ideas arrise? Unlike bridges, we can’t cleanly separate design from construction.

Enter Agile!

Agiles takes an iterative approach to software delivery. In short, we break down our project and build it out incrementally, delivering in two week cycles called sprints.

But again to re-iterate, Agile is not a rigid process! It outline guidlines and tools that help us work efficiently and effectively. If it’s not, we adapt - and there’s some suggested tools to help us do so! (we’ll come back to this later)

For now let’s take a closer look at Agile!

Part 2: Three Key Principles of Agile

Agile has 3 core principals behind it.

1. Adaptive:

   • Change is inevitable. We understand user might (and likely will) shift their requirements! They might see new potential, change their mind, see unexpected results, etc.
   • To accomplish this we,
   • Sprint! By building in short bursts we are always producing a tangile product
   • Work lean! Less documentation, more code. We know our plan will shift, so document “enough”
   • Maintain transparency! At any moment in the project we know where we are and how much we have developed

2. Emphasize people rather than roles

   • People are seen as creative individuals who should be empowered to make decisions. Instead of defining and filling specific roles, we encourage flexibility.
   • We create self-managing teams - indididuals choose what they do!

3. Self-adaptive processes

   • We are not locked in a certain process - we adapt! (even on a spirt by sprint basis)

Part 3: The Agile Manifesto

In addition to it’s princiapls, agile revolves around a handful of fundemental values:

• Individuals and interactions over process and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Part 4: The Agile Team

Now that we understand what Agile is based on, let’s start to shift our focus to its application.

Agile teams are made up of a few key components,

• Product Owner

  • Define features, Release date and content, ROI (profitability of the product), Prioritize features according to market value, Adjust features according to market value, Adjust features and priority every iteration, as needed, Accept or reject work results

• Scrum Master

  • “management”, Enacts scrum values, Removes impediments, Ensure functional and productive team, Enable close cooperation across all roles and functions, Shield the team from external interferences,

• The team

  • Typically 5-9 people, Cross-functional (dev, testers, UX, UI, etc), Members should be full-time (no changes during sprint), Self organizing (try to avoid titles) & self-managing

Again these are flexible; our product owner and scrum master roles can be combined and filled by an individual.

Part 5: Artifact

The artifact are used to help us plan, organize, and evaluate our software development progress.

• Product backlog

  • Our requirements (aka. a list of all desired work)
  • Each item has value to user/customer
  • Prioritized by product owner

• Sprint backlog

  • The list of tasks for the sprint
  • Individuals sign up for work of their own choosing (never assigned)
  • Estimated work remaining daily

• Burndown Chart

  • Timeline of story completion, where
  • Our team “velocity”: number of stories (points) per iteration

• User Roles

  • Collection of defining attributes that characterize a population of users and their intended interaction with the system
  • Steps to defining user roles:
  • Brainstorm initial set of roles - write down roles on a card and place on table
  • Organize the set - arrange related roles together and overlap if needed
  • Consolidate the roles - Discuss overlapping (either remove, or find new name) and remove unimportant roles
  • Refine the roles - identify attributes (i.e. freq of interaction, level of expertise, goal, etc.)

• User Story

  • Formal one-sentence description of a functional requirement
  • Template: “As a \* I want * so that ____“_
  • Not related to UI, clear lanugage, valuable, estimatable, testable (acceptance criteria)
  • Details are determined through dicussion with the product owner

Part 6: Ceremonies

Ceremonies refer to acitivies that help keep our team on track.

• Sprint Planning

  • Team selects items from the product backlog they can commit to completing this sprint
  • Sprint backlog is created
  • Tasks are id’d and each is estimated collaboratively
  • High-level design is considered

• Daily Scrum

  • Daily, 15-min, stand-up
  • What did you do yesterday? What will you do today? Blockers?
  • Not for problem solving
  • Everyone is invited but only team members, scrum master, and product owner can speak
  • Avoids unnecessary meetings

• Sprint Review

  • Presents what is accomplished (demo of features or architecture)
  • Informal (2-hour prep time rules, no slides)
  • Whole team participates and anyone can join

• Sprint Retro

  • Periodically take a look at what is and is not working - this is where we focus on improving our team’s unique agile process.
  • 15 - 30 min
  • Start doing? Stop doing? Continue doing?
  • Done after every sprint
  • Whole team participates

Part 7: Steps

In general when we get a new project we will flow through the following steps,

1. Identify user roles

2. For each user role, what is the goal(s) the user has for interacting with your system. These goals serve as high level stories we can break down

3. Estimate user stories

4. See Wideband Delphi Estimation Method

5. Estimate project velocity (num of story point dev/iteration)

6. Initial Value: use historical values, run an iteration, take a guess (1/2 - 1/3 of dev-days in an iteration)

7. Prioritize stories

   • Desirability of feature to broad user base and important users
   • Cohesiveness of story in relation to other stories (zoom out & zoom in)

8. Allocate stories to iterations

9. Sprint!

10. Update the plan as you go (Burn down chart)

Part 7: Retrospective

Hopefully we now have a better understanding of the what, why, and how’s of Agile software development. It’s a toolbox of roles, artifacts, and ceremonies all wrapped up in core values/principals. And like any toolbox, we choose what we use and how we use it to solve our problem.