Agile Development Blog

The Agile Blog is proud to present the first post from our newest contributor, Agile Coach Ken Clyne

If a team member doesn't take accountability, things can get messy

With a four year old and a six year old, familiar sayings around our house are “pick up your toys,” “pick up your clothes,” “brush your teeth,” “get dressed.” Of course, as parents we could get our short-term objectives met much faster if we just did these tasks ourselves… but we don’t.

We understand the importance of our children developing their own awareness of basic hygiene, cleanliness and developing their own skills that will one day help them become independent.

Giora Morein takes somewhat the opposite view in a recent Agile Tip of the Month article. He proposes that ScrumMasters (or, in my extreme analogy, the “parents”) should track hours remaining on a sprint on behalf of the team members (the “kids”). Giora says:

“Team members are focused on completing tasks and delivering value. The time-tracking is a nuisance and a distraction for these motivated folks. To the ScrumMaster and the team, however, it is extremely important. As such, the ScrumMaster should take on the responsibility of updating burndown data.“

While I don’t question Giora’s good intentions and there is no doubt this approach is expeditious, I believe it is worth striving to have the team update their own hours remaining. There are many benefits to being a member of a self-organizing, self-managing team, but with those benefits also comes responsibility and accountability.

Here are some dangers I see in a team not taking responsibility for their hours:

• They become less accountable for the number they provide

• They don’t understand the mechanisms of the self-managing, self-organizing team

• They become dependent on the ScrumMaster

• The ScrumMaster becomes frustrated and disillusioned

• The ScrumMaster morphs from a leadership role to a management role

• The team starts to revert to form

How does your team update its remaining hours? Have you tried one method that worked better than another?

#5 in our list of the Top 10 characteristics of an Agile organization is about the importance of practicing both Bottom-up and Top-down decision making.

In this 4 minute video, I talk about how successful Agile organizations embrace a notion of the ‘knowledge-creating company.’ In Agile, knowledge-creation can use “5 Levels of Planning” to ensure they are engaging in this whole organization practice. In sum, the highest level of planning, the vision, feeds and is fed by all subsequent levels, down to the lowest level of planning, the detailed daily work.

Watch my video for more about why I truly believe in both Bottom-up and Top-down decision making as a key success factor.

See our previous coverage of #10 Work/Life Balance, #9 Being a Servant and Leader, #8  Sustainable and Successful, #7 Contributing to the Community and the Company and #6 Collaborative and Smart. Stay tuned for #4 in our series, Personal Flexibility and Rhythm.

The next round of Agile Success Tours starts next week as Rally customers share their stories in a community-building event. We coordinate these events for the purpose of learning from do-ers. This is not a Rally sales pitch or a parade of “experts”; this is a place where software and IT leaders can share with their peers the best practices and roadblocks to Agile adoption. Peggy Reed, one of our phenomenal speakers from the Denver event and Avaya’s Director of Contact Center Reporting, said:

“I would totally recommend this event to people who are moving from another methodology to Agile. There are moments of truth when you move to Agile that are really tough for organizations. Having some help in a community that shares those moments of truth and change makes it understandable. You can see your progress if you share your journey with other people.”

In addition to the speakers below, Israel Gat, former VP of Development at BMC Software, will be at all three events sharing his enterprise Agile adoption story. The event is free, but registration is required.

June 4, 2009 – Santa Clara, CA

• Leigh Anne Glasson, VP IT Applications Engineering, VMware
• Doug Miller, Software Program Manager, Thermo Fisher Scientific
• Melina Linder, Director PMO, e-Business, Kaiser Permanente
• George Morris, Director, Roche
• Rajesh Natarajan, Sr Director Global Merchant Services, PayPal

Register for Santa Clara >>

June 25, 2009 – Atlanta, GA

• Michael MacDonald, Sr VP Product Development, NEOGOV
• Darren Shipp, VP of Engineering and Development, AutoVIN
• Judith Mills, VP Product Engineering Operations, CDC Software

Register for Atlanta >>

July 23, 2009 – Washington, D.C.

• Charlie Felmeister, CIO, SMARTHINKING
• Jay Ennis, VP of Product Development, Netcordia
• Additional speakers are being confirmed now

