Posts Tagged ‘Agile’

A Culture of Heroism

Agile & Lean, Coping and Communicating, Musings | Posted by Doc
Feb 11 2010

A while back, I wrote about A Culture of Blame. As I’ve traveled around the US and to other countries, I’ve seen more and more evidence of this, which keeps me thinking. I’m always looking for patterns of behavior, and simple ways to describe them.

When talking about Agile teams as compared to Waterfall teams, one of the things that has become apparent is that Waterfall is also a Culture of Heroism. In fact, in many ways, much of Western culture is about heroism. We laud the star athlete, the exceptional business person, the standout author, and so on. In many cases, it seems to be recognition and acclaim for the individual over the group, or at least the individual separate from the group.

Agile teams foster a culture of collaboration and cooperation. That’s not to say that there’s not room for individual excellence, effort, and achievement. I would say that high performant teams tend to focus on the success of the team over the individual. Is Agile more socialist, while Waterfall is more capitalist? I’m not sure, but it seems that way.

Regardless, there are a number of side effects of a Culture of Heroism:

  • Ego-driven achievement
  • Unhealthy competition (although sometimes it’s quite healthy)
  • Rewards that – in recognizing the individual – discourage the others on the team
  • A focus on the individual rather than the group goals

This is an interesting thing for me, because I’m highly competitive, and am happy to have individual recognition. On the other hand, I believe strongly in subordinating my ego to the purposes and goals of the team, and that the success of the team is what’s important*. Since my ego still wins out at times, I recognize that this is not just a struggle for me, but for others as well.

We’re raised in a culture of individualism and heroism, then we are invited into the Agile fold, and asked to shift our focus and our energy from ourselves to our teams.

I’ll continue to explore this as I get the opportunity to work with more teams. I will say that I’ve seen the culture of heroism everywhere I’ve gone, in one form or another, and believe firmly that the change to a culture of collaboration must come from the leadership as well as the team.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Training is amazing

Agile & Lean | Posted by Doc
Feb 09 2010

I’m at the end of day one of training, doing a custom two-day workshop for a client. The requests were long, so we negotiated it down to what we thought would reasonably fit within two days.

At 11am, I was on slide 4 in the PowerPoint deck. The reason it was moving so slowly is that these people are STARVING for information and guidance. They know they’re doing “quagile” (quasi-agile), they want to move closer to “real” Agile, and they are interested and eager and articulate.

It fascinated me all day, as they took what I was presenting and ran with it. Some heated discussions, some passionate, some involving the whole group of 15, some a subset. It went on all day.

It’s frustrating to me that they’re so eager, and facing such challenges in achieving Agile adoption. And yet it’s the same pattern…

The development team wants it, the QAs want it, the BAs and PMs want it – the “business” and the “customer” want the same old thing.

Sigh.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

The Endowment Effect (Cognitive Bias)

Coping and Communicating, Musings | Posted by Doc
Jan 29 2010

A couple of weeks ago, I was in Sandusky, Ohio for CodeMash 2.0.1.0. One of the keynotes was delivered by Andy Hunt (co-author of “The Pragmatic Programmer” and co-founder of The Pragmatic Bookshelf). Andy was talking about some of the material related to/from his book “Pragmatic Thinking and Learning: Refactor Your Wetware”.

One of the things that Andy talked about was Cognitive Bias. I found it fascinating, as he reiterated some of the research and findings that I’d just read about in “Predictably Irrational: The Hidden Forces That Shape Our Decisions“.

What got me was when he talked about the endowment effect. Simply stated, “a hypothesis that people value a good or service more once their property right to it has been established. In other words, people place a higher value on objects they own than objects that they do not.”

This got me to thinking about the resistance we meet when we introduce Agile concepts and practices to product development teams. After all, while I understand that change is hard and frightening, sometimes it still surprises me how much energy people put into resisting change, especially when they are suffering.

At one client I worked with recently, we had the group split into two teams, and had each team do a process doodle. As part of the exercise, each group explains their doodle. Both teams that participated explained that they spend something like 60% of their project time developing requirements and generating the various design documents. Add to that that they spend something like another 20% of their time on QA and UAT, and they spend 20% or less of their project time on actually building the product. They expressed frustration at the amount of overhead and the difficulty of getting things done. Finally, they explained that at each phase of the project, there are specific percentages by which they are allowed to be off in their estimates. That is, during requirements gathering and writing, they can be off by 50%. When they get into design, it goes down to 30%. And so on.

There’s such a powerful expression of lack of confidence in this that it amazed me. They have institutionalized their lack of confidence in both their system and their approach. And yet, there are way too many of “them” who hang onto this approach for dear life!

Let’s look at the endowment effect. “…people often demand much more to give up an object than they would be willing to pay to acquire it.

Here’s my Agile Adoption Resistance Endowment Effect: If I know how my system works, and I know how to work my system, then even in the face of something that appears to work better and will probably ease my pain, I will demand more assurance of success and ease of adoption than I am willing to offer for the system I am currently using.

