How does Agile help us to do better work for our clients?

To answer that question, I think it’s important to reflect on what makes building a product hard. Here’s a clue: Everything.

There are technical challenges, but those are the least of your worries in practically every case (especially early on). There are product questions: who are you building for? what features do your customers really want? how can we validate our hunches in a meaningful way? what incarnation of those features will be both useful and a delight to use? There’s time pressure. And to add fuel to the fire, the team is made of people. You know… with ideas, egos, personalities and feelings. It’s amazing successful products happen, period.

We wanted a process that’s effortless when it’s working awesome while also giving us signals when something is broken. We’re not interested in process just for process’s sake. It turns out that Agile can help navigate these challenges and gives us pretty clear warning signals.

At the Core

In trying to distill out the most important parts of our Agile process, I came up with my take on the essential ingredients. I’m not saying other aspects aren’t important too, just that these make a strong foundation.

• Small units of work
• Optimize for value
• Iteration
• Product owner involvement
• Feedback
• Honesty and trust

If any one of these is missing or broken, the project has a much higher risk of running into trouble. That doesn’t necessarily mean complete failure, but it does mean the project and overall experience will fall short of its potential.

Small units of work keep the team focused and allow for greater flexibility when planning. We write user stories and every one of them captures single workflow framed from the user’s perspective. A story should be whole, meaning it delivers value to the user on its own. Stories normally take a couple of minutes to a couple of days to deliver. When they’re small it’s easy to move them around and make tactical decisions during planning. It’s also easier to avoid needless yak-shaving when the stories are small.

Small units of work aren’t enough, they must deliver Value. We typically measure value in terms of user-facing functionality. We know that some amount of infrastructure, architecture, meetings, etc needs to happen to build a product. However, that’s not what first draws a customer to a product. It has to solve a customer’s problem. Getting everyone on the same page about value is crucial, otherwise folks may be optimizing for different things.

Software products evolve over time through the addition of new features, the enhancement of existing features, and removal of unused features. It’s inherently Iterative. We start the process of iteration from week one. By the time a product sees its first ray of light, the team has executed the process of planning, designing, building, and deploying many times. The structure of the process is in place and the team has enough experience with it that it can be repeated confidently.

Knowing that there’s always an opportunity to iterate on a feature allows us to build the right-sized version of the feature for where we are in the lifecycle of the product. Not every feature needs to have all of the bells and whistles when it’s born. The time saved can be spent on something that is more valuable.

Every one of our projects has a Product Owner who’s part of the client team. Our goal is to guide and empower the product owner so that they can direct the team’s focus on what’s important. Some product owners are very involved and others minimally so. The low bar of involvement includes two important activities: prioritization of stories and acceptance of the stories once they’re complete. Without these, there’s no one at the helm and the chance that the client isn’t going to be happy with the engagement goes up a ton.

There’s internal and external Feedback. External feedback on the product can be collected via a wide array of techniques. Until ideas are validated by customers, they’re just assumptions. Building features on top of untested assumptions drives up the chance that we’re building a dud. It might be high-quality code with an extensive set of automated tests, but who cares if no one wants to use it. Building a product without integrating external feedback is like betting everything on your first hand of poker when you haven’t yet learned the rules.

Internal feedback comes from the team and improves the process itself. Reflecting on how it’s going and making changes to better suit the reality on the ground is critical to keeping the process a good fit throughout the lifetime of the product. Otherwise, the process starts getting in the way when things are going awesome or it starts failing to give signals when it should.

It should go without saying: Transparency and trust are key to building a team that can overcome the challenges of building a product. If there’s bad news, we want to deliver it early so that we’re in the best position to do something about it and reap the benefits. Without trust, it’s hard to stay psyched about the people with whom you’re working. When every action comes from a place of honesty and your intentions true, trust grows naturally.

Signals

Here are a couple of the common signals that suggest something’s up:

Low velocity – Velocity is the rate at which the team is completing stories that deliver user-facing value. Really low velocity can be a sign that stories are too big, there are inefficiencies in how work gets done, or the team is spending a lot of time on “infrastructure”.

Erratic velocity – Often the result of inconsistent planning. When the backlog is well thought out, things move fast. When the team gets to stories that are poorly written or vetted, productivity grinds to a halt.