Register for D.C. >>

We look forward to seeing you there!

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.

As geeky as it sounds, I love learning. When I was first exposed to the world of organizational learning back in the 90’s, I picked up a couple of handy phrases that I chant on weekly basis:

• Learn – Teach – Learn
  
• No Theory, No Learn
  

These phrases capture two of my mental models on organizational learning. Mainly that it is an iterative cycle, only comes through sharing, and requires reflection and measurement on your theory to learn. With that in mind, we frequently open our doors to our customers to Learn and Teach.  They observe our stand-ups and planning meetings and we discuss how Agile development has infiltrated not just our development team, but our entire business.  I always try to ask them – “What is your Theory?” before they come.

Creative Commons Kathy Sierra - Click to view her blog post on the topic

What’s Your Theory?

Many organizations are simply happy to take the first step toward the smooth and continuous flow of Agile development. But what I love about working with many of our customers like Pinnacol Assurance is their desire to go beyond amateurism, what Kathy Sierra shows as the road to becoming an expert.  Amateurism is not enough; they want to become experts by fully adopting Agile throughout their organization and through a continuous improvement process.

At our last release planning session in April, members of the Pinnacol’s IT team participated right alongside our internal team. Wednesday of this week, members of Pinnacol’s leadership team shared in our company-wide rhythm of daily  stand-up meetings, rotating through a variety of stand-ups from the dev team to IT to marketing.

How about a Learning Journey?

The goal of their trip was bringing mental models from outside of Pinnacol into their organization. I love that approach and it’s one we use ourselves at Rally. If we see a company doing something particularly well – whether it’s supporting their customers or hosting an out-of-this-world event – we ask to visit their company, shadow them for a day or two, and get first-hand knowledge of their success. It’s one of the best ways I know to quickly learn a model in a very hands-on way and almost immediately translate that into success at your own company – all without reinventing the wheel.  Otto Scharmer who developed Theory U calls these trips – Learning Journeys.  They are the first step to help you see what you do not know and getting you to open up and learn as a team.

Pinnacol has been very successful at attaining the benefits of Agile in flow inside of IT, but they are already looking above and beyond. They brought business representatives and operations leaders to share and learn about increasing agility in a larger, enterprise-wide context. I am really looking forward to hearing more about Pinnacol’s path to fast learning. You can read about Pinnacol’s adoption of Agile and Rally in the case study.

Okay, I must be obsessed with Agile and PMOs lately. Well, Lean, too, as long as we are talking about obsessions.

Recently, I posted two blogs on the PMO topic: “Are PMOs Obsolete in Agile?” and “8 Ways to Re-tool a PMO in an Agile Environment“.

Now, in the upcoming Better Software Conference June 8 through 12, I will be presenting “Agile, Lean and the PMO”.

To summarize and entice, let me give you a quick preview.

PMOs usually think they are out of a job when Agile comes to town. But the truth is that a PMO can play a pivotal role in successful Agile adoption in large organizations.  In this presentation, I bring my experiences guiding organizations in how to engage their PMOs for successful Agile Adoption.

Enter three primary Lean Principles:

• Eliminate Waste
• See the Whole
• Amplify Learning

I intend to give examples of how PMO members act as the “systems thinkers” for their organizations, pulling Agile success outside of the engineering group alone and into the entire enterprise.

As I’ve stated before, there is a fundamental shift of the role of the PMO with Agile.

Simply stated, the PMO pulls standards versus pushing them;  the PMO provides product backlog prioritization guidance with regard to architecture and governance; and the PMO serves its Agile community by facilitating release planning across teams and creating and maintaining product councils.

In short, I contend that a truly Agile PMO brings “shocking openness” to the organization. This ensures deep, wide Agile adoption.

Let’s get together in Vegas to talk about PMOs and Agile and how Lean can guide us to take “what happens in Vegas” back to our organizations!

I have always answered the question “Where does Agile not work?” with the answer: “We have customers in all forms, geographies, and technologies working in Agile. It works everywhere!“

Of course that is my Agile Convert persona coming screaming through…

In his article “Agile Processes Go Lean” on the Dr. Dobbs portal, Forrester analyst Dave West does a great job illustrating the true challenges and roadblocks in successful Agile adoption beyond the team. His research across numerous sources, collaboration with Tom Grant and ability to synthesize these concepts makes this article a must-read for executives in software development organizations.

