.jpg)
This week, Tom (TH) interviews Ron Siven (RS), a Help/Systems Development Manager, to discuss the agile software development model that Help/Systems now uses.
TH: Ron, tell us a little bit about your background at Help/Systems.
RS: Well, I’ve been with Help/Systems for almost 16 years, and I’ve been a Software Development Manager for six years. When I first started, before I moved to Development, I maintained software. After that, I worked on the very first version of Robot/SPACE, and several versions of Robot/NETWORK, Robot/SCHEDULE, and others.
TH: So, what’s changed in development over the years?
RS: When I first started, we used what’s called the “waterfall” model for development. It’s analogous to a cascading waterfall, where as each part of the project completes, it spreads and drops to the next level. First, developers work with others to define a feature list and then they create design documentation and screen layouts. After those are reviewed and approved, the developers start coding. When coding is complete, the project “cascades” to testing, support, and documentation. One problem is, if one part is stalled or running behind, the others must wait. In those days, the process was reasonably fast because everybody knew the technology. But, over the years, we started using more complex technologies. Now, it can take a lot more time to develop software, especially prototypes, screen layouts, and design documents.
To streamline the process, we moved to an “agile development” model. We actually use a version that incorporates scrums. This model allows the Development team to change directions quickly, based on changes in market demand or user preference. When we first discuss requirements, it’s very high-level and we break things down as we move along: we divide the project into releases and the releases into iterations. An iteration lasts two to four weeks, and during each iteration we try to accomplish a certain number of tasks.
TH: So, what’s your role as manager and what does scrum mean?
RS: I’ll start with scrum first. The word ‘scrum’ is actually a Rugby term that means ‘fresh start.’ Scrums are a short, daily status meeting where team members explain what and how they’re doing, and indicate whether anything is blocking their progress. To allow the team to self-manage on a day-to-day basis, managers do not attend scrums. We stay out of daily work to encourage team members to help each other. Instead, we manage the overall direction of the project. We know the direction we’re going with each iteration and what’s in each release, and we have a project administrator who attends scrums and reports any major issues.
TH: Can you describe the process and is it new or unique to Help/Systems?
RS: At the beginning of a project, we have a large feature list and we prioritize the features. After they’re reviewed and approved by management, we break out various tasks and estimate the work required for each. Next, we get a group of people from the team to play what we call “Planning Poker”. Using a special set of playing cards, we talk about a task briefly and then everybody votes on how much effort the task requires. Based on the results, we assign every task a point value. When we’re done, we have a list of tasks, each with an assigned point value, and a total number of points for the project.
During an iteration, we can measure our velocity by comparing the number of points that we accomplished against the amount of time the iteration required. Typically, with the waterfall methodology, you have fixed features and fluid time (the deadline is always moving out). But, for really good time estimates, you actually want the opposite: a fixed time and a fluid feature list.
Agile Development is not new. In fact, it’s becoming more and more common in the industry. During an agile-based project, we use our current velocity to estimate how long it will take to complete an iteration. At each release checkpoint, we know that we’re going to have a certain number of features available. As we proceed, we send the latest portion of the product for testing and documentation. That way, the testers and documenters keep up with the project. We can design, code, test, and document at the same time because the testers and documenters are usually only one iteration behind the developers. And, at any release checkpoint, we can decide whether the product is ready for release and we can “cap” the project.
TH: Have any products from Help/Systems gone through this process?
RS: Yes, Robot/SCHEDULE Enterprise, Robot/CONSOLE 5, Robot/SCHEDULE Enterprise Multi-Platform (V2), and SEQUEL ViewPoint 10.
TH: What are the benefits for the customer?
RS: Because we’re a lot more flexible, we can produce quality software faster. If something is going to take longer than anticipated, we can make room for it and start cutting lower priority features sooner. That’s one of the reasons we prioritize the features—so that we finish the highest priorities first.
TH: Is Java the new standard?
RS: Well, we are using Java and a lot of different Web technologies. Java is now the most heavily used programming language in the world and we’ve learned a lot about it over the past decade. It’s a great language: multi-platform, object oriented, well established, stable, and strong, with a lot of functionality and documentation. For the most part, we’re not doing any new green screen products. We’re doing Java interfaces and a lot of our backup processes are in Java. When you deal with dynamic technologies, things change constantly and there’s always a lot to learn. Product development is both a science and an art. And, with agile development, we can keep up with new technologies and produce higher quality products faster.