Read a full transcript of the discussion.
Borland Software has been in the developer productivity field for decades, but when it came time to build out a new software delivery management suite for application lifecycle management, Agile Development methods became both the means and the ends.
Over the past few years, the development process at Borland shifted dramatically to Agile and Scrum practices, which in turn deeply influenced how the new products were crafted and refined. These shifts fundamentally impacted a set of recent new products. [See product and solution rundowns. See demo and see launch video.]
To learn more about Agile Development and how Borland used the methods to build their own software management products and solutions, I recently spoke with Peter Morowski, the senior vice president of research and development at Borland. He described the journey, the productivity and business outcomes benefits, and the potential pitfalls and errors to avoid. He also wrote a great article on the experience.
As part of the podcast, I asked Peter what surprised him most about this Agile journey at Borland. "The thing that surprised me," he said, "is how powerful it is each morning when everybody gets around the table and actually goes through what they've done, basically saying, "Have I lived up to my commitments? What I am committing to the team today? And then is there anything blocking?"
"Generally speaking," said Morowski, "a lot of developers tend to be quiet and not the most social. What this did is that it just didn't allow the few people who were social to have input on what was going on. This daily stand-up had people, everybody on the team, contributing, and it really changed the relationships in the team. It was just a very, very powerful thing."
Here are some excerpts from the discussion:
Look at the late delivery cycles that traditional waterfall methodologies have brought upon us. Products have been delivered and end up on the shelf. The principles behind Agile right now allow teams to deliver on a much more frequent cycle and also to deliver more focused releases.Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Sponsor: Borland Software.
What I have observed over my career was the fact that there really existed two worlds. There is what I call the "management plane," and this is a plane of milestones, of phase transitions and a very orderly process and progress through the software development lifecycle.
Underneath it though, in reality, is a world of chaos. It's a world of rework, a world of discovery, in which the engineers, testers and frontline managers live.
What [Agile] is really about is that teams begin to take ownership for delivering the product. What happens is that, by allowing these teams to become self-directed, they own the schedule for delivery.
Hiring is important, regardless of what methodology you use, and I tend to stress that. I do contend there are different kinds of personalities and skill sets you are going to be looking for when you are building Agile teams, and it's important to highlight those.
It's very important that whoever comes onboard in Agile team is collaborative in nature. In traditional software environments, there are two roles that traditionally you may struggle with, and you have to look at them closely. One is the manager. If a manager is a micromanager-type, that's not going to work in an Agile environment.
What happens is that you see some things like traditional breakdowns of roles, where they are looking at what work needs to be finished in a sprint, versus "Well, I am a developer. I don't do testing," or "I am a doc writer, and I can't contribute on requirements," and those types of things. It really builds a team, which makes it a much more efficient use of resources and processes, and you end up with better results than you do in a traditional methodology.
When Borland first started developing in Agile, we had multiple locations, and each site was, in essence, developing its own culture around Agile. What I found was that we were getting into discussions about whose Agile was more pure and things like that, and so I decided to develop a Borland Agile culture.
As we've grown, and our projects are getting more complex, the fact that we evolve from site-to-site based on the same process and the same terminology has allowed us to now choose more complex Agile techniques like Scrum of Scrums or work across organizations, and have a common vocabulary, and that kind of common way of working.
One thing we clearly did was, once that we saw the benefits of doing this, we had a lot of executive sponsorship around this. I made it one of the goals for the year to expand our use of Agile within the organization, so that teams knew it was safe to go ahead and begin to look at it. In addition, because we had a reference implementation of it, it also gave teams a starting point to begin their experimentation. We also paid for our teams to undergo training and those types of things. We created an environment that encouraged transformation.
Read a full transcript of the discussion.
No comments:
Post a Comment