-

“There is No End State When Transitioning to Agile” (Mike Cohn, Succeeding with Agile)

As usual, a good article from Mike Cohn to start off my work week.

This reminds me of an article I read earlier, about process improvement at Toyota (I can’t find the link, but if I do, I’ll come back and add it to this post). In short, they described the view of “process” at Toyota as fairly binary: either the process is being actively improved, or it’s degrading. There’s no concept of a steady-state, no concept of “done”.

From Mike’s article:

So, a transition to agile cannot be a process that “articulates and defines the entire change process required to bridge the gap between ‘as is’ and ‘to be’ and creates tactical plans,” as I read in a traditional change management book recently. Creating such a plan would require leaping two impossible hurdles: first, knowing exactly where we’ll want to end up; and second, knowing exactly the steps to get there.

There’s a ton of utility in this half-paragraph - in Agile, in business, in life. Most importantly, though, is the recognition that like Toyota, no matter how good your transition is, no matter how refined your process, you’re never done.

This is hard, and tiring. Accepting that you’re never done also means accepting that there’s always work to be done, always more to do, always more improvement. If your goal is to coach a team until they’re Agile, then realizing that you’ll never be done means that you have to redefine your personal success criteria.

How can you succeed personally if you have to accept that you’ll never be done?

One of my friends and I have been talking about this very thing, albeit in a more circumspect manner. How can you feel comfortable walking away from a job, a project, a team without feeling like a failure? How can you say “I’m done” without sacrificing your own sense of commitment to the team, without feeling like you’ve failed in your project?

Agile is tough. Continuous improvement is tough.

No matter the circumstances, you can always improve. You can always start improving with yourself. You can always start improving today.

Kent Beck’s quote has always resonated with me, especially as I’ve transitioned through so many things over the past few years. It’s setting the bar higher, always looking to do more, do better. But, accepting that the bar can always be set higher means figuring out when to stop, when to catch your breath.

I don’t have a lot of answers today; mostly, Mike and Kent’s quotes leave me thinking and rolling thoughts around in my head. But, a quote from one of the books I keep on my bedside table has been stuck in my head as something of a counter-point:

The tiger is the same way. He conforms to every situation that comes. If he spots prey and is not ready to hunt, he will let it go. But he has not failed to act. He has knowingly let the prey escape, and this is much different from someone who loses a situation through slow reflexes or inability. When the tiger wants his prey, he pounces upon it without any thought or hesitation. There are no morals, no guilt, no psychological problems, no ideologies to interfere with the purity of his action. This undiminished grace in action is called nonaction.

No. 34: Engagement, Deng Ming-Dao, 365 Tao

A tiger sits and waits, and knows when he needs to act, when he needs to let a situation pass him by. When it comes to knowing that, I’m still Shu. I’ve got a long way to go before I’m ready to move to the next step of wisdom there, I think.

-

Don’t do XP «  Agile Anarchy

Great article about Tobias Meyer. I don’t know why I never stopped to think about XP as being over a decade old, but he’s exactly right. Software craftsmanship is a great movement, but I’m concerned that without the “package”, there’s less for people to talk about.

XP may be getting long in the tooth, but it’s a set of principles that an organization looking to make the evolutionary change from non-Agile to Agile practices can rally behind. As much as the “do this, and this, and this” mentality can hinder teams, it’s also something that management can understand.

Working to help adopt Agile practices - both project management and software development - I believe that the team’s the easier collection of converts. They get it, they can see the empirical evidence that adopting XP practices, say, brings to a team. In this respect, I think Tobias is right on the money.

But management? I think it’s much harder to explain “We’re doing TDD and CI, with a little bit of pair programming, and mixing that with short iterations and cross-functional teams” than to be able to say the conversational short-hand “We’re adopting Scrum and XP.”

Will any team ever do pure Scrum? Pure XP? I doubt it, and again, I totally agree with Tobias on this point. Being able to have a team pick up the right collection of engineering practices is key to the success of an Agile team.

But, having the understanding and support of the organization as a whole - the conversational short-hand to be able to explain to a division President exactly how you’re developing software and, more importantly, why it’s so much better, is key.

“Scrum” and “XP” are labels, but labels can be important.

-

Managing Product Development » What Would a Successful Agile All-Remote Team Look Like?

Aside from sounding like some Agile Awards Team (“And now, your 2009 Agile All-Remote Team!”) Johanna has a good overview of some of the hurdles facing remote teams.

My two most recent perspectives, from today. Earlier, @mhsutton sent out a question over Twitter, asking if anyone uses remote desktop sharing tools to facilitate pair programming. I enthusiastically answered, “YES!”

Two of our DBAs use remote desktop sharing so one of the pair can work remotely a fair portion of the time. They’ve got pair programming down cold, and are a fantastic testament to the advantages of pair programming. It’s a great example of how remote pairing can work, well.

But then, earlier today as we were stressing out about the testing effort we’re undertaking with our outsourced testing team in India (yes, I know. It hurts. Deep, deep hurting) one of that pair exclaimed, “Dammit, it would be so much easier if Mohinder were sitting here, so we could actually see the output of their testing tools!”

So, thinking some more about Johanna’s blog post, I think that one of the things I’ve seen that leads to a successful remote pairing arrangement, and by extension remote teams, is that they need to work co-located for a bit, first.

There’s a natural shorthand that develops between team members. There’s a language of work habits and methods that, when working remotely, you encounter obstacles to developing.

I’m sure that you can develop these habits, only working remotely. It just seems that being co-located, first, allows those habits to develop sooner, and makes working remotely easier, later.

I’m sure there are lots of things I’m forgetting, too. But my brain’s wandering off to how to integrate new team members into a remote team, without bringing the entire team together to indoctrinate the new team member, and that’s a whole other blog post.

-

Whinging Pissants | xProgramming.com

You know, I love Ron. I understand that some people don’t, and find his style too abrasive. So be it.

Regardless of that, the fact remains that he’s one of the best minds in the Agile community, and the work he’s doing to try to bridge the knowledge gap between project management practices and technical practices is invaluable.

Shine on, Ron.

-

Ssssh….Agile Is All About Micromanaging | Mike Cohn’s Blog - Succeeding With Agile®

Good, short article by Mike Cohn. It illustrates the necessity for personal responsibility in Agile, and the necessity for micro-management, even if it’s just micro-management of your own tasks every day.

Hard lesson for me to learn, but I’ve got the stack of lists to remind me of how important it is.

-

Watering Things Down Is Not Good For The Plants | xProgramming.com

I love reading Ron’s work. He’s so straightforward and to-the-point, and has a fantastic way to cut through the bull to the point we’re all talking around.

The recent conversations about Scrum and engineering practices, or between @michaelbolton and @thatqaguy are perfect examples of us getting lost in the words, and losing focus on the intent of what we’re all trying to. While it’s an interesting discussion from an academic perspective, how does any of it actually help us deliver more quality software?

-

Aspects of Truthfulness | Agile Advice - Working With Agile Methods (Scrum, OpenAgile, Lean)

A good list of the qualities that make up a successful Agile coach or Scrum Master, in my opinion. The ability to accept the inevitability of the unexpected, and the ability to therefore react without over-reacting, to react like water reacts to a stone falling into a pond.

Very appealing as an idea, a mental image for my Taoist mind.