This is not the column I had planned to write. But in October I went to Silicon Valley Code Camp where I attended an excellent session called “Agile in a Waterfall World” by Jeanne Bradford. Her company, TCGen, did research into using Agile in hardware development and manufacturing. Now, this column is about software, not hardware; but much of that research and what she said in her session is applicable to software gardeners.
So let’s go back to one of my first columns Software Gardening: Using the Right Soil where I discussed soil. As any good gardener will tell you, soil needs the right nutrients and different types of plants need different nutrients. It’s also important the soil does not have things that are bad for the plants. You need to know about the soil you already have. That sometimes requires a detailed analysis of the soil. In my earlier column I also said that as software gardeners, our soil is agile practices.
This article is published from the DotNetCurry .NET Magazine – A Free High Quality Digital Magazine for .NET professionals published once every two months. Subscribe to this eMagazine for Free and get access to hundreds of free .NET tutorials from experts
What is Agile Software Development?
What I decided to write about in this issue is to analyze Agile to see what it really means. Jeanne has graciously allowed me to use parts of her presentation in this column. If you want more, you can get her entire slide deck at http://www.tcgen.com/tools.
We’ll start by going back to the Agile Manifesto. On that winter day in 2001 at Snowbird, a ski resort just outside of my city of Salt Lake City, Utah, the 17 original signers of the Manifesto came up with four main points (see Figure 1).
Figure 1: The main points of the Agile Manifesto
But there is more to it than those four points. There are actually 12 principles that support the four main ones. You can read them at http://www.agilemanifesto.org/principles.html. In Figure 2, I’ve taken Jeanne’s rewording and reordering of those 12 principles. Take a moment to read that reordering. I’ll be here when you get back.
Figure 2: The 12 supporting principles of the Agile Manifesto
Agile: The important Bits
Did you see what’s important in that reordering? No? Read the first nine again. None of them have anything to do specifically with software. That’s nine of 12 or 75%. In other words, the success of your project is 75% based on non-technical skills and only 25% on technical skills. The non-technical principles can be applied anywhere and on any team. That leaves only the last three as software specific.
This is really important. It means that nine of the top 12 nutrients for your soil are not targeting software development, but rather targeting the general health of your team. It includes developers, QA, devops, management, business owners…everyone involved. It means that you need excellent interpersonal (how do you work together) and soft skills (the non-technical skills). It means if you want your project to succeed, you need to concentrate more on these types of skills rather than technical skills. This is not easy. In fact, I’ll bet it’s easier to cultivate the technical skills over the non-technical skills.
These non-technical skills include things like presentations, public speaking, understanding the business domain, willingness to get the job done, ability to talk face-to-face, ability to explain extremely technical concepts to a non-technical person, trusting team members, interacting with them daily, etc. Can you do these things? If not, you should concentrate your learning on them. How about your team members? Can they do these things?
In their research TCGen asked their customers “What are the most impactful elements of Agile/Scrum applied to software?” The four things that stood out as having the biggest impact were daily standups, burn down charts, team culture, and customer owner. Are you doing daily standups? Do you have burn down charts? Is your customer owner engaged in the project?
Agile is hard
So why is applying Agile so hard? This is another question Jeanne addressed. The simple answer is Agile is hard. It requires higher process literacy and greater cross-functional teamwork skills. Your team must be sophisticated. I once worked in a company where water-fall development was the way things had always been done. The Vice-President of Development wanted to adopt Scrum. She read a couple of books on the subject then had development and project managers read the same books. When Scrum was rolled out to the organization, it failed. Teams were convinced that Agile was worthless.
The proper way to do this would have been to have key players attend training classes, then hire an experienced Scrum Master and/or Coach and roll it out to one team then move on to the next team. The bottom line is Agile is not for the faint of heart.
Agile Development Methodology - Making it happen
To be successful with Agile, your team must first adopt some cultural aspects:
- Teams must have high performance
- Teams must be self-organized
- Teams must have trust and empowerment
- The customer owner and team leader must interact daily
- Teams must have daily standup meetings
- Teams must accept the fact that requirements can (and probably will) change
Next, create boundary conditions. These are the conditions that you will use to help identify what goes into a sprint. The top of the list is a User Story, which is a short explanation of how a user will use a particular piece of functionality. These user stories are the Product Attributes. Then add Program Attributes or budget and schedule.
When you have these, pick the top three to seven. You can now further define your boundary conditions. In fact, there are five primary conditions to consider - features, product cost, development cost, schedule, and quality (see Figure 3). If you can keep the team progressing inside these conditions, you will have success.
Figure 3: Boundary conditions
Agile Development Challenges
As long as you stay inside the boundary conditions, everything runs fine in the sprint and the project. But what happens when something doesn’t work as planned? Say, you lose a key team member (Figure 4). The schedule could slip and suddenly you’re outside the boundary. If you are continuously measuring all aspects of your project, you’ll see this issue and adjust accordingly.
Figure 4: Out of bounds condition
Perhaps a schedule change will be sufficient. Or you may need to change other aspects of your project, maybe dropping features and dealing with cost adjustments. I strongly encourage you to not decrease quality. This adds technical debt and actually will increase costs long term.
Now you can move to step 2, attacking your burn down. For each sprint, you need to identify tasks you can get done. Track how many you accomplish over time. In the beginning of your project, you’ll probably do more work on definitions and infrastructure. The middle is mostly task-based work, getting working code out the door. Later in the project schedule, you’ll probably do more validation.
But what happens if you get to the end of sprint and you haven’t finished all the tasks planned for the sprint? You have two choices. First, you can extend the length of the sprint to finish them or second, you can schedule to finish the work on another sprint. Pick one, but pick correctly. Did you pick option two? If so, good for you. Don’t slip the sprint. As you gain more experience with Agile and better understanding of the business domain, you’ll be able to more accurately split up stories into tasks and estimate how long each task will take.
Finally, do not skip the retrospective. Key learning goes on here. It’s where you and the entire team, including the business owners, discuss what went right and wrong and how you can fix it. Do a retrospective often, perhaps a short one at the end of each sprint and a longer, more in-depth retrospective at the end of the project.
You should now be able to look at the nutrients in your soil. How well is Agile working for you? Where do you need to make changes? How can you make changes so that Agile works for you? By having the proper nutrients in your soil you can ensure that your software garden is lush, green, and growing.
About Software Gardening - Comparing software development to constructing a building says that software is solid and difficult to change. Instead, we should compare software development to gardening as a garden changes all the time. Software Gardening embraces practices and tools that help you create the best possible garden for your software, allowing it to grow and change with less effort. Learn more in our Software Gardening article series.