Communities of Practice are a solid way to help experts in their field stay on top of the latest in their domains. They also help managers and leaders create a collaborative learning culture.
A CoP is a forum where experts meet together on a periodic schedule to share and learn from each other. It can be a one hour event every other week or from time to time, a mini-conference using an open space or trade show format.
I like to see managers or leaders shepherd or curate CoPs. A CoP needs care, feeding, and leadership to get off the ground and remain useful. The best CoPs I’ve experienced have the following characteristics: Continue reading →
A classic use of Kanban is in field support. Trouble tickets arrive on their own schedule. Team members take a Kanban course or read a book. The team puts up a board, sticky notes, and watches as the tickets flow across the workflow, pretty much as they did before. No real improvement except that the manager can now claim that her team is using Kanban and there is greater transparency. (Everyone is happy, and now the team can tick off their “Agile” box–done.)
Traffic slows to a crawl on the Monash Freeway in Melbourne, Australia through peak hour traffic. (Photo credit: Wikipedia)
Even when WIP limits are put in place, they are ignored. “This customer issue is too urgent so we have to exceed the WIP limit” is the logical and customer-focused rationale for the decision. A few weeks or months go by and the team has not stopped to examine why their activities do not flow faster. Kanban does not work. The flow data is not being parsed nor dissected to understand how to improve throughput. Does this sound familiar? Continue reading →
I had a conversation with my friend & colleague Catherine a few weeks ago that I want to share with you. She told me that her mother, Claire Louis, described cancer and heart-attacks not as events or as states, but as trends. She said, “You don’t have cancer but you are cancering. You have not had a heart-attack, but you are heart-attacking.”
I was struck by the power of this and then we started to think about it in terms of Waterfall and Agile. Are you Waterfall-ing or Agile-ing? Are you applying the values and principles of Agile, even if not perfectly, but enough to start to move you in the right direction? Can you build on that tomorrow? And the next day?
On my table lamp in my home office I have a sticky note that says, “Was I better today than yesterday?” Same idea. What small thing am I doing today that makes me better than I was yesterday? It accumulates.
Are we working toward building a healthy, profitable and fun place to work, or are we doing the same old thing as yesterday? A little bit every day? And building on that the next day?
There are no short-cuts, no sliver bullets, no magic processes or quick-fixes. It is all about doing that little bit each day that incrementally, almost imperceptibly, effects you and your friends, family, employees, organizations and your quality of life. You and they will see and feel the difference. But it takes time.
Shall we “ing” together?
Share your “ing” here on the blog. I’d love to hear from you.
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:
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. Continue reading →
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?
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.
Don’t trust the team or agile. Micromanage both your team members and the process.
If agile isn’t a silver bullet, blame agile.
Equate self-managing with self-leading and provide no direction to the team whatsoever. (Good leadership always matters!)
Ignore the agile practices. They don’t apply to management. (As a manager and leader, this is my favorite.)
Undermine the team’s belief in agile.
Continually fail to deliver what you committed to deliver during iteration planning.
Cavalierly move work forward from one iteration to the next. It’s good to keep the product owner guessing about what will be delivered.
Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on.
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.
Don’t communicate a vision for the product to the team or to the other stakeholders.
Don’t pay attention to the progress of each iteration and objectively evaluate the value of that progress.
Replace a plan document with a plan “in your head” that only you know.
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.
Start customizing an agile process before you’ve done it by the book. (Another favorite of mine.)
Drop and customize important agile practices before fully understanding them.
Slavishly follow agile practices without understanding their underlying principles. (I call this one Agile-By-Rote).
Don’t continually improve.
Don’t change the technical practices.
Rather than align pay, incentives, job titles, promotions, and recognition with agile, create incentives for individuals to undermine teamwork and shared responsibility.
Convince yourself that you’ll be able to do all requested work, so the order of your work doesn’t matter.