DotNetCurry Logo

Agile is not for the faint of heart (Software Gardening)

Posted by: Craig Berntson , on 2/14/2015, in Category Software Gardening
Views: 18490
Abstract: What is Agile Software Development? 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? 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 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).

agile-manifesto

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.

agile-manifesto-principles

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.

agile-boundary

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.

out-of-bounds

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.

Was this article worth reading? Share it with fellow developers too. Thanks!
Share on Google+
Further Reading - Articles You May Like!
Author
Craig Berntson works for one of the largest mortgage companies in the US where he specializes in middleware development and helping teams get better. He has spoken at developer events across the US, Canada, and Europe for over 20 years and is a Grape City Community Influencer. Craig is the coauthor of 'Continuous Integration in .NET' available from Manning. He has been a Microsoft MVP since 1996. Craig lives in Salt Lake City, Utah. Email: dnc@craigberntson.com Twitter: @craigber.


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

http://www.agilemanifesto.org/principles.html

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 http://paytonrules.com/

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.