Agile is not for the faint of heart

Posted by: Craig Berntson , on 2/14/2015, in Category Software Gardening
Views: 34148
Abstract: What is Agile Software Development? How well is Agile working for you? Where do you need to make changes? This Software Gardening article analyses Agile to see what it really means.

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

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 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.

This article has been editorially reviewed by Suprotim Agarwal.

Absolutely Awesome Book on C# and .NET

C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.

We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).

Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.

Click here to Explore the Table of Contents or Download Sample Chapters!

What Others Are Reading!
Was this article worth reading? Share it with fellow developers too. Thanks!
Share on LinkedIn
Share on Google+

Craig Berntson is a software architect specializing in breaking up the monolith and improving developer teams and processes. He is the author of two books on software development and has been a speaker at conferences across North America and Europe. He received the Microsoft MVP award twenty-two straight years. He lives in Salt Lake City, Utah.

Page copy protected against web site content infringement 	by Copyscape

Feedback - Leave us some adulation, criticism and everything in between!
Comment posted by dbrown_ny on Tuesday, February 17, 2015 11:38 AM
I just loved reading this article. My CTO was thrilled when I sent him your Software series. What is your next article going to cover?
Comment posted by Dave Schinkel on Wednesday, February 18, 2015 7:33 PM
"Continuous attention to technical excellence
and good design enhances agility."

There is not enough focus or talk about quality even in your post above...which is the problem in today's perverted translation and use of the term "Agile".  Agile has failed us

This is just as important as the 75% you claim about Agile.  And this is in the list.  Quality is just as important.  It's not just about soft skills. Working software essentially means it meets the requirements is usable, and is MAINTAINABLE.  That's why TDD is so highly regarded as a way to ensure quality throughout the entire iteration.
Comment posted by Keila on Wednesday, February 18, 2015 9:25 PM
Dave, check out the link at the bottom of the articles about the Software Gardening series. A lot of your doubts will get cleared.
Comment posted by Craig Berntson on Tuesday, February 24, 2015 7:11 PM
dbbrown_ny: Next column is Pruning. It should be available around March 1. Thanks for the kind words.

Dave: This was one article in the series. Click the link at the end for prior columns on technical excellence.

Comment posted by dbrown_ny on Monday, March 2, 2015 9:16 PM
Craig I absolutely loved the Pruning article. Thank you for it. Words cannot express my gratitude.

What's your next column about? I will wait for it.
Comment posted by Juan Nallar on Tuesday, March 3, 2015 9:27 AM
Sorry, but I disagree. Building software is a technical activity and it cannot be done (at least in a good way) with just 25% of technical skills.
Second comment is absolutely hitting the nail: You can have non technical people building software, but after time time, it will collapse (and I've seen this more times than I would like to).
You are telling that building software is like gardening: I'm a very social person, very kind, and I understand problems in a very quick way, but I know nothing about plants. Would you hire me to take care of your house garden?
Sadly I'm seeing more and more managers thinking like you do... and I'm seeing software projects failing over and over again.