Agile Development Blog

Recently, I was working on an introductory presentation about Kanban. A “thorough” Google search revealed how drawn out and convoluted many Kanban explanations can be. Was there one true answer I was missing? Something nice and succinct like, say, a tweet on twitter?

Acting on this and laziness, I decided to pose the following question to twitter:

I was so surprised by the number of great responses that I’ve decided to compile and share them with you here:

• 

  giff24: #kanban 130 chrctrs? PLS!!! I dnt hve time or patience 2 rd that much

• 

  erwilleke: #kanban combines systems thinking with a work-limited pull system to allow rapid maturation of teams and delivery of software.

• 

  neontapir: Kanban uses visual signals to track and optimize work delivery through key stages in its lifecycle.

I like the commonalities around value, visualization, limited WIP, pull systems, cadence, and flow. This tells me that Kanban is speaking a common and useful language to a lot of us. And, its value can be articulated in a tweet.

But my quest goes on!

I encourage you to add to this list by submitting your own 130 character Kanban definition either as a comment to this post or as a tweet to me (@jeantabaka and use #kanban in your answer.)

In April, I’m attending the Lean SSC conference in Atlanta. There will be a lot of discussion about Kanban.  I’ll personally carry all comments and tweets to the conference for inclusion in the discussion. If you’re able to attend, let’s stretch the envelope and go beyond 130 characters on Kanban.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

For 2010, lets find ways to focus on teaching our craft and growing the world of skilled software development professionals instead of trying to figure out who is “right.”

I believe much of the “Escalation” that Jean is seeing was correctly titled by Regina Mullen as a battle to be “right.” (see and read Escalation is Killing Agile – Can We Please Stop It? and Escalation is Killing our Healthy Conflict in Agile). That behavior focuses on carving up the pie instead of growing the pie.   There has been so much added to the field of software development methods, tools and techniques from the guiding ideas of Agile.  Now is not the time to stop and eat.

For me, 2010 is about continuing to grow the Agile software development pie’s reach and innovations.

I believe one of the key fixes to the problem of escalation can be found through increased professionalism and certification in Agile. By raising the bar through “difficult and skills-based certification,” as Brian Marick and the board at the Agile Alliance described, we can advance the Agile discourse through :

• a defined a bar that is deep in skill, knowledge and practice
• a significant enough bar to engage College and University study and examination
• research and curriculum that explore the tough questions in a scientific method
• development of more flexible or “T” shaped individuals that can see and work beyond silo roles.

With this back-drop, I am motivated by the notion of creating a  A Community of Thinkers,:

I am a member of a community of thinkers and I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

A Community of Thinkers creates more leadership in our profession. I see the expanding certification efforts in 2010 as great steps in these directions:

• Lean Software and System Professional – new certification emerging
• Agile Developer Certification – that is also emerging
• Certified Scrum Practitioner – especially as it intertwines with the PMI’s Agile Community of Practice

I encourage everyone in our community to figure out how to put energy toward one or more of these efforts.  The benefit of actively learning, teaching and reflecting on our work should lead us all to expanding civil dialogue that works to understand all points of view and keep expanding our thinking.  Thus broader education and difficult certification helps create a “Community of Thinkers.”  And, a Community of Thinkers will create a virtuous cycle of win/win and thus a larger pie for all.

That is my hope for 2010 in our profession.

About the Author: Ryan Martens is a happy father,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

I had the fine fortune of spending a day with Liz Keogh and Eric Willeke in Boulder last week.

What a wonderful experience! The three of us gathered with the goal of producing something for the Lean and Kanban software community. We didn’t know what that would be. We just knew we felt strongly that we should give something to the community.

We were heavily influenced by past conversations with Chris Matts, his call for “fewer leaders, more leadership”, and a desire to see the Lean Software and Systems Consortium (LSSC) learn from some of the trials that other communities and community-leading organizations have undergone. Ryan Martens, the CTO and a founder of Rally, also provided thoughtful input to our discussions during the day.

As we talked, we discovered something. We were all keenly interested in the general notion of “community”. We became less convinced that the LSSC needed a challenge from us, and more convinced that it was applicable to software communities generally. For me, this was a deeply personal statement and commitment.  It played heavily into my recent blog posts on “Escalation”. And yet, together, Liz and Eric and I found the same deep conviction.  So as you look at the statement I provide below, if it’s exactly the same as the copies on Liz or Eric’s sites, it’s only because their arguments were equally sound and convincing.

Because of that personal nature, we wanted to avoid putting our statement up as some kind of manifesto that people can sign. If you feel strongly enough about this statement that you would want to sign up, copy it. Post it on your own site. Attribute it to wherever you got your copy from – the act of sharing is more important to us than the act of creation – and feel free to change it so that it reflects your own values. I don’t think that any statement like this can ever be perfect, nor will we perfectly live up to it.

I am a member of a community of thinkers. So are you.

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

Recently, I wrote the post “Escalation is Killing Agile – Can We Please Stop It?”  My passion around escalation brought 40+ in-depth comments.  With my travels and lack of internet access, I had been unable to sit down, sift through, and absorb all the various perspectives.  Until now.

I’m offering this follow-up post as a means to provide an overall response to all these great comments. I want to add some further background on the “escalation” topic and some more of my personal conviction around it. Specifically, I’d like to provide some insights into delayed feedback, the need for conflict, and how to “show up”, all without escalation.

In one part of the comment stream, I heard and felt the call for an effort to get to the root cause of such deep-rooted assumptions.

According to the Systems Thinking Toolbox from Pegasus Communications, to break an Escalation structure, ask the following questions:

1. What is the relative measure that pits one party against the other and can you change it?
2. What are the significant delays in the system that may distort the true nature of the threat?
3. What are the deep-rooted assumptions that lie beneath the actions taken in response to the threat?

So, in our system of sharing information in the Agile community, we have to ask, “Are we setting up a dynamic that pits us against one another?” If this is true, then we have to ask, “How can this be addressed and still ensure that we share insights?”

Guided by Systems Thinking, that means we need to check in with: what is distorting our communications and what might our deep-rooted assumptions be that would have us act as we do?

Here is an example:

I created a delay in feedback by my not responding to posted comments. I believe that created assumptions around what I may or may not have intended in the post.  I think some individuals thought I had written the post pointed specifically at them. Faster feedback would have helped quell that assumption.

I was writing about, and continue to write about, the Systems Thinking Escalation archetype and how I see it in our community. I was and am looking at a dynamic not at an individual. Escalation is NEVER about an individual; it is about the system in which blame is occurring and allowed to continue. I am fearful that blame and the win/lose game are in our system and that is what I do not like and I want to address.

Some of the comments to my post seemed to indicate that I was anti-conflict. Far from it! In studying the inner workings of high-performing teams, I have often referred to Sam Kaner’s model for participatory decision-making. Conflict is a must.

In this model, Kaner insists that, to get to high performance we must bring forth conflict to discover the best informed decisions. Divergent ideas must be invited. Divergent voices must be heard. Divergence must be allowed to just be. That is, don’t just jump to conclusions. With enough time and patience around divergence, we can then move toward informed convergence.

Conflict in this context is dialogue. It seeks insights. It invites greater and greater participation. I also want to emphasize that in this context of dialogue and non-escalation, our purpose is to engage in forward thinking. We let go and we look forward. And as we look forward, we let go.

So, as a member of the Agile community, my interest in expending energy in discussions is to seek insights, encourage divergence, and discover convergence as it emerges. All of these practices help and encourage me to create more and more forward thinking. If this is not occurring in our community, then we are not getting enough for the energies we expend.  If in our community we really “must win”  in order to “be heard”, we are stuck in an “Escalation” archetype. And, that means we are all trapped on an up escalator to nowhere.

What could any individual do to break an escalation pattern in a system? Create energy around your insights and share them without a need to apply win/lose stakes. Stop expending energy to refute others.

Here is a simple formula for bringing your viewpoint to bear without escalation:

1. Show up. (Be willing to be engaged.)
2. Find out what has meaning to you. (Be willing to be honest about your perspective.)
3. Tell your truth. (Be articulate about your insight without attacking or assigning blame.)
4. Let go of what happens. (Be courageous enough to allow others to agree or disagree.)

I believe this formula provides guidance on how to remain forward thinking, remain open-minded, and remain engaged.

I have some more mental models I want to offer here. But they will wait for another post.

Thank you in advance for your considerations, insights, and comments.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

I have been told repeatedly that my brain thinks in pictures, and as a result I have to work hard to communicate my logic effectively in words. Recently in my argument against an Agile Process Maturity Model, I made a comment that Agile is an instance of Lean.

One of the replies on the Agile Alliance Group of Linked-In countered that my statement isn’t accurate – and in fact a team being both “Agile and Lean” is an oxymoron. So, I looked in the mirror and said this must not be clear. I need to communicate better in both words and pictures.

“The term Oxymoron originates from the Greek oxy (”sharp” or “pointed”) and moros (”dull”). Thus the word oxymoron is itself an oxymoron.”  Wikipedia’s Etymology for Oxymoron

Instead of trying to figure out which is sharp and which is dull, I thought I would present my mental model on the evolving Agile software development ecosystem.

Agile as an umbrella term

First and foremost, Agile as an umbrella term was hatched in 2001 to represent a “way” of developing software that is focused on rapid value delivery, collaboration with a customer, face-to-face communication and measuring progress in working code.  It casts a wide net of iterative and incremental process frameworks including RAD, Spiral, Extreme Programming (XP), Scrum, DSDM, Feature-Driven Development (FDD), Lean Software Development, OpenUP and Kanban. These methods stand in contrast to highly structured methods that tend to measure success based on meeting plans and following the process.

My rendition of the geneology of Software Development Approaches

Agile has evolved both bottom-up and top-down based on the evolution in technology infrastructure, tools and guiding ideas of our industry. It is symbolized by increased productivity, speed to market, response to change and craftsmanship.

I believe it is not a fad, but a natural by-product of the increasing scientific as well as craftsmanship approach brought to this critical industry.

Lean merges with capital-A Agile

I see the pictured genealogy tree merging Lean software development methods together with capital-A Agile methods. This is because the physics behind Lean design and production are the same physics that make Agile deliver impacts like we see in the Agile Impact Report from QSMA – 50% faster time-to-market and 25% increased productivity.

Though the principles of the Agile Manifesto do not sound like the principles of Lean, the patterns are the same. (For a great overview of Lean software do not miss Corey Ladas’ guest post on Shaping Software.)

• Small batch sizes, short cycles that create rhythm
• Reduction in queues through pull
• Reduction in work in process inventory
• Design quality in
• Stop-the-line defect control
• Value streams the link to the customer
• Integrated learning through reflection
• Last responsible moment decision making

These patterns are the same for an effective Lean effort or an effective Agile effort. This thinking has me advocating that Agile is an instance of Lean, not just a ground-up new tree that was born solely from the roots of OO, Spiral and RAD.  I am having a hard time seeing the black and white separation between agile and lean. This is all grey, maybe I should say blue and red based on the diagram, to me. 

What do you believe – is Agile is an instance of Lean, or together are they are an oxymoron?

Kanban is great. I value that it seeks immediate fixing of problems, which is referred to as continuous improvement. I love that.

I value that teams are prepared to “Stop the line” and not allow process or defects to continue unscathed. I love that too.

I wonder what Ferris would say about "Fixes that Fail"

But for all that, I haven’t seen clear Kanban practices for long-term trending that would help us identify or capture those “Fixes that Fail” or “Unintended Consequences.”

I am concerned that the emphasis on immediate improvements may fail to capture what long-term negative impacts may be lurking. I worry about a “not seeing the forest for the trees” effect.

So what does my concern about Kanban have to do with Ferris Bueller?

It is admittedly an odd connection. Specifically, it refers to a classic line in the movie “Ferris Bueller’s Day Off.” Ben Stein, Ferris’s history teacher, asks the class, “Smoot-Hawley Tariff Act: raised or lowered tariffs– anyone? anyone?” trying to get at least one student to respond. Classic line from a classic movie, though most people believe that the line was about a fictitious act.

Fast forward a few decades. In a recent New York Times Sunday Business section,  Stein wrote an article on economics entitled, “The Smoot-Hawley Act Is More Than a Laugh Line.”

Smoot-Hawley, unbeknownst to Ferris Bueller and most of us, in fact RAISED tariffs in an effort to protect the US economy from an influx of foreign goods during a challenging national economic downturn.

At the time, the “immediate fix” of the Smoot-Hawley Act seemed like a good one. Ultimately, however, the pundits of the time declared that it wasn’t enough to save the country from the economic ravage we now know as the Great Depression.

Today, economists are reconsidering the supposed low or non-correlation of the Smoot-Hawley Act and the Great Depression. Did that immediate fix actually have a lot more to do with the Great Depression than had been understood? Hmmm. Something to reflect on for future possible fixes. The debate is absolutely there. An immediate fix (like Kanban fixes or Smoot-Hawley fixes) may be one of the “Fixes that Fail” or have “Unintended Consequences” that can only be seen  through a longer view lens.

The value of this long-term reflection, whether in Kanban or in economic fixes, on such a small fix can have far-reaching impacts on our overall systems.

As Stein points out in his article, economics is not physics. For my part, our analogous comparison is that software development is not manufacturing. We need to walk the walk of systems thinking by being ever vigilant to seeing the entire system, the whole. And that means acknowledging that we will absolutely have delayed feedback loops on our fixes. Longer term reflection and retrospectives can help us make more informed “immediate” fixes as we move through ever challenging world of software development and delivery.