Agile development means staying limber

Feature

Converting a company's development process from the traditional long-wave waterfall method to the more frantic spurts and sprints of Agile methodology will change the organization's culture.  But, according to Ennio Carboni of Ipswitch, a maker of network management software which recently made that transition, it can be a change for the better.

Humility is not an easy lesson for anyone.  And for hotshot product technologists, it is particularly difficult.  Consider the case of Ipswitch, a network software maker in Lexington, Massachusetts. 

Two years ago, in response to emerging customer needs and a surge of new entries into the network monitoring market, Ipswitch realized it had to pick up the pace of its product development strategy.  Although the company's software had been widely regarded as among the best and easiest to use, the game had changed.  Overseas companies had started to become serious price competitors.  And a number of domestic startup firms, armed with marketing tactics fortified by strong venture funding, had also aggressively entered its space.  As a result, unless the company could deliver its products to new and frequently inexperienced customers in ways that would work right the first time, Ipswitch's managers knew their market edge risked being lost for good. 

Waterfall Development

From its start in 1990 until 2005, the privately-held company had used the Waterfall method for planning and developing its three product lines - software to manage email, managed file transfer, and network monitoring.  Waterfall methodology is an approach that sees development flowing methodically and sequentially, over time, through a series of phases until final release.  But the sequence can be a long one, often involving a year or more.  And in a fast-moving market, that simply isn't good enough, according to Ipswitch Product Management Director Ennio Carboni.

"We found that building a plan and allowing our Development folks to go at it for a year and then releasing it to the market was just not competitively strong enough," he said.  "We would miss opportunities; we might go down the wrong path.  So we wanted to implement a system that would bring us closer to the customers and their pain points, closer to the people who use and buy our software daily."  

That was when the company decided to implement the Agile development methodology.  "The way we use Agile is that every 30 days we have what's called a ‘sprint.' " Carboni explained.  "At the sprint, a couple of things occur: first, the development team demos for me everything they've developed over the previous 30 days.  Second, we begin the planning for the next 30 days.  And that planning is based on the priority order I've set so that in the coming 30 days they'll build whatever I prioritize as my top one, two or three requirements - which sometimes include priorities I've revised based on deal opportunities."

Closer to Customers

The switch quickly transformed the company's relationship to its customers.  And it has already paid off in several ways.  "In February, I went to Europe with two of my developers to conduct training for our reseller channel," Carboni recalled.  "When we were there, we learned there were two to three product characteristics that were not optimally engineered for the customers they were selling to.  So we were able to come back and start the next sprint the following week.  We re-prioritized that sprint to address the issues we had just heard; we saw it as an opportunity to make our Agile process really work for customers.  It was a small but important pain point they wanted relieved, and we were able to get that fixed in 30 days; otherwise it would have been a year before we could even address the issue."

Europe was not an isolated case.  The Agile method has required Carboni and his development staff to maintain greater contact with customers everywhere.  And the results have put company technologists into much closer touch with the end users of their products. 

"It's become a very humbling and productive experience for my developers and for me," Carboni noted.  "Developers, by nature, are bright, self-sufficient people and they start to get the idea that they're Super-developers when they sit in an office for too long.  They start to build their own universe and believe their path is the right one.  It's a very humbling experience when you get in front of a customer - who is also, by the way, invited to those 30-day demos - and you hear the customer say ‘hey, that looks good, but I wouldn't use it that way; I'd rather do it this way.'  That kind of interaction has been a great advantage for the company, because now my lead developers rely on customer feedback.  So instead of saying ‘here's the way they'll use it,' they ask: is this a good way to engineer the product based on what we're seeing from our customers?"   

Winning Them Over

Clients love it.  "Our customers are really energized because they have a lot more involvement throughout the year," Carboni said.  "It's not like they sit in a beta program and either ratify what you've done for 12 months or keep quiet on the phone.  These folks are very vocal.  We do on-site visits, we do phone calls, we do Webexes - whatever it takes to get direct feedback.  And I can make moves every 30 days, which keeps me very competitive in this marketplace and allows me to be opportunistic.  That also allows me to deliver news about upcoming products right to the front lines, where Sales can use it." 

