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.
Recently, on a private forum, a member posted a query about their team’s recent drop in Velocity. Concerned about how their boss would respond, this individual wanted to know how to troubleshoot velocity issues.
After spending over an hour crafting a response, I decided I would also add it to my public blogs in case there are others who have similar questions about velocity.
I often find myself talking to people who are in the midst of a switch to agile and who find the change very difficult to get used to. They may be strong advocates, but their team just "doesn't get it". Through discussion, I find that many of them are attempting what I refer to as "Shock and Awe" agile. If you couldn't tell by the name, I consider this another agile coaching anti-pattern.
I read an article today that was posted on LinkedIn. I'm not going to link to the article. I'm not going to tell you who wrote it. I am only telling you about the article to set the stage for what I want to write about in this quick post.
In the article, along with "taking the best from Waterfall and Agile" and mixing them together into a "perfect methodology", the author, as a self-proclaimed change agent, suggested you should force implement all CMMI Level 5 developer practices at once.
I saw a tweet this morning that got me thinking about a coaching anti-pattern I frequently see:
"Without knowing you, your Agile coach knows you use should start using stand ups, TDD and pair programming, etc.
Taylor would be proud."
THE PRESCRIPTIVE AGILE COACH
The Prescriptive Agile Coach is armed with a reliable set of practices. The practices have been documented, vetted, and implemented successfully on a number of teams. They are inarguably proven. To the Prescriptive Agile Coach, those not following these practices are not truly Agile.
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.
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.
A client was looking for a way to introduce code quality standards to their development teams. There had been a few meetings prior to our involvement. The prevalent line of thinking was to draft a standards manual for dissemination to the teams. This would consist of a comprehensive set of rules and clear specifications to which all teams need comply.
Agile Rob posted a column a few days ago entitled, "If You Don’t Focus on Business Value, Don’t Adopt Agile." He tweeted it out and after reading it, I replied that I did not entirely agree. Rob asked that I post a comment on his blog. The following is an extended/modified version of that reply.
I read two articles today, "Adopting Agile Isn't The Point", by Mike Cottmeyer and "If You Don’t Focus on Business Value, Don’t Adopt Agile.", by Robert Dempsey. Rob's posting is an expression of agreement with Mike's.
