A recent client was in the beginning throes of assembling an agile team. The Team Lead had fought battles with management for three months and was eventually assigned a war room. Once he got the room, he placed half the number of computers as team members - 3 computers for six developers. He established daily standup meetings. All of this was to develop a well-functioning agile team. Unfortunately, the team struggled with test-driven development, architecture, planning and managing the user stories, and maintaining focus.

Although the team lead had many great intentions, he forgot something fundamental: the goal of software development is to deliver high-quality software in which the customer finds value. Customers are satisfied when the system is deployed and adds value to the organization. They don't care how the system was developed, only that it does what they want and is defect-free.

Just as the world pays close attention to the first 100 days of a Presidential or Congressional term, the first 100 days of an agile project are critical. During the first 100 days, the Team Lead should focus efforts and the team on essential tasks that deliver high-quality software. These tasks include team selection, daily standup meetings, organization of the user stories, a release plan, coding standards, a focus on test-driven development, establishing automated deployment procedures, and source code control.

Team Selection

At POMIET, we try to keep in mind what Fred Brooks and many others have pointed out: there is a 10 to 1 difference in performance between a great software developer and an average one. So, we make it one of our highest priorities to secure the best people for a team, even if it means fewer people. There have been a few occasions when we begin the project with just one or two people who understand how to gather and organize the requirements - maybe a project lead and a tech lead. Once these individuals get a handle on what the system is to do, the team can grow.

One handy interview technique we have employed is called Pair Interviewing. Essentially, with Paired Interviewing, the interviewer sits down with the candidate, and they write a simple program together. As they do this, the interviewer can see how the candidate thinks, how they approach problem-solving and their "coding personality." We can determine how well the candidate will work with the rest of the team and how much the candidate knows.

Standup Meetings

POMIET teams start daily standup meetings from the first day of a project, even with just two people. This commitment establishes a needed routine early in the project. As the team grows, new team members join in. Standup meetings are essential because they keep individuals focused on the tasks at hand. If someone is spinning their wheels for more than a day, the rest of the team knows and can jump in to help. If someone is being lazy, the rest of the team knows about that also.

User Stories and Release Planning

The first and most crucial task facing the team is understanding the details of the expected work product. This understanding grows by gathering user stories. Ideally, these stories are product requirements that can be implemented in three to five days. If a story is too large, we break it up into smaller stories until each story is understood and estimated as three to five days of work.

As we develop the stories for the most important features, we also assemble a release plan. The release plan encompasses all features/feature segments that can be accomplished within a foreseeable period - 1 to 3 months. The details of these features and stories are understood enough to implement these stories in that timeframe. Details for the product's other features need not be delved into until the next release planning cycle.

After completing the initial release plan, we review it with the client product owner, directing the team toward the highest priority stories. These stories are then queued up for a development cycle, typically three weeks. Once the stories have been identified, the team works hard to complete them within the cycle. It can hurt team morale when a team consistently fails to complete all the stories in a cycle, and so we also work hard to determine the team's actual capacity for work within a cycle.

Coding Standards

As the team begins to develop code, a few simple coding standards are developed and followed. It doesn't matter what the standards are, as long as they are observed. Many teams waste time determining the criteria. At POMIET, we have a senior technical person make some decisions and have everyone fall in line. Try not to make this a big deal. One good way to encourage using standards is to create a code template in your IDE and share the template with everyone on the team. Then, when each developer automatically formats their code, it automatically falls in line with the standard.

Test-Driven Development

The best thing a team can incorporate into their test approach is test-driven development. This one practice has revolutionized the quality of software products; however, the practice takes time, energy, and accountability. Since developers do not naturally write tests with their code, it is important to focus more energy here than any other practice. Be aware that it may take up to three months for the practice to become a habit that the developers fully embrace. However, once you master this practice, the other ones will fall into place.

Often a POMIET team has over 80% of the system covered with automated unit tests that run multiple times each day. We hold our teams accountable for writing tests by reporting the number of tests and the code coverage percentage at each cycle review. This accountability gives us a considerable advantage when changes arise and confidence to meet software development challenges.

Deployment

Once we write code with tests and follow standards, we must work out how to release the code. This practice is a bit unusual as far as software development practices go. Typically, developers focus on getting a system to work on their box that they don't worry about deployment until they have to. Remember that in an agile environment, we are looking for customer feedback as soon as possible. The only way we can get this feedback is to allow the customer to access the product as quickly as possible. Therefore, one of the first things we try to do is establish deployment procedures. At the end of our first cycle, we try to have a simple system deployed into an environment that maps as closely as possible to the production environment. Going through this process at the beginning of a project encourages the team to automate the whole process.

For example, it took us two days to deploy to a production-like environment the first time we tried on one project. In many shops, that would be considered a waste of time. For us, though, we saw it as a learning opportunity. We continued to deploy each cycle, automating as much as possible along the way. After a couple of months, we could deploy a new, thoroughly tested system in 5 minutes. This speed gave us a huge advantage when it came time to push out maintenance updates - the downtime for updates was less than 30 minutes.

Source Code Control

Finally, as a bit of infrastructure, we always use a sound source code control system. Depending on our client, we may use one of the large source code control systems like Microsoft TFS, but we prefer GitHub. We have written scripts that enable us to use GitHub and synchronize less frequently with the company standard product. Though this isn't ideal, syncing with GitHub multiple times each day and synchronizing weekly with a client system is better than daily fighting with a large, difficult-to-use system.

Conclusion

As you can see, when you begin a new large project, the first 100 days set the tone for the rest of the project. In these first three months, focus on the most important practices and parts of an agile process. Setting up a war room and enforcing pair programming can be good practices, but they don't create the most productive environments. Understanding what needs to be done, setting a plan for doing it, and creating an infrastructure to support a good team should be your primary focus.