Written by Reedy Feggins, Jr, IBM
Agile is all about people, flexibility, trust, communication, and feedback. To be successful, an organization must instill these values at all levels in the organization. In this first of a multi-part blog, author Reedy Feggins Jr, IBM Solution Architect and Agile Coach, describes some of the common challenges that many large organizations face when attempting to adopt Agile practices on an enterprise scale, techniques that he has used successfully in the past with these organizations and the critical success factors from these Agile transformation efforts based on his four years experience helping organizations inside and outside IBM adopt agile practices.
Introducing Agile in an Organization
Within almost every business domain, companies are working to transform their software development organizations by adopting agile practices to improve product quality, team efficiency and on-time delivery. While once considered viable only for small, co-located teams, these practices are now being successfully implemented by organizations with larger distributed teams through the effective use of collaboration software development tooling such as those found in the IBM Jazz Platform to assist with in an effort to achieve these same benefits). Most successful transformations must have strong support from the top and the needs of this critical set of stakeholders must be understood. To get solid agile transformation, most organizations must focus their improvement activities on three critical aspects.
- What skills do the resources have
- How are the teams organized
- What practical experiences do they need
- What processes are currently being used? Waterfall, iterative, hybrid
- Depending on the process different practices may need to be adopted or emphasized.
- What tools are needed to support the practices?
- Continuous Integration, Automated Testing, Agile Planning and Collaboration support
While each adoption effort is different, over the course of several agile adoption projects inside and outside IBM, a common set of principles have begun to emerge. Agile adoption efforts must be
- Driven from Top down and implemented from the bottom up
- Business-value focused
- Adopted Iteratively
- Agile in its approach (Learn and Grow as situation evolves)
- Adopt a test-driven adoption strategy
Driven from Top down and Bottom Up
Large-scale agile transformation requires the entire organization to be committed to its success. Most organizations can be roughly grouped into three viewed to be made of three layers of people with a varying degree of authority. Figure 1: Stakeholders in a typical organization Interests / Needs
- How productive are our delivery teams
- How accurate is our planning and estimation
- What are our development costs?
- What is our return-on-investment? What business value are we achieving
- What is our teams velocity
- Is our Sprint burn-down on track
- What risks have we identified / mitigated
- What is our Defect Density / Test Coverage
Leadership must champion the importance of the adoption activities (such as training and mentoring). An effective program really comes from the top and unless you have their support it’s very difficult for people to adopt the programs and implement them. Recommendations include:
- The team overseeing the adopting efforts must use agile techniques to Learn and Grow.
- The team must establish success criteria at each level (Business level, Project level and Individual level)
As organizations scale up their agile transformation efforts, they will need to build a core staff of resources capable of assessing the needs of new teams and helping new teams to adopt the selected practices. Common challenges include:
- Funding training and enablement programs. Most organizations now have budget and travel restrictions that limit most organizations ability to send people to training classes
- Finding the right resources to training. Often times getting skilled resources to attend live training sessions is a big challenge in itself as most people have little time of extended formal training.
- Convincing people that enablement is important—especially mid-level managers.
- Scaling up training was a big challenge and while this can be overcome through virtual enablement sessions and media training, there is not substitute for face to face training
- Implementation of training can be a challenge, especially across multiple locations.
While some of these concerns can be mitigated by self-paced training, virtual training and media training videos, there is often no substitute for face-to-face training. The use of advanced e-Learning techniques addresses several of these issues but there are often communication and technical difficulties that are hard to overcome. Many times scheduling and commitment are some of the largest issues that need to be constantly addressed.
Business Value Focused
First and foremost the agile adoption efforts must be focused on increasing the value of software development to the business. The practices selected and the order in which they are adopted must be selected to deliver the greatest potential value to the business. In most cases these values fall into one of the following categories:
- Reduced time to market
- Increased value to business
- Increased quality
- Increased flexibility
- Increased visibility
- Reduced cost
Large transformation efforts especially agile transformations are not easy. But economics are driving all organizations to seek creative approaches for cutting costs, improving performance while delivering value to their clients in this competitive marketplace. More companies are moving towards taking advantage of Lean principles to help cut waste and using Agile for Managing IT and Non-IT project efforts for maximum ROI. At IBM we often recommend an iterative and incremental approach for strategic enterprise agile transformation. This high level pattern uses adoption “waves” instead of a rigorous step-by-step procedure (waterfall) which won’t account for the evolutionary nature needed for this transformation. During each wave the team overseeing the agile transformation focuses on different agile practices that correlate to the business values driving that wave.
Wave One: (or Mobilization) Focuses on establishing a firm agile foundation and deliver initial value by establishing a Center of Excellence (CoE) staffed by resources responsible for the supporting the Agile Transformation. The CoE should be comprised of Agile Transformation team members; Mid-level managers and upper management guide the overall transformation. This team is responsible for
- Obtaining executive sponsorship and commitment
- Cultivating experienced agile mentors and coaches from within the organizations
- Building agile infrastructure (C0E, process, tool)
- Demonstrating measurable value by piloting agile practices on 1 or 2 process to show quick-wins and increase visibility
Wave Two: (or Early Adopters) Focuses on building on early success by helping a relatively small number of internal employees to become internal coach/trainers. The Agile Coaches must work with employees to develop a sufficient number of people who are capable agile facilitators (Scrum Masters). This team engages the trainers/coaches to do the following things roughly simultaneously:
- Conduct awareness sessions to introduce everyone in the organization to agile concepts
- Do initial cultural and process assessments to track progress over time
- Start _everyone_ in the organization using the agile meta-process
These are the people will slowly take over from the external coaches. They learn about agile methods more deeply: practices, principles, variations, techniques, and tools. They learn to be effective facilitators who have the trust of their co-workers. These facilitators then become responsible for ensuring that everyone else is using the agile meta-process for effective learning and simultaneously applying appropriate agile practices.
Wave Three: (or Enterprise Transformation) Finally, the coaches work with the Agile Transformation Team to help a relatively small number of employees to become internal coach/trainers. These are the people who will take over from the external coaches. As for ongoing assistance, the coaches should be working in a consultative capacity as the organization struggles with obstacles, restructuring, and the deeper culture changes. Like any change effort, there are five critical components: sponsorship, communication, training, support and strategy. The coaches should be advising the Agile Transformation Team and management on how these five components can best be handled for the agile transformation.
Agile in it’s Approach
In the early days the project chosen to pilot Agile practices were often smaller green-field projects that were smaller in scope and relatively low risk if problems arose. But today many companies need to apply agile practices to a broader set of projects requiring the teams to adapt to many of the agile scaling factors spoken of Scott Ambler in his work on Agility@Scale: distribution, organization, and technical complexity to name a few. Agile techniques, such as test-driven development (TDD), continuous integration, iterative development, agile modeling, daily stand-up meetings, and so on are quickly being adopted within large IT organizations. Today most teams usually start with a core set of agile practices such as those found in Scrum and then extend them. For example, where Scrum uses a single prioritized list of User Stories (i.e., requirements) called a product backlog, many organizations need to take this practice one step further and use backlog to track all “value-added” work, even the non-requirement related work such as managing defects, prioritizing stakeholders needs and reviewing products of other teams, and so on. New work items, including those items identified as part of your user testing activities, are added to the stack in the appropriate place. The Product Owner, with input from the other project stakeholders has the right to define new requirements, change their minds about existing requirements, and even reprioritize requirements as they see fit. However, the Product Owner must also be responsible for making the final decision and providing information in a timely manner.
Regular Delivery of Working Software
- Only valid measure of progress
- Provides visible results to stakeholders
- True earned value, not documentation-based “earned value”
Daily Stakeholder Interaction
- On-Site Customer
- Active Stakeholder Participation
- A Product Owner that understands business priorities driving change to the backlog
- Automatically compile, test, and style check your code
- Continuous code integration is nice
- Continuous system integration is nicer
Use a test-driven adoption strategy. (i.e. validates your results)
Most developers can understand and relate to identifying and fixing code smells as it relates to their development methodology or practices. But agile transformations on a large scale must also watch out for “Business smells” and “Process smells”. Business smells are issues that affect the business and are visible to customers while process smells are only visible to the development team. Some common business smells include:
- Time-to-market – delivering new features to the customer takes too long
- Little or No Real Value – Too many unused features by the customer.
- Quality Problems – Software is not useful to the customer.
- Too Expensive – Software is too expensive to build.
- Pilot a proven Agile approach (e.g., Disciplined Agile Delivery) first before customizing it (don’t start by changing an approach that works)
- Understand the motivation behind a specific practice before (adding / dropping)
- Start with a small Pilot, prove success, learn from the pilot, and then scale Agile adoption (avoid too much change, too fast)
- Impacted Teams must see value so avoid the “Checklist Agile” adoption
- Avoid WAGILE (Waterfall Agile – e.g, BUFR Big Up Front Requirements)
- Use a wave of change Adoption Roll out strategy
- Develop new incentives that recognize team delivery instead of individual delivery
From my experiences, successful enterprise agile transformations require the proper mixture of top-down and bottom up activities. Agile transformation efforts are much smoother when buy in and continued support is obtained from sponsors high up in the organizations. Results are more tangible when the impacted teams help define the values, practices and tools to be adopted. With both approaches in play, I firmly believe that any organization can succeed.
1. See http://agilemanifesto.org.
3. See Patterns of Agile Practice Adoption, posted July 13th, 2010 by John Turner
5. See “Working in Priority Order: Agile Change Management”, www.agilemodeling.com/essays/agileRequirements.htm
6. See Agile Advice – Working with Agile Methods (Scrum, OpenAgile ..,), http://www.agileadvice.com/page/3/ (accessed February 16, 2011).
About the Author
Reedy Feggins, Jr, is a Solution Architect and Agile Coach at IBM Rational Software, a global software development company. Reedy is a certified ScrumMaster and PMP certified Project Manger. In this role, he trains, mentors and coaches teams in implementing practices such as Scrum, XP and Disciplined Agile Delivery (DAD). Reedy is also a IBM subject matter expert (SME) supporting the adoption of several IBM software development tools: Rational Team Concert (RTC), Rational Quality Manager (RQM), Rational Requirement Composer (RRC), RequisitePro, ClearQuest and ClearCase. He has extensive experience mentoring teams over the past four years has given him the ability to assess business needs, craft an adoption strategy and provide organizations with practical experience implementing the appropriate Agile adoption strategies.