Create Your Own Flavor to Become Agile within Your Constraints

Applies to: Agile

Authors: Greg Smith and Ahmed Sidky

Get this book in Print, PDF, ePub and Kindle at manning.com. Use code “MSDN37a” to save 37%.

This topic contains the following sections.

• Become Agile within Your Constraints
• Key Points to Remember
• Copyright

Become Agile within Your Constraints

We’re huge proponents of Agile, but we need to tell you a few things that the surveys don’t reveal. Here are some questions that would bring additional perspective to VersionOne’s findings.

• How difficult was it to convert to an Agile development process?

• How was your conversion initiated? Did the idea originate with executive management or from within the development team?

• Have your employees bought into the process, or was it forced on them?

• What are you doing to ensure that your development process is viable for the future?

• What did you do to make Agile work within the realities of your environment?

We believe 100 percent of the survey respondents would say that moving to Agile was a lot of work. We think they would tell you that to be successful, you need your project team to buy into the process; and that management requires time to learn how to provide value in an Agile environment.

This discussion reminds us of a popular commercial from our childhood. When we were kids, we ate Jiffy Pop popcorn. Jiffy Pop ran a commercial for many years that stated, “Jiffy Pop: it’s as much fun to make as it is to eat!”

After you establish an Agile culture and lifecycle, it’s “fun to eat” (as illustrated in Figure 3.4), and you’ll do a better job of delivering projects. But creating an Agile environment is work. Many companies implement an Agile methodology and then fade back into their previous process because they didn’t cover all the delicate areas needed to ensure long-term support for Agile.

We’ve spent a lot of time with companies that have made it to the other side and stayed there. As this book continues, we’ll show you how companies got to be Agile with the least amount of pain and sustainable benefits.

Now let’s take a moment to look at the importance of creating an Agile process that supports the unique characteristics of your environment.

Figure 3.4 Is Agile development like Jiffy Pop popcorn—as much fun to make as it is to eat? Not during the migration phase. Managers need to learn when to manage (or not), and team members need to experiment with their new freedoms. These cultural changes take work and time.

Your Goal: Reach the Right Level of Agility for Your Organization

Many companies try to “shotgun” Agile into their organization. They think, “Let’s get through the migration pain quickly and start obtaining the benefits as soon as possible.” We’ve seen a few cases where this approach makes sense: for example, a project team that has become so dysfunctional that they’re delivering practically no functionality or business value. This approach also works well for a start-up company that hasn’t yet established its development process. But for most companies, you should allow time for the process to “bake.”

This is why we suggest an iterative approach for bringing Agile into an organization. An iterative approach allows you to see how well your employees are adapting to the change. It also lets you learn what works and what doesn’t in your environment. In effect, it allows you to reach the right level of agility for your organization.

Part of your iterative approach will include a process for maintaining the methodology. We suggest establishing a core team to support this maintenance. A core team is composed of employees from all aspects of the development process. They play a huge part in establishing your custom methodology and then settle into a maintenance mode with the goal of constantly adapting to your environment.

Next, you need to choose the best way to iteratively create a methodology at your company. Should you select a packaged method, such as Scrum or XP? Or should you create a custom or hybrid process?

Custom process or packaged method?

In order to be successful, you should customize your Agile process. For many years, consultants and others have said that you must embrace Agile completely or not at all.

In 2006, we witnessed a shift in this attitude. Highly respected folks such as Kent Beck (the founder of XP) and Steve McConnell (the writer of Code Complete) now endorse customization. Kent Beck noted the following in an interview with InfoQ (InfoQ.com is an independent online community focused on change and innovation in enterprise software development) in 2006:

Failure at an organizational level seems to come from the inability to customize processes and make them their own. Trying to apply someone else’s template to your organization directly doesn’t work well. It leaves out too many important details of the previous successes and ignores your company’s specific situation. Rubber-stamping Agile processes isn’t Agile. The value of having a principle-based process is that you can apply the principles for an individualized process for your situation and, as an extra bonus, one that has been designed to adapt from your learning as you adopt changes into your organization. It’s always “custom.”

Kent’s quote is comforting to us because it supports our personal experiences. Custom means picking and choosing the Agile practices that best support your environment. Custom means you shouldn’t use a pure packaged methodology off the shelf, such as Scrum or XP. You can start with one of these methods as a basis for your process, but you should modify it to obtain the best results for your company.

If we revisit VersionOne’s 2008 survey, we see that 14 percent of the people who responded are using a hybrid process based on Scrum and XP. The hybrid model is closer to what we’ll suggest for you. To be specific, here are the steps we’ll walk you through as the book continues:

1. Assess your organization to determine where you should begin adding agility.

2. Obtain executive support for the move to a more Agile process.

