So you want to launch an Agile Pilot?
Taking the first steps are often the toughest. An Agile implementation is not proven in your own organization and it is difficult to know if the benefits can be real and lasting.
The following are some suggestions to consider when embarking on a pilot. They are taken from various sources including Mike Cohn, Jeff Sutherland, informal chats with Agile practitioners, personal experience and various books on the topic of Agile and organizational transformation.
“Be Agile rather than Go Agile.” This may seem like semantics but the idea here is to embody the principles and ideas rather than focus on the processes and practices by rote. The principles drive the processes and provide a context to think about how to get from where we are to where we want to go.
Where to Start
A good place to begin is to look at the end in mind at a high level and then translate that into some short-term steps and actions which you can apply to start moving in the right direction. With large and complex feature development, all the requirements are not clear up front. Your transition model, with all its inherent complexity, will surely fall into the same, somewhat ambiguous space. Accept the ambiguity and get started. Requirements for your transition model will evolve as you move forward.
Establish the high-level objectives – what are your requirements?
You can write user stories to capture your intent and business value. “As a leader of Organization X, I want to trial an Agile project so that I can measure the effectiveness of this framework against our existing development practices.” It’s useful to get similar stories from other stakeholders to build a better view of the goal. For example, “As a development manager who leads a multisite team, I want to evaluate if Scrum can provide better results than my current processes and practices.” Another example: “As a project manager, I want to reduce the overhead associated with coordination and reporting across multiple teams in different time zones so that I can focus on solving problems, rather than gathering information.” These stories suggest distributed teams. For early pilots, find co-located teams and work.
With some key requirements identified, ask yourself how you will test them. What are your acceptance criteria? Here are some examples:
- “Velocity of delivery should be as good or better than traditional waterfall.”
- “Teamwork and interaction between stakeholders should more useful and effective than today. (e.g. Less miscommunication, better quality of information and understanding, which translates into less mistakes).” Define what this means for your stakeholders. Have a conversation.
- “My team should work with a higher level of enthusiasm and engagement compared to today.” The happiness metric matters!
- “The quality of software produced should be as good or better than that built using traditional waterfall project management, only faster.”
Be sure you and your team understand your goals and how you will measure them.
Building a transition model
John Kotter, Mike Cohn and others advocate establishing a “guiding coalition” of people responsible for ensuring the success of the pilot. One senior management sponsor + team leads that can make it happen.
1. Establish the timetable
- Set up a high-level schedule and roadmap for transition which includes your first pilot or pilots. You don’t have to define everything upfront, because your early experiences will drive the roadmap and schedule. You need early feedback before building a good plan.
2. Choose the work
- Long-pole features or long duration projects that require significant up-front analysis before work can start if done using traditional waterfall are good candidates. These projects and features get developers to build iteratively and have early “rubber meets the road” experiences which help to define the path to completion.
- High risk features where, because of new technology or unclear requirements, the information required to build a traditional plan is low. With these types of deliverables, you can start on what you know and work in parallel with Product Owners to refine the unknowns as you go.
- Manage bug lists in an Agile way within the confines of a waterfall plan. Build a cross-functional team including Test and Design and possibly even Field support teams to work issues together.
3. Choose the team
- People on the team need to “get it”. Select people who are willing to experiment and show enough self-direction to act without having to “get approval”.
- The team should be a mix of personalities, with different viewpoints and ideas. Homogeneity is not a good thing in this context. You’ll get better, richer feedback from the early pilots by staffing them with vocal, diverse, and opinionated people.
- The team members should be willing to do work not in their domain of expertise. Team members must be willing to help each other. This has the added benefit of building cross-training into the process.
4. Identify the Product Owner
- Should be a person who can be available and accessible to the team.
- Should have a vested interest in the success of the team.
- In large-scale telecom development, POs are often spread thin, so consider a PO proxy such as an architect who can work with the PO and other stakeholders, and be available to the team.
5. Choose the the ScrumMaster
- The role of this person is to enforce the process, protect the team from interruptions, clear impediments and facilitate the activities on a daily basis.
- Should be willing to let the team define the “how” of the work within the confines of the process framework and the application of good engineering practices.
- Someone with a test or integration background can be a good choice. They are the people most likely to look at the deliverables from a testability and quality perspective.
- Find someone who can leave their ego at the door.
6. Establish a few key unbreakable rules (some ideas from Jeff Sutherland).
- Before the start of work, the definition of “done” must be clear and well understood.
- Daily stand-ups are mandatory.
- The team is left completely alone to do the work. No interruptions.
- The team will develop test cases for their work before the start of any design activity.
- Team members are expected to work together and perform any task within the iteration that may be required. In other words, adopt a model of team members acting as generalists whenever it is necessary.
- An information radiator will be created (a corridor wall or white board will do) where all project information is available and visible to anyone who wants to see it. For a multi-site team, consider some simple on-line tools to share information. Newsgroups, wikis, Livelink or web pages.
- Success and failure is measured at the team level, not on an individual basis.
Mike Cohn’s suggestions for identifying change agents who are likely candidates for being a part of the Agile transition:
- Find out who people listen to. These may not be people with formal authority.
- Look for people who think differently. Change agents are not satisfied with the status quo.
- Consider new employees or others who may not be infected with a common mindset yet.
- Consider people with different backgrounds, such as the programmer with the art history degree.
Scaling issues are generally related to coordination of activities across teams, and communication/information sharing. Some examples of scaling issues:
1. Concurrent code changes by different Scrum teams in the same code base (in the same module of group of modules).
- Build teams and assign requirements on the basis of minimal overlap where it is appropriate.
- Use architects’ help to carve up the requirements (within and across features) to achieve this.
- Serialize code changes to common modules through prioritization.
2. Managing interdependencies between features.
- This is managed through prioritization and scheduling. No different from what we do in traditional waterfall. Product Owners and architects work through this together at the beginning, and throughout the release delivery.
- Stop thinking in terms of features and start thinking in terms of individual requirements within features as the way to prioritize. This could be a way to get the granularity you need to separate work between teams. Traditional telecom User Stories are usually epic.
3. Coordinating large scale development and integration.
- For distributed teams across time-zones, establish local scrum teams that coordinate work through a scrum of scrums (some key people that talk together as needed to work out interdependencies, for example, 2 to 3 times a week).
- Consider requirements or User Story workshops, sprint planning and reviews together at one site – an approach used by some large-scale global telecom suppliers. I would estimate that these types of workshops cut the time required to build a plan from four weeks of remote work to one, simply by insisting on no interruptions and being face to face.
- Establish a mid-term to long term goal of co-locating technical domains where the number of interdependencies is high.
- Consider wholesale transfer of ownership not on the basis of “low cost sites for mature software”, but perhaps on the basis of delivery velocity and simplicity of communication.
- Slice work differently. Consider all the work that can be done on a site across different features on a requirement by requirement basis and build Scrum teams along these lines.
Bottom line – there’s no clear cut recipe that can be easily applied across teams. You need to find the solutions that best fit your circumstances and overall business strategy.
LEAN can lead the way
LEAN principles and thinking are a natural driver towards becoming Agile. When implemented properly, the ideas of iterative delivery, improved communication, multi-disciplinary teams, early and continuous test and flow vs. batch, which are the hallmarks of Agile, become the norm. This is a good way to think about the transition to becoming Agile.