I’m going to spend more time on this stuff – cognitive bias – with thought toward how it applies to the training and coaching we do. There are some powerful lessons in there.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

ThoughtWorks India helping to put on the first RubyConf India 20-21 March

Events | Posted by Doc
Jan 25 2010

I’m really proud of our team in India.

ThoughtWorks India is taking the lead in making the first ever RubyConf India happen on Mar 20th and 21st in Bangalore. RubyConf India is being organised by the Ruby community in India and actively supported by Ruby Central. It will feature keynote addresses and talks by Chad Fowler, Ola Bini and other key figures in the Ruby community like (*cough*) Roy Singham. :)

This is a big deal for the Ruby community in India, and for ThoughtWorks.


270X185_supporting (1).jpg

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

The Anchor

Agile & Lean | Posted by Doc
Nov 14 2009

In Agile software development, we talk about learning from the past in order to improve the future. As I spend time with clients, whether doing coaching or training, I find them burdened by the past.

The Anchor.

“That’s the way we’ve always done things.”

Resistance to change for the sake of resistance.

Those of us who have had opportunity to work on and with Agile teams have seen what a difference that shift in principles, practices, and thought makes.  It makes a difference in the pleasure and pride that team members find in what they do. It makes a difference in the quality of the product they create.  It makes a difference in the overall competence of the team, both as individuals and as an entity.

Waterfall, on the other hand, has led to unhappy team members and failed projects.  Demonstrably.  In one report, the Standish Group found that only 34% of software projects were unqualified successes. While it says that the percentage was up to 34%, I still find that to be a discouraging statistic.  What’s encouraging is this:

Asked for the chief reasons project success rates have improved, Standish Chairman Jim Johnson says, “The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.”

So here we have an approach, along with a set of practices, that has been shown not to work for years, even decades, and yet managers or organizations hang onto it like it’s a life preserver, when in fact, it’s an anchor.

Drop your anchors. What is so frightening about not buying into the fallacy that you can know everything up front, plan everything up front, budget everything up front…?  Well, it goes on and on.

Of course you need to be able to plan and budget. But I don’t buy into the idea that anyone believes that those numbers are real or accurate. Rather, it’s “the way we do things” and they are resistant to change and the unknown.

Cast off your anchors! Learn from the mistakes we’ve been making for 50 years and find better ways to do things.  Let’s deliver better software with fewer defects that meets the needs of the customers/users, delivers more value, and does so when it says it will.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

With Blame Goes Guilt

Agile & Lean, Coping and Communicating | Posted by Doc
Nov 07 2009

I was talking to a colleague last night about my thoughts around A Culture of Blame. He was sharing with me one of the tactics used by management, and it occurred to me that it’s hard to live in a culture of blame without also having blame’s counterpart, guilt.

“We’ve made a commitment to our customer, and we must fulfill that commitment.” This frequently means “I made a commitment to our customer, and YOU must fulfill that commitment (or YOU will suffer).”

Poor managers frequently combine blame and guilt as their two weapons of destruction. Rather than think of positive ways to motivate people, they undermine and discourage, somehow believing that this will produce better results.

Research and anecdotal evidence reveal that reward and positive motivation work far, far better than punishment and negative motivation. And yet, there we are.

One of the many things I love about Agile teams is that we move away from blame and guilt to collaboration, support, respect, and motivation.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

A Culture of Blame

Agile & Lean, Facilitation | Posted by Doc
Oct 30 2009

In developing and delivering training on Agile Software Development, I frequently talk about the group ownership and individual commitment. I also talk quite a bit about the formation of the team, the group responsibility, and the mutual respect.

This is very cool stuff.

When I get to the Agile Manifesto, I dig into what the four main concepts mean to us as we embrace Agile.

Right now, what’s on my mind is the third value: customer collaboration over contract negotiation.

Here are some of the key points that I find in this statement:

  1. Contracts are only put in place so that we can enforce them when we believe that the other party has not met their obligations under the contract.
  2. Contracts imply a lack of trust.
  3. If you’re actually talking to your customer on an ongoing basis, then contracts generally become superfluous.
  4. Requirements specs and design specs are software contracts.
  5. See point #3.

As I’ve been doing coaching and training, I’ve had the opportunity to see a variety of different organizations and situations. What has become clear to me is this:

Some organizations that embrace Agile have a culture of openness, safety, respect, and friendliness, where the people who work there are happy to go to work each day. Those employees have a feeling of pleasure and pride in what they do and the people they get to do it with.

Then there are organizations that are built upon a Culture of Blame.  Contracts are about blame.  Specifications are – at least to an extent – about blame. Project plans, which on the surface are about predictability and budgeting and resource allocation, are also about blame. What I’ve seen happen in these organizations, more than once, is that Agile adoptions fail in the worst case, and struggle in the best case.

The problem is that their “leadership” (quotes intentional) are mired in Waterfall practices. The irony of this is that – while management is operating under the fallacious assumption that these practices work – these practices have been demonstrated repeatedly and measurably to fail.