Slow acceptance – The product owner isn’t providing the team with the feedback it needs to know it’s doing a good job. Sure, developers move on to the next story, but they may be building on building blocks that miss the mark. It can be a real drag on morale and velocity.

Big bug fix session before a release - Rather than finding and fixing bugs continuously, the team is delivering stories that are buggy. That debt has to be paid down before the software gets into the hands of users. This creates a false sense of velocity which is knocked down periodically before a release.

Others: Running out of stories, stories are frequently blocked, need for big refactors.

The more experience you have the easier it is to pick up on the signals and figure out what to do about them.

What about the Developer Practices?

I’m leaving developer practices out of this conversation deliberately. Testing, continuous integration, pairing, sustained schedule, etc are all second nature for us. There’s enough content there for a another article (or several).

Conclusion

My experience has shown that if the process includes the above components, we’re able to rapidly build valuable features. When something isn’t right and we’re being perceptive, it becomes apparent quickly and we’re able to reflect and make the changes necessary to fix the problem. In the end, Agile lets us welcome feedback that inspires course correction while also making it really hard to overlook issues when they come up.

It’s not in every agile software team’s bag of tricks. Asking around our fairy savvy office, I discovered it’s far from universal. In the “State of Agile” report from Version One, which includes survey results from 2500 software developers, it wasn’t mentioned. Since I haven’t seen it show up that much in other agile writings, I thought I’d share my experiences here.

What is “5 Whys”? I picked up “5 Whys” from the lean software movement, which sprang from Toyota manufacturing. You can read about its history on wikipedia, but it’s pretty simple: at the end of the assembly line, when a widget comes out with a problem, you stop the line and ask “Why?” Whatever the reason, you ask the “Why?” again. Repeat at least 5 times. The goal is to discover the “root cause” of the defect, and fix the root cause, not just some symptom. Wikipedia has a good example around car repair. Here’s a software example:

1. Why did Sheryl say the sign-up flow was broken?
A: Because she was trying to sign up a second time. Duh.
2. Yeah, but why did the flow break if the user is already signed up?
A: It’s a bug. We didn’t have a test case for that.
3. Why didn’t we have a test case for it?
A: I just didn’t think of it.
4. Why didn’t you think about it?
A: The story seemed easy– I guess I didn’t think it through.
5. Why do you think you didn’t think it through?”
A: I guess I was working alone and was in a hurry.
…

Obviously you don’t have ask “Why?” exactly five times, but that does seem to be a pretty good number. The point is you start articulating the behaviors and procedures that cause the problems.

Taking It for a Spin. I’ve come up with exercise for agile software teams. Like I mentioned, when quality drops below your comfort level, give it a try:

1. (2 minutes) Make a list of the most recent bugs you’ve uncovered. I’ve found that the last 10 is usually enough– if not too much. You can put these on a white board, index cards or a wiki page– all will work.
2. (2 minutes) Prioritize them based on the ones you want to talk about. Which caused the most embarrassment or cost? You usually only have energy to talk about 5 or 6 of them.
3. (15 minutes) For each bug, ask “Why did this happen?” Then, probe deeper until you can’t get much further. Write the answers down where everyone can see.
4. (5 minutes) When you’re done with all the bugs (or out of time), circle common root causes.
5. (10 minutes) Brainstorm ways to mitigate or eliminate the root causes. Come of with one or two SMART goals for the team.

Some of the root causes we’ve gotten to recently:

• we didn’t pair on hard features
• we didn’t ask for clarifications on the requirements
• one engineer didn’t understand the intent behind the code
• nobody looked at the app on Internet Explorer 6

Just like in agile reflections, the changes made coming out of these meetings stick with the team. During one session, the developers decided that there were just too many mistakes that someone else would have easily caught– so they always needed two sets of eyes on every checkin. I’d advocated this before, but it was never applied consistently. To my surprise though, after the reflection, everyone was  disciplined about this policy– and our quality was much better.

On those occasions, I supplement my list in Tracker with another technique for capturing user stories. It involves modeling using a UML IDE. Primarily, I use Activity Diagrams because they capture behavior using ‘actions’ and allow for flow. Because activity diagrams are essentially flow charts, they provide a simple comprehension mechanism for all customers regardless of their technical background. I usually display my desktop in the conference room using a projector and interactively add elements to the diagram as I receive customer input. For demonstrating modeling techniques, I will use a ‘Music Store’ web application as an example.

Summary of Steps:

1. Create an Activity Diagram from a High-Level Functional Requirement.
2. Capture Customer Input for Identified Functional Requirement.
3. Model Flow for Activity, Link Actions with Diagram Elements.
4. Aggregate Similar Actions to Separate Activity.
5. Convert Activity Diagram into User Stories.
6. Repeat Steps until all Functional Requirements are Exhausted.

Step 1: Create an Activity Diagram from a High-Level Functional Requirement

Start with a known high-level functional requirement and create an Activity diagram. When starting, I will identify a large chunk of functionality that I know to be required for the project and use that as a discussion point with the audience. For my sample Music Store project, I would choose ‘Browsing the Inventory’ as a large piece of functionality. At this point, the audience might begin to shout out other large pieces of functionality (i.e. ‘Customers can create accounts’, ‘Employees can add to inventory’). If this occurs, I like to create empty Activity diagrams named appropriately. These large pieces of functionality will eventually be decomposed into smaller, more manageable, Activities and Actions.

High-Level Functional Requirement as an Activity

Step 2: Capture Customer Input for Identified Functional Requirement

Gather input from the audience regarding this Activity / functional requirement and capture pertinent information as Actions. Essentially, what you are trying to do here is decompose the larger ‘Browsing the Inventory’ functional requirement into smaller ones. Make an attempt to name each of the Actions with story-like syntax (i.e. ‘As a <role> I can <result> so that <benefit>’). The goal of this step is to create a catalog of smaller functional requirements so that you can start modeling flow.

Capturing Smaller Functional Requirements as Actions

Step 3: Model Flow for Activity, Link Actions with Diagram Elements

Start modeling flow for this Activity, linking Actions with other diagram elements. All Activities must have a start as well as an end point. I model my Activities so that my flow is complete. This ensures that all known paths have been captured. This step is crucial in capturing all known functionality for the high-level requirement.

Remember that this is an interactive step with the audience. The audience / customer will provide input as to the flow of the Activity from Action to Action.

Adding Flow to Activity

Step 4: Aggregate Similar Actions to Separate Activity

If the diagram begins to flow outside of your viewable area, this is an indicator for breaking out one or more actions into a separate Activity. Several actions can be converted into one abstract action that encompasses all the functionality provided by all those actions. In the figure in step 3, the Action ‘Purchase an Item’, was created to represent another Activity diagram. The separate Activity diagram that I created was named ‘Purchasing an Item’ and contains the detailed flow for that functionality.

This step is reliant on the Tech Lead’s skill to identify similar areas of responsibility within the activity. 

Step 5: Convert Activity Diagram into User Stories

After one Activity diagram is fairly complete, begin entering them into Tracker as Stories. Each Action should be converted into a user story using a consistent syntax (i.e. ‘As a <role> I can <result> so that <benefit>’).

Convert Action elements into User Stories

User Story list with Activities as Milestones

 

Step 6: Repeat Steps until all Functional Requirements are Exhausted

Steps 1-5 must be repeated until all high-level functional requirements have been modeled as Activities during discussion. In the end, I will have a catalog of Activity diagrams. In the figure below, a Package Diagram displays all the Activity Diagrams that I have modeled. I like to use each of the Activities as a milestone during planning. This may or may not be ideal depending on how granular your functional requirements are.

Package Diagram: Inventory of Activities as Milestones

 

Conclusion

There are many arguments against modeling in the agile communities, so it is important to view modeling as being supplemental to the process. In the end, our models are used to aid in the process of conveying and gathering information with the customer. Some other benefits include:

• The diagrams can serve as a documentation deliverable
• Interactive modeling along with the diagrams, which serve as a visual aid, improves customer comprehension of our software development process
• This is a great way to capture requirements when none exist
• The Activity diagram allows us to write stories in a format that follows an accompanied wireframe (if available)
• User roles can be added to Activity diagrams as swimlanes (partitions). This aids in separating functionality by use case