Urgency - Not Panic - to Move the Business Forward

Inc.'s September 2009 issue has a well-timed article for my current work environment in the financial industry, especially given the economic climate. It's an interview with John Kotter, the author of "A Sense of Urgency", and his thoughts on why urgency, not panic, is the key to moving your business forward.

Currently I find my work environment chanting a mantra of "doing more with less", and emphasizing the need for increasing our speed of delivery. All the while with all the noise and pressing demands, on a team by team basis, there is little focus on what matters most to the organization on the whole. Kotter's points out that in many organizations there are a lot of signs of false urgency. Your teams are working long hours and are just plain exhausted. "Frenetic activity," he calls it. That word accurately depicted some of the scenes I've been witnessing lately.

How do you distinguish between good and bad urgency? Well Kotter suggests one way of spotting the bad. Ask how hard is it for someone to schedule a meeting on your calendar? If it isn't easy, it means that you aren't leaving enough white space on your calendars to leave room for the important stuff that is going to happen and needs to be dealt with immediately. The unintended fallacy that people tend to believe is that during urgent times you need to take on more and demonstrate your value by being busy. Otherwise risk losing your position. Instead, Kotter insists we should be looking at our calendars and removing anything and everything that isn't moving our business forward.

This point resonates with me, and illustrates the value of being focused on what matters most. All too often I find the business is trying to please all of their constituencies at the same time with resources working at over their capacity. By doing so they're settling for mediocrity in their delivery and ultimately failing. Following Kotter's thinking, focus both your efforts and resources on the initiatives that meet the bottom line. And either delay the delivery to those other constituents, or completely abandon those efforts if they do not bring the value needed to meet the demands dictated by your organization's urgency.

To get there you need impassioned leaders. Leaders need to set the direction to get to the place where the entire organization is truly focused and seizes on the opportunity presented by urgent situations. Nothing will be gained by merely announcing urgency with lackluster and stoic rallying calls.

At the end of the article the topic of a leader's role in times of urgency is addressed. Kotter is notably quoted in saying, "True urgent leadership doesn't drain people. It does the opposite. It energizes them. It makes them feel excited. And the idea isn't so much that the leader is always showing emotion as that he's trying to produce the right emotions in the people he leads. But again, he has to model it. You can get people to respond rationally to a problem, but if you haven't stirred their hearts and minds, once the immediate crisis has passed, you lose them. The sense of urgency dissipates."

I think I'll be checking out Kotter's book on my Kindle in the coming weeks.

Click here to check out the Kotter interview on Inc.com.

Bringing the Cost of Failure Down to Zero

In continuing my postings around my takeaways from the Agile 2009 conference, while also promoting a post-Agile 2009 conference here in New York hosted by LiquidNet, I want to cover another great session presented by David Hussman. David is this year’s Gordon Pask award winner, and with his unique background in music performance and production, has applied a unique agile coaching style. He views coaching from a holistic approach, and designs his strategy with the organization’s cultural context in mind.

Perhaps the most important one-liner I was able to quote from David at his “Coaching & Producing Value” session was, “…bring the cost of failure to zero so we can do it a million times; failure is a learning tool.” I couldn’t agree more. But how do we go about bringing that about, without harming the organization and still increasing our agile adoption’s effectiveness?

Well David goes about listing what he calls “Pre-Production Tasks” in order to execute effective coaching and producing value to the organization. They are as follows:

• Assessment – Interviews
• Coaching Plans – Practice Selection
• Chartering
• Personas – Story Mapping
• Creative Eco-Systems
• Road Map Planning

For this posting I’d like to focus on the first two.

Assessment – Interviews

Here David recommends us to turn away from being an agile-zealot or purist, and with good reason. Implementing all of the agile practices in their strictest fashion will completely backfire unless the organization understands the values that those practices bring. Therefore to select and introduce these practices, the ones that makes the most sense for the culture and environment of the particular organization, need to be understood. The only way to do so is to spend time interview and assessing the organization and its people. Some questions he suggests to ask are:

• How do they work now?
• What works – what does not?
• Why change? Why agile methods?
• What strengths and challenges exist?

David emphasizes that in this change process of adopting agile a coach’s approach needs to be descriptive, “This is what I have seen work.” And not prescriptive, “This is what you should do.” A prescriptive approach will appear to be dogma, and dogma kills.

Coaching Plans – Practice Selection

With undersanding the context of the organization, its culture and people, you can start to understand and see how the agile practices fit into the scheme of things. Hussman organizes these practices into valuable groupings (pictured at the right). For the practices that you decide to employ, for their given grouping, you need to describe to your audience not only what you know about it (“the how”) but also describe the value of that practice (“the why”).