“The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term “waterfall” in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970).” (from Wikipedia)

What seems to go hand in glove with this Waterfall mindset is the contract. These managers need to have specs and project plans so that they can figure out who is at fault when the project is late, over budget, or of low quality. Sadly, those of us who have embraced Agile – and many who still live in the Waterfall world – would tell you that at least one of those three – lateness, over budget, or low quality – is pretty well guaranteed.

Someone asked me recently whether it was possible to succeed in adopting Agile without there being a cultural change.

My answer is a resounding “no!” Without the move to a culture of trust and respect, without the true support – not just lip service or permission – of representatives of “leadership” at all levels*, Agile adoption is very unlikely to succeed.

A Culture of Blame is not always obvious – although frequently it is obvious. But there will generally be smells that a reasonably discerning individual can detect that make it clear that the Culture of Blame is present.


* I refer to this as Vertical Commitment or Vertical Buy-In. As a coach and facilitator, I believe that without ensuring that management shares the same language about Agile principles and practices, and without ensuring that they are committed to the success of Agile adoption, the culture clash is unendurable.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Is Agile a mystery?

Agile & Lean, Musings | Posted by Doc
Sep 02 2009

Over the past few weeks, in between preparing for Agile2009, I was preparing to deliver some Agile training to a company’s product owners and project managers. I was told that they’d been doing various Agile practices for as much as a year.  This made me curious as to why we’d be delivering a course on Agile Fundamentals.

After all, if they’ve been doing stuff for a year, I thought, shouldn’t they have some of the fundamentals firmly in mind?

Nonetheless, skepticism firmly in hand, I prepared myself to deliver to what might be a knowledegable and, perhaps, challenging group.

Much to my surprise – although it shouldn’t surprise me – these folks have piecemeal knowledge of certain practices, and seem to mostly lack a solid grasp of the underlying principles of Agile. While I don’t think that the Agile Manifesto is a bible, I do think that it’s both required reading and deserves some thought. The implications are profound, once you start thinking about them and trying to understand what they mean for an organization.

How can it be that people have been doing standups and iterations and estimating and story cards for 6 – 12 months, and don’t have a firm grasp of the why of what they’re doing?

Maybe it’s just me.  Maybe most people don’t have any need to understand the philosophy or principles or subtleties of what they’re doing, and are happy to just learn the what and the how.

I’m still a bit baffled. The subtleties of what makes Agile be what it is are what excite me. Yes, I do get excited about pairing and standups and iterations and IPMs and retrospectives and all the other stuff we do. And I also get excited by the understanding and the “cultural shift” (as one attendee put it) that goes along with Agile adoption.

After all, Agile is clearly not just about the practices and methodologies. It’s about the discipline and the attitude changes and the mental shifts in things like code ownership and transparency. How can you go from the dark ages of Waterfall, individual code ownership, controlled communication, and defensiveness to Agility without being affected by all of those changes in profound ways? How can you make the shift from maybe-doing-unit-testing-a-little-bit-after-the-fact to TDD/Test-First and not see that there’s more going on than just the practices?

Sigh.

I guess the opportunity to share that excitement that comes with the transformation is part of what drives me to do coaching and training and facilitation.  If I can see just one person get it, then it’s all worth it.

It seems that you can take the man out of motivational speaking, but you can’t take the motivational speaking out of the man. ;)

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

More new graphics, and Agile2009

Agile & Lean, Events, Facilitation | Posted by Doc
Aug 07 2009

Yes, I’ve added more new graphics, courtesy of Mike Ferrin.

I don’t remember if I’ve mentioned that these characters will make their “live” debut when I present my session on Facilitation Patterns and Antipatterns at Agile2009. I’ve developed a workshop around these ideas, and I think it will be a lot of fun.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Yo! Pass the potatoes!

Agile & Lean | Posted by Doc
Jun 11 2009

Many of us have seen, and firmly believe, that co-location works for agile teams. The freedom to interact any time, all the time, is intensely powerful. The value of being able to see and hear one’s teammates is incalculable.

Working with a distributed team on my current project, we’re seeing how challenging it is for the folks over in India. The team here talks to each other all the time, expresses and resolves issues, jointly decides on architectural challenges, and overall is just more effective.

What’s particularly joyful for me is watching this team go from completely non-co-located and struggling to being mostly co-located and effective. It’s impressive and gratifying.

The level and quality of communication has gone up.

The number and severity of problems has gone down.

The “customer” is thrilled with the amount of communication and his understanding of what’s going on.

Perhaps best is that the project manager’s manager wandered in and asked the lead developer to show him the system. The lead developer did. The manager, after bouncing up and down with joy, proceeded to show some of the members of the user/customer community the system, and they are thrilled too.

Co-location works. Give up your walls and partitions and privacy. Embrace the connection with your teammates, greater productivity, greater satisfaction, and the joy of being siginificantly more effective.

Wow.

Post to Twitter Tweet This Post

  • Share/Bookmark

Related posts

Twitter links powered by Tweet This v1.6.1, a WordPress plugin for Twitter.