The first thought I had is training.  Yes, coming from a guy who does coaching, that is the first thing I thought of.  But not for the reasons you may think.  If you think about it, the number of teams applying agile methods is climbing the blade of the hockey stick. As someone who has seen the benefits in product outcomes and overall organizational morale, I think this is great!  But the challenge is, with adopting agile it does require training the team members so that they, the TEAM, can make the transition successful and help adapt, adjust and evolve the agile methods used to fit their development environment.  In agile development, the TEAM owns the process and the TEAM is empowered to make it successful.  This is much different than traditional project management where you can focus training on just the project managers and folks in leadership positions.  The team just needs to know where to report time, and how to write up their status reports.  So, if the team has not been trained on what agile is, and the surrounding methods and processes, then I can understand when you ask them, “Do you do agile?” … “Yes.” “What agile method do you use?” … “I don’t know.”

The second reason I can think of why folks answered, “Don’t Know” is that they are leveraging multiple concepts from the various agile methodologies – including agile project management and traditional project management.  The survey did allow folks to answer “Hybrid” (9% of respondents answered), but in my discussions with teams lately – the application of Agile principles is the beginning focus with the adopting and adapting processes is much more flexible.  Teams are starting with one method and morphing to another, and in some cases leveraging a little bit from everything.  This approach can be good and bad, depending on the maturity of the team and the ability to continuously improve.

Besides the answer of “ignorant blissfulness,” the only other thought I had for the “Don’t Know” response are those that work at organizations that have heard about this Agile thing and decided that they will become Agile.  So they leveraged Find and Replace to put the word Agile in place of whatever methodology they were using before.

So, what are your thoughts?  If you participated in the State of Agile Survey this year, why did you answer “Don’t Know”?

Continued from Part 1 …

And, of course, we also have the rest of the musicians who are like the testers and programmers in that they all have some specialization, perhaps the instrument they play, or the particular way in which they play.  For instance, in the Duke Ellington Orchestra, not only was Cat Anderson known for being a great trumpet player, but he was also known as a high-note specialist. If applied to the agile software development environment, not only are there specializations like programmer and tester, but there are also some folks who are best at User Interface, or at database work. There was never a rule that only Cat Anderson could play the high notes, or that he could only play certain notes. And there should never be a rule that only your “UI guy” can work in the UI. That would lead to a very thin team.  There would be no ability to build a depth of knowledge throughout the team.  Should a particular team member be unavailable, and the skill in which she specializes is required, the team is now hostage to her schedule.

There are many reasons why small groups are desirable. Members of a small combo are best able to work together and play off of each other’s strengths and weaknesses. They can react to changes that might come from the stage dynamics. Whereas many large bands require a hefty amount of coordination and very little room for improvisation, the small combo thrives on improvisation. Everyone adds what fits best, and the feedback from the audience is immediate. The energy builds – not just from each contribution, but also from the cumulative effect. The band doesn’t stop and argue when someone makes a change during a jam session. Band members pick up the new tempo and use this change to make the music better than ever before; the same thing happens in agile software. The team is able to communicate and work together. The different players are not going through some intermediary, but directly to each other. The energy, the pace and the quality of the product all come out through this tight, frequent interaction.

I’d like to take the next few weeks or even months to explore further how we can apply the lessons of our jazz brethren to the world of software development.  We can talk about ideas like how to be successful with duets (pair programming), or perhaps how to conduct a jam session.  Hopefully, this will spark some ideas that can build a strong understanding of how to work in our agile teams.  What other comparisons can we make?  What do we do when a small combo begins to grow into a large orchestra?  What might that mean to us?  The possibilities are endless.

So now picture this: The agile development team comes together for a planning meeting. The director establishes the tempo by identifying, with the help of the team, the velocity for the upcoming work. The product owner then lays down a groove, describing the melody and harmony of the iteration.  She does this by providing a depth of description and acceptance tests, which show not just what we will be doing, but how each story interacts with the others. Now the rest of the team picks up the melody as shown by how the programmers and testers pair up and work on stories together. The team’s energy builds as the code is tossed back and forth in short phrases. Each member employs his strengths, but helps to contribute to the overall outcome wherever he can. At the end of the iteration, the audience expresses their appreciation for another fantastic performance.  Now we can chill for a little while, enjoy our success and look forward to the next gig.

