Mark Shead

What is Behavior Driven Development?

Test Driven Development is the process of using examples to guide the development of each function of your software. In TDD you create your program by working through a loop like this:

Write an example as a simple test
Watch the test fail
Write code to make the test pass
Refactor and clean your code

So what is Behavior Driven Development? BDD is somewhat similar and complementary to TDD. However, where TDD focuses on driving the development of the individual functions in the code, Behavior Driven Development applies a similar process at the level of features.

Since features are driven by user needs and most users are going to express themselves in natural language rather than the language of code, BDD starts with a natural language to create examples. To make the examples executable BDD requires a little bit of structure and this structure allows a bridge between the world of programming and the world of natural language requirements.

A BDD feature file consists of one or more scenarios. These scenarios are just examples of how the application should behave from the standpoint of a user. For example you might have a scenario that says:

Given I am on the login page
When I attempt to login with valid credentials
Then I am shown the application dashboard

And another scenario that says:

Given I am on the login page
When I attempt to login with invalid credentials
Then I am shown a login error message

These examples are written in English, but are still very structured. The Given portion tells the starting condition for the example, the When line tells what you actually do, and the Then tells what results are expected.

Behind the scenes, your BDD framework will match this natural language to code that developers write to actually do those steps, but it is always driven from the natural language.

The feature files then become the documentation of the application, but unlike most documentation they get executed against your program. If this documentation ever gets out of date, then something will break in your testing stage. Any change made to the software gets verified by every example that was created in this process of documenting the requirements as an executable specification.

None of this is magic. It is a lot of hard work and requires a lot of discipline across the development team, but the results can be amazing. Not only does BDD streamline the requirements process, but it brings the value of QA to the beginning of development.

One BDD project I coached involved a complete replacement of a very important legacy mainframe system. The system went live a year early and at 1/3rd the cost of what had been estimated using their traditional development method. The ability to execute every requirement against the application let the team regularly deploy new changes in days that normally would have taken 6 months.

The business owners identified a small change that would let the application make more money. The change was made in a few hours, but under the old process it would have taken 6 months to make sure there were no side effects and that it was safe to deploy. Because of the investment in BDD, the change was put into production almost immediately, fully tested and with complete confidence. BDD cut out 6 months where that change would not have been producing any value. For this single change, BDD resulted in savings of $5 million that would have been simply lost under their old process.

What is Agile Methodology?

Agile is a set of values and principles yet people are constantly asking about “Agile Methodology.” If you want to know more about agile values and principles, take a look at my video called “What is Agile?” In this video, we are going to try to answer “What is Agile Methodology?”

This is a bit of a trick question. A methodology is a body of methods, procedures, and rules for a particular discipline. But Agile values and principles explicitly avoid prescribing any particular methods or procedures. Agile doesn’t specify methods. Agile is not a methodology. This is probably a surprise for many people, but if you really take the time to look at the Agile Values and Principles you won’t find any methodology there. Instead you will find guidance on how to choose methods and procedures that will work best for your team.

The Agile Values and Principles don’t try to prescribe the way your team should work. Instead they focus on helping you and your team think and interact in ways that achieve Agility. Agility is the ability to continually adapt, the ability to constantly make improvements to the way you work.

Understanding this is important because it explains why Agile explicitly avoids being a methodology. If Agile specified a methodology it would necessarily be less…well…less Agile, less able to adapt to the specific circumstances of your team in your organization. So instead of telling you explicitly what to do, Agile gives you some values and principles that your team can use to *decide* what you should do.

So if Agile is not a methodology, what about all the specific things you hear about Agile teams doing? What about standup meetings, product demos, retrospectives, planning poker, etc.? While Agile is not a methodology, there are a number of methodologies teams can use to follow the Agile principles and values. Take SCRUM for instance. SCRUM specifies a number of specific ways for teams to work. This includes things like having daily standup meetings, fixed length sprints, product demos, and retrospectives. Many teams find SCRUM to be a very good way of following Agile values and principles. It provides a powerful methodology that assists in following Agile, but it is important to note that just following those ceremonies, doesn’t make a team Agile. They have to be following those ceremonies *because* it helps them align with the Agile values and principles.

