The Experiment Canvas is a simple means of planning, tracking, and responding to your experiments.
Simple Things
When I say simple, I don’t necessarily mean easy. And I certainly do not mean crude in form or incomplete. Simple indicates something that does not have superfluous parts or multiple responsibilities, is easy to understand, is as independent from the rest of the solution as possible, and meets a need as is.
Simple may not address all use cases, but it does address some use cases.
Over the past several years, as I’ve been helping teams and organizations improve their ability to deliver software products that are desirable, viable, and feasible, I have been experimenting with a Behavior Framework that has proven to be rather effective. And I’d like to share it with you in hopes that you find it useful and that you provide me feedback on your experiences with it.
My plan is to write a series of blog posts all related to the behaviors framework. Some of them will be about a specific behavior. Some of them will be about tools or techniques that help teams express one or more of the behaviors. Some of them will be my own experiences. And some will be damn near complete fiction.
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.
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"?
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.
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.
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.
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.
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?
Earlier this week, Bob Marshall (@flowchainsensei) retweeted an article by Dan McCarthy on The Meaning of Respect, where he discussed respect as a value. I then saw a blog post from Seth Godin entitled "Seven Questions for Leaders" where he asks if you would walk away from a client or employee whose values don't match yours. This weekend, at Agile and Beyond, I got into a conversation with several others about company values and walking away from clients when there is a mis-match. At LeanDog, we proudly display our company values and we often refer to the XP values of Simplicity, Communication, Feedback, Respect, and Courage.
Have you ever been on a team where your velocity suffered wild variances? Maybe you ended up using a running average instead of yesterday's weather?
Have you heard phrases like, "Well, our velocity last iteration was 3, but our average is still 22"?
Have you ever heard the phrase, "Dude, we need to get this velocity stable."
Have you worked on teams where they took partial credit for done at the end of the iteration? Where maybe you'd split a card strictly on points and award some apportion to the current iteration and assign the remainder of the card to the next iteration.
I really enjoy pair programming. It seems a natural process to me and I often wonder why it is that I like it so when others may not. Clearly, we have differing tastes and styles. I am sure that contributes to the joy (or lack thereof).
I've been watching others pair lately. And there is something I've noticed; pairing done well is conversation.
