Being on an agile team is not all that different than being on any other team, according to Aaron Bjork, principal group program manager at Microsoft. On a team, the teammates have to understand the game, communicate with one another, collaborate, and function together toward their goal.
“The idea when you are putting together your software team is that you are putting together a team of people that is going to work together, and they live across roles,” he said.
When an organization says it is agile, it is increasingly referring to shortening its development cycle, getting features in the hands of customers more rapidly, talking about visibility, and talking about the work and also the results of the work, according to Dan Chuparkoff, group manager at Atlassian for JIRA. While the essence of agile seems simple, the transition can be difficult.
It is impossible for an organization to come in and say, starting next Monday, it is going to be agile, Chuparkoff explained. “Agile is not a light switch,” he said. “It is a process and a long cultural change.”
When approaching agile for the first time, organizations need to understand that they are going to have to fail first in order to succeed.
“Don’t expect to get it right the first iteration or first sprint. You need to be willing to try things and learn how to measure your successes and failures so you can improve,” said Jeff Smith, development manager at Rally Software.
Hitting a homerun
There isn’t one way to be successful in agile, but there are a few practices that can help get you there:
Pair programming: Pair programming is simply the act of having two people sit down in front of a screen and write software together. One person writes the software while the other observes and comments. “It really helps to build software with fewer defects,” said Bjork. “It also serves the purpose of learning as you go and sharing what you are thinking with somebody else as you go, and in the end that usually brings developers and testers closer together, and there are huge wins in that.”#!Continuous integration: The idea of continuous integration is that teams are checking their code into a main codebase multiple times a day. “You are essentially keeping your codebase fresh and making sure it continually works,” said Bjork. “Staleness in your codebase leads to bugs and integration problems downstream.”
Continuous Integration also acts as a safety net, according to Chris Clarke, senior vice president of product management at CollabNet. “You can’t be turning the crank very fast if you got an army of manual testers that are sort of standing at the end having to manually test everything,” he said. “You have got to be test-driven development about it. You have got to have infrastructure that can fire off and execute a battery of automated tests quickly without slowing the developers down.”
Creating teams around the right kind of conversations: “If you are in a large organization and you are trying to scale, you want to be able to have a leadership team that is having synchronized discussions where they are making decisions about what different teams are doing,” said Andy Powell, vice president of customer experience at VersionOne.
Measuring business results: Look at and define the things that are going to matter to the stakeholders, the upper executive team and the customers. “Why you do something and what you do is actually more important than how you do it,” said Clarke.
Alignment with strategy: Teams want to know that they are working on the right task and how they can contribute to the overall success of their business, according to Matt Holitza, product marketing analyst at Rally Software. “When you tie what you are doing on the development team to what the business goals are, it results in less rework, less priority shifts and less fire drills at the end of a cycle.”
Seamless collaboration and context: This allows teams to know what is going on without having to ask. “It allows teams to understand if there are any dependencies that are going to impact their work in real time,” said Holitza. “If a build fails, they understand that it has failed, and no matter where they are you don’t have to have a status meeting to tell everybody. You don’t have to call everyone and tell them the build failed. They can look; they can be aware of this in real time.”
Collective code ownership: Every team member should have the ability to make changes to code as necessary. “Teams tend to deliver higher-quality code because they are going to be maintaining it in production,” according to Holitza.
Traceability: According to Magdy Hanna, chief architect at Rommana Software, it is important to document project-management activities into user stories. “Resources must be allocated to perform-specific tasks for specific user stories,” he said. “Timelines and milestone must be determined based on what tasks should be completed for which user stories. Even risks identified throughout the project must be traced back to user stories that are impacted by those risks.”
Traceability also makes history of a certain artifact available so developers and teams can see what happened to an artifact and why decisions were made without having to ask, according to Holitza. #!Dropping the ball
Every agile methodology has its own idea of what best practices are, but depending on the team and organization, practices are usually altered to fit their needs. Consequently, what may be best practices for some may be downfalls for others, and then there are some organizations that just don’t get it and struggle with a couple of key basic practices.
“You have some teams performing admirably, and you have an awful lot of companies struggling terribly,” said David Jabs, CTO of AccuRev.
One key concept agile teams struggle with is the purpose of standup meetings, according to Atlassian’s Chuparkoff. In the past, standups were status meetings that usually lasted at least 30 minutes, but in an agile process, standups shouldn’t be more than 10 to 15 minutes, he explained. The key to a successful standup is being short, concise and to the point. It shouldn’t be used as a forum to make announcements or updates.
Organizations should also be careful and make sure their agile teams aren’t relying on verbal communication for documentation.
“In many agile projects, for all the wrong reasons, somehow verbal communication in agile meetings and hallways and cubicles has replaced documentation,” said Rommana’s Hanna. “This is dangerous because those verbal communication are not reminders of the years or even over the weeks of the project. Besides, decisions made through verbal communications, when not documented, no one is accountable for them.”
Requirements are another area in agile that organizations and teams tend to struggle with, according to Jabs. “People tend to think agile means no requirements, and that is absolutely not true,” he said.
Requirements still exist in an agile project; they are just executed differently. “An agile team is gathering requirements constantly; they are refining requirements constantly,” said Microsoft’s Bjork. “That is different from a waterfall team that dedicates a period of time to gathering requirements and then says these are the requirements for the project, and then goes and executes on them.”
On an agile team, requirements should be adjusted as the team learns, and they should be continuously tested against stakeholders and customers, according to Bjork.
Requirements should also be complete. According to Hanna, user stories are equivalent to a very high level of requirements, and if they are incomplete, a developer won’t be able to write good code.
“A user story must be broken down to a set of positive and negative scenarios before development can start,” he said.
Another big obstacle standing between an agile team’s success is a disconnect in management. “It isn’t about ‘I want my team to be agile, ‘it is about ‘I want my organization to be agile,’ ” said CollabNet’s Clarke.#!While a lot of teams may have made the transition to agile, most managers haven’t changed and are still waterfall in their outlook, according to Jabs. “That disconnect percolates through the organization a little bit and makes some of the agile planning less effective than it can be,” he said.
Leadership needs to not only support the transition to agile, but also actually participate in it, according to Lowell Lindstrom, vice president of services at VersionOne. “The mistake that most organizations are making today is that the leadership isn’t really participating in the transition,” he said.
“They’ll sponsor the transition, fund the transition and support the transition, but they don’t actually participate. They don’t actually do agile. They don’t actually practice the things that they are asking their team members to do.”
The problem is that few managers got to where they are by practicing agile, according to Lindstrom. He explains that with time this problem will dissipate as the next generations of leaders who kind of grew up with agile arise.
“Successful management and team alignment comes down to a matter of mutual trust,” said Rally’s Holitza. “Management has to trust the agile team by empowering them to make and meet commitments, and the agile team has to trust that management will both insulate the team from extraneous requests and that their decisions are in the best interest of the business.”
Choosing a game plan
There are many different types of agile, and very few organizations are purely agile. Most organizations adopt some sort of hybrid agile practice depending on what works best for the team, the complexity of the work, and how frequently and aggressively a team needs to collaborate to get that work done quickly.
“Agile by definition is something that reacts to change really really well,” said Atlassian’s Chuparkoff. “When you are running an agile development shop, you are reacting to your external inputs, you’re reacting to the change that you encounter every day and figuring out the best way to produce the thing so that you produce it in a way that best fits your team.”#!When transitioning to agile for the first time, Microsoft’s Bjork suggested starting with a Scrum approach. “Scrum is easier for people to transition to because there is a little bit more of a recipe book for Scrum that has roles in it, has a schedule…” he said.
A Scrum team works in short iterations and is optimized for collaborating to quickly solve a complex problem. As a team starts to mature, it starts to move into a more Kanban-like approach, according to Rally’s Smith. Kanban requires a team to be more disciplined and familiar with agile practices, he explained.
Unlike Scrum, Kanban doesn’t focus on a date-driven milestone. The process is more isolated and flow-based, and it focuses more on getting a predictable managed flow through a set of activities, according to VersionOne’s Lindstrom.
“I think part of it is you measure different things to gain predictability between the two,” said Smith. “In Scrum, you are much more talking about the velocity that you can achieve during a given time box, whereas with Kanban you are measuring how fast you are flowing work through the system.”
As teams start to learn from their process, they are more likely to transition into a hybrid agile approach by adopting practices from each methodology based on what they know works well in their team, according to Microsoft’s Bjork. “I see that a lot of teams make the jump from waterfall to Scrum and learn to do Scrum, and then they start to incorporate elements of Kanban as their business needs allow,” he said.
Scrum (and modified versions of it) has been adopted by the majority of organizations, according to AccuRev’s Jabs.
“We see people start with Scrum and then modify it in some way to meet the particular needs of an organization,” he said. “That is something agile explicitly allows if it is done based on a sort of introspection of the process to a given need.”
Lean and Kanban often go hand and hand, but lean’s practices and principles are essential to all agile teams, according to Bjork.
“It’s all about eliminating waste in your process and making sure that your process isn’t contributing to waste,” he said. “Everyone should know what they are and understand them because waste is one of the biggest problems we have in software teams.”
Lean is a philosophy of not doing things that don’t add value to an organization’s value stream. It is a good thing as long as the organization understands it.
“Lean always comes with trimming some fat, cutting off some fat, and this is not how software processes work,” said Rommana’s Hanna. “The software process is not a piece of steak where we start to trim out all the fat that is bad for you, because the trick here is to know what to trim and what not.”
According to AccuRev’s Jabs, managers who don’t get lean often think it means cutting staff even if that staff is doing valuable work, and that isn’t what being lean is all about.
“Lean really is at the end of the day about being able to deliver value to the customers rapidly and incrementally,” said Rally’s Holitza. “How you get to that point is not as important as the end goal of getting to that end point where you are able to deliver value rapidly to your customers.”#!Choosing a tool for success
Experts stress that tools are necessary to strengthen the agile process, but not just any tool will bolster an organization.
“Just going out and buying a tool and thinking that that is going to make them agile, I think that is one of the most classic mistakes or pitfall that teams run into,” said Holitza. “The tool is not going to make you agile. You have to have a well-defined process and approach, and then have a tool be able to support that process or multiple processes.”
Chris Riley, technology evangelist at CloudShare, said organizations should be more deliberate about their choice of tools and their impact on the entire process.
“Often development teams make decisions reactively based on a current pressing need,” he said. “Being only reactive forces them not to look at the complete picture, which is necessary to take advantage of all the benefits of the process.”
When looking for a tool that is going to support the organization’s agile process, it needs to be something that development teams can come into to quickly to update their work, have context around the work they are performing, and help them understand what is happening at a certain level.
“Being able to have a tool that gives the developers an understanding of where they fit in the bigger picture [that] they like using is really key because that is going to drive your adoption and ensure that the organization embraces the need for the leadership to be able to plan and track the work effectively,” said VersionOne’s Powell.
Tools should give teams a way to break their stuff into pieces, be specific in what is contained in those pieces, make information visible, allow the team to connect as a team to the same information, and, most importantly, be customizable, according to Atlassian’s Chuparkoff.
“Every team is not going to work the same way; your tools have to be flexible enough to adjust to the way your team operates,” he said.
At the end of the day, developers just want to deliver great code and make a difference to their organization, according to Rally’s Smith. A tool should be easy for the team to use and not get in the way of the developers.
“Having good tooling allows me to write code because things like status infor
