Want to really set yourself apart as a leader? Try telling your employees, "Don't bring me problems, bring me solutions." This phrase will absolutely set you apart as a leader; apart from your people, apart from communication, apart from real issues, and apart from collaborative solutions.
Coaching Anti-Patterns : Drive-By Coaching
As an "agile coach" over the past several years, I've seen a lot of different techniques and approaches. I've been impressed with the ability of some coaches to slowly and gently affect change; sustainable, genuine change. And I've been dismayed at the number of coaches who trivialize the complexity of change to check-lists and notions read from books, but never tried.
This series covers some of the (anti-)patterns I've seen among check-list agile coaches.
Collaboration Contract (was Collaboration 8)
Back in April, I wrote about a practice we were experimenting with at LeanDog. I called it Collaboration 8. The intent is to figure out who are the right people to have involved in a discussion. Rather than the boss making the decision, Collaboration 8 provides a way for the team to self-select and get clarity around levels of engagement and responsibility in the decision making process. I've found coupling Collaboration 8 with Six Thinking Hats has been a tremendous boon to the self-organizing teams to whom I've introduced the concepts.
Maybe it's about you...
I am reading "Good Boss, Bad Boss". It isn't a book I'd first recommend to aspiring or existing managers. It's not bad, it's just not as good as "The Advantage", or "Leading at a Higher Level"
In the epilogue to the book, Sutton talks about Steve Jobs and differing perspectives on what contributed to his success; creativity, assholery, or some magic combination of both. Pondering this made me think of a story from my own life.
Forever Forward
Memory Lane
Retrospectives are simple, but not easy. The general idea is to get the team together, establish a context, gather relevant data, develop insights, and decide what actions to take. Esther Derby covers the retrospective structure well in a slide presentation on her blog.
The most important agile practice?
As a coach, I've gone into numerous environments with the intention of introducing agile. Of course, I always talk about the values and the principles. Of course, I try to help people to see that there is no one true agile. There's no prescribed set of practices that once followed earn you the agile merit badge.
At the same time, these teams need something concrete. What things can one do in order to set them on the path to "being agile"?
Collaboration 8
For an update on this process, be sure to read Collaboration Contract.
In January of 2012, we at LeanDog were honored to host Jurgen Appelo for his first Management 3.0 course in the US. If you've not read Jurgen's book on "Leading Agile Developers, Developing Agile Leaders", I recommend it. The book is full of good advice and simple techniques for improving the way you manage. Among the items Jurgen shares in his class, I was intrigued by The Seven Levels of Authority and his Delegation Poker game.
SCNA 2011 Apprenticeship Panel
This year, at SCNA 2011, I had the honor of moderating a panel on apprenticeship. I was lucky enough to get participation commitments from an impressive list of individuals. I feared I would not be able to get a decent panel together and instead, I had to pare the panel from a list of eleven amazing people down to just six.
Fighting Entropy
It was 1983 and I was in science class when I first heard the term entropy.
I don't recall if we were discussing energy conversion, heat as waste, or some other topic wherein entropy plays a part, but I do recall how profound the concept of entropy seemed to me. The notion that there was a lack of order, a lack of predictability, and a gradual decline into disorder resonated with me deeply.
Estimating our Work
I've been thinking quite a bit about estimations and our general obsession with getting them "right". After all, we need to know when the project will be done. And we need accuracy. Knowing the entire project will be done before the end of the third quarter isn't good enough. We need to know that the project will be done this month or this week or perhaps even on this specific day.
"Necessary" Refactoring
In a discussion on the Agile Alliance Linked In Group, Michael Moles asked how refactoring fit into the agile process.
The Question
Refactoring: How does it fit into your Agile process?
We are in the midst of writing a new product, at this point the developers are realizing that some of the code should be refactored to improve performance and or clarity for ease of use. How do you fit refactoring into you Agile process? We have created separate backlog items for refactoring specific pieces of code. These backlog items are treated exactly like any other backlog item (meaning they have effort assigned and are committed to sprints by the team). What do you do when refactoring is necessary?