This and many other topics are planned to be covered at the post-Agile 2009 conference here in New York City. If you're interested in attending, please email me (grochejr@gmail.com) and I will be sure to send you the details.

David Hussman’s Agile 2009 conference presentation on "Coaching and Producing Value" at be found here.

Protection for Linux Users from Patent Lawsuits

In an article in today's Wall Street Journal, the Open Invention Network, or OIN, is seeking to protect users of Linux from "patent trolls" by purchasing patents formerly owned by Microsoft. For those of you unfamiliar with the term "patent trolls" it's generally a term used for groups that do not create products but acquire patents to earn financial rewards through lawsuits and settlements. OIN is made up of several major corporations such as IBM, Red Hat, and Sony.

OIN is currently seeking to acquire patents from Allied Security Trust (AST), another organization that purchases patents and provides licenses as well as reselling those patents on the open market. AST previously won several Microsoft patents in a private auction.

Death by Scrum Meeting

My next takeaway from the Agile 2009 conference is a session given by a mentor and coach of mine, Pete Behrens. First let me say that Pete is one of the best Agile coaches I’ve worked with. He’s trained me and even now continues to supply me with a wealth of new ideas and techniques to help me with my current endeavors in the financial industry. Pete shared some of these ideas and techniques at the Agile 2009 conference in his session titled, “Death by Scrum Meeting.”

Many of us can relate to the wasted time and efforts we spend in so many ineffective meetings at our organizations. For those organizations practicing Agile, following lean principles in every sense is the mantra. Therefore we should avoid long, multiple, and unproductive meetings and instead make them lean. If we’re practicing Agile, or specifically Scrum, how do we conduct effective, necessary, lean meetings? Well, below I highlight a few of the tips Pete shared.

The four main elements for keeping your (Scrum) meetings lean and effective:

• Determine the focus of the meeting. Is it strategic or tactical?
• Timebox the meeting.
• Attendees need to be able to visualize what is being discussed by using color, sizes of objects, or calendar/timelines in your meetings.
• Engage the team/attendees during the meeting by having them participate in it.
  

How should we timebox all of our (Scrum) meetings?

Pete recommends the following guidelines:

• Daily Stand-ups: 5-15 minutes
• Retrospectives: 15-30 minutes
• Reviews: 30-60 minutes
• Planning: 60-120 minutes
• Release Planning: 120-240 minutes
  

Daily Stand-Ups:

• They should be collaborative.
• Team members should care about each other’s tasks, so that there’s vested interest in the outcome of each other’s work.
• Perhaps try rotating who organizes the stand-ups so there's shared ownership.
• Use the stand-up as a thermometer on how the team is doing and how they feel about the project and the organization.

Retrospectives:

Instead of asking the team “what worked”, “what didn’t work”, and “what should we start doing”, try focusing on just two aspects:

• What went well? (What were the takeaways?)
• What are the changes or improvements that need to be employed in the next sprint?

By focusing on these two questions at the retrospective you can quickly vote for the top three changes to employ in the next sprint. Also the timeboxing of the retrospective helps to avoid the meeting from just becoming a reoccurring “bitch-session”, or worse, a “bitch-fest.”

Reviews:

Try visually displaying:

• The team’s commitment compared to what the team actually delivered.
• Product progress by feature.
• List specific work done within the current sprint.
• The focus for the next sprint.
  

Planning Sessions:

• Avoid using a software tool to help with planning during the meeting.
• Try printing out your stories, with their details on a single page, and prioritize them from left to right on the wall.
• Engage the team to design and break-down the stories via post-it notes or on a whiteboard. Instead of sitting down and talking leisurely about the stories and their requirements, the team is up and actively producing valuable information.
  

When estimating stories, try leveraging a technique that Pete calls, “affinity-based estimating,” as opposed to planning poker. I call it the “card-wall exercise.” Where we lay out all the outstanding stories on a wall and let the team members sort the stories from easiest to hardest (left to right). Afterwards I assign the story points as columns at the top of the wall and the team will then line up the stories underneath the points accordingly. I have post-its on hand to document any new stories or spikes uncovered during the exercise. This basically helps the team and I to document the conversation. This technique is especially effective when trying to estimate an entire backlog. Trust me; I know from personal experience after trying to get a team to slowly poker plan through each of the 400 outstanding stories over the course of several weeks.

There’s a lot more that was covered during Pete’s “Death by Scrum Meeting” at the Agile 2009 conference. I invite you to take a look at the presentation deck used at the conference (click here). Also to learn how Pete can help your organization’s goals of becoming more lean and agile, check out Trail Ridge Consulting.