Do you enjoy Steve’s posts? Check out more on his personal blog: http://bit.ly/yOBqBn

Have you ever watched a jazz combo? The performance starts with the leader counting off the rhythm, then stepping away. Then the drummer begins to lay down a beat. Even at this stage, the audience can feel a groove hit the room. Soon, the piano joins and adds both melody and harmony to the piece. Energy is flowing from the chords as the team starts to see and feel the direction of the piece. Now it’s time for the other instruments to join in the fun. A typical combo will have a couple of different instruments, maybe a sax and a trombone or some other combination. Whoever starts off will state the melodic theme for the song, although sometimes the whole group does this together. After that, everyone gets the chance to do a solo, in which they improvise on the main theme, key off of past experiences and apply their musical knowledge. It’s not uncommon for jazz musicians to jibe each other, making jokes and comments while they are playing. The energy in the room builds and builds as the musicians play together, sometimes one at a time, sometimes in tandem. When you watch a jazz combo really swinging, it can be hard to tell who his having more fun – the audience or the musicians.

This metaphor works quite well to understand what makes a small team desirable, and how to be successful with such a team.  In the agile software community, we have asserted over and over again that we need small, cross-functional teams. And yet, what really is cross-functional? Can cross-functional really work? The more traditional view of software creation involves the need for separate, functionally focused teams who are experts in their domain. The teams only interact as they are passing work items from one to the other. When development is done, the teams hand off work to test. Test will find defects and hand them back to development. And the dance continues in this light forever.  The jazz model demonstrates that this can, in fact, work.

In a jazz combo, each member of the team has a specialty. The members play individually, but often together  they create a tapestry of music that becomes much greater than the sum of the individual contributions. A small development team works best this way. We have some set of programmers, testers, documentation specialists and some representative of the business working together. Team members gain their energy from each other. They try new things and get feedback right away from anyone who wishes to listen and share.

The team members don’t need to just focus on their own areas either. A tester can very easily and effectively form a duet with a programmer. They will play off of each other with their ideas. The tester will write a test to express some piece of functionality that the software will have. Then the programmer will answer with the code that will cause the test to pass. So we write another test based on this back and forth interaction. In music this interaction is known as “call and answer,” and it is especially effective with the testing and programming cycle, as it provides a rapid, tight feedback loop.  Communication is instantaneous, allowing for more freedom of action. More often than not, a programmer will pair with another programmer. This duet is very effective and powerful as well.  The programmers can build off of each other’s knowledge; ideas that might “seem like a good idea at the time” are instantly reviewed by a peer.  This type of pairing turns code review from an intermittent, reactive process into a continuous, proactive activity, and should be embraced as often as possible.

Let’s explore some of the roles that are important in a development team. Usually there’s some sort of coach or leader. In the Scrum world, you might hear about the ScrumMaster. Each of these names is meant to describe someone who is both a part of, and to some extent outside of, the team itself; in a jazz combo, this is the director’s role. Not every combo has a director, but many do. Sometimes that director is part of the team, only directing long enough to initiate and introduce a number to the audience. In software development, the director represents the team to the stakeholders, and helps plan the meetings, stand-ups, and the like – essentially counting off the beat. If the rhythm seems to be getting lost, the director can help the team identify this fact and help with corrective actions.

A team also needs an individual who has the ability to identify what needs to be developed. In agile development, this role belongs to the product owner. Now consider a jazz combo’s basic rhythm section… The drummer lays out the shape of what is to develop; the bass takes this one step further, presenting the progression of chords that identify the order in which the chords (which make up the actual harmonies and melodies) will be played. Lastly, the piano comes in with the rich, fully realized chords. Accordingly, the product owner has to play all three roles of the rhythm section, explicitly: identifying the work to be done or the shape of the upcoming work. Ordering the work in order of priority sets the rhythm.  Elaborating the story in terms of acceptance criteria provides the chord structure. And lastly, the constant interaction with the team throughout the development cycle provides the fulfillment of the intention as laid down by the acceptance criteria previously mentioned.

