Agile is... continuous delivery

Agile is... continuous delivery

There's a lot of buzz nowadays about being "Agile." But what does this really mean for software or product development? And what's the point of it?

Deliver early and often

To me, Agile most importantly means continuous delivery. When working on a product (software or otherwise) we want to deliver the product in increments, each with more features than the last. We don't wait for the project to be "done" to deliver, we deliver continuously along the way as we're working.

Why is this so great? Well, early and frequent deliveries of the product enhance customer collaboration and make it easier to respond to change. When the customer can see the product as it develops, they can give feedback and help us build exactly what they want. If something isn't quite right, the sooner we know about it the easier it is to fix. This reduces the risk that we won't build the right product.

Delivering continuously also allows us to demonstrate our progress to the customer. This builds confidence for the customer and shows them that we know what we're doing. Rather than waiting until late in development, the customer gets to see early on that we'll be able to build their product successfully. It also lets the development team showcase the hard work and effort they've put in.

Integrate sooner

This sort of development approach is particularly useful at Syncroness where we usually work on products involving multiple engineering disciplines. Because of our diverse group of engineers, many of our development efforts involve mechanical, electronic hardware and software components. You can't wait until the end of the project to put all these pieces together… or it will be a disaster!

You need to get all of your components -- from all of your different engineering disciplines -- working together as soon as possible. A favorite question I've learned is "how can we integrate this sooner?" Any time we delay integration, we're taking on risk that might need to be paid for later.

This continuous integration is possible when each of your components is being continuously and incrementally delivered to the customer -- and within team. For example, you could connect the latest software build up to the latest hardware prototype and make sure everything works like it should. Or, you could install that new mechanical assembly and make sure it gives you the right tactile feedback.

Plan the work right

Sounds great, right? So how might you need to change your thinking if you're trying this approach? Well, in order to make continuous delivery possible you need to partition and plan your work correctly.

Each time you deliver, you want to be able to show the product improving in some way. This means you want to break down the work of creating the product into tasks that can be completed and demonstrated. This requires defining these tasks so that we 1) know when they're done and 2) they implement something we can show.

If you're doing a lot of "work" but you don't have anything to show to the customer, delivery is going to be pretty difficult. It can be easy to fall into this trap, but this is a sign that maybe you need to plan things a little differently.

Your customer isn't likely to care about all the work going on under the hood. What your customer cares about are features -- things they can touch and poke and feel. How can you break down these big work items into smaller features that you can deliver?

When you start answering this question you'll make it easier to show real progress, get real feedback, and make the customer happier.

 

 

Why not build your own engineering team?

Why not build your own engineering team?

Syncroness at Denver Startup Week

Syncroness at Denver Startup Week