Gathering a group of people together and labeling them an “agile team” is easy. Getting that team to be efficient using agile methodologies while leveraging ALM tools and best practices is infinitely more difficult, and there are good reasons why that’s the case.
While many organizations claim to be “agile” these days, agile means different things to different people. Few teams are purely agile; most are some sort of hybrid, which may mean combining agile practices with more traditional ones, or mixing and matching agile practices to suit the organization. When assembling an agile team from scratch, remember to keep flexibility and continuous improvement in mind because transitioning to agile is a cultural shift.
“The first thing people forget when setting up an agile team is that there has to be a culture in place that accepts agile tenets such as nimbleness, self-reflection and collaboration,” said Peter Chargin, senior director of product management at CollabNet.
Often, agile practices are narrowly viewed as something specific to software development when they affect the way the entire organization functions.
“Transitioning to agile is not simply a matter of adopting a methodology; it’s setting yourself up for organizational change,” said Todd Olson, VP of products at Rally Software. “If you’re going to be successful, you need to look at everything because the titles, roles and decision-making processes are different.”
Because transitioning to agile requires the cooperation of many people, it’s important that team members understand what the benefits are to them as individuals. One software development executive got executive team approval on an agile transition plan, and based on the success of his presentation, he used the same presentation hoping to get the developers, testers and documentation writers on board. He didn’t realize his mistake until an agile coach gave an “Introduction to Agile” presentation to his staff. At the end of the presentation, one of the developers approached him and said, “If that what agile is all about, I’m in. I had no idea.”
In short, when selling the idea of agile, setting up an agile team, and embracing agile, one size does not fit all.
#!
Cherry-picking agile practices
Being agile is a journey, not a destination, and the road is full of potential obstacles. Some teams transitioning from waterfall may decide to adopt agile iteratively since it is usually impractical to use purely traditional practices one day and purely agile practices the next. For a waterfall team transitioning to agile, it may make sense to start with something as simple as burn-down charts and then incorporate other agile practices as the team experiences small successes one step at a time.
One easily avoidable mistake is putting too much effort into “getting agile right” once and for all. When that happens, agile practices may become rigid rather than flexible, which can undermine success.
“Agile development teams started being way more productive than waterfall teams because they were flexible enough to adapt to change,” said Hamid Shojaee, founder and CEO of Axosoft. “Agile methodologies like Scrum are being so well developed and fine-tuned that the rigidness traditionally associated with waterfall is coming back in the form of agile, and that’s not what agile is all about. Being agile is about being flexible and making changes based on the reality of what’s going on.”
Another mistake is choosing a subset of agile practices that sound good without fully understanding them and experiencing their value—or the lack of it—as applied to a particular situation.
“Stories are easy; pair programming, refactoring, and sustainable pace are harder conceptually and in fact. The biggest mistake is cherry-picking agile practices without having the experience to know which techniques you actually need,” said Mike Mason, head of technology at ThoughtWorks. “When people say they’re ‘doing agile,’ it often means they have iterations and visibility and they’re beating people when they don’t hit their estimates.”
While pondering what it means to be agile, it also behooves teams to understand what may be preventing them from working in an agile fashion.
“Problems can appear in a number of different dimensions: culture, architecture, legacy practices and so on,” said Svante Lidman, senior productivity expert at Hansoft. “Many organizations do pilots to ‘benchmark’ against existing practices, and this is not what you want to do. You want to focus on learning and uncovering and removing impediments. In large organizations, you sometimes see an agile implementation project that is trying to figure out what the challenges and solutions are in advance. The [approach] can be useful to a limited extent, but it is much more important to get started and learn and adapt as you go.”
Before breaking agile rules, learn what they are and why they exist in the first place. Otherwise, the agile initiative may be deemed a failure and it is possible that agile practices will be blamed for the project’s failure.
#!
A word about methodologies
There are many flavors of agile being used alone and in combination. The best fit can vary based on a number of factors, including team experience, team size and project.
“People make a lot of money promoting different methodologies, but for the most part, mature agile teams practice hybrid,” said Ian Culling, CTO of VersionOne. “If you’re a new team, you need to look at the work you’re doing.”
For those completely unfamiliar with agile practices, the Agile Manifesto is a necessary conceptual starting point, and depending on the nature of the work, Scrum may be a good place to start because it is so prescriptive.
“You can learn a lot just by following [something prescriptive like Scrum], doing it repeatedly, retrospecting and focusing on continuous improvement,” said Rally’s Olson. “After you’ve done a few iterations, ask yourself what’s good about your process, what you like and dislike about it. You can adjust your process from there.”
That’s where the hybrids come in—after learning from experience, hopefully. Scrum and Kanban are considered good for project management, while XP addresses engineering concerns such as continuous integration and test-driven development. If your team is inexperienced, Adam Sandman, director at Inflectra, suggested starting with Scrum because it is prescriptive, then adding the appropriate XP practices later.
“Starting with raw XP is harder because it requires more invention at the start to put its principles together,” he said. “Scrum and XP are mostly complimentary, so you tend to choose elements of Scrum and XP for the specific project.”
Kanban focuses on work in progress and the flow of tasks, which makes it a good choice for software support and maintenance. According to CollabNet’s Chargin, it is best suited for items that are similar in size and scope.
Which methodology or combination of methodologies is best really depends on the team, the project, the business situation, the technical environment, and the product architecture at any given point in time.
“Typically you don’t select a single agile methodology; you adapt a set of practices and hopefully live by a set of principles,” said Hansoft’s Lidman. “It is of course useful to start with an approach that has been successful for others as a starting point to evolve from, [but since] agile is to a large extent about learning and continuous improvement, the rigid implementation of a particular ‘set methodology’ is contradictory to what we want to achieve in the first place.”
As situations evolve, team members will likely be exposed to different methodologies, or some team members may be assigned to another team or project that uses a different methodology. How easy the transition will be is typically determined by two things: individual attitudes and training. If the individual enjoys experimentation and doesn’t mind adapting, the transition will be easier than if the person resists change. Formal training and pairing also can help bring inexperienced team members up to speed.
“The right people are going to be open to trying new things and adding new skills to their toolbox,” said Axosoft’s Shojaee. “The wrong people are set in their habits, and they view things as right and wrong: ‘I’m doing things the right way and you’re doing things the wrong way.’ ”
If you’re starting up a new team and can handpick team members, choose people who like to experiment and don’t mind adapting to change. If you lack the luxury of choosing team members, try gaining momentum through small successes, adding more adaptive team members, or finding a more palatable way to introduce new ways of working.
“When I first joined VersionOne, our teams had been heads-down for four years building the product. They hadn’t been outside the room, so they were still using the practices they came with and were pretty comfortable,” said Culling.
“We brought in people with more of an experimental bent, and using retrospectives, we introduced new ways of doing thing as experiments. Even the most change-averse person on any team will be willing to try something for two weeks. As a result, we went from being very fixed to very experimental.”
Because project teams tend to adopt formal practices and usually have their own information conventions, it’s important that incoming developers understand both so they know how the team works and why.
“Project managers [should] explain why a particular process is used and not just what the process is,” said Inflectra’s Sandman. “If a developer goes from an XP team to a Scrum team and challenges why the new team is not doing pair programming, [it is helpful] to explain why the team has not followed that practice. It may also be helpful to consider whether pair programming could be useful such as on the high-risk parts of the system.”
#!
Why best practices might not always be best
Just about everyone claims to be using “best practices,” but like so many other things that influence the success of agile, the outcomes can be case-specific. While every methodology has its own set of best practices, the practices may have to be adjusted to suit the organization, the project and the team.
“A best practice may not be the right practice. The essence of any practice is the value it is intended to provide,” said Culling. “Look at the best practices people are promoting and understand the value of them and whether they’re a good fit for your team—individuals and the codebase—and maybe the organization.”
Test-driven development and automated testing are examples of best practices, and yet they may not be economically or technically viable, he said. Alternatively, a particular practice may be a poor business decision.
“Best practices are a moving target,” said Thoughtworks’ Mason. “Agile encourages continuous learning and continuous improvement. Ensuring that a team has time to reflect on their work and tweak their practices is a key to success. A team needs to acquire sufficient experience with agile to understand what will work in a particular situation.”
For example, one of Axosoft’s game developer customers does continuous integration directly into production several times a day, which means the product gets updated several times a day. At a different type of company, that practice could open the door to litigation, fines or worse.
“If a feature gets pushed out that’s not up to par, it will hopefully be fixed in a few hours later, said Axosoft’s Shojaee. “If you’re a game company that’s acceptable. If you’re creating mission-critical applications for an enterprise, you’ll probably want to do much more testing than that. Best practices in one environment don’t work in another. While some best practices stand the test of time, there are others that can only be discovered through trial and error.”
Inflectra’s Sandman agreed. “There is a danger that following best practices simply means not actually thinking about what’s appropriate. I’ve seen teams use tools and frameworks that were a best practice for 100-person teams but overkill for a five-person team,” he said.
#!
Choosing the right tools
The best tools for the job are the ones that serve actual needs. While individuals and teams have their preferences, the general consensus is that tools should have the ability to adapt to change, whether they’re “best of breed” point tools or end-to-end ALM solutions.
“Make sure your tools can grow with you. Rather than buying what you need today, plan what you need for your current and next project,” said CollabNet’s Chargin.
While white boards (if the team is co-located) and spreadsheets may work for very small teams, as the team grows and becomes distributed, formal tools become necessary for efficient workflow and collaboration.
“There are a couple of things that are important to consider when selecting an agile planning, tracking and execution tool,” said Hansoft’s Lidman. “It should be something you can grow into, easily adopt, and modify as you learn from experience what does and does not work in your organization. Tools with predefined methodologies can become an impediment to continuous improvement, which is what agile is all about.”
At the enterprise level, visibility becomes critical among tools, if not across the entire life cycle, which is why ALM tools have become popular.
“In order to have a single source of truth, you need to have some sort of project-management and tracking infrastructure that complements the way you work,” said VersionOne’s Culling. “That central platform needs to adapt as your team adapts, and as you extend out from that central planning and tracking tool, you need tools that support development and delivery that need to adapt as well. That way if you’re talking about source control, you can understand what check-ins were done for a particular story, and if you’re talking about continuous integration, you can see which defects were fixed between two builds, what stories we delivered and those kinds of things. They should work in concert, but you want to be able to adapt your choices.”
One mistake people make (and later regret) is choosing tools based on the long list of impressive features they provide rather than the features that the organization actually needs. Simply buying a checklist of features can result in purchasing a feature-packed solution that is too complex or sophisticated for the organization’s needs, or in selecting the wrong tool altogether. To balance the need for scalability with the needs of organizations, a number of tool providers—including many ALM solution providers—offer multiple versions of their products. These include a free version for very small teams that lack enterprise functionality; a full-featured enterprise version designed for multiple distributed teams that provides life-cycle tracking and visibility; and a version in between.
“If you’re using a product that doesn’t support your process, doesn’t support agile, and makes you translate an old way of doing things into a new way of doing things, it is blocking organizational change,” said Rally’s Olson. “Pick something that makes change easier.”
The only way to know if a tool is a good fit is to try it instead of watching a demo or populating a trial version with the vendor’s sample data.
“Always take a real trial of the tool…using real project data and see how it really works for the team,” said Inflectra’s Sandman. “You’re also wise to consider an exit strategy. Even if you don’t have the most complex and powerful tool necessarily up front, at least make sure the tool has the ability to export the data into an open format, or it has APIs for accessing the data.”
One important feature than can get overlooked in favor of sexy next-generation features is ease of use. “You can usually find multiple tools that have the core functionality you need, but for me, ease of use trumps everything else,” said Axosoft’s Shojaee. “In a project-management tool where any time developers spend in the tool is time they’re not writing code, spending one minute versus 10 minutes matters because they could have spent the other nine minutes writing code.”
#!
Ask for help
If few on the new agile team are familiar with agile practices, or the majority of team members are change-resistant, hiring an outside consulting or training organization can help. They can give individuals, project leaders and teams a better understanding of how agile practices could be best implemented.
“Find a coach that you find through references that has hands-on experience transitioning teams to agile practices,” said VersionOne’s Culling. “If you don’t want to invest, it’s short-sighted. Their job is to help you avoid a ton of mistakes many people have made before you. Although you will make some mistakes…you need someone to guide you through the learning to help you deal with the change stuff because this is a significant transition.”
Some organizations hesitate to invest in outside help because of the cost, or out of fear that the consultants will sell the organization more than it needs. To avoid this, Axosoft’s Shojaee (who is a former consultant) suggested doing some short introductory meetings to see whether the consultant is a cultural fit and whether they have the level of expertise necessary to be effective.
“You can tell them about your development processes in an hour meeting and they can give you advice to prove themselves,” he said. “You’ll know whether or not they have a point. If you do that with two or three different companies, you can choose the one you think is best.”
Training can be helpful, but the benefits may be limited when team members are sent to a class for two or three days but lack follow-up from the company. A lot of information tends to be crammed into training sessions, considerably more than a person can retain and especially if the knowledge is not applied. If the training is supplemented with incremental assessments and follow-up work, it is easier to gauge and manage individual and team progress.
“Supplementing training with coaching is good. You want people to learn the basics in a one- or two-day class, but it is also helpful to have coaches help them move beyond the basics,” said Rally’s Olson. “I don’t think you need to hire a third-party consultant or trainer; you can promote from within, you can hire from outside, there’s a number of things you can do. It does make sense to hire a third-party consultant to kick things off because they have experienced similar situations and can help adapt things to your needs. I wouldn’t try to transform your organization without one.”
Because there is no single right way to implement agile practices, it behooves team members to learn the basic principles, apply them, and then adapt them to suit the unique needs of their project or organization.
“The biggest risk is that you think you get agile just by adopting terminology, role or meetings from a defined approach like Scrum,” said Hansoft’s Lidman. “We often see people adopt the terminology while doing something that is quite contrary to agile principles and values.”
VersionOne’s Culling agreed. “If you have a basic understanding of Scrum and try to apply it by doing one-week sprints, but you don’t have any understanding or appreciation for things like automated testing or work-in-progress-type limits, if you’re still [thinking in terms of waterfall], you’ll design for a week, code for a week and test for a week. Although you’ll be delivering products, which is awesome, you’re going to build up technical debt, and your testing period will become longer and longer. That’s a death spiral for a codebase, and a potential problem for an experienced team,” he said.
Being agile is about being flexible and dedicated to continuous improvement, which may be easy to forget when the team knows just enough to be dangerous. Rather than being overconfident, which can lead to misunderstandings about project scope, priorities, architectural implementations, and team dynamics, it is better to be open to making mistakes, acknowledge them, and learn from them so that processes and practices can be improved incrementally over time.