Dave sums it up nicely:

“The problems, broadly, tend to be technical, cultural, or organizational. Technical problems relate to infrastructure, tools, and architecture, and are often the most visible of the changes involved. But many companies find the cultural and organizational issues are the hardest to resolve.”

“When a development organization uses the approach to transform itself, it often runs into problems with other parts of the company that haven’t undergone similar transformations. Clashes come with the business operations, governance, and organizational structures, among other areas. For example, hierarchical organizations may struggle with agile development’s quick, iterative review cycles and decision making.”

In the past few months, I’ve talked with Dave and Tom about the opportunities and success of large-scale and successful Agile adoptions (beyond single teams and beyond simple flow) using examples from our customers and even our own internal processes. I’m excited to see analysts tackle the meaty topic of scaling Agile and Lean with real data and customer stories.

Further Reading:

• Lean Webinar Q&A Part 3: Championing Agile
• Scaling Lean and Agile Development – Ask Bas and Craig
• What Are Your Favorite Resources for Lean and Agile?

I love talking about Agile Organizations with Ryan Martens. When we thought about our Top 10 characteristics of an Agile organization, we recognized the pivotal importance of collaboration. (Having written a book entitled Collaboration Explained may have prejudiced me slightly :- )

When I talk with teams, organizations, and  CxOs about adopting a collaborative culture, I can be met with some resistance. Some of it is very direct; often it is passive-aggressive. The rub lies in deep assumptions and old wounds:

• Collaboration means dumbed-down
• Collaboration means group-think
• Collaboration means bringing decision-making to a halt

When Ryan and I say “collaboration” this is the opposite of what we mean. We have a very different picture in mind. Here is a quick view of what WE believe:

Not only can collaborative and smart go together —
they must!

1. Command-and-control actually makes people stupider—we hire smart people. Don’t we want them to stay as smart and actually get smarter? Command-and-control has the effect of lowering people’s IQ. Collaborative environments improve people’s cognitive skills. They raise people’s IQ’s. Which statement would you like to go home and tell your family: “Hey! I lower people’s IQ’s as a living!” or, “Wow, I actually make people smarter!”
2. Whether you read “The Wisdom of Teams” or “The Wisdom of Crowds” the evidence is in: we make better decisions when we invite more insights. This aligns with the Lean principle about gathering as many insights as possible before making a decision. Think about set-based, concurrent design and concurrent engineering.
3. People who believe collaboration means group-think (or dumbing down of decisions) haven’t experienced the power of Storming. That means inviting open and safe conflict around decision-making in a high performance, high trust environment. A prejudice against collaboration is usually based on old wounds. Trust was low. Safety was low. People’s IQ’s had been lowered. In these contexts, an individual team member may only have one tool in their toolbox: a hammer of heroics. Taking that hammer away can look disempowering. In this context, collaboration has to prove that they have something to gain. That is, they are ADDING to their toolbox.
4. Finally, to make sure that collaboration isn’t a drag on an organization, we rely on extremely effective facilitation. (Collaboration Explained is a good guide!) We rely on effective processes to gather the insights, to seek conflict and dialogue, and to guide teams to take insights and turn them into consensus. This form of collaboration is NOT compromise or capitulation. It manages and then eliminates swirling down energy-draining ratholes. It ensures discussion around useful dialogue versus interesting debate. And, it prevents Loudest Voice Driven Decisions (LVDD) :- )

See our previous coverage of #10 Work/Life Balance, #9 Being a Servant and Leader, #8  Sustainable and Successful and #7 Contributing to the Community and the Company. Stay tuned for #5 in our series, Top-Down and Bottom-Up Decisionmaking.

I am ever seeking to expand my Lean learning. This week I am attending and speaking at the Lean Kanban Conference in Miami, FL. I’m excited about the opportunity to engage in more Lean learning with some great people. Real conversations with the folks behind the books and on the forefront.

In my post on my Leaning Bookshelf about my Lean learning, I included Craig Larman and Bas Vodde’s wonderful book : Scaling Lean and Agile Development, based on their collective experiences in very large (and distributed) Agile software development.