3. Get the development team involved in the migration process to ensure buy-in. You do this by establishing a core team.

4. Develop a clear understanding of your current processes by documenting them.

5. Identify a coach or consultant to help you with your migration. They will train the core team on Agile and help you with other adoption aspects.

6. Review your current process, and look for areas that can be shifted to more Agile methods. Focus on areas with the most potential for improvement and the most value to the customer and your organization. The readiness assessment will also help with this task.

7. Outline a custom process based on the findings in step 6.

8. Try the new process on a pilot project.

9. Review the findings after the pilot, make changes, and continue to scale out your new methodology.

As this book continues, our case study, Acme Media, will represent your company. We’ll take Acme through these nine steps and show you how the company iteratively creates and tests a custom process. We’ll also show you how Acme Media takes its own constraints into account with the new methodology.

Before we jump into the case study, let’s spend a moment looking at the characteristics that make it easier to adopt Agile and the characteristics that make Agile adoption more challenging.

Characteristics that Make Agile Easier to Adopt

As we stated earlier in this chapter, Agile principles can be applied in any environment, but some environmental characteristics influence how easy the principles are to adopt. Let’s look at these characteristics.

Urgency to Deliver

Agile works best in an urgent environment. It provides tools to prioritize features quickly and determine how much scope to pursue within the constraints of a critical timeline. If you have urgency due to a competitive market, compliance deadlines, or a large backlog of project requests, Agile provides methods for quicker delivery.

Evolving or Volatile Requirements

One descriptor of Agile could be just enough. “Give me just enough requirements to start a design.” “Give me just enough design to start my code.” “Give me just enough code to demonstrate some level of value to the customer.” If you don’t have all the requirements, you can still get started with an Agile project. If you complete an iteration and the customer wants to change the requirements, you can adapt and still meet the objectives. Managing changing requirements still takes effort in an Agile environment, but you don’t have to fight the project framework. The framework is designed to support uncertainty.

Customer Availability

One Agile Manifesto principle states, “Business people and developers must work together daily throughout the project.” In our experience, these groups don’t have to work together every day throughout a project cycle, but there are definite times when the customer must be available. In theory, a project must not be urgent if the customer can’t make time to clarify requirements or review functionality. The customer can have a proxy, such as a product manager; but someone needs to be available every day to represent the customer’s vision.

Consistent Resources

Part of the power of Agile is a level of familiarity within the team and a consistent understanding of the processes they use. Agile teams and processes get better over time. If project team members are new to each other, they must learn processes together while at the same time trying to complete the project. Agile works best with a core group of people who work together on continuous projects. Agile isn’t a good methodology to use with a team that has never worked together before, unless you have long-term plans to keep them together.

Co-Located Resources

Agile promotes face-to-face communication and common understanding. One of the best ways to support this principle is to put your team members face to face. Co-location is an amazing tool. Your team can get out of email hell, and their mutual understanding of the project will increase.

One of the best setups we have seen is at a Fortune 500 company we visited. All 10 of the project team members are in an area approximately 25 feet by 25 feet. The cubicles have half-walls that provided a level of privacy when people are sitting but let them easily see the rest of the team and communicate when they stand up. This setup provides the privacy the developers enjoy when they’re deep into a coding session but also lets team members stand up to converse with each other at any time without having to go to each others’ cubicles. Team members can also walk a few feet and reach common areas where they can whiteboard a design or have a quick caucus.

The Team is a Team

In larger companies, a project team may be constructed of team members from a shared resource pool. For example, the QA (Quality Assurance) lead for a project may be from the QA shared resources pool. If such team members view themselves as resources on loan, and not as team members dedicated to the project, the result can be functional silos.

When silos exist, team members are more concerned about the welfare of their team or area than they are with the livelihood of the project. This mentality doesn’t bode well for Agile development and leads to customer neglect. The team needs to bond as a unified group toward the goals of the project. Roles are assigned, but one of the objectives of Agile is for the team to working collectively.

Working collectively can also be applied to team member roles. A tester can point out a possible code improvement. A developer can suggest a feature enhancement. In general, team members speak out—they don’t limit their roles to their titles.

Management should ensure that individual goals include how well employees support the common good of the project.

Roadblocks that Others Have Overcome

Now that you know the characteristics that make Agile easier to implement, let’s look at a few that make Agile more difficult to move to.

Lack of Agile Knowledge

Your first challenge will be finding expertise to help you with your migration. If you’re fortunate, you’ll have some level of Agile experience within your company; but this probably won’t be true to the point that you can coach yourself through an Agile migration.

We’ll help you with this issue by showing you how often Acme Media requested assistance, from initial training to issues encountered along the way.

Large Project Teams

