“Iterative Software Development – It’s a Sprint AND a Marathon” by Kelly Bakst

Agility in sports requires speed and quickness. In software development, being truly agile is a little more difficult to define. We asked Kelly Bakst, who has deep experience as a VP of technology and other executive roles within a variety of tech and media companies, to discuss the value of iterative software development. His tips below provide insight into the enigmatic balance involved in reconciling short term and long term software development goals.

Iterative Software Development – It’s a Sprint AND a Marathon, by Kelly Bakst

Developing web-based software has been an absolute boon to developers.  Remember the days when you had to push out updates, hope everyone installed them, and hope (more like pray) that their local configurations didn’t break anything?  Remember how a tiny bug caused the same headaches as a massive upgrade?  Remember screaming at testers because something made it into a release that went out on CD? Ah, those were the days…

Now we have none of those problems!  Push changes anytime, and everyone gets them at once.  Upgrade a server, and everyone sees the benefit.  Everyone’s data is backed up, and safe, and consistent.  No more problems…none…zero!

Well, ok – one small one.  Ever hear the saying “Do a little more each day, and soon everyone will expect a little more each day”?  Well, that’s where your users are now.  They know that you can push stuff out quickly, so they want more updates.  More frequently, and bigger.  But it’s OK.  Customer engagement is what we want, desperately.  Feedback is like gold in this business – so we’ll take all we can get.  So how does this change the development process?

In short – it has become about speed AND accuracy.  You need to be targeting the right features, and delivering them in a true iterative fashion.  It sounds hard – and it is.  This is why you need to be more organized than ever, therefore:

• Eagerly ask your users to tell you what to work on next. We provide customers with the ability to not only submit bugs and change requests, but to vote on which ones they like most.  That’s the bible for us.  That’s what we work on.
• Bite sized pieces.  You can have a team dedicated to a complete new look or version of the software – but you absolutely need a team dedicated to the changes your users want.  Telling users “We’re working on these 78 features, and they should be out with the new version in 6 months” is just going to frustrate them.  Explain that a big batch of new features are in the pipeline, but that the most important functions are at the top of the list and will be coming really soon.
• Listen. When you roll out changes, the things users hate will be made known to you very quickly.  Be prepared to fix, explain, or roll things back.
• Guide. Try and guide your users to a destination.  Not just where you want them to be, but where they really need to go.

So run fast, pace yourself and drink lots of water 🙂

Kelly Bakst is a technologist who has experience running technology teams and companies in a variety of industries. He can be contacted through his software company, Pi Software or on LinkedIn.