While it is always important to remember that Agile is a set of values and principles, it can be useful to look at some of the practices that teams implement when following Agile. (If you haven’t read What is Agile? stop and read that before this article.) Practices are only Agile to the extent that they help a team follow the values and principles. In this post we are going to look at how a mature Agile team does their work. There are a wide variety of practices used by Agile teams. We are going to focus on the general aspects of some common practices.
Your team may arrive at something similar to support Agile principles or you may end up with practices that look very different. Just don’t forget that the important part is the why behind each practice.
Agile Team
Agile software development relies on a strong team. In this section we are going to look at some aspects of creating and nurturing a team that supports following the Agile Principles.
Team Composition
Agile principles suggest that the best way to write software is when you have face-to-face communication every day. In many organizations, the best way to do this is to make a team of everyone that is needed and put them into a big room to work together every day. So a team would consist of developers, business owners, and testers. Sometimes the business owner role has to be filled by a representative, but the idea is that you have people working together every day that wear all the various hats that the project needs to make progress.
Supporting Agile
It is important for the individuals on a team to buy into a different way of working. Some places have had success in forming a new Agile team by asking select individuals if they want to join. However, a new member has to sign an agreement that includes the Agile Principles as well as some other language about being willing to participate in a team driven environment.
When you try to fit Agile onto an existing team, it is easy to run into resistance from people who aren’t interested in taking a new approach to software development. It is not uncommon for a few people to wreck the progress of a team that is trying to follow Agile Principles by being unwilling to participate in a team-driven culture. While most people find the switch to Agile challenging but very rewarding, one detractor can bring progress to a halt if left unchecked. The easiest way to avoid this is to do your best to make sure there is support up-front for the way that the team will be working and making decisions.
Cross Trained Teams
Valuing face-to-face interactions lends itself to cross-functional team composition. Good communication leads cross-functional teams to do a great deal of cross-training—even if it isn’t formal. If a team is truly focused on delivering valuable software rapidly to the customer, they can’t have silos of who can do what. That doesn’t mean that the business owner on the team is going to learn to write code (though that does happen sometimes) but it does mean that working together on the same team should recreate organizational silos in a smaller setting.
Practices like pair-programming can help promote this level of collaboration and cross-training. In a well-functioning team, individuals will be constantly sharing how to do new things. It is a good sign when you hear people asking to help with things they haven’t done before so they can learn.
Defining Work
The way a team defines their work can heavily influence how they approach doing the work. If the work is defined in a way that supports Agile Principles, it is much easier for the entire project to follow on that foundation. There are many ways to do this, but here are some very general approaches that a number of high performance Agile teams have found work well in their organizations.
Story Board
Most teams find that in order to follow the principles regarding communication, they need some type of way to visualize work. This is often done with some type of story board where work can be represented on cards by placing them in different columns to represent the state of that work. The principles tend to suggest a few different states (columns) that are good to track visually.
First you need some state that shows work that is yet to be done. Typically, this is called the backlog. Since we have a principle that we are going to focus on delivering valuable software, this backlog is usually prioritized with the customer deciding what the most valuable thing to put at the top of the list. If the software can be kept mostly in a state where it can be released into production, then the code that has been developed can be put to use whenever the customer wants to start using some of the value that has been created. The prioritized backlog helps make sure that the next item the team works on represents the most valuable thing to the customer.
After the backlog, there is usually a state of work that says it needs to be discussed with the customer. This is where the developers, customer and testers get face-to-face and walk through what it means for the particular piece of work to be done. This state can be called requirements, discuss with user, or whatever makes sense but it should involve face-to-face interaction between the people who will use the code and the people who will create it.
The next state is usually doing the actual work. So a name like in progress is appropriate. This is where the work should go that is actively being developed. Once the work is done, there should be a state where it gets shown to the user to make sure that what was built was what they actually need. This state can be called verification or something similar. Once the user agrees that the work meets their needs it gets moved over to the done column.
This is a very general approach and some teams find it works well to add rows (swim lanes) to represent different types of work or additional columns to handle other states that are necessary in their organization. Others add columns that represent when the work gets deployed to staging and to production. The way work is represented should be malleable and constantly adapting to the needs of the team.
While we’ve described a physical board, there are a number of tools to create virtual software boards that allow this approach to visualizing work and can be especially helpful with a distributed team.
Stories
Most Agile teams define their work as stories of some sort. The reason for calling them stories is because it helps promote the value of concentrating on user collaboration rather than contracts. A “requirement” has quite a bit of baggage associated with the term that tends to prevent collaboration. A story needs to be something that can be written quickly as a placeholder for work with the idea that it can be refined through collaboration when it is time to actually do the work later. Many teams find that using a simple template can help keep the stories short and easy to create. Here are two examples:
As a visitor
I want to create an account
So I can apply for a loan
As a registered user
I want to view my order details
So I can I can see when my items will arrive
There isn’t anything special about the template other than making sure it captures who, what and why. This is just a way to help enable communication and get people on the same page for the collaborative discussions that should happen before beginning the development work.
Developers tend to write stories from the developer perspective. So you might see a developer write a story about some section of programming they want to have built. For example:
As a developer
I want to have a database
So I can store information
Obviously the application is going to need to have a place to store data, but the problem with this story is that it doesn’t keep the work focused on what the user considers valuable. We are following a principle of delivering valuable software to the user, so we need to organize our work in keeping with this value. One of the easiest ways to do this is to make sure that the stories represent how things will be different in the user’s world when they are completed.
Developers tend to see applications as different layers. There might be a database layer that is underneath a business rules layer and that is underneath a GUI layer. Users, on the other hand, see an application as representing something they do. They see it as a piece of functionality that cuts through all those layers.
So developers see the app as the layers of a cake with each layer built on the one below it. Users see an application as a bunch of slices of cake with each slice letting them do something useful. While it may take some effort for developers to get used to building an application the way users view it, it is very possible and the ability to align the development of the work with the user’s definition of value is a powerful way we can follow our principles.
User stories should be written as slices that represent complete functionality that a user can look at and use. For example, instead of building a database layer, we can start with a story that speaks to the ability to login to the system—building just the parts in the different layers necessary to support that slice of functionality.
Doing the Work
As an Agile team evolves, they will develop, adopt, or borrow a number of software development practices that can be used to help them follow the Agile Principles. In this section we will look at a few development practices that many teams find helpful.
Pair Programming
Pair programming is a common practice used by Agile teams. It puts two people at one computer working on writing code. While it might seem like everything will take twice as long to code, programming is a thinking activity more than it is a typing activity. Two developers are less likely to get stuck and more likely to catch problems as they occur. Many teams have found that for some types of development, pair programming is actually faster than the alternative.
Another advantage of pair programming is that as people rotate through different pairs, skills are transferred through the whole team. If one person finds a keyboard shortcut that saves them time, the person they are pair programming with will pick it up and show it to the next person they program with. Pair programming is an effective way to continually increase the skill of everyone on the team.
New teams that are not used to working collaboratively can especially benefit from pair programming—especially when they are first formed. If everyone is required to always write their code as a pair, the team develops good communication skills and much lower resistance to asking someone else for help. Often after a few months of required pair programming the requirement can be lifted and the team will naturally continue with a much higher degree of interaction than they had before. Even if they aren’t constantly programming in pairs, they are much more prone to ask someone to come over and collaborate after having pair programmed for a time.
Continuous Integration
Since Agile says that our highest priority needs to be continuously delivering valuable software, anything we can do to streamline the delivery process become very important. Automation helps follow this principle. Continuous integration is the process of automatically building and testing the software every time a developer checks in code. This helps reduce the amount of time from when a bug gets checked into the code until it is noticed. A common problem in software is for a developer to check in a bug that works on their machine, but fails for everyone else. A continuous integration server will run the changed code and notify the team of the failure so it can be fixed quickly, while the developer still has the context for what they were working on when they made the change.
The longer that elapses between a bug entering the code base and identifying it, the more time it will take to fix. Continuous integration helps keep this cycle as short as possible.
Test Driven Development
Several of the Agile principles deal with creating good design. Others talk about the need for technical excellence and the ability to continuously deliver new functionality. Test Driven Development is a practice that most teams find support all of those things. TDD involves writing tests that would pass if the code you’ve imagined worked correctly and then writing the imagined code until it exists in a state that will make the tests pass. Not only does this approach help maintain focus on the goal of the current work, but it also provides a great deal of safety when code needs to be changed. When a developer can make sweeping changes through the application and at the press of a button verify that no unintended side effects have been created, it is much easier to respond rapidly to changing requirements.
TDD also can help developers keep things simple and not over-engineer their code. They can choose the simplest approach and get the software doing what is required functionally with tests to prove it. If they then discover something needs optimized or requires a more complex approach than what they tried originally, tests make it easy to tell if the more complex approach still functions the same as it did when it was simple.
Behavior Driven Development
While Test Driven Development focuses on making sure that the pieces of code do what the developer expects, Behavior Driven Development focuses on making sure that the application as a whole does what the user needs. BDD is a practice that helps teams follow the Agile Principles that discuss creating good communication with users.
There are different tools to facilitate BDD, but the key piece is creating a plain English description of what the software needs to do that users, testers, and developers can all agree on and then making that description into something that can be executed against the application. This means you have a specification (the description of what the software does) that everyone can understand, but it always stays current because if it stops describing the application’s behavior, the build breaks.
The key point of BDD is that it enables better communication with the users and provides a way of clearly articulating and specifying what the application is supposed to do along with a mechanism to automatically verify that it behaves as expected.
Rituals
Most teams will naturally develop some rituals in the way they work. In this section we will look at some of the rituals that many Agile teams have found useful as a way to follow various Agile Principles. The value isn’t in the rituals themselves, but in the principles they follow. A highly functioning Agile team will probably tweak and modify these rituals when they find changes that will let them better follow Agile Principles in their particular environment. These rituals are a good place to start as long as the team understands the principles behind them.
Daily Standup
To follow the Agile principle that says the most efficient way of communicating with and within the team is through face-to-fact meetings, many teams find it useful to establish a ritual that helps facilitate this communication called a daily stand-up. The idea is to get everyone together for 15 minutes and walk through the current state of the work.
One approach is to go around the room and ask everyone to say what they worked on yesterday and what they are working on today. Many teams follow this approach, but running a daily stand-up that is organized around the individuals usually results in meetings that aren’t driven by user needs. Individual centered stand-up meetings tend to spend more time discussing issues from the greater organization than on topics that help move the work forward. The user needs should be represented by the user stories. Stand-ups that focus on the user stories keep the actions of the teams better aligned with the Agile Principles and keep work and discussions focused on the value being provided to the user.
Once the team has heard a brief update about each user story, it is usually a good time to make any general announcements to help coordinate the work. For example, a team member may find it useful to remind everyone that they will be out on vacation for the next two days, the team lead may want to remind everyone to fill out their time sheets, etc. Once the team has covered the stories and any announcements, there will be people who need to get more details or talk through some issues. When the stand-up is over, these discussions can take place with the more detailed conversations they need to move forward on their work.
Stand-ups typically should last about 15 minutes and many teams conduct them standing up because it is easier to keep the meetings short if everyone is standing. Standing up also helps facilitate the interactions after the meeting where team members need to continue a conversation about a particular story.
The stand-up should keep everyone up to date, but you don’t need to have a 20-minute discussion about each story—especially if it isn’t relevant to everyone in the room. A few questions and clarifications are fine, but if it looks like the discussion of a particular story is taking too much time, it is usually best to move on and let the people involved dig deeper after the stand-up is over.
Retrospective
The Agile Principles say that teams should regularly reflect on how to become more effective and adjust behavior accordingly. This principle is usually followed through the use of retrospective meetings. A retrospective is a meeting where team members discuss what is going well and what can be improved. Some teams do these to coincide with the rhythms of other rituals in the project. For example, if a team is batching their work into two week periods they might do a retrospective after each period. Teams that approach their work as a continuous flow, may still choose to do regular retrospective meetings every two weeks or some other interval. Some teams find it effective to just let team members call a retrospective whenever they feel one would be helpful.
There are many different ways retrospectives can be conducted. One simple approach is to give everyone two sticky notes and ask them to write one thing that they feel is going well and one thing that they feel needs improvement. Group the notes on the wall in these two categories and then let people vote for which “needs improvement” notes they want to address. Take the top voted items and spend some time discussing some concrete steps that will improve things.
These changes should usually be things that are small, manageable and something that can be rolled back if it doesn’t seem to help. The goal isn’t to fix everything—just to make adjustments to areas that need improved and keep the parts that make things better.
User Demonstrations
Several of the Agile Principles talk about focusing on working software that the business owner can actually use. Having regularly scheduled times to demonstrate software for stakeholders and users can help teams follow these principles.
These demos can be formal demonstrations in a conference room, every two weeks or something much less formal that just involves getting the users around a developer’s computer and letting them use some new functionality.
The “right” way of doing it depends on your team and your users. However, most teams find they get the most out of demonstrations when a user is actually the one “driving” the application. If the team has users embedded in the team, those users are an excellent choice to demonstrate the application to other stakeholders.
