Agile Manifestations

Agility is Not Enough: Beyond the Manifesto, written by Forbes columnist Steve Denning, challenges those “still living within the confines of the Agile Manifesto” to consider Agile in the context of today’s business world. Customer delight is the new bottom line for business, according to Denning, and Agile methods must evolve if they are to embrace this new reality.

What’s fascinating about this article is not the so much content, but the conversation that ensues. In the comments section, reader Kevin Ross puts up both a spirited defense of the manifesto and a thoughtful, reasoned challenge to Denning assertions. Denning, to his credit, takes Ross’ respectful criticism and responds in a second post, Agile Part 2: Can the Manifesto be Defended as well as a third, where The Conversation Continues.

Despite arguments regarding the need to update a decade-old declaration of policy and principles, Agile methods are constantly being tailored to meet new demands. For example, in A Practical Way to do Agile in an Enterprise ALM Environment, (CM Journal, Volume 9 - No. 7 - July, 2011), PTC’s Harsh Sabikhi describes approaches his clients have taken to tailor Agile methods in the face of regulatory compliance and quality assurance mandates.

As software becomes a more critical component in product development, Agile methods are naturally gaining traction in this space. While the trend has been evident for years, we have reached an inflection point where rapid innovation and product differentiation relies increasingly on the software, rather than the electrical or mechanical, aspects of a product. In the product development environment, software alone is not considered the final deliverable, rather it is an integral aspect of the final deliverable. Is “working software” a sufficient iteration objective or must we incorporate physical and electro-mechanical system aspects in order to provide value? If so, how do we reconcile the different paces of change in the software and hardware aspects of the system?

This is not to say that the physical and electro-mechanical aspects of a product don’t provide opportunities for innovation and differentiation. They can and they certainly do. However, these aspects of the system are relatively well understood and suited for predictive design and manufacturing processes. The software aspect, as we have observed, is extremely malleable, relatively poorly understood, and better suited for empirical and adaptive development processes.

Product development, especially in the context of variant management and product lines, presents an entirely new set of challenges and opportunities as Agile methods manifest themselves in traditionally predictive environments. The Agile Manifesto may be a guiding light, but it is not meant to be a prescriptive solution. Tailored solutions will emerge as organizations on the forefront of product development apply Agile principles and best practices to a proven and pragmatic product development framework.

---

Leveraging Agile in an ALM World

By John Hennessy, Customer Solutions Director, MKS Inc.

A common perception is that going Agile is the panacea for large project failings. Agile sounds wonderful. It makes perfect sense, right? "Shorter cycles giving rapid feedback and faster time to market", "Constant re-prioritization allowing agility as business priorities change", "Deliver highest value items first, with actual working software" and of course happy smiling programmers. Utopia!

However, as you press for change within the enterprise, the reality of resistance to change sinks in.

The version of 'Scrum but' you hear is, "We would love to do SCRUM, but we don’t have executive support..", "But the timing is wrong..", "But our clients gave us their "approved" requirements documents", "But we need electronic signature support..", "But the processes are validated..", "But we must follow the approved SDLC.." etc.

Where do you start? You can't change everything overnight. Leverage what's working well such as the real-time visibility, traceability, impact analysis and enterprise metrics from ALM (Application Lifecycle Management) and don't try to change everything at once.

Development teams wishing to do SCRUM can easily work within your existing ALM framework by taking the enterprise-level requirements and creating user stories from these, to form product backlogs for the Agile teams, while teams not doing SCRUM can continue with business as usual on their parts of the projects.

Having taken Jeff Sutherland's Certified Scrum Master course, I found his "ScrumBut test" or "Nokia test" very interesting. It became clear to me that Agile teams can score very well in this test working within existing enterprise frameworks without changing everything.

The Nokia Test (Are you doing SCRUM?)

1. Do you have fixed iterations 4-6 weeks in length?
2. Have you working software at the end of the iteration?
3. Have you good user stories tracing to specifications?
4. Are you testing during your sprint?
5. Have you a Product Owner who motivates the Team?
6. Is the Product Owner’s Product backlog prioritized by business value and estimated accurately by the Team based on Planning Poker?
7. Do you have burndown charts and does the team know its velocity?
8. Are the teams self organizing and allowed to work without interruption?

By starting with a product backlog of user stories generated from and traced back to the projects requirements, you get the best of both worlds. The enterprise cohesiveness of ALM remains intact and the development teams become more productive with increased agility.

If you want to know how an Agile ALM solution can support an organizational Agile transformation watch this ADTMag.com Supercast. MKS is a recognized leader in Agile for the enterprise; if you’d like to learn more click here to see a video of the Agile Solution Overview.

Please send your comments and let me know your thoughts on working with Agile in an ALM framework.

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.