Have you ever met with your development team, explained exactly what you wanted, and thought everyone was on the same page? Then the team “goes dark” for three, six, or twelve months. And when they come out of hiding, the app they produce is nothing like you expected? More importantly, it’s not what you – and the business – wanted.
Remember the frustration? Remember the wasted time? Maybe you’re fortunate enough that you’ve avoided it so far… but it’s pretty easy to imagine, isn’t it?
Whether you’re working with a contracted team or your own internal developers, this can – and does – happen. I call this a “fundamental disconnect” between your business and engineering types. And when your software processes don’t account for this disconnect, the situation above is far more likely to occur.
So how do you avoid this problem? How do you make sure that the mobile app you receive is the mobile app you wanted?
In this article, I’ll share several of the tactics Ascendle uses to safeguard us from delivering mobile apps our clients don’t want. By following these tactics, you, too, can ensure your business ends up with software it wants and can use… without all the headaches and disappointments.
Use Accurate Estimates from the Professionals Doing the Actual Work
One huge advantage of Scrum development is that your estimates are built by the people doing the actual work. That represents a resounding shift from the old school days – when engineers were told what to build, how to build it, and when they needed to have it done. Estimates created like that proved inaccurate most of the time.
But with Scrum-based estimates, there are whole new levels of reliability – and accountability – in play. For a deeper discussion of why Agile estimating works and how to do it, check out our video Always Ship on Time.
Make Sure Each Production Sprint Produces a Shippable Product
There are several important reasons why each of your production sprints should result in a shippable product. At least two of these have to do with making sure your business team ends up with the mobile app it really wants.
- Each shippable feature, demonstrated to the business team at the end of each sprint, shows the progress being made as well as the direction headed. This gives business owners confidence in the project team and provides many windows of opportunity for them to adjust any priorities as needed.
- When you prioritize your features in the product backlog before each sprint, only those the business really wants will make it into development. This ensures the project team focuses on and delivers those features that are deemed important to the business and provide the best returns.
Allow Short Production Sprints for Maximum Results
Production sprints are meant to be completed in short periods of time. At Ascendle, we recommend sticking with two-week sprints as the ideal length. Despite this, some companies are tempted to engage in longer sprints rather than shorter ones. There are a couple of reasons for this. One is when they find it difficult to break up their user stories (features) into small enough pieces for a sprint. Another is when they’re trying to limit what they view as “non-productive” time spent planning and reviewing each sprint.
Avoid this temptation!
If your team is struggling with breaking user stories into small enough pieces, our article on Splitting Epics and User Stories should provide some much needed perspective. If you find that the team is always running out of time, then our blog The Sprint’s Almost Over and the Team is Sitting on Their Hands may help troubleshoot some underlying issues.
Reassess Priorities After Each Sprint
One of Scrum’s critical advantages is the flexibility to change your focus at any time. Sometimes an industry event – or the activity of a competitor – can cause your business priorities to shift. When this happens, you’re no farther than your next sprint from acting on that information. That’s no more than two to four weeks (depending on how long your current sprint is and how far along they are).
The shorter your sprints are, the faster you can respond to changing business priorities and needs. And because it is just part of the process, your development team won’t even be stressed out by these changes in direction.
Scrum is the Best Way to Develop the Mobile App You Want
As you can see, Scrum is a key enabler for many of these methods. In fact, one of the main reasons Scrum was created with so much flexibility was to ensure that more software would match the actual needs of businesses. The fact that it can often do so in less time and with less cost is like icing on the cake.
Plus, the shorter sprint cycles in Scrum means your business should be seeing real progress every two weeks. No more development teams disappearing for six months. No more developing unwanted (or easy) features first. No more building off a priority list that’s months out of date.
So if your development team is using Scrum the way it’s supposed to be used, odds are you’ll be shouting, “YES!” when they deliver that app.
Otherwise, you could be muttering, “Damn it!”
And then go looking for a development team that uses Scrum.