In Part 2 of this post, I’ll talk about what other roles are integral to every agile development team and explain how keeping the teams small and cross-functional makes it easier to react to change.

Is it fair to call Quasimodo ugly?

Earlier this year, on the LinkedIn Agile and Lean Software discussion group, someone posted the question, “Is it fair or accurate to malign the waterfall process as is rote when people push agile and Scrum?”  The original question drew a lot of discussion, and then it seemed to die down.  All of a sudden it has reared its ugly head again, and really requires a more thorough response.

When I first saw the post, I laughed.  Here was a guy posting in the Agile and Lean Software group a question which implied that any negative talk about waterfall was “maligning” it.  Needless to say, the wording implied an assumed answer.  My first thought was that this guy was a troll. And the usual folks would quickly send him on his way with scorn and derision.

What surprised me, and somewhat delighted me, was how many people replied with thoughtful discussion.  Folks took the question, wording and all, seriously.  They started to explore the question of whether agile had become dogmatic, or perhaps we were being unfair to waterfall.  The conversation was going to help everyone better understand why the world is moving to a better way of creating software, which is what we are calling agile (and now also Lean).  This is, after all, what discussion groups do so well.  We learned so much through the discussion groups in the early days of agile, as if we were our own Socratic society.

I quickly became disillusioned though.  The discussion was not a serious examination of the pitfalls of the processes known as waterfall management, and how to overcome them by moving to agile development.  Nor was it an open conversation on why – when it comes to software development projects -waterfall is the poorest of choices.  Instead, we saw a lot of folks very nicely saying that waterfall management will work just fine if you have all of the information up front… or if you have a very clearly defined set of goals and a strong understanding of the problem domain.  This would lead one to say, “gee, if that’s all it takes, why learn all these new processes?  Maybe we should just put a lot of time and energy into being able to get all the information up front, or into making sure we have a clearly defined set of goals and ensure they just don’t change during the project?”  Well I’ll tell you why.

***It just doesn’t work!***

This is a good time to remember why agile software practices came into being in the first place.  We didn’t all sit down and say, “You know, everything is going so well and projects are really coming in on time/budget, with high-quality code.  Let’s change everything.”

This all started because folks realized that projects were failing more often than succeeding.  Most of the projects that were considered success on the outside were the result of long hours and dangerous shortcuts.  Change became something to resist, even if the change was the right thing to do.

We spent a lot of time and energy trying to find ways to change this; we usually exhausted time and energy that would have been better spent creating software.  Agile development is about recognizing the difficulties and complexities of the software world, accepting them and working in a way that harnesses the ability to change software at a minimal cost.

So no, everyone doesn’t get a trophy.  Waterfall is not a good way to approach software projects.  That’s ok.  There are many non-software projects that would do quite well in the waterfall model.

Meanwhile, let’s dedicate ourselves to spending this coming year getting the most out of agile, especially finding the time to improve the craft of creating the software. Arguing about whether waterfall is still good is *so* 2011!

One question that comes up a lot is, “Who should be the Scrum Master?”  Sometimes it is as simple as, “Hey, we are starting to do Scrum, so we need a Scrum Master. Who should we get?” Sometimes it’s a bit more involved.  Many of these conversations really focus on turning Project Managers into Scrum Masters, as a sort of natural step in transitioning to a Scrum Team environment.  While I understand this seems to be a convenient, comfortable step, I’m not sure it is as helpful as it originally appears.  In our never-ending search for metaphors to explain ourselves, I am going to utilize that well known show from the ’70s and ’80s, M*A*S*H.

Consider the role of the Project Manager.  A good Project Manager is responsible for making sure all the variables for a project are identified and categorized.  He/she is also responsible for identifying and mitigating all of the risks in a project.  Most of this is done at the beginning of a project, and will then continue in a reactive manner throughout the course of the project.  Other tasks that are important to a Project Manager are to identify and manage the budget for a project, as well as make decisions along the way as to changes and delivery.  To me, this is Colonel Potter, as played by the late great Harry Morgan.