I love this book.  Given my interest in the book, and knowing both Bas and Craig a little, I invited them to tell us a few things about themselves and the book.

Q. [JET] I’m very interested in Systems Thinking and yet don’t find too many people in our software development field talk about it. So it was a wonderful surprise to see it as the opening topic in your book.

Tell me, why do you feel it is so fundamental to the work of scaling lean and agile development?

[Bas] I do think systems thinking is discussed in the software development field. Gerald Weinberg, of “Psychology of Computer Programming” fame, has written three books on the topic. Of all the topics Jerry talks about, I think this is probably the one he has written the most about. Also, Mary and Tom Poppendieck wrote about the topic in their lean software development books. But perhaps you are right, it is still not covered enough.

In large-scale development everything tends to have an effect on everything else. It is easy and common to quickly respond to events or draw conclusions. For example, if there are many bugs in your system, it is easy to relate that to something you did recently and act based on that. When, after acting, the bugs increase or decrease, it is too easy to conclude that these two relate.

These mistakes in cause-effect thinking are especially common in large-scale development and therefore it is important to try to think of the system as a whole. System thinking helps thinking about the whole system and especially doing that together so that perspectives become aligned and a common understanding is created.

[Craig] The large-scale immediately (and usually, painfully) bumps us into the organizational structures and policies, and their impact to support or inhibit the flow of value. And large-scale development organizations have more formal policies and structures compared to the small-scale. The organizational design reflects the psychological and systems insight — or lack thereof — of the people in management.

Most business (and broader) problems have their root cause in mental and emotional limitations or weaknesses: command-and-control management and “Theory X” managers, not seeing the true nature of causal relationships, not grasping non-linear effects and delays in the workplace, lack of kindness and transparency, and so forth. And it extends to deeper issues: awareness of and healthy suspicion of our own mental models, double-loop learning, skillful listening and conversation, emotional intelligence … Great organizational designs reflect people in leadership with great personal mastery — and part of that mastery is people who can do systems thinking.

Q. [JET] Craig is a great guy. I’ve enjoyed the few times I’ve had to talk with him. As you were writing the book together, what would you describe as something in particular you were grateful that you learned from him?

[Bas] The book is a result of years long co-operations and discussions. So to limit what I learned from him to writing the book wouldn’t be fair.

Over the years, I mostly appreciated the countless discussions we had on large-scale development. I’m not always good at expressing my thoughts and Craig is a patient listener who really tries to understand different perspectives. Then, he is not shy on giving very direct feedback. I think it’s these discussions (and the ones we will have in the future) that I’m most grateful for.

Then, specifically to writing the book. I’m not a native English speaker and not an very experienced author. I don’t think I could have learned more about English language and writing in a shorter period.

Q. [JET] I love the “Try-Avoid” model you use throughout the book as well as inside the covers. It seems to walk a nice tight rope between prescription/non-prescription. What inspired you to come up with this approach?

[Bas] That is interesting. I wish I could take any credit for this, but I’m afraid Craig actually made that decision. I even argued against it since I felt that it would hurt the readability of some parts. Not all parts are easily put into this “experiment-format.” After many discussion on the format, I agreed with going forward and over time started to appreciate it.

What inspired the approach? I’ll let Craig answer this more thoroughly, but the main thing was the illusion of knowing the answer. Every situation, product, culture and company is different. Every product we go, we learn new things and experiment with new ideas.

So instead of giving “the solutions” we’d like people to think about their context and about the different experiments they could do. Learn from these and find themselves the best solution in their context.

[Craig] First, to reiterate what Bas said, kaizen in Toyota, and empirical process control in Scrum, emphasize a culture of structured experiments, rather than defined process or a cookbook of process recipes to follow, and I hoped to emphasize that notion.

Second, I become frustrated when reading a book and I have to dig around in the text to find specific actionable advice the author is offering. I want to respect my reader’s precious time, and make it as easy and immediate as possible for them to find that.

Q. [JET] Several years ago Bas, you and I roamed through Powell’s bookstore’s used computer books in Portland, Oregon together. That gave me a glimpse into your love of books; your bibliography for “Scaling Lean and Agile Development” is yet another indicator!