(As a side note, some people will argue that SCRUM is a framework and thus more flexible than a methodology, but the line between the two is fairly fuzzy, nuanced, and often depends on whether or not someone has negative connotations of the word methodology. For the purposes of this discussion I’m using methodology, but in a positive sense–SCRUM gives you powerful methods and processes for getting work done. )

Extreme Programming is another methodology that you’ll encounter in software development. It includes a number of practices like test driven development and pair programming. The extreme programming methodology gives teams methods and processes that can be used to follow Agile values and principles. For example, Agile principles say that teams should leverage change as a competitive advantage, XP practices give methods for writing software that enable this.

So why do people still refer to Agile as a methodology? Usually because they are confusing Agile, the values and principles, with the methods and methodologies people use to follow those principles. If your team is truly trying to follow Agile principles and values, your methodology will evolve over time as your team grows and adapts. After all, that is what it means to be Agile!

Splitting User Stories – Agile Practices

Hi I’m Mark. I help organizations write software more efficiently. The Agile principles say that we should try to deliver software to the user frequently and that we need to do our best to strive for simplicity and only build what is necessary and important. Both of those things require a great deal of skill and practice in the way we organize our work. In this video we are going to talk about how to slice our work into valuable user stories that are small enough that they can be completed in a reasonable amount of time while still being valuable enough that they represent progress to the user.

If we want to create stories from the perspective of the user, we need to think about the application the way the user thinks about it. Developers tend to see the application as a stack. There is the hardware at the bottom. On top of that is the operating systems. Then comes the database and application server. Then we have a database access layer. Above that is the service or business logic layer. Somewhere above that is the code that is responsible for the GUI. Everything is stacked on top of each other like a cake. So a developer is likely to think in terms of stories like:

As a developer
I want a service layer
So the application logic is separated from the GUI.

As a developer
I want a GUI layer
So the so the user can interact with the system.

Having a service layer is good. Having a GUI layer is good. But having stories to build each of these layers violates our principles, but it is easy to see why we might end up with stories like this when we recognize the way developers think about an application. But what about the user? We want our stories to start off as fiction from the user’s point of view. It represents the way the user’s world will look once the story is completed. To write good stories about the user’s world, we need to understand how they think about the software applications.

A user will think of an application in terms of the behavior they find valuable. So they might think of an accounting system as consisting of the part that lets them create invoices, the part that lets them pay bills, and the part that lets them balance their accounts. They may know that creating an invoice means doing something in the GUI that gets passed on to the business rules and eventually ends up in the database, but that isn’t how the application is organized to them.

A developer sees an application as a collection of layers of cake that are stacked on top of each other, but users see the application as a collection of slices of cake that represent the different things they need to do. The fact that there is a database doing something toward the bottom of their slice of functionality is important but only to the extent that it is necessary to support that slice of functionality.

If we could build software the same way users think about (and use) software, we could deliver value much more quickly. It is a nice thought, but everyone knows you can’t build a house one slice at a time. For that matter you can’t just create one slice of a multilayer cake. You have to start at the bottom right? Absolutely—IF you are building a house or cake, but we are developing software. Code is not at all constrained by the same physical properties of buildings and deserts.

We actually can build a slice of functionality in software. If it seems hard to do, it is because we are too set in our ways of thinking of writing code as a construction or baking project where you have to complete one layer before putting anything above it. If you want to think of writing code in terms of some other activity, think of writing music. Bach didn’t have to write the entire bass part of a fugue before he could go back and put the other voices in layer by layer. Instead he could write a few bars for all the parts and try it out before moving on. Or think of a symphony. Composers don’t write hundreds of bars of base drum before going back to add the next instrument. Instead they write music several bars at a time with different voices interacting together. They may even finish a section and have it played to decide how well it works. They create valuable slices the same way that users think of our applications—the same way we should develop our code.

As we’ve mentioned before, the size of a story can vary from team to team, but a good starting place is to make stories represent what you think will take one or two days worth of work. This may sound like a a contradiction. We just talked about creating stories that represent an entire slice of user functionality and now we are saying the slices shouldn’t take more than a few days. How can you create something useful for a user in a few days if you don’t even have you database layer setup?

