Agile Software Development

Things You Observe in an Agile Project

If we compare our agile toolkit with a menu in a restaurant, the foregoing key practices are entrees. In addition, many agile projects make heavy use of complementary tools (side dishes) that either support or enhance the impact of the key practices. Although they seem optional, they should not be ignored.

Pair Programming

Two people work together at the same time on the same code using one keyboard. Pair programming has often had a stigma attached to it in traditional organizations. “Why would I pay two people to do the job of one?” Well, in reality two people often do the job of three! In the past, I’ve taught developers in training courses for Java or Smalltalk. During the course, I offered every student the opportunity to pair up with another student during the exercises. Some thought it was a good idea; others argued that they did not pay good money to not have access to the keyboard all the time. Of course, I did not force anybody either way; I just offered the option. I admit, originally the idea was a bit selfish, because I could not assist 10 engineers with individual feedback all the time. It turns out that some of the pairs helped each other with the most basic questions and needed less attention from me. Because they did work out so many things together, they used the instructor time for the tougher questions. At the end of the week, the pairs completed much more course work than the individuals. As a matter of fact, the individuals often held the pairs up in their learning goals. And as a positive side effect, the pairs usually had more fun and shared more laughs.

One of the secrets of pair programming is psychological. Adults, especially, learn most effectively by doing rather than listening or reading. The knowledge is internalized by the learner the first time someone explains or demonstrates it to that person. That is exactly what happens in pair programming. One person does a thing the other person might not know about. Through the question and answer process, the expert explains and the listener receives the knowledge. Now, equipped with the knowledge, the former listener practices it, and so forth. As a positive side effect, two people then know the same code. Think about the benefits of that in terms of sick days, vacation time, and other employee fluctuation.

Building pairs to increase productivity is not new. As a matter of fact, the army uses pairs of soldiers especially during battle at the front. Two soldiers together are more likely to stand up to an attack than individuals. Police departments also often operate with pairs of officers assigned to a case. That reduces slack but it also provides support in the event of a critical situation.

Daily Stand-Up Meetings

Short daily meetings are commonly practiced in Scrum projects, which we will focus on in a later chapter. The art of these projects is that no other meetings are scheduled besides these daily stand-up meetings, which should not last longer than 15 minutes. If you have ever tried to keep a meeting with 5 to 8 people in the 15-minute range, you know how difficult it can be. In Scrum, for example, every team member provides answers to three questions only:

• What have you done since the last meeting?

• What are you planning on doing until the next meeting?

• What issues and impediments are you facing that prevent you from accomplishing these things?

What an agile project manager is interested in are the deliverables and tangible results. That is, in my experience, the point where the daily stand-up meeting most frequently fails. Because we are used to weekly or monthly status reports, we like to elaborate on accomplishments to justify our existence in the project. But seriously, how much tangible output can someone produce in eight hours of work? But these small accomplishments demonstrate daily progress to other team members. Also, quite an important difference from other, traditional, status meetings is the fact that the team members report to each other, not to the project manager.

Stories About Requirements

Stories on index cards are a very common practice in extreme programming. They can be estimated and planned for, and picked up by pairs of developers. Using the following template

<as a > I want <the feature> so that I can <business value>

the team can produce requirement cards and post these cards in the team room. Once reviewed and prioritized, the cards are subject to iteration planning, and team members sign up to test and develop the items on the cards. Stories just seem to have the right style and are the right size for agile teams to work with requirements.

Writing these stories is not as easy as it might first look. Many project teams struggle with coming up with the right size for the story. Some stories are too granular and user interface focused (for example, “As a customer, I want an OK button so that I can save the changes made to my account information”); other stories are too broad (for example, “As a customer, I want to order a product online so that I can save time going to the store myself”).

Team Rooms

The majority of agile projects are based in a single team room, which makes face-to-face communication very easy. In the past, project teams posted their index cards on the wall or on whiteboards and signed up for pair programming by simply looking around the room. Even today, with more tools and technology available to facilitate agile projects, the team room still plays an integral part. Instead of physical index cards posted on the wall, stories are captured on electronic “cards” and projected against the wall or against whiteboards turned into smart-boards with more features to store results more quickly and more conveniently. The idea behind all this innovation, however, is the same. The entire project team always shares and works with the same information and collaboratively works toward the same goal. Therefore, electronic communication across continents is less efficient than communication among team members in the same room. In addition to overcoming difficulties in conducting the daily meetings, geographically distributed projects are challenged by meeting the goals of continuous integration, stakeholder feedback, iteration planning, and pair programming.

Frequent Releases

A build is a collection of tested and integrated software components that can be released either internally for verification or externally in a production environment. A build process—which includes the compilation, testing, and integration of all software—can either pass or fail. When a build passes, it represents the last good build. That build is something a test engineer, business analyst, or other stakeholder can work from and use as a test against the original story. A release, on the other hand, is a good build that has enough functionality to be released—internally or externally. For example, consider a project that is estimated to last for 12 months. During the first phase, a group of stories is aligned to create a release after 8 months of the project. The second phase of the project (months 9–12) include the other logical group of requirements. The first release can be used inside the organization or unleashed externally. The concept of builds and releases has tremendous influence on agile portfolio management, which I’ll discuss in the second part of this book.

Self-Organized Teams

When you observe an agile project, you’ll notice, for example, that a pair of developers agree during the daily meeting to tackle a story card—taking ownership and responsibility for a story card for at least a few hours or until the story is implemented. They refer to themselves as self-managed or self-organized. Surprisingly, at the end of each stand-up meeting, you’ll notice that almost magically the work got divided and distributed without any top-down commands. During the next stand-up meeting, team members will report their progress to one another, which means they are also controlling one another. The traditional command-control paradigm we are so used to working in has shifted to a team-organized approach. Does that mean a manager is not needed anymore in an agile project? Because the team is already self-managed, all it needs is a leader. The person in that role will drop duties and responsibilities that the team has already taken over, but he or she will pick up new challenges, especially those related to project leadership. Here are just a few examples:

• Facilitating the iteration retrospectives

• Prioritizing the stories for the project and iteration with the business

• Estimating requirements

• Communicating the progress of the project

• Removing organizational and technical obstacles for the team

You might argue that these are responsibilities project managers already had in the past. Yes, but please remember, the leader’s sole responsibility is to inject the vision into the project and keep the team focused without a command-and-control style. It sounds like an easy job for future project managers in agile projects, but reality shows that the opposite is the case. Good leaders can steer a project without the team feeling that it is being led. Team members can just do their jobs while the leader creates an environment where everyone feels that everybody is working toward the same goals.