Problems and Processes for Agile Software Development

Can you sense when a storm is coming?

We’re not talking about being the kind of person who chases tornados or follows Jim Cantore’s travel plans. We’re talking about the kind of storm that wreaks havoc in your business.

Unfortunately, software far too often becomes the source of storms for business. And often, the best way to sense that a storm is coming is through the language that’s used.

In our most recent post, we talked about 5 things your developer should never say to you. This is just the tip of the iceberg when it comes to language gaps between business leaders and software developers.

Mike Acton recently took the discussion to another level in an article published by Seth Godin’s It’s Your Turn blog. (Note: There’s a bit of crass language in the story.) In the post, Acton shares a wealth of questions that business leaders should ask developers, and some real-world interpretations of developer-speak.

Acton’s story prompted quite a bit of discussion within our team. Here are some the key points of discussion, and some insight into how we seek to avoid these stormy problems in our work for our clients.

The Trap of Interesting

Acton said, “A trap a lot of technical people can fall into is wanting to create something simply because it’s interesting, not because it’s actually useful in any way.” Action said this while explaining the importance of ensuring that developers think of users first and foremost in everything they build. That’s true, but it’s only a starting point.

Our lead developer, Robert Roskam, made a good point. He said, “I’d delete the word technical. This is true of all people involved on a project. The technical people want to make a library. The design people will want to make neat little widgets. The business people will want all sorts of fancy graphs.”

The point is that everyone involved in a project needs to stay focused on the big goals—what users want, and what improves the business. If anyone along the way loses sight of these goals, the project will flounder or even fail.

This is an area that we are continually working to improve at Worthwhile. We document what users will need, and what the business value of the software we’re building should be. Our strategists and account specialists test with these things in mind, to ensure that every part of the software meets these user and ROI goals—instead of just trying to be interesting.

The 80/50 Rule

Acton contends that if a developer or development team is not 80% done with a project at the point when it has used 50% of its allotted time or budget, then you are behind. This rule points to the fact that it takes significant time refining and polishing a product.

The truth is, you need a good idea about where you are far before your budget is half gone. The reason is that it’s far too easy for designers, developers, and even testers to fall down a rabbit hole on minor pieces of a system and lose sight of the larger user and business goals for the system—which goes back to the interesting trap above.

So how do you do this? At Worthwhile, we divide up projects into milestones and tasks, and track how we’re doing with milestones and tasks against the plan. This gives us early visibility. Then, we test every milestone internally and let our clients do the same, so we ensure that the pieces will actually work in real life along the way instead of all at the end.

This doesn’t prevent the fact that the final polish still takes time, but it does distribute that time throughout the project more, which allows us to provide timeline certainty to clients. That’s something that many developers fail to deliver on, and something we have to be intentional about every day in order to serve our clients well.

Reading Between the Lines

My summary of Acton's article was this: Don’t let your software developer just be agile. Make them have an actual plan—even if it’s an agile plan.

Agile is a buzzword in the development community, and it’s easy to see why. Agile lets developers figure things out as they go along, which can often lead to a better end result.

But agile takes discipline. Without it, projects stall by adding unnecessary features and scope, or constantly changing directions, or running over timelines.

I’m not telling you to either embrace agile, or to reject it. But I would tell you that agile requires established processes. For us, process means doing a lot of planning on the front end, and then using more agile methodology as the project goes on.

That doesn’t have to be your process—but you need to establish and follow a process.

Otherwise you’ll be hearing more and more of the things that your developer should never say—and you may need to engage your detector to translate.

From experience, we can tell you that the kinds of processes we have described have kept Jim Cantore from knocking on our door. We hope that they will help you do the same.

About Worthwhile Storyteller

We'll never tell you a lie, but we might tell you a success story that protects the intellectual property of our clients and partners. Our Worthwhile Storyteller is an amalgamation of all of our thoughts, experience, and expertise brought together to give you the facts about our relentless improvement in the software development space.