This is where the skill of splitting user stories comes to bear. Yes it is hard at first, but it is possible. If you can take a story that is going to take more than a few days and split it into several stories that are shorter you’ve done two things. First, you’ve created smaller units of work so we can keep everything closer to the same size. Second, you have now created the chance to prioritize the stories differently. This is a very valuable thing for the user because if some of the resulting stories are lower priority and can be deferred until later, the user can instead focus on stories that are higher value. Splitting stories is a way to increase the user return on investment.

But how do you split stories? Lets look back at our music example to see if it gives us any ideas. Many composers of large-scale works would write the most important parts of their ideas in slices (measures) at a time for a reduced number of instruments and then come back and fill in the supporting parts once they had proven out the overall idea. They would write the 20 percent that gave 80 percent of the value and then come back later and enhance it.

There are some pieces of functionality without which no value has been created. There are others that are very important but their absence doesn’t block value. Think about a checkout process for a web store. You add items to a cart, click the checkout button, login so you don’t have to type in your address information, choose how you want to pay, type your payment information, and complete the purchase. Is there anything in that process that could be left out in providing a first slice of value? What if we didn’t bother with the login? Everyone just types in their information to checkout. Can we split it to something even simpler that adds value? We could do away with the idea of a cart and just have a buy button that takes you to the payment page to purchase one item at a time. What if our first story is just to get the catalog available online so customers can find products, but to order they still call the 800 number?

So what started out as a sizable story is now a matter of hooking your database up to the web to display products. People can actually find the products online which adds quite a bit of value even if they have to call to place an order while you build the next piece. Even if you decide not to push this version all the way into production, you still have created something the user can exercise and provide feedback.

Now you might look at this and say it is way to small. You can get the product information into web pages in 45 minutes. Don’t forget we are building the full slice of functionality though. That means you’ll need to setup your database to allow access. You also may need to setup the web server and make sure it integrates into your existing site. There are many things that need to happen to make this seemingly small story work. Of course that is the point, make the story small because there are a bunch of other layers that need to be in place.

With rudimentary capability to let a visitor see a product, users can figure out what the next most important piece is they want to see built. Maybe it is the ability to buy a single product and process the credit card transaction. Maybe once they have seen the products online they realize that displaying related items is actually a higher priority than online checkout. By splitting the story into something small, they now have options on what to do next that they wouldn’t have if everything was all in the same big story. These options mean work can be prioritized.

Creating software with slices of value isn’t easy. It takes a lot of practice, but it is well worth the effort because it gives you the ability to create a constant flow of valuable, usable functionality for your users.

Creating Good User Stories

Hi I’m Mark. I help organizations write software more efficiently. A big part of this is helping teams find ways to organize their work in a way that follows Agile values and principles. In this video we are going to talk about creating user stories. User stories aren’t Agile in and of themselves, but they can be used to help us follow Agile principles. For example, here are three Agile principles that we should keep in mind for this video.

Working software is the primary measure of progress.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Simplicity–the art of maximizing the amount of work not done–is essential.

If working software is the primary measure of progress, we need to make sure we organize and track our work in a way that supports this goal. We need to make sure that our work is organized and chunked into units that represent value to the customer and we need a way to sort out what is extremely valuable from what is less important.

Most teams find that the best way to achieve these things is to visualize their work so it is easy to see what has been done, what is being done and what is yet to be done. Visualizing the state of various pieces of work can be done in software or even on a wall with sticky notes, but in this video we want to concentrate just on how to represent the units of work. A good approach is to represent the work through simple stories that describe what the users world must look like in order to mark a story as complete. Here are some example stories using a typical story template.

As a registered user
I want to change my password
So I can keep my account secure

As a website visitor
I want to subscribe to the mailing list for a product
So I can get product updates through email

As an admin user
I want to disable a user
So I can prevent unauthorized logins by past employees

As a mobile app user
I want to save all my data to the cloud
So I can access it from another device

There isn’t anything magical about this particular format for stories. The examples we’ve just seen cover who, what and why. Having a template is a good way to make sure you capture enough information to represent the idea of what the user needs without getting bogged down in the implementation details.

