The never-ending renovation, and what I learned… so far

September 6, 2011 4 Comments

I live in an old stone house which was built between 1839 and 1849. In the 1970′s, an addition was added on, extending the original house with a large family room, extra bedrooms, a rec room, and two extra bathrooms. Over the past three weeks during my vacation, we’ve been working on upgrading the dated interior. This included:

  1. Updating two bathrooms. These were stripped to bare walls and redone. The demolition had been done before the vacation, so all that was left was to repair floors, install tiled flooring, new tub, shower, vanity, toilets, and associated fixtures. Plumbing is not my favorite thing, and my plumber, like me, was on vacation, so I ended up doing it. The pipes are circa 1970, and waste pipes are all copper or cast iron. None of the sizes seemed to match the modern brass or PVC / ABS pipes so that created some adaptation problems. Read more of this post

Filed under Continuous Improvement, Learning, Refactoring, Retrospective, Technical Debt Tagged with , , ,

Deliberate Practice – the Leadership Kata

August 21, 2011 Leave a Comment

A kata is a set of actions that are assembled in sequence to help you train your mind and body to perform with precision, proper form, and to help you develop muscle memory so that these forms are available to you without thinking. The word “kata” comes from the martial arts. At the Agile2011 conference there was a tutorial titled “The Agile Leadership Kata: Discovering the Practice of Leadership” by Tom Perry. We applied the kata to the practice of leadership. Slides form the session can be found here.

Stephen Denning refers to leadership communication as performance art. All performance requires practice. Katas are a practice tool. Why bother? As a leader, why does it mater if I practice? If my current set of leadership tools are working, do I really need to develop new ones?

Read more of this post

Filed under Communication, Continuous Improvement, Individuals and Interactions, Leadership, Learning, Thinking Tools Tagged with , , , ,

How Adopting Agile can Lead to Business Failure

January 22, 2011 Leave a Comment

For Agile veterans, this list of failure reasons is not new. But it never hurts to be reminded of what they are.  So here is the list by Clinton Keith and Mike Cohn. I wish everyone would read this list and post it on their bathroom mirrors. You can find the source document here.

  1. Don’t trust the team or agile. Micromanage both your team members and the process.
  2. If agile isn’t a silver bullet, blame agile.
  3. Equate self-managing with self-leading and provide no direction to the team whatsoever. (Good leadership always matters!)
  4. Ignore the agile practices. They don’t apply to management. (As a manager and leader, this is my favorite.)
  5. Undermine the team’s belief in agile.
  6. Continually fail to deliver what you committed to deliver during iteration planning.
  7. Cavalierly move work forward from one iteration to the next. It’s good to keep the product owner guessing about what will be delivered.
  8. Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on.
  9. Large projects need large teams. Ignore studies that show productivity decreases with large teams due to increased communication overhead. Since everyone needs to know everything, invite all fifty people to the daily stand-up.
  10. Don’t communicate a vision for the product to the team or to the other stakeholders.
  11. Don’t pay attention to the progress of each iteration and objectively evaluate the value of that progress.
  12. Replace a plan document with a plan “in your head” that only you know.
  13. Have one person share the roles of ScrumMaster (agile coach) and product owner. In fact, have this person also be an individual contributor on the team.
  14. Start customizing an agile process before you’ve done it by the book. (Another favorite of mine.)
  15. Drop and customize important agile practices before fully understanding them.
  16. Slavishly follow agile practices without understanding their underlying principles. (I call this one Agile-By-Rote).
  17. Don’t continually improve.
  18. Don’t change the technical practices.
  19. Rather than align pay, incentives, job titles, promotions, and recognition with agile, create incentives for individuals to undermine teamwork and shared responsibility.
  20. Convince yourself that you’ll be able to do all requested work, so the order of your work doesn’t matter.

Filed under Continuous Improvement, Leadership, Scrum, Teams Tagged with , , , , , , , ,

Perfection and Pragmatism

August 14, 2010 Leave a Comment

This is a long post, so here is the digest version first.

  • Develop a vision of perfection for your Agile business that includes the product AND the people that create it.
  • Think about what it feels like to work in this perfect Nirvana – engage your right brain.
  • Start moving toward that vision now as fast as you can without losing control – be pragmatic.
  • Be prepared to suffer some mental pain along the way – so eat cookies and drink milk.