Col. Potter understood that his job was not to tell the surgeons what to do, or how to fix a wounded soldier.  He was absolutely a figure of authority, but knew when to get involved and when to stay out of it. When push came to shove, if there was a decision that the team wouldn’t or couldn’t make on their own, he was there to either offer some insight to help them come to a decision, or in some cases he knew he had to be the one to make that decision.  One disclaimer here:  the level of authority for a wartime military commander is going to be much higher than in our world, but much of this still applies.  Leadership is not really different; it just becomes that much more imperative.

So in the M*A*S*H series, who represented the Scrum Master?  I see the epitome of a Scrum Master as Radar O’Reilly.  He made sure everything got done.  People got used to relying on him without asking for something in particular, and he really made everything happen.  If something got in someone’s way, he knew what to trade -and with whom – to make that obstacle go away.  I also think it’s worth noting that Radar was a Corporal for most of the series.  He led from a position of no power whatsoever.  He knew nothing about surgery, nothing about the military, but everything about relationships (albeit, not the romantic kind). There was never any doubt as to who really made things happen there; it was all Radar.  He made things run smoothly so the doctors and nurses could focus on healing the sick and wounded.  This is the Scrum Master.

One last comment on the M*A*S*H analogy.  At the beginning of the series, the doctors did all of the surgery and the nurses supported them.  Over the course of the series, you would hear surgeons use statements like, “OK, nurse, close for me.”  Then later, the nurses started doing triage (determining which patients had to be operated on right away and which could wait) and, in some cases, even getting involved in the actual surgery itself.  So while everyone kept their specializations, each was able to branch out and help wherever necessary.

Sound familiar?

On paper, Kanban is certainly easier to kick-start from a change management perspective because you can leave current roles and processes largely intact; you just need to get commitment from the business to adhere to three basic principles:

1. Provide a high degree of visibility/transparency of the state of all work queued and in progress
2. Establish and respect WIP limits in the value flow
3. Commit to execution in a ‘pull-based’ manner from the prioritized work queue

Yeah, just get commitment and practice of these three things… Much easier said than done in my experience because they are frequently outside the circle of influence of those driving the change to implementing Kanban!

Usually it isn’t that the agile software teams are unable to execute under Scrum; the fundamental issue is that the business isn’t willing to accept a “pull-based” execution model  (required for Kanban and Scrum).

Businesses continue to make irresponsible commitments to customers and investors. This only perpetuates crystal-ball thinking, fixed-date, fixed-scope and fixed-cost projects. It’s the classic sales-driven model we see all too often where the sales arm doesn’t respect the capability of its product development group to produce predictable value for the customer in a timely manner, and with an agreed-upon level of quality. After all, quality is a business decision.

This irresponsible action ends up causing organizations to be unpredictable in their delivery, have lower quality, and to burn out their teams.  These outcomes in turn destroy brands, ruin company reputations on Wall Street,  increase the percentage of each investor dollar serving up technical debt (in lieu of adding new value to products), and causes instability in the organization’s systems due to turnover.

Bottom line, if an organization can’t make the commitment to respect their product development system’s proven delivery capability at the current level, neither Kanban nor Scrum will provide predictability.  But even in the face of this dysfunction, agile methodologies like Kanban and Scrum can still provide faster learning to teams, which allows them to test their assumptions faster and provide more value to their customers by delivering what they actually need.

In conclusion, I leave you with this advice:  ignore the myths and hype about Kanban. Before you can make any decisions on the Kanban vs Scrum debate, you must first evaluate:

• Your organization’s product development and sales culture,
• The nature of the demand for service from product development,
• The competency of your organization to plan and execute change, and
• The degree to which you’re willing to face the truth

Only then can you choose the best agile software tool for the job.

Related topic: What is Kanban? How is Kanban different from Scrum?

It's usually about degrees for true and false