When our development efforts are driven by stories that represent our understanding of user needs, it supports our principles and fosters good development practices. Stories that are written in ways that violate our principles will hinder good development practices. Anything we can do to increase the quality of our stories will make the rest of our development process more efficient.

One time I was working with a team that was just starting to organize their work like this and we were using a template similar to the one we’ve just seen. One of the users had missed the initial meeting where we explained what we were trying to do. He was a bit confused and asked why he kept seeing all these short pieces of poetry about the software. Evidently he thought we were writing some strange form of haiku.

Good user stories start off as fiction. The setting is the world in which the user interacts with the software. The story is written from the user’s point of view and talks about things from the perspective of the user. The user perspective is very important because our principles say that we are going to define our progress based on giving the user the ability to do something valuable with the software that they were not able to do before. If we are working on stories that aren’t creating business value for the customer, we are doing work that we’ve explicitly said isn’t going to count as progress.

So how do we handle all the work we need to do that the user can’t see? How do we handle stories about the developer’s world? How do we handle stories like this?

As a developer
I want a database with all the tables to model the data
So I can store information the application needs

This is a bad story because it violates our principles for software development. Notice I said the story is bad, not the idea of having a database to store data. We definitely need a database, but if we create this story, almost all of the application depends on it being done first. We could complete this story and have no functionality we can show our user—nothing they can actually use as working software, but this would violate our principles. Further, the information we need to acquire to complete this story will only be known when we figure out how we are going to build other parts of the system. So in effect, a story like this is both a prerequisite for and a dependency of every other story.

When you have two things that both depend on the other being done first, you have a recipe for deadlock. If you’ve ever worked on a story like this, you may have experienced a long period of time where the user is asking how things are going and the development team is saying, “Well we have a bunch of setup work to do first before we can start working on the actual application.”

There is another way. If you write your stories from the user perspective you can build just the parts you need in order to create some value for the user. This likely will mean building some of the database, but only the pieces you need as you need them to complete each story.

It may seem counter-intuitive for developers to build software from the users perspective because such an approach means you may have to rework some of the things you’ve done in then past as future stories become clear. However, software projects that fail usually do so because they weren’t focused on delivering actual usable business value to the user on a regular basis. Building the application the way the user thinks about value minimizes this risk. If you are following the other Agile principles, the cost of some rework is trivial compared to the benefits it provides in delivering business value sooner rather than later.

What is Agile?

Many things get called Agile—especially by people who are selling something. Agile is defined in the Agile Manifesto. The Manifesto makes it clear that Agile isn’t a methodology. It isn’t a specific way of doing software development. It isn’t a framework or a process. In fact, most of the things that are marketed as Agile tend to miss the point of what Agile actually is.

Agile is a set of values and principles.

Much of the discussion around Agile has to do with following different practices, using various methodologies, and even developing with specific tools. For example, while a team may find that having a daily standup is helpful, the standup is only “Agile” to the extent that it is the result of a team following the Agile principles and values.

When you understand this, it is easy to see that Agile is really a collection of beliefs that teams can use for making decisions about how to do the work of developing software. While this means the term Agile gets subjected to a great deal of abuse when people claim that this or that is the way to be Agile, it also means that if you truly understand what Agile is, it is surprisingly flexible. Agile doesn’t make decisions for you. Instead it gives a foundation for teams to make decisions that result in better software development.

Agile Manifesto

The Agile Manifesto is only 68 words and very simply says that the signers have found that they can develop software better by valuing the items on the left side of the list more than the items on the right side. Below is the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Principles

In addition to the values of the Manifesto there are 12 principles that support the values. Once again the principles are very general and are less about telling you what to do than they are about giving you the ability to make a good decision in a particular situation.

The principles are:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Decisions

Since Agile is a collection of values and principles, its real worth is in giving people a common foundation for making decisions about the best way to develop software. For example, consider a new project that is in discussion on how to get the requirements from the business owner. The suggested approach is to require that the business owner write down all the requirements and sign off on them before beginning the work. A team that is following Agile would say:

“While that might work, isn’t that inconsistent with our belief that we should value customer collaboration over contract negotiation? And doesn’t it violate our principle that says the developers should be working with the business owners every day? How can we make this decision in a way that is consistent with our values and the principles we follow?”