That’s it. The rest of the post is some ranting to prime some thinking.

Read more of this post

Filed under Communication, Continuous Improvement, Culture, Individuals and Interactions, Leadership, Metrics, Organizational Transformation, Scrum, Teams Tagged with , , , , , , , , , , , , ,

Sir Ken Robinson: Bring on the learning revolution!

June 5, 2010 Leave a Comment

Innovation is about challenging our assumptions. It is about challenging what we take for granted. This talk is about education, but wow! It drives home so many salient points about how to bring out the best in people! Watch this talk and ask yourself how these ideas could be applied to your organization.

Tread softly, you are walking on my dreams!

Filed under Continuous Improvement, Culture, Innovation Tagged with , ,

Building Better Metrics

May 15, 2010 2 Comments

I have seen my share of good and bad metrics. And I continue to get it wrong. Then I learn and try again. Below are some of the guidelines I am using for developing useful metrics.

  1. TIE METRICS TO BUSINESS GOALS – seems obvious but a metric tells you something, and if that something cannot be tied directly to a business goal, why are you using it?
  2. GET ALIGNED ON THE GOALS BEFORE YOU START – it’s amazing how two people can look at the same goal and interpret it in completely different ways. Make the effort.
  3. BALANCED VIEW – weight your metrics so that you avoid over-rotating on any one or small set of measures. A balanced view of metrics provides a holistic picture.
  4. ORTHOGONAL METRICS – rather than use one complicated metric, develop two or three simpler ones that provide a faceted view of what you are trying to measure. The goal here is to avoid metric gaming and having a few metrics that look at a goal from different points of view. The benefit is simplicity without being simplistic. Measuring a complex system requires different views and synthesis to deliver the big picture.
  5. THE NAPKIN TEST – if you can’t write your metric calculation on a napkin and explain it in less than a minute, it is too complicated. Read more of this post

Filed under Continuous Improvement, Metrics Tagged with , , ,

March 29 2010 – Dinner with Jeff Sutherland

April 23, 2010 3 Comments

Monday, March 29, I had the opportunity to have dinner with Jeff Sutherland and other RTP leaders. The dinner was a fundraiser for CITCON, which came to RTP in April. This was an opportunity for Agile practitioners and experts to have an informal chat about the challenges and opportunities of using Agile in the world of work.

I was interested in learning more about Systematic, a CMMI level 5 company that implemented Scrum across its entire business. One thing that sets Systematic apart from other companies is that it has really good data to prove that Scrum works, and it is a software company that can execute perfect waterfalls every time. Systematic created hyper-productive teams, and by Jeff’s definition, they are at least 4 times more productive than industry average. They cut TTM in half and the development costs by the same as well.

Read more of this post

Filed under A-TDD, Acceptance Definition, Acceptance Tests, Continuous Improvement, LEAN, Organizational Transformation, Research, Scrum, TDD Tagged with , , , , ,

Theory of Constraints

March 16, 2010 Leave a Comment

The Theory of Constraints (TOC) is all about flow, and identifying and removing bottlenecks in the flow. Think of the analogy “the chain is only as strong as its weakest link”. The weak link is the bottleneck in the flow from from quote to cash.

A simple example is to look at manufacturing where scarce machinery or skills creates a backlog of work directly in front of it. Inventory piles up as teams in different departments build excess stock in the production chain which the bottleneck resource cannot keep up with. Software is no different. In our world, we see it all the time. Scarce skills, people with specialized expertise cause those who need their services to queue up in front of them.

Root cause analysis is at the heart of TOC – something that we in the software industry understand very well. TOC applies 5 focusing steps to identify constraints and their root causes in the context of a continuous improvement exercise. These 5 steps are:

  • Identify the constraint
  • Decide how to exploit the constraint
  • Subordinate and synchronize everything else to the above decisions
  • Elevate the performance of the constraint
  • If the constraint shifts, go back to step 1.

Read the white paper here. And if you can, I recommend you read Eli Goldratt’s book, Theory Of Constraints.

Filed under Continuous Improvement, LEAN, Organizational Transformation Tagged with

Follow

Get every new post delivered to your Inbox.