Recently, I heard folks at a few of my clients and at a couple conferences talking about why they are considering moving to using Kanban vs. Scrum.  I have no preference to either method other than choosing the right agile development tool for the job.  My concern derived from what I have heard identifies the beginnings of some myths and also demonstrates some of the hype around Kanban.

First, a clarification; Kanban with a capital (K) is the term David Anderson coined with respect to an agile development approach to driving change based on lean principles.  Kanban with a little (k) represents the idea of the “sign” or “billboard” that provides the signal/visibility in a production line for additional demand for service of a particular station. It is one of the tools that enables just-in-time (JIT) action as described in the Toyota Production System.

Kanban, as Anderson explains in his book, relies on change occurring in more of an optimizing manner (see kaizen culture).

David Anderson's Kanban book

This is the significant difference between Kanban and Scrum.  In a Kanban approach, an organization can begin with their current practices with a few exceptions. Kanban requires:

1. A high degree of visibility into the state of all work queued and in progress
2. Absolute respect for WIP limits
3. A commitment to execution in a ‘pull-based’ manner from the prioritized work queue

Kanban also demands a focus on quality.  In fact, this is Anderson’s first step in his six-step recipe for Kanban.  Quality comes first primarily because of the obvious cause-and-effect relationship to waste — and because it’s generally more in the direct control of technical management.  Working down his recipe, there tends to be less control and influence over the changes by technical management.

Now for the Myths and Hype

Myth:  Scrum has work pushed onto the team while in Kanban work is pulled into the system.  This is incorrect.  Scrum does not have work “pushed through the system.”  It is a pull-based agile development system with work pulled in larger batches (the Sprint Backlog).  A Scrum implementation (as well as Kanban) becomes a ‘push-based’ system when the business doesn’t respect the current proven capability of its teams to produce value and just continues to push demands for service into the system.

Doesn't just apply to Kanban

Hype:  Kanban at its core is summarized by the premise:  ’Stop Starting, Start Finishing’. The entire team’s focus is on ‘getting to done’ for the tasks in progress. This statement is certainly true of Kanban, but the implication that Scrum does not have this focus is not true.  Scrum done right has the same focus, delivering software sooner and doing so in priority order to maximize the value delivered to the customer. I’ve coached to Scrum teams for years that, wherever possible, everyone on the team should work on the highest priority item and get it done first before starting on the next item in the Sprint Backlog.  This implies limiting WIP, as well as focusing on delivering the Backlog in rank order.

If the focus of a Scrum team is to just get everything in a Sprint Backlog into an in-progress state, regardless of priority, then you have a dysfunctional team that’s most likely not working cross-functionally and certainly not focused on delivering the highest-value items first.

Hype: The statement, “The Kanban method is intuitive and is quickly and easily adopted by teams,” to me is a statement that’s used irresponsibly.  It is too often a battle cry of those trying to sell Kanban as a product.  It is the cop-out reason used by many organizations who are failing at Scrum and looking at Kanban.

In Part 2 of this post we’ll continue the conversation about implementing Kanban and some of fundamentals that hold back Kanban and Scrum implementations.

Related topic: What is Kanban? How is Kanban different from Scrum?

Every time a bell rings, an angel gets his wings.  While I’m sure that Clarence appreciated getting his due, I’m not really here to discuss campanology, nor its merits on signaling major life events amongst angels.  Rather, I was recently reading the December 2011 Wired Magazine interview with Jeff Bezos, founder and CEO of Amazon.com, and something he said struck me:

“Every time a customer contacts us, we see it as a defect.”

While certainly not as sweet and innocent as little Zuzu’s proclamation, Bezos’ version does hint at that same sense of childhood naiveté and idealism.  You see, what he’s really saying is that he wants Amazon to be a perfect customer experience.  Not just when a customer reports a missing order or something else unpleasant, but when a customer makes any contact, whatsoever.  In Bezos’ world, a perfect customer experience should be so intuitive, painless and efficient that the customer can barely even recognize that an experience has occurred at all.