Or consider a developer who is working on implementing a feature for the business owner. The developer realizes he needs a database to make the feature work. The first idea that comes to mind is to stop work on the feature and build out a robust database layer that will handle the needs of the feature and provide support for other development that will be needed later. If the developer believes in the Agile values and is trying to follow Agile principles, they would think:

“But building out this layer means I will have to delay delivering what the customer can see as valuable software they can use. If I can find a way to build just what is necessary to deliver this feature, it will better align with my principles.”

When you have a team that is following Agile they will be making hundreds of decisions each week in the way described above. That is what it means to be Agile. Making each decision based on the principles and values that the team has decided to follow.

Being Agile

The decision making process matters. You can’t try to short-circuit things by taking decisions made by another team and just blindly doing what they decided to do. Another team may make decisions based on the Agile principles and values and end up with a particular way of doing their work. Simply trying to mimic another team’s actions and practices won’t make your team Agile.

After World War II Melanesian islanders were observed trying to bring cargo planes and their supplies from the sky by mimicking the practices they had seen performed during the war. This included clearing the forest to make a landing strip complete with full size planes made out of straw. They also created structures that mimicked a control tower out of bamboo and had someone sit in it wearing headphones fashioned from coconuts.

It is easy to fall into a similar type of cargo cult mentality when it comes to Agile. The things that are easy to notice in a highly functional Agile team are the practices they are using. But the practices a team uses is the result of following Agile principles and values. It is less important what practice a team happens to be using than why they are using it. In fact, as time goes by, a good Agile team is probably going to change and refine what practices they use.

A team might start with SCRUM and later find that Kanban is a better fit for delivering value to their customers. A team might begin standing up in a daily meeting and later decide it works better for everyone to stay sitting down. Another team might start out using Planning Poker to estimate story size and later do away with story points and simply split stories to where they are somewhere in the same range.

That isn’t to say it is useless to look at practices being used by teams that are performing well, but you can’t go looking for practices to make you Agile. Your principles and values are what will make you Agile. You have to look for practices that support your principles and values. The way you select your practices is what determines whether you are being Agile or not. If a practice is being selected because it looks like a good way to follow Agile principles, it is probably a good place to start. The same practice can work poorly for a team if it is selected for the wrong reason.

So what is Agile?

Agile is a set of values and principles.

How does a team become Agile?

They make their decisions based on Agile values and principles.

The decision making process is how a team becomes Agile. The values and principles have enough flexibility to allow teams in a wide variety of organizations to develop software in the ways that work best for their particular situation while providing enough direction to help a team continually move toward their full potential.

Agile Practices

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.

Test Driven Development

When you start using Test Driven Development, it is easy to get so excited about having regression tests that you miss the point of using tests to drive the actual development process. While regression tests are a nice benefit from following TDD, they really aren’t the main point. TDD is about letting the design of your code be driven by the following cycle:

Write a simple test that will fail.
Write simple code to make the test pass.
Refactor to improve the existing functionality.
Retest to make sure functionality is still the same.
Back to step 1.

The goal is to follow a discipline that will produce code that is simpler and more robust than what would emerge if you were to focus on a larger part of the problem.

You cannot use TDD successfully if you believe that a line of code should only be touched once. TDD requires you to do a lot of writing and rewriting. You may write code that makes your first test pass knowing that it will be rewritten when you add the second test. At first this can be frustrating. Why would you write code that works for test A knowing it won’t work for test B that you are going to write 90 seconds later? Why not go ahead and do it right the first time?

The reason is simple. You want to minimize the amount you have to think about at any given time and also minimize the amount of time that your code is in a broken state. The more things you try to do before getting your code back to where it runs, the longer the code exists in a state where it won’t run correctly. If you add a method that simply returns a hard coded value, it might seem like you’ve accomplished nothing in that step of getting the test to pass. However, you’ve made several decisions about the new method: Where should I put this method? What should I name it? etc. When you add another test that forces your method to actually do something intelligent, you’ll still be working with a smaller set of changes than trying to do it all at once.