So here is a tough question for you: what were the top 5 books that inspired you in writing this book?

[Bas] Yeah, the visit to the bookstore was nice. :)  I’ll change the question a bit. I’ll answer it with the top 5 books that inspired the content of the book… but weren’t mentioned in the book. There was no appropriate place to recommend them.

• - Debugging the Development Process – Steve Maguire.  Steve wrote two classics in 1995. One related to writing code “Writing Solid Code” and one related to the processes for writing code called “Debugging the Development Process” which describes how he managed software development groups within Microsoft. The book is full of insightful advice about software development and it is a book I always get back to and re-read parts of. Still today, most of Steve his writing is exceptionally relevant.

• - Secrets of Consulting – Weinberg. Gerald Weinberg has contributed so much to the knowledge of software development. Not just his 40 books, but he has a group (Weinbergians) who he trained and is still in contact with. I know some of them and Weinberg’s influence is visible. Of all the books he wrote, this one was perhaps one of the most insightful ones. It is, like all his books, full of stories and small insights on working together with people and companies.

• - Juran on Quality by Design – Juran. It is quite amazing that we did not have any place where we could recommend the work of Joseph Juran. Juran, next to other “quality gurus” such as Deming, Crosby, has been a huge influence on my personal thinking about organizations and developing quality products. I especially enjoyed this book of Juran and his insights related to quality planning and product development.

• - The Gold Mine - Balle and Balle. We recommended a lot of lean books, but not this one. This lean book is written as a novel, which makes it hard to find a good place to recommend it. It is quite much like “The Goal” which is the well known business novel introducing Theory of Constraints. The Gold Mine, however, didn’t introduced any new concept, but it does a great job of clarifying lean in a form that is easy and engaging to read.

• - The Peter Principle – Lawrence Peter. Some organizational behavior is so taboo that you shouldn’t be talking about it. But, of course, you can ridicule it. Thats exactly what the Peter Principle does. It shows that human society is rising in the animal hierarchy and has reached its level of incompetence. Books like this one give a great perspective to behavior in organizations and are very funny to read. Painful, but true :P

[Craig] In the same spirit of Bas, on relevant works that weren’t really emphasized:

• The Birth of the Chaordic Age by Dee Hock; and,
• various books by Ralph Stacey on the illusion of the belief of how much we can influence or control our complex non-linear social work systems (Stacey’s work is touched on in Beedle and Schwaber’s first Scrum book). There is a deep assumption in most people at work: we can control complex things. Once a great doubt arises about this core assumption, it opens a major can of worms that pulls the rug out from underneath many organizational design ideas.

Q. [JET] You mentioned to me that you and Craig discovered that in the writing of your book, you were uncovering “an embarrassment of riches”. This led you to decide to divide your work into two books.

What sort of preview can you give us to the material coming in the second book?

[Bas] Oh yeah. We kept saying “Oh that must be there.” Then we kept removing things to only leave the essentials. But soon it became clear that all the things we wanted to say would not fit in one book. Influenced by Don Reinertsen’s “The Design Factory,” we wanted to split the book in thinking and action tools. However, we had a group of ideas which didn’t fit well in either, so we came up with the “organizational tools.” Suddenly we had two logically consistent books and decided to do that.

The second book will be the “action tools.” The goal is to give concrete advise on how to do particular practices. How to do planning? How to do design? What do with with multi-site development? What to do with legacy code? All of these chapters will use the action and organizational tools from the first book. When people read the book, they ought to have concrete experiments for their current situation.

[Craig] We maintain a current-vision TOC at:
http://www.craiglarman.com/wiki/index.php?title=Book_-_Practices_for_Scaling_Lean_and_Agile

Chapters include: Contracts, Offshore, Multisite, Product Management, Legacy Code, and more.

#7 in our list of the Top 10 Characteristics of an Agile Organization is about the importance of contributing to both the community and the company.

In this 3-minute video I explain that by (1) finding a sustainable pace and (2) delivering continuous innovation, organizations define a higher level purpose that goes beyond their economic bottom line.

See our previous coverage of #10 Work/Life Balance, #9 Being a Servant and Leader and #8  Sustainable and Successful. Next up is #6 Collaborative and Smart.