Back to Basics: The Agile Manifesto and The Principles Therein

OK, so I’ve been doing this blog thing for about a week now.  I’d say it has gone pretty well. I’ve got a few posts under my belt and even gotten a bit of positive feedback. So I figure now is as good a time as any to go back to basics and perform what is probably a rite of passage for all Agile blogs: covering the Agile Manifesto and its 12 guiding principles, while remixing it a bit with my own input, anecdotes and opinions. Well, maybe it’s not a rite of passage, but let’s do it anyways.

Over the next, oh let’s say 1 or 2 weeks, I’ll make a series of posts about each of the value areas of the Agile Manifesto, and each of the guiding principles of Agile. But before we get into the nitty gritty, lets look ahead to where we’re going, and take a look at the values and principles of Agile, all courtesy of The Agile Manifesto.


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.

A pretty clear list, if I do say so. One important thing to note, is that the existence of value in all of these items is not disputed. There is value in everything on the right, but the items on the left will be more valuable. We’ll get into why as examine each item more in depth in it’s own post.


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.

Well, that is quite a list. Each item is a powerful statement in and of itself, many with multiple nuances leading to different practical applications within the Agile world.

This will be a lot of ground to cover, so stay tuned and stay patient, and thanks for reading!

Coming up next: Individuals and Interactions


Paint the Fence, Daniel-San: Thin Vertical Slices and the Economy of Movement


I’m not the first person to equate Mr. Miyagi’s method of teaching Karate in “The Karate Kid” to Agile. Jeff Gothelf equated Miyagi’s use of rote repetition and skill mastery to Agile and Lean UX. Ed Wong gave a talk to his Scrum User Group about how the learning from an expert is very similar, whether its Scrum or Karate. I’m sure there are many more out there. Continuing on that thread, I’d like to look at this in the context of story splitting, different methods of ‘painting the fence’ and how rote repetition can allow us to improve our skills and apply them in new and unfamiliar ways.

In this particular example, the fence is a section of our project. It’s clearly defined, relatively uniform, and can be painted with many different methods. Each board in the fence is a feature.

A poorly drawn blank fence.I’m not very good at art…

If we were painting via waterfall, we’d be painting horizontally, applying changes across multiple features. We would get a certain distance, and then need to come back, painting more parts of these features,

FenceHoriz1 FenceHoriz2 FenceHoriz3

Look at how much work has been done here, and nothing is even halfway complete. Some planks couldn’t be painted in the same way, since they weren’t uniform. What happens if we want to change colors? Or pull out some fence posts? We might have a vague idea of what a finished product will look like, but nothing concrete. All of these features are linked now, to finish, we really have to finish them all.  We might have saved a little energy by not having to switch levels as often (front end, back end, database, etc.), but we wasted a lot more going forward on features, then going back and touching all those features again.

On the other hand, lets take a look at the way Agile would have us do it, in thin, vertical pieces, or in our examples, plank by plank.


Here we see each plank completed on its own. Irregularities in size or composition no longer create issues. We can see what a completed post looks like, and extrapolate what the fence may look like once complete. If we decide to make changes, it is easier to adjust or remove completed work, while maintaining uniformity. We may move up and down more often, but we complete more often, and we reach more natural stopping points to review our work. As our muscles(skills) in this area improve, we become more efficient at this vertical movement, needing to expend less energy to do so. The smaller the slice, the less energy we have to expend to complete it.

Once we are efficient at doing so we can then apply these skills to other areas, even areas which are unknown to us. Just like when Mr. Miyagi had Daniel apply his fence painting skills to blocking, we can now look at a new project, find the features and apply all of those now-engrained skills, and flex our agile muscles. You can also begin to work on new skills, such as refactoring and communication or punching and crane kicks.

So get out there, and paint those fences!

The Agile Master

Catchy? No, I’m not proclaiming myself a master at Agile… actually I wanted to pose a question. In Scrum, there is a role called the “Scrum Master”. It’s very unique, and it speaks to what that person is all about. They will (in a manner of speaking) master the Scrum. Not the Scrum Team, but the Scrum itself. They facilitate, lead, coach, and in general do what needs to be done to facilitate the Scrum for their team, so that the team can focus on delivering value.

However, once you get outside of Scrum, does that person disappear? Just because you’re running some other Agile flavor like Crystal or Lean Software Development (maybe supplemented using Kanban to control work-in-progress) on a DevOps team, does the need for a “Scrum Master”-like person disappear? The most common title I’ve seen is the “Agile Coach”, which is a great title as well. One of my favorite books (indeed, my coaching bible) is Lyssa Adkins’ Coaching Agile Teams which uses Agile Coach as the title of this role. However to me, “Agile Coach” can be both too narrow and too broad of a description or role. If only interacting with a team, this person does far more than coach. Like the Scrum Master above, this person will not only coach and teach, but facilitate, remove impediments, resolve conflicts, and solve problems. On the other hand, I’ve seen Agile Coach thought of and described as a coach/mentor for a group of “Scrum Master” like people, be they actual Scrum Masters on Scrum teams, or other such facilitators.

There is a distinct difference which seems to go unaddressed. Scrum Alliance makes a distinction between the Scrum Master/Scrum Professional level and Scrum Coach/Scrum Trainer level of certifications. does not, but they do make a distinction for experts which they list on their site.  Agile as a discipline at large does not seem to do so. Scrum Master sounds focused, Agile Coach is kinda nebulous, and doesn’t speak to your team’s discipline.

Maybe we can just add “Master” to the flavor of agile your team most closely resembles? That sounds fun!

  • The XP Master! World of Warcraft here I come! Or, a Windows guru from last decade.
  • The Lean Master! I can lean at any angle! 30 degrees, 32 degrees, you name it! (OK I know it’s supposed to be bend, bite my shiny, metal… ahem.)
  • The Crystal Master! New age hippy, or reject boss from the Legend of Zelda series?
  • The Agile Master! I don’t know, sounds like it outranks a mere Coach…

At the end of the day, it doesn’t really amount to much, mostly semantics and curiosity. As with many things, I don’t know the answer, I just pose the questions.  What do you think? Leave me some comments!