Once a test is passing, that doesn’t mean you are ready for the next tests. It means you are ready to refactor. You are now in a working state so you can change things and immediately tell if it changed the way the application works. Once a test passes you need to consider if there are any refactoring steps you can take to clean up what you have so far. Have you named things in a way that will be clear to others? Can you break some of your code out into a helper method to make it easier to understand?

This is probably the most important part of TDD—taking an application that is passing the existing tests and improving the code while leaving the functionality unchanged. If you aren’t trying to do this before each new test you write, you aren’t doing TDD.

Agile in Name Only

Last minute travel plans had me looking for a way to get some dry cleaning done with faster turnaround than what my local dry cleaner could provide. We had to go to Joplin for a few hours before heading to Kansas City to catch our flight. A quick search showed there was a “1 Hour Dry Cleaners” in Joplin, so I figured I could drop my clothes off with them and pick them up as we headed out of town. On our way I gave them a call. The conversation went something like this:

1HDC: Hello, this is 1 Hour Dry Cleaners.
Mark: I’ve got some clothes I need to get cleaned quickly. Which location should I take them to?
1HDC: It doesn’t matter.
Mark: Ok so if I drop them off around 8 I can pick them up a bit after 9.
1HDC: They probably won’t be done. But I guess we could mark them as “expedite.”
Mark: Ok I just need them before we leave town, so if I drop them off at 8 and you mark them as expedite, will they be done by noon?
1HDC: Well even with “expedite” we probably won’t have them done that fast.
Mark: I’m sorry who did I call?
1HDC: This is 1 Hour Dry Cleaners in Joplin.
Mark: … ok…
1HDC: Oh, but that is just our name. It isn’t what we do.

I see a lot of “Agile teams” that suffer from the same problem. You aren’t Agile because you call yourself that name. Ceremonies don’t make you Agile either. A team isn’t Agile just because you have a daily standup or retrospectives. You have an Agile team if you are able to deliver usable code on a regular basis and welcome changing requirements. You have an Agile team if you prioritize face to face communication and the team has a lot of latitude to self-organize.

Teams that are Agile in name only are just like the 1 Hour Dry Cleaner in Joplin that doesn’t do dry cleaning in an hour. No matter how great your name, it is the execution that matters.

(photo credit)

Teaching Class on Git

I spent some time this past week teaching a class on Git for the Treasury Department. We had a lot of fun. I used Digital Ocean to spin up an instance for the students instead of the AWS instances I usually use. It seemed to work well and in some ways it was simpler than using AWS.

Mark Shead Teaching Git Class — Mark Shead Teaching Class on Git Version Control

Why Do Some People Hate Agile?

Imagine that there is some group of people that speak English, but never learned to read or write. Someone literate shows up and explains that you can make marks on paper to represent words and read them back. All of the illiterate people are very excited about reading and writing and decide they need to start doing this right away.

Some of the people start learning phonetics and practicing writing the alphabet in order to learn the principles necessary to be literate. It is slow going and very difficult work.

Another group of people start making random marks on paper to represent the words they are thinking in their heads. They stand up in front of each other and hold a book open while pretending to read the pages. Of course they can’t read so they just make up stories. They try their best to emulate all the practices they saw people doing that could read and write.

After a year how do you think the two groups describe literacy? The group that had focused on the principles behind reading and writing would be very happy about it. They can pick up a book and read it. They can communicate with each other by writing on a piece of paper. The group that tried to emulate the practices without first learning the principles would declare literacy a fraud. Both groups would be equally strong in their opinions.

Agile is a set of values and principles. Teams use these to make decisions that lead to good project outcomes. These values and principles guide the selection of different practices.

There are a lot of people trying to “do Agile” by emulating the practices they have seen on other teams. They try to use Scrum, Kanban, Extreme Programming, etc. But these practices aren’t Agile unless they are being driven by the Agile values and principles. Like the people who try to develop literacy by pretending to read and write, they get very frustrated.

Agile is polarizing because it is easy for people to spend a lot of effort doing things that look like Agile without having any of the foundational beliefs in place. If someone says Agile is a recipe for failure, ask them to describe Agile. If they name a bunch of practices and no values or principles, then it isn’t actually Agile that they dislike.