Case Study: Targeted Practice Adoption using Patterns

Posted by Amr Elssamadisy & John Mufarrige on Jan 29, 2007 05:40 PM

Community

Agile

Topics

Stories & Case Studies ,

Delivering Value ,

Change

Tags

Testing ,

Refactoring ,

Simple Design ,

Patterns ,

TDD ,

XP ,

Introducing Agile

Introduction

It's all too easy to get caught up in the energy of trying out new agile practices like pair programming, iterative development, and test driven requirements, and lose sight of the original motivating factors behind instituting those practices in the first place.

There may be this vague notion that "anything new has got to be better than what we have always (often painfully) done around here", and therefore the mere fact that you are trying something new is often good enough to justify the investment in time and effort of adopting a new practice. Yet at the same time, there are now so many practices which fall under the Agile umbrella that you may find yourself trying to figure out how you can possibly adopt everything at once, because maybe that one practice you ignore could be the one that makes the biggest difference.

One popular way of dealing with this madness is by picking one particular methodology or set of practices and internalizing them (or at least promoting them) to the point that your software development organization becomes an "XP shop" or a "Scrum shop" or a "UP shop". For every team member plus half the marketing team and a few of the more enlightened senior managers, purchase a copy of your Agile Methodology Adoption book of choice, agree on a few minor details such as the time and place for your new daily standups and which continuous integration tool to use, and you are well on your way to becoming a full-blown Agile Development Shop.

While this is a common and useful approach, it's unfocused and tends to result in behavioral change simply for the sake of change. There is, however, a more targeted approach to agile practice adoption that does not promote one particular named methodology over another but rather helps you pick and choose those practices that will best help you achieve your organizational goals. The following three points summarize this approach:

1. Determine Business Value - It is all too easy to forget who the real customers are.
2. Weigh Activities and Technologies in relation to Business Value - Change for the sake of change tends to dilute the desired results of becoming Agile.
3. Incrementally Apply Sets of Practices that Correspond to Value Sought - You don't need to adopt every popular agile practice to see a positive change, but rather a focused, diagnostic approach will help get you where you want to go faster and easier.

For this article we will consider the ongoing work of the BC 2.0 team. This is a development team that is working to rewrite an successful website that has millions of hits per day. We will share how we went about identifying which agile practices would be most beneficial to adopt. The approach we took was to start by prioritizing a comprehensive list of possible business values to highlight those specific business values that the team felt most accurately represented what they were trying to accomplish with the BC 2.0 development effort. We then talked about which agile practices are most closely aligned to each of their top three desired business values, and found that a few key practices either influenced or provided the basis on which many others depend. Finally we discussed which of those agile practices the team was currently utilizing and, based on that, crafted a plan for adopting the remaining high-impact practices.

Crafting an Agile Practice Adoption Strategy

Determine Business Value

The first step, regardless of where the team is today, is to focus on the business values that they are trying to bring to their customers. This actually required a slight step back to first identify who the customers were for, as with so many public websites whose revenue is based on advertising sales, the end user of the site is rarely the actual source of income for the company. With this understanding, we went through an exercise where we prioritized business values as understood by the whole team ¹. This question must again be asked of the customers of BC 2.0 which will include members of advertising, publishing, and management. At this point here is a first cut of the business values in prioritized order:

1. Value to Market/ Product Utility
2. Quality to Market
3. Visibility (to Customer)

There are possibly other business values that are important to the company such as:

1. Reduce Cost
2. Flexibility (turn on a dime)
3. Time to Market
4. Product Lifetime

Of the three business values deemed important, by and large Product Utility is the most important to this group, meaning that their emphasis should be on delivering a useful website as determined by the end users. Delivering a high quality website and keeping their customers informed of ongoing changes were also high on their list of important business values. What's even more telling about this particular organization is the list of business values that were considered lower priority. At many companies, reducing cost, delivering quickly, and building a long-life product are key goals, which understandably should influence the practices that they adopt. However their focus on building a high-quality, useful site means that they will want to emphasize different aspects of their development effort, specifically those that deal with customer involvement and feedback.

Weigh Activities and Technologies in relation to Business Values

This next recommendation seems obvious, but in truth it is something we, the software development community, have never done well: drive the use of process and technology by business value. This means, if a practice or technology cannot be related to business values as prioritized by the customer or organization, it should not be used.

Here is a list of software development practices to consider (for all business values):