It’s a bit of a paradox.  While we all want customers to use our specific brands of software and services, they’re only doing so to solve some other sort of problem.  I’m not using WordPress for the sake of using WordPress; I’m using it to communicate my ideas here to you. We spend lots of time and money building features to make it easier for customers to solve problems using our software. But the truth is, if we’ve really done our jobs right, the customer almost forgets that they’re using our specific brand of software and services to actually solve their problem.  The tool becomes invisible.  I don’t think of the power company when I turn on my lights; why should I think of Amazon when I use them to purchase my, “It’s a wonderful Life” two-disc collectors set DVD?  If the experience was perfect, their role in the transaction would be transparent and forgettable.

Long ago, I had a mentor who suggested that a good employee is one who makes himself indispensable, while a great employee makes himself redundant.  If your job is to solve a problem, and your charter is to make solving that problem as easy as possible – and if your goal is perfection – then at some point you’ll work yourself out of that job.  If our goal as software and service providers is to solve customer problems, and perfection is something we strive for, at some point we should become an invisible part of the equation.  While the idea of invisibility and redundancy may seem threatening, it shouldn’t.  If people can use our software to solve their problems with such ease that they don’t even consciously recognize that they’re doing so, how do you think they’ll feel when they use tools that force them to be aware?

While Zuzu had her rose, Bezos’ petals is the idea behind his words:

1. Focus on the details,
2. Expand your definition of quality, and
3. Never compromise

Striving for perfection may mean that you essentially become invisible. But that’s okay.  Customers may not recognize you when they’re using you, but they sure will miss you when they are not.

It’s almost 2012, a brand new year!  Being an eternal optimist, I am excited with what the year has to bring.  In a short time, the holidays will be officially over and it will be back to “business as usual.”  So as a final adieu, I’d like to offer a toast -

In 2012 may all your builds be good, and all your acceptance tests automated and passed.  May you continue to focus on innovation, quality and user experience.  And may Adrian Peterson of the Minnesota Vikings recover from his ACL and MCL injuries very quickly, as we really can’t afford to have our star offensive player out for the 2012 season over a stupid play from a game that didn’t even matter… er, well Happy New Year!

I’ve interacted with companies large and small, and people from entry-level to the executive ranks about their agile intentions.

Here are the Top 5 ‘Agile Adoption’ ideas that I’d like companies to consider in 2012 (let’s call it an early Christmas present):

1. Start small. Agile methodology doesn’t need to be a scary, hairy, intimidating concept. Change is hard; yet there’s a way to start with one project today.
2. Ask around. More than likely there’s a colleague in your office who has practiced scrum or Kanban in his/her professional career. Ask that person how he or she got started.
3. Understand that ‘lack of control’ is a myth. If done right, agile adoption brings you, your team and your organization unparalleled visibility and transparency. Agile is not the Wild, Wild West. There are rules and best practices.
4. Team first. Your teams will like the collaborative, communicative culture that agile introduces. With everyone ‘in the loop,’ you’ll see high levels of performance.
5. Fail fast. Agile methodology, or any process for that matter, DOES NOT encourage failure. Agile does, however, allow the team to iterate and get to the best way to solve a problem, while learning from those paths that don’t meet objectives.

If you or anyone you know has an interest in starting an agile team or raising an existing initiative to a different level, seek out VersionOne. We can help.

Happy New Year!!

Yours in agile,

Dan Naden

How many times have you found yourself facing the same problems of getting your team to work as a team, getting buy-in from stakeholders, improving your CI capabilities, understanding requirements…? Agile development teaches us to stop trying to figure out all the angles. Focus on the action, commit yourself, and act with purpose.

Recently, while flying home from spending time with a customer, I found myself knocking back a few cocktails (bourbon if you really must know), staring out the window and contemplating quietly from 36,000 feet. As one is apt to do after having had a few drinks, I began reminiscing on my past. You see, in a previous life I was a thespian. That would be actor for all of you folks who spell it theater instead of theatre. Anyhow, for much of my early life, I was almost completely immersed in acting. I performed in dozens of amateur and professional productions, graduated from an arts high school and attended one of the most prestigious theatre conservatory programs in the country. Somewhere along the way, as is typical for people in their 20s, my interests changed. Although my wife still insists that I’m the biggest drama queen she knows, I haven’t stepped foot on stage in many, many years. As this piece isn’t really about my penchant for melodrama, I digress. Rather, the thing that struck me most on this particular flight was just how relevant one of the fundamentals of my acting training is to my current life in coaching, training and development.

