How Ixia and Apple prove scrum works
It was by using the scrum approach, also known as agile, to product management. As an old process guy at IBM I was fascinated about what appeared to be a far better approach to product creation. What makes it better is the entire development unit works together as a team and the product owner has the role of proxy for the customer, something that I saw Steve Jobs do at Apple to great success.
[ Related: 7 agile certifications to take your career to the next level ]
I should mention that it is working fantastically at Ixia: It leads its segment, its stock is trading up sharply since Mayer joined, and growth has moved into double digits. Ixia makes network testing gear and one of the leading network security offerings, ThreatArmour, in the market.
[ Related: Scrum’s co-creator talks about the framework’s transformational effect ]
Let’s talk about Scrum method of agile product development this week.
The most common method for product development for large companies is called the waterfall method (which goes back to 1956), because the product falls through a series of set steps in order to make it to market. The product owner defines the product in terms of features and functions in a series of seemingly endless meetings. This effort is then resourced by development, which sets a timeline (typically 18 to 24 months to completion). This process is defined by more long meetings on progress, the timeline is seldom met, the product is created and then it is sent over to QA to make sure it works.
Any problems are identified in more long meetings. These problems are fixed by development, QA signs off, the product is sent to customers for beta testing, more meetings on identified problems some of which are fixed, deadlines force the product out often incomplete with known problems. These problems are identified by upset customers, the product is patched, a maintenance release of the product is created, and anywhere from three months to a year after the product is released late and the offering is actually in good enough shape to deploy even though it may have missed the core customer requirements by leagues.
[ Related: Comparing scaling agile frameworks ]
The worst instance I’d ever experienced was when I was in product marketing and a manager sat at my desk and told me I needed to develop a marketing plan for the product. I asked him who the customer was and he said, and I’m not kidding, “I don’t know the guy’s name.” I refused the product and they gave it to another marketing manager who did a $20K study and found there was no one who was interested in it.
I’m pretty sure this isn’t far from how we create movies either, which would explain how so many come out that are almost painful to watch.
This apparently came out of research in the 1980s by Hirotaka Takeuchi and Ikujiro Nonaka documented in the Harvard Business Review. This is a team approach to product development and the name scrum comes from rugby and the product is the ball passed constantly between team members.
In this process QA and product development are interrelated. The product takes as long as it takes to get done, which often is a fraction of the time compared to the old process, and the product owner is a proxy for the customer and recognizing that not only must the requirements be well grounded they may change during the development period. Each phase of the product is checked both to make sure it is bug free and to make sure it is on target while the target itself is constantly checked to see if it moved.
This is also referred to as a process of fast failure where, designed in is the recognition that the product will be off-track and the constant need to retarget because the customer in changing. The authors compare the old process to a relay race where the product is the baton handed to each successive runner but, often, none of them know where the hell the finish line is. The scrum process is the product is born from team interplay which moves to iterative experimentation flowing into the development process concluding with a product.
This process is far more dynamic, and the engineers love it because they have a far better sense of where they are going and it doesn’t pit groups against each other, and, apparently given it is more like a team sport, it is a ton more fun. Another difference is that the development group isn’t pounded on by management. It is mentored by management, which is a ton more fun for managers.
I’ve been looking at the Apple development process for some time and trying to figure out why more companies didn’t follow it given how successful it has recently proven to be. It is very similar to the scrum process I’ve been talking about, and while it clearly puts a lot of pressure on folks the end result is better and, overall, the people on the project seem to generally have more fun. Better products, happier employees, and the most powerful technology company in the world and yet Apple and Ixia are still the exception and not the rule. Explain that one to me.