1. Test First Development
2. Test Last Development
3. Evolutionary Design (cluster)
4. Upfront Design
5. Upfront Architecture
6. Upfront Requirements
7. Refactoring
8. Continuous Integration
9. Simple Design
10. Collective Code Ownership
11. Test Driven Development (cluster)
12. Functional Tests
13. Test Driven Requirements(cluster)
14. Iteration
15. Stand Up Meeting
16. Retrospective
17. Pair Programming
18. Kick Off Meeting
19. User Story
20. Use Case
21. Information Radiator
22. Customer Part of Team
23. Evocative Document
24. Prioritized Backlog
25. Demo

Of the practices listed above, here are the ones currently practiced by the team:

1. Upfront Architecture
2. Upfront Requirements
3. Continuous Integration
4. Functional Testing (beginning stages)
5. Iteration
6. Retrospective
7. Kickoff
8. User Story
9. Collective Code Ownership

To help us determine which practices should be introduced or emphasized, we used the following agile practice dependency maps for each of the three business values we are interested in. Each of these diagrams shows the practices that affect that business value and their interdependencies.

Product Utility Practices

Product Quality Practices

Visibility Practices

Incrementally Apply Sets of Practices that Correspond to Value Sought

Based on the business value priorities, the practices in the above diagrams should be incrementally adopted, starting with any key practices that either influence many others or have a number of practices which depend on them.

All of the practices already in use (except Upfront Architecture) directly address the high priority business values described above. Those practices should be kept and the Upfront Architecture and Upfront Requirements should be diminished because they cannot be realistically dropped. At this point we have a large list of practices we want to adopt and a couple that we would like to diminish. It is almost never a good idea to take a large number of practices at once; an incremental adoption strategy is better.

So which practices, of all the practices listed should be adopted? We started with the most important business value, Product Utility. Within the practices listed in Product Utility, we took the practices with the most incoming dependencies because they enable other practices. This leads us to:

• Customer Part of Team
• Release Often
• Automated Functional Tests

When we take a look at the next business value, Product Quality, we pull in Automated Developer Tests because many other practices depend on their presence and Pair Programming to support its adoption.

• Pair Programming
• Automated Developer Tests

From the third business value in our list we pulled a simple stand-alone practice to adopt:

• Information Radiators

When the team has successfully adopted these practices they will go back and pull in more practices to increase the business value they deliver. A practical adoption strategy includes an iterative approach to incorporating new practices, in other words: Adopt in small steps. The BC 2.0 group will begin with these practices and learn as they go. They need to experience the practices for themselves and build up their own body of experience. After an adoption cycle or two, they should revisit their list of business values to see if any have changed or been noticeably addressed. In addition to their end-of-iteration Retrospectives, they should also periodically review the progress and feedback from their adoption efforts, and use that as a steering influence for continued improvement.

Conclusions

The software development organization was more heavily focused on delivering usability and quality, which is a bit unusual in this age of almost relentless cost cutting and emphasis on time to market. Yet the development team was a fairly typical case from the standpoint of practice adoption, taking a hybrid approach of formally adopting Scrum while also incorporating individual Extreme Programming practices such as Continuous Integration and User Stories, in a piecemeal fashion as opposed to taking on the entire suite of XP practices. While there is certainly nothing wrong with this configuration, we want to promote the idea that certain practice groupings can result in specific business value improvements, and therefore teams looking for the most "bang for their buck" should pick those practices that align well with the driving forces behind their software development efforts.

Further Reading

This is a practical example of creating an adoption strategy tailored to a specific development team and project. The mini-book, Patterns of Agile Practice Adoption: The Technical Practices, takes a much more involved and detailed look at creating an adoption strategy and incrementally adopting many of these agile development practices.

About the Authors

Amr Elssamadisy is currently a Principal Consultant with Valtech Skill Development (www.valtech.com). He considers himself a programmer but has worked for consulting companies since 1999. So an outgoing, people-oriented, programmer is a better description. He has been working professionally as a software developer, architect, manager, consultant, etc... since the mid 1990s helping build software systems in C++, J2EE, and .NET. His first agile development project was a large project XP effort in 1999 where he had a chance to work and learn from some of the best in the field. Since then he has lead, participated, and mentored large and small development in both the .NET and J2EE worlds.

John Mufarrige is a Senior Consultant with Valtech, responsible for active analysis, design, and implementation of enterprise-scale applications.

---

• Older >