In my time, method acting was the primary technique that acting students were expected to learn. Famous method actors include Dustin Hoffman, Marlon Brando, James Dean, Sean Penn and many others. For those in the know, there are really two main types of method acting. There is the American Method and the Stanislavski Method, devised by Constantin Stanislavski, of which I was a student. The goal of method acting is rather than simply pretending, the actor physically becomes the character by experiencing a psychological and emotional response based on the character’s circumstances. What makes the two methods different is that while the American Method focuses on recreating the emotional and psychological conditions in which the characters exist, Stanislavski focused on creating the emotional and psychological conditions through purposeful physical action. I realize that though the difference here may seem subtle, the application is profoundly different. For the sake of argument, let’s say that you are asked to play the character of a recently widowed, elderly person who has lost his much beloved spouse of many, many years. It’s the holidays, and even though you are still very much in grief, you are trying to reclaim some normalcy by decorating the Christmas tree. In this scene, as you are unwrapping the tree ornaments from last year, you come across the very ornament that you and your spouse bought to celebrate your first Christmas together, all those years ago. An almost overwhelming wave of conflicting emotion washes over you as you place the ornament in your hand. You feel sadness for the loss of your dearest friend, loved one and confidante, while at the same time an intense joy over the memory of your life together. With a tear in your eye, but the glimmer of a smile on your face, you slowly yet purposefully walk over to the tree and proudly hang your ornament for all to see.

If you were a student of the American Method, you would attack this scene by carefully drawing upon your own emotional and psychological memories in the attempt to place yourself in a frame of mind, similar to that of the character. As a student of the Stanislavski method, your approach would be very different. Rather than calling upon your own memories, or any memories for that matter, you would instead focus on how someone who was in that state of mind would move and physically act. How would the character physically hold his head and move his hands as he unwraps the ornaments? How would he physically hold his shoulders with the weight of the ornament in his hands? How would he walk to the tree as he prepares to hang the treasured keepsake? Stanislavski believed that by focusing on recreating the physical actions of the scene the actor would, through his subconscious, naturally create the emotions and psychological state of the character. As any actor will tell you, this technique is incredibly difficult to master. To this day I still fondly (although I couldn’t use that same word at the time) remember one of my acting coaches screaming at me to “Stop Acting! Just Do!” as I tried to think up the emotional state of the character.

By this point, I fully expect that most of you who are still reading are wondering what in the world does this post have to do with agile development.

Stop acting, just do!

How many times have you found yourself facing the same problems of getting your team to work as a team, getting buy-in from stakeholders, improving your CI capabilities, understanding requirements, etc.? The list goes on and on. Humans are funny creatures. When presented with problems, we like to think about all the different ways that we could solve them, all the possible causes for them, and all the things that go wrong in between. We feel a need to be able to cognitively understand and comprehend the situation, analyze our options and then attack. The problem is that for most of us we spend far more time thinking than actually doing.

Stop acting, just do! That’s the idea of agile development.

If you ever see actors in rehearsal, you will know that they practice by repeating lines and sequences over and over again, making both subtle and radical changes in delivery, timing and intent. They experiment with a multitude of variations before arriving at an approach that works. This is inspection and adaptation at its finest. While it goes without saying that the problems faced in software development are far different from preparing for another staging of “That Scottish Play,” the lesson is still just as valuable. Agile development teaches us to stop trying to figure out all the angles. Focus on the action, commit yourself, and act with purpose. By doing so you will find that meaning and intent will emerge. When the results aren’t exactly what we hoped for, change and try again. The more time we spend doing, the more we will learn, and the more we will grow and improve.

Now, where can I find another one of those bourbons…