Agile Advisor

Agile Development: Art, Science or Both?

Properly using agile software development practices requires skillful application of principles from both sides.

• By Aaron Bjork
• 10/25/2013

In my profession, I'm fortunate to spend a lot of time talking to people about what's involved with running agile teams. When given this opportunity, I often find myself describing two aspects of agile, what I've been calling the "art" and "science" of running agile teams. Let me explain.

Agile Science Let's start with science. Below is a definition of the word pulled from an online source:

Science: A branch of knowledge or study dealing with a body of facts or truths systematically arranged and showing the operation of general laws.

I consider many of the common practices that agile teams follow as science. The practices are fairly prescriptive, and when followed, produce an excepted result.

Estimating a backlog using planning poker is a good example of this. There are well accepted rules to planning poker:

• Each team member is given a set of cards.
• The product owner describes the item being estimated.
• The team discusses the item.
• Each team member privately chooses a card representing their estimate.
• After all have chosen a card, everyone shows their card.
• If all estimates match, the estimate is accepted.
• If estimates don't match, the team discusses why.
• The process repeats until consensus is reached.

These prescriptive guidelines have proven over time to produce positive results.

Pair programming is another practice that falls into the science bucket. Teams have found that over time, developers produce programs with fewer bugs and better designs when they pair. Why? Because while the developer who's actually writing the code is focused on assembling the code, the developer they're pairing with is freed up to focus his or her attention on different aspects of the code being assembled.

Now, it might be a stretch to state that these practices really are "science," but I think they represent examples of well established practices in the agile community that have led to positive outcomes. They are "truths" (practices) that, when applied, demonstrate the operation of "general laws" (better software).

Agile Art Then where does art fit into the picture? I find that when undergoing an agile transformation in any organization, many people express dismay at how to influence others. Performing agile practices (the science) is often the easy part. But influencing key team members or stakeholders to believe in and trust agile practices is a completely differently skill. This is where art fits in. Below is a definition of the word "art" that resonates with me.

Art: Skill in conducting any human activity.

Agile practices are almost always about dealing with people. Dealing with people is in many ways an art form. Why? Because we all come from different perspectives and different backgrounds. These perspectives and backgrounds are what influence our thoughts, opinions and perceptions.

Most of the people I work with on a daily basis have built their careers building software a different way. Agile philosophies and practices represent a change in what they've done for the bulk of their careers. As we all know, change is usually difficult. It's not bad, but it can be challenging. This is obviously no secret, but it can get lost when undergoing an agile transformation. I find many people hyper-focused on practices, without giving much thought to how they'll influence the people involved.

So, how do you then get good at the "art" of influencing others? Practice and study. I find that I read far more books and articles about psychology these days than I do about new processes or practices. This is not to say that I'm not studying new techniques or new approaches to building great software; instead, I've found that regardless how proficient I am at a practice or method, I don't get very far without paying equal (if not more) attention to the people involved.

One resource I've found helpful in recent years is a book titled Switch: How To Change Things When Change Is Hard by Chip and Dan Heath (Crown Business). The book talks about the need to engage two parts of our minds (and others minds) when working through any change: the rational part of our minds, and the emotional mind. These two parts of our minds compete for control. The book outlines some great strategies for getting the two working in sync. Give it a read and see if it doesn't help you in perfecting the "art" of influencing those you work with.

Both, Rather Than One or the Other The point I'm trying to make here is not that a specific activity or practice is either 100 percent art or science. Instead, it's that when building and running an agile team (or set of teams), you're going to need to apply a fair amount of both art and science. There are proven best practices in the software development landscape. These practices are mostly science based; they prescribe a method to accomplish a task that, when repeated, produces a desired result. They're good, and you should be proficient in them. However, as agile practitioners, it's equally important to perfect the art of influencing and motivating others if you want to be successful.