Now, two years after introducing the Agile method, the Ipswitch developers love it, too.  But that wasn't always the case.  "At the beginning, we probably had 80 percent skepticism; today I'd say we have probably less than 10 percent skepticism," Carboni observed. "At first they were obsessed about the possibility that they might not be able to work on the things they wanted to work on.  That's important because at the end of the day, the developers are the ones building the product.  And if they decide to make some change, or tweak the software in a certain way, it's not going to be known until very late in the process.  So you need to be very respectful of your peers in development.  This isn't a domineering game.  I want to make them partners in the business and not be this ruling force, because that just doesn't work." 

No Hiding

But as Ipswitch's developers gained experience in the new methodology, their concerns dissipated.  "What we found is that they could still work on those areas of the application they enjoyed, and it actually diversified their skill sets because in these short sprints, they were doing a lot more cross-training.  One might be helping out with the QA; one might be helping out with the Web interface that he or she might not normally do in a waterfall process.  So it really helps them increase their interest and knowledge in the overall product and process," he said. 

Nor are the company's 30-day sprints limited to its development staff.  Indeed, according to Carboni, limiting the Agile method to just one area of company operations would be an invitation to failure.  "We've done a total Agile methodology implementation," he pointed out.  "Not only do we run the development side in these 30 days, we also run the business side.  Every morning at 9:30 we all get on the phone and talk about what we did yesterday, what we're doing today, and any obstacles that are in the way.  If there are obstacles, people can help out.  But the idea is that there's no hiding; people are either productive or it becomes very visible very quickly because 30 days goes by fast." 

For organizations considering Agile methodology for the first time, Carboni offers this advice:  "The first thing is that you have to have across-the-board management team buy-in.  Culturally, things will change a lot, but they'll change for better productivity.  The next thing you need is a very strong scrum master.  That's a term that comes from the sport of rugby.  The scrum master is responsible for running that morning meeting and for the overall planning schedule.  One of our best was a guy named Adrian, who ran Development like a finely-tuned German car.  He really set all the rules in play and did all the monitoring so that every 30 days the planning sessions went well and we were getting optimal productivity out of everybody."

Of course, it can't work unless your customers are also willing participants.  And at Ipswitch, they were.  "Our customers are passionate about our network monitoring product and excited about getting close to the development operation," he said.  "Our job was to figure out how to take all that passion, know-how, and bias and use it constructively in a roadmap.  But we have a VP of Development who's been a real champion of that process, and she's brought professional Agile trainers in to help train our own cross-functional teams in the Agile method." 

Agile is Flexible

However the company's 30-day development cycle is not carved in stone, Carboni points out.  Other Agile companies often use shorter or longer times, depending on their distinctive needs.  And there's nothing about the Agile method that works against much longer-term planning.  Just the opposite, in fact.  "I believe strongly in Agile as a day-to-day management system for the development of products," Carboni said.  "But that by no means negates the need for an overall roadmap that takes the product out a year or two."

Story Tools Share on LinkedIn Digg This Save to Delicious Email Page Print Page

That longer-range vision is important for several reasons, according to Carboni.  "One is that customers want to know that you have a vision when they invest with you.  And also because your own people need to be excited about where you're headed.  That's how they get up in the morning and come to work and get excited about being able to move you closer to that oasis.  We have a strong product roadmap.  But we also know that it will likely change.  I find it very hard to believe that there's any software company out there today that can say they know for sure what they'll be building for the next 18 months.  Six months out is very realistic.  Twelve months out today is very challenging.  Eighteen months is almost impossible.

"It's a way of looking at the business that says: I want to be more competitive and I want to win in this marketplace because the marketplace itself has become more competitive," he said.  "If I didn't do this, frankly I don't think I could be competitive.  We have, in my opinion, a product that's superior to most of the players out there.  But that doesn't buy you a cup of coffee if you're not getting good end-user experiences.  And the only way to know that is by spending a lot of time with customers to really understand the way they use the product." 

About the Author

Peter Longini is the Managing Editor
for Inside Product Strategy™.

He can be reached at:
editor@productstrategynetwork.com