Agile is compromised as team size increases. Major principles such as face-to-face communication and common understanding require additional effort to maintain their effectiveness as a team grows.

Larger teams require additional overhead to ensure that information is shared consistently across all groups. Scrum teams frequently use the term scrum of scrums, meaning a representative from each team Scrum attends a master Scrum meeting to share information with other groups.

Jeff Bezos of Amazon.com believes that the most productive and innovative teams can be “fed with two pizzas.” Jeff shared this thought with his senior managers at an offsite retreat. He envisioned a company culture of small teams that could work independently, which would lead to more innovative products. Since that time, the Amazon “pizza teams” have created some of the most popular features on the site (Fast Company, 2004).

If your team has an average appetite, you can convert Jeff’s concept into a team of five to seven people. This is a nice-size group for communication and agility. If five to seven is perfect, then what is the maximum size for a team to remain Agile? On the high side, we believe you can have a team of 15 people without major impact on your agility. When you have more than 15, communication needs to become more formal, which slows the team.

There are ways to make Agile work with larger or distributed teams, but you’ll sacrifice some level of agility.

Distributed Development

Related to large teams, many companies use distributed development. Frequently, the distributed development is performed by offshore resources.

Distributed development implies that the team is large in size and that communication methods must be scaled to get information to all involved. In addition, you may have issues with time zone differences, language, and code integration into a common environment. Some offshore companies support and advertise the use of Agile methodologies, but their location may make it challenging to support the core principles.

We’ve seen Agile teams successfully use offshore resources for commodity or repeatable-type work, such as regression testing, smoke testing, and cookie-cutter development (for example, providing an offshore group with standardized tools to create automated workflows).

Fixed-bid contract work goes against most of the Agile principles. The customer isn’t a partner, evolving requirements are a no-no, and adapting is usually called scope creep. We used to believe that fixed-bid work couldn’t be performed using an Agile process, but recently we’ve met several managers who have customized their process to allow the inner workings to be Agile while customer interaction remained contract oriented.

If you have a team that will work together for only one project, they’re usually better served by using a plan-driven methodology unless they have previous exposure to Agile. If the team will work through multiple projects or releases, you can introduce Agile techniques, and the team can migrate to a full Agile methodology as their knowledge matures.

“Hey, it’s Agile. We don’t need to do any planning to convert to it, just start thinking Agile!” A lot of folks take this approach when migrating to Agile. But if you go too fast, you don’t give your company enough time to digest the concepts. When this happens, you may experience issues with common understanding and terminology.

Don’t let this happen to you. You need to plan before migrating to Agile, and this book will show you how to do it with an awareness, buy-in, ownership approach. If you take your time, the methodology will stick, and you’ll minimize the risk of failure.

An organization’s structure can create artificial barriers between teams, and so can skill sets. If your team has specialized skill sets, it’s hard to be Agile when the work mix doesn’t correlate well to the available resource types. Some tasks always have to be done by certain individuals, which doesn’t help the team bond or unite when pursuing the completion of a feature.

Specialized skill sets also place an additional constraint on team capacity. Imagine that your team has only one person who can perform user-interface design, and the work assigned to an iteration is 80 percent user-interface work. Other team members can look for work to do outside of the iteration, but delivery will be slow due to the one-person constraint.

Teams that are just becoming Agile usually have members with specialized roles. You can overcome this constraint by cross training over time and rewarding employees for obtaining and using additional skills.

Many people get hung up on the questions, “Are we doing it right? Are we doing it in an Agile fashion? Are we following a pure Agile process?”

When teams ask us these questions, we tell them the answers aren’t important. All we want to know is this: Have you created a development process that provides the most benefit to your company ?

This same mentality has managers trying to find a perfect Agile methodology and insert it directly into their company. As we discussed earlier, you can start with a packaged Agile process, but you need to look at the realities of your company and adjust accordingly. Acme Media will look at a generic Agile process and see how it applies to their realities; then, they’ll modify the process to fit their environment.

Key Points to Remember

The key points to remember from this chapter are as follows:

• Moving to Agile isn’t a one-time event. You can and will add agility over time.

• The goals of an Agile process tie directly to company success.

• You can start with a prepackaged Agile process such as Scrum and then modify and enrich the process to support the realities of your environment.

• Some of your existing company characteristics will make it easier to move to Agile. This is especially true if you have volatile requirements or urgency to deliver frequently.

• Every migration to Agile encounters roadblocks. We’ll identify the most common roadblocks and show you how others have addressed them.

• Every migration to Agile is unique, but we believe our nine-step framework will work for most companies and provide the best chance of moving to and sustaining an Agile process.

Previous article: Are You Ready for Agile?

Continue on to the next article: Mindset of An Agile Leader

Copyright

©2009 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.