Intro to Agile development for Lean Startup practitioners

Lombaugh: “What do you think?”

Parker : “I think a plan is just a list of things that don’t happen.”

- The Way of the Gun

“In preparing for battle I have always found that plans are useless, but planning is indispensable.”

- Dwight D. Eisenhower

 Photo Courtesy of gadl (Alexandre Duret-Lutz) on Flickr

Photo Courtesy of gadl (Alexandre Duret-Lutz) on Flickr

These quotes explain exactly why I think Agile Software development is one of the best ways to develop modern software and here’s why: You may think you have all the answers, but things constantly change. That is the core of Agile, to be agile in your thinking and approach to developing your product. You may plan out every feature you’re going to add for the next year (or two or three), and it’s important to do this, but be prepared to abandon that plan when things change.

You’ve decided to use the Lean Startup methodology and maybe you’ve actually started validating some of your hypotheses using tests and interviews. You’ve read the Lean Startup book but one thing still sticks out, what the hell is Agile development and why should you care about it?

Intro to Agile

Agile is a set of principles on which to base your software development methodology, whereas Lean Startup pertains to how to run your business and product development. The two can marry quite well together. You can certainly do Lean without Agile (and vice-versa), but putting the two together is like chocolate and peanut butter, they go well together :).

Let’s take a look at the Agile landscape a bit to get a better feel for how you can start using it in your startup.

The Agile Manifesto

The term Agile Software Development comes from The Agile Manifesto, which arose from the pain that developers were feeling (and still feel in a lot of software companies, which I can personally attest to) from traditional waterfall development methods.

To truly understand Agile then we need to look at the reasons why it came about first. Here’s traditional waterfall development:

  1. Spell out all the requirements up front.
  2. Design the entire system as it fits the requirements and estimate it so that management knows how long it will take to get the software they want.
  3. Implement said software to specifications.

What ends up happening, though, is that waterfall projects:

  • Meet specifications, but it doesn’t really do what the customer wants (i.e., they wrote the specification based on what they said and didn’t actually watch the customer use their software or drill down into why they wanted X feature)
  • Get behind schedule because the estimates were way off
  • Are full of bugs by the time they get released to QA
  • Are missing key features because the team ran out of time to implement everything and needed to deliver by a specific time

All of these reasons and more are why developers decided to try and find a better way to deliver quality software to their customers.

Through trial and error, a group of developers developed Agile and came up with a set of guiding principles:

  • Satisfy the customer through early and continuous delivery of valuable software
  • Welcome changing requirements
  • Deliver working software frequently (not at the end of the project)
  • Business people and developers must work together daily throughout the project
  • Build project teams around motivated individuals
  • The most efficient and effective method of communication is face-to-face conversation (as opposed to email, video chat, etc.)
  • Working software is the primary measure of progress
  • Agile processes promote sustainable development (i.e., the software is easy to maintain and grow)
  • The sponsors, developers, and users should be able to maintain a constant pace indefinitely (i.e., not be put on a death march to deliver software by a specific date)
  • Continuous attention to technical excellence and good design enhances agility
  • Simplicity–the art of maximizing the amount of work not done–is essential
  • The best architectures, requirements, and designs emerge from self-organizing teams
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

As I stated above, this is a set of principles but not a concrete implementation. As such, there are several methodologies that can be called Agile. Chief among them are:

  • XP (Extreme Programming)
  • Scrum
  • Kanban
  • Lean Software Development

These methodologies aren’t necessarily exclusive from one another. You can use Scrum with XP, you can take principles of XP and use them with Kanban. In future articles we’ll take a closer look at some of these (and a lot of the nuts and bolts, like Test Driven Development, Behavior Driven Development, etc.).

Release Cycle

OK, now that we’ve looked at the high-level, how do you actually use Agile with Lean Startup?

First, we have a release cycle. This is where you decide how frequently you’re going to do releases for your customers. (I’ll discuss defining your software lifecycle in a future article.) In short, you have a few options:

  • 2 – 4 weeks (traditional release cycle)
  • Continuous (you’re releasing new features whenever you finish them)

I wouldn’t go any longer than 4 weeks, as by that time you’re going too far out to deliver something the customer wants. It shouldn’t take that long to develop a feature or set of features to test. If it does, then you should simplify to deliver something of value to them first, then iterate on it and build on it.

Continuous delivery brings its own set of issues that we’ll cover in software lifecycle article.

User Stories

Now that we’ve decided on a release cycle, the next big step is to define what to build exactly; that’s where User Stories come in.

A User Story captures what a typical user will need to do as part of their interaction with your product. For Lean Startup practitioners, these typically come from direct interviews with users (or potential users). The key here is not to take a User Story directly from them but to get to the core of the problem they’re having and figure out what you will need to do to solve that problem.

Each User Story can be characterized like so:

“As a [role] I can [function] so that [rationale].”

A User Story should be expressible in just a few sentences and easily understood. It’s key to remember that the story doesn’t spell out how a developer implements it, only what the user should be able to do functionally with the application.

User Stories can typically be accompanied by mockups or workflows that the product owner has come up with to illustrate more details. On most Agile teams, you take these stories and give them a high-level estimate like XS, S, M, L, XL, or XXL. These estimates are then used to determine what a given team can take on for a specific release.

If there is a particular story that is extremely high-value to the customer (but also determined to be XL or XXL), then you want to see if you can reduce the story’s complexity so that you can deliver something quickly and then iterate on it.

As developers, our job is to take a given User Story and break it down into a concrete implementation. These tasks are then estimated as part of the planning session.

Time to actually get some stuff done!

Baking the Cake

  • Define and estimate what features you want to deliver to your customer in that cycle
  • If you commit to doing that work, make sure you have enough developers and/or time to deliver those features they’re tested and functional
  • Trust your development team to deliver on what they committed to (i.e., don’t micromanage them, and let them decide what the best way to implement a particular feature is)
  • Don’t interrupt the delivery of a release (remember these are 2 – 4 week cycles) to have them work on something unless:
    • It’s preventing customers from doing something that was already delivered and it has prime business importance
    • A previous delivered feature is deemed incomplete and needs additional work

Additional ways that Agile and Lean fit together well:

  • When you’re working with your customers, you are trying to understand what problem they have (and you’re coming up with the solution to that problem).
  • The problem you’re trying to solve has a set of hypotheses you will need to test, and each of these should have a priority (in a business sense) and you should use these priorities to estimate and commit to delivery (if development is required to test those hypotheses)
  • Each release should be focused on what you’re testing currently and using the results of the last tests so that you can re-prioritize as needed
  • Release retrospectives can be used to review the deliverables to make sure they meet the User stories defined

Things to think about:

  • Don’t be afraid to throw out code if it isn’t needed any more or no longer satisfies a business requirement
  • At the end of each release be ready to re-prioritize or even throw out previous requirements if they are no longer needed
  • Be flexible
  • Be consistent in your approach

Most of all, be agile! The quickest way to solve a customer’s problem is by iterating through the possible solutions and then implementing them.

What are your biggest hurdles to learning or adopting agile methodologies? Are there any questions you have after reading this?

Posted in Uncategorized.