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.

Requirements Management in an Agile World - Yes it does make sense!

By Harsh Sabikhi, Certified ScrumMaster, MKS Inc. in collaboration with Doug Akers, Director of Customer Requirements, MKS Inc.

The main benefit of today's Agile development methodologies such as Scrum or XP is the promise of delivering working software in a shorter period of time and the value derived from having the flexibility to adjust which features need to be implemented for the next iteration or release. But does this type of approach allow for requirements management? Or a better question is do we need to manage both requirements and backlog items such as user stories? Or are requirements and user stories analogous? Well -- does the need to deliver what the requirement originally requested go away? Does the desire to control change to the requirement go away? Of course not, and neither does the need for requirements management under these newer methodologies. The nature of RM will change, certainly, but the fundamental principles will not.

In working with enterprise customers across various industries such as aerospace, embedded engineering (high-tech electronics companies) and financial institutions, I find myself wondering whether the term requirements management really means what people think it means. The term 'requirements management' is being used to describe a whole slew of different processes, tools, capabilities that have absolutely nothing to do with managing requirements – which is probably the contributing factor to some believing that RM has no place in an Agile world.

Within an Agile environment, let's take Scrum as an example, you need the ability to define an overall product backlog which houses all outstanding feature requests the Scrum teams will eventually work on. For some organizations, call it a backlog item, user story, or feature request, this is the same artifact that the development team will see and break down into tasks during their sprint/iteration planning meeting. The job of a Product Owner would be to constantly sift through that pool of artifacts to identify candidates for the next release. However, some organizations that are now transitioning into an Agile development methodology typically are coming from a traditional methodology where they had 'formal' requirements management. By 'formal' I mean the requirements documents needed sign-off either from the key stakeholders in the company or their end customer. Let’s take the example of a cell phone manufacturer who gets most of their requirements from their carriers. These requirements typically come in a Word document format containing hundreds of requirements. Requirements management doesn’t go away in this scenario - it is just as important to ensure that the requirement is met, tested, and controlled in terms of change over the shorter development periods that these methodologies represent. What I have noticed is these requirements are sometimes very high-level and there is a need to decompose these into either Epic or User Stories to be placed in the Product Backlog. A RM solution can bring forth the visibility necessary to ensure that requirements are satisfied appropriately, reflect the current needs of the business and are communicated to end customer and key stakeholders.

What the Agile methodologies are also doing is that they are forcing requirements to be decomposed much earlier in the lifecycle such that their scope can be understood and mapped to an Epic or User Story in the backlog to be prioritized. We find ourselves moving away from a system of Business Requirements documents tracing to Technical Requirements documents tracing to System Requirements documents to one where the Business, Technical and System requirements for a given feature or request are fully defined and become the new Requirements Document. Once we have the Requirements Document, the Product Owners can decompose these into more granular User Stories so development can start building the end product. Pure Scrum does not talk about formal Requirements document because it is "too heavy weight". However, there are companies out there that need to communicate progress in term of the requirements originally received and not in terms of backlog items such as user stories. The reason being the same document that came in needs to be sent back showing the status of each requirement. This holds true in the automotive industry as well where the OEM (automotive company) and parts suppliers need to communicate using the standard Requirements Interchange Format(RIF).

Under this environment the Development and Test (QA) teams have greater visibility into the entire request, from the business level through to the system level, and can make design and test decisions armed with that knowledge. Furthermore, requirements traceability becomes about how these requests and the User Stories themselves relate to each other rather than how the high level requirements are decomposed into lower level requirements.

All that said, the requirements within these documents still need to be managed – scope and change to them needs to be controlled and more importantly communicated – and they still need to be linked to the rest of the application development lifecycle - the designs, the test cases and the source code. So in a nutshell, we are talking about Lean development. See Brad Appleton's article exploring the need for traceability and transparency in Agile development in his article - "Lean Traceability" CM Journal, September 2007 (Vol. 6 No. 9) (see http://cmwiki.com/AgileSCMArticles).

Remember, software methodologies need to be applied in a way that matches the strategy of your business. Whether Waterfall, Iterative, Agile or some combination of all of them, you still need to define what your customer wants, even when they change their minds (and they will!). -- You need to know what you are building and how to adapt to those changes. In the end, you need to be able to match the deliverable back to what the customer originally asked for, and this requires a repository and change management for requirements, with traceability over the requirements throughout the lifecycle – sounds like RM to me.

Please feel free to comment on what your thoughts are on RM in an Agile World.

If you would like to learn more on Agile Requirements Management register for this upcoming LIVE Webinar on February 16, 2011 "Agile Journal: Agile Requirements Management - When User Stories Are Not Enough". Our strength in supporting Agile development projects is what drives both analyst recognition and customer adoption of our solutions. One other resource you can check, click here to see the Agile Video.

Agile Programming: Building Applications Your Users Are Sure to Like

Discover Scrum and learn how to deliver build better, higher-quality applications.
By Marty Acks, Customer Requirements Manager, MKS Inc.

Agile programming has gained significant momentum recently by changing the way in which organizations develop software. When I was first introduced to agile programming a few years ago by a colleague, I politely listened to his enthusiastic description, but it really did not resonate for me. The more I learned, the more fascinated I became. Now, our organization is in the process of moving to Scrum, which is a well-known agile programming methodology.

This article will introduce you to the basic concepts of Scrum development and help you determine if Scrum is right for you. Scrum terminology is probably rather different from what you currently use. Although some of the terminology maps closely to what you may do today, much does not. While Scrum tends to talk about "products" a lot, Scrum is equally appropriate for both IT organizations and ISVs.

Click here to see the full article posted on MC Press Online.