From Technical Competence to Technical Excellence

This past Tuesday at the Communitech Agile P2P session, Kevin Tureski from Kevin Tureski Consulting, held a very engaging discussion about his past experience at Alias during their transition to Agile. It is unfortunate that there was no time for questions at the end, but the stories were all riveting.

Prior to its adoption of agile, Alias faced some problems that most of us can recognize with. While their product, Maya (and its predecessor PowerAnimator) was extremely powerful and capable, Alias found they were biting more than they could chew. Consequently, they were "killing" their teams to deliver on the promises made. Maya's functionality was also limited as the cycles to add more capability were simply not available. Then there was the "feature freeze convergence hell"; modules were developed independently and worked very well standalone but collapsed when integrated together. "Big fix death matches" were not infrequent, release dates sometimes slipped and inter-team communication was poor.

The initiative to move to Agile came from the R&D leadership who realized they were in hot water; they knew they were getting things out the door but that their productivity was not sustainable as their workforce was collapsing under the pressure to deliver. There was also the need to improve ability to react to the market and agile practices offered this flexibility.

The move to agile began with professional consulting to analyze the current processes and suggest viable improvement plans. Anyone that had anything to do with the product was trained on Agile. This training took about a year to complete. Kevin Tate, who was then Chief Product Architect at Alias, went on to write "Sustainable Software Development" which discusses the principles that will create software that is maintainable and sustainable. These principles include:

• A working product that is shippable in a short period of time
• Emphasis on design, not by doing up-front large-scale designs but by a continuous refinement of design through regular feedback
• Continuous refinement of the processes in place
• Defect prevention by ruthless testing. This includes testing by developers who are required to ensure their code works as expected before handing it off to QA
  

Alias used standard Agile practices to develop their processes. Some practices, however, were particularly helpful:

• Planning poker was not used a lot, but Alias ensured that effort, time and risk estimates were gathered at every level, from Support to Developer to Architect.
• Abstractions using user stories was very helpful. Product Owners developed personas that might not have made a huge difference in quality but facilitated understanding and communication between teams.
• Iterations were short to avoid feature freeze mess and the iteration length varied by the work done. Alias had major releases roughly once a year. At the beginning of development work, when there was more "heavy-weight lifting", the iterations were longer, about 6 weeks. This duration reduced to 4 weeks when the major pieces were in place and then dropped to about 2 weeks.
• Regression suites were run daily. These were critical in identifying and fixing regressions as soon as they were introduced.
• There was a dedicated room with physical planning boards for all teams. The board included all information that was needed to give an on-looker an update on the team's status, including a printout for burn-down charts. Camera shots were sent to geographically removed team members and their feedback was included into the status by a local team member.
  

The stress on testing and low bug count was resonant throughout Kevin's talk, and to put this into perspective he shared a very inspiring story about SketchBookPro which was targeted primarily for tablet pcs. In its adoption of agile, the SketchBookPro team members were co-located such that even sales was situated in the same area as the developers, testers and others who worked on SketchBookPro. The bug pile was never allowed to get larger than what could be fixed within a week, and the team invested heavily in automated testing tools.

At the time version 1.0 was released, tablet pcs were not very popular in the North American market. During the development of version 2.0, the sales force found an opportunity in the Japanese market where 100,000 PCs could be pre-packaged with SketchBookPro. The challenge, however, was that version 1.0 was not internationalized. Version 2.0 was fully internationalized but it was still under development. Since the team's bug count was always low, they were able to stabalize version 2.0 is a very short period of time. They then created a branch off the 2.0 version's development path and turned off all the 2.0 features so that it "looked" like version 1.0 with support for internationalization. The team shipped this version to the Japanese market within 6 weeks!

The low-bug count rule also allowed teams to produce much more stable product alphas which were then used to get user feedback. This feedback was much more helpful at the alpha stage than it would have been at the beta stage when most development work is complete and there is not much room for change.

Alias' complete transformation to Agile took about 5 years, but Kevin reiterated that this time investment was well worth it. When asked if there was ever a time during this transformation when people threw up their hands in frustration over being worse-off than they were before, Kevin said he does not recall such a reaction. The improvement in code quality was backed by increased customer satisfaction and a noticeable drop in level 1 critical bugs. Statistics such as these substantiated the cost of reduced pace in delivering new features, and convinced upper management that the investment in moving towards Agile had put Alias on the move from technical competence to technical excellence.