Why so many V/Ps?

I was talking with a friend of mine about defining success for Agile companies based on our experience.  It turns out we came up with a very simple formula.  Here are the two factors of success that we narrowed it down to:

• Length of time spent in planning meetings
• Timespan of the company vision

Let's explore each of these in detail.

Planning


The company that has shorter planning sessions with as few people as possible will be successful.   Longer planning meetings involving the whole team are physically draining and technically introduce a drag on the team's velocity.   They also water down the resulting user stories because too many opinions get voiced that are not relevant to the customer problem.  These sessions usually end up with a lot of frustrated people and no clear vision of what people are working on and why.

The alternative is to have impromptu planning sessions that come during bits of downtime during the day.  Involving as few relevant folks as possible gets enough points of view and leads to less opinion and more fact in the story definition and sizing.  It also promotes a more productive team boosting team velocity rather than being a drag on it.  People simply gather at a pairing station, discuss the story, size and get done in less than 15 minutes.

All of this leads us to the first rule that a company's success is inversely proportional to the amount of time it spends in planning sessions:


     S ~ 1/p

Vision

Many of us have been a part of a company that despite having potentially good products and talented people still doesn't seem to take it to the next level or outright fails.  It comes down to the transformation that the company undergoes from working on new and great ideas to suddenly losing its way and simply trying to keep the developed assets afloat in the marketplace.  They eventually get lapsed by competitors or passed over by new technology offerings and get purchased at a bargain price or go out of business entirely.

The successful company keeps the vision moving forward and long range.  They are always adapting and constantly adjusting it along they way just like a driver in a car manages the steering wheel.  You make a lot of adjustments but in general go on a direct path from point A to point B.  They are nimble and unafraid to do something entirely different as long as it is maleable with the tenets that make up the evolving vision.

These facts give us the second part of the equation for success which is the longer and more far reaching the vision is the more successful the company will be:

    S ~ v

Formula

Now that we have our factors we can quite easily define the formula for a successful company:

    F(v,p) = v/p

This captures everything succinctly and can be applied easily.  The longer the vision and the shorter the planning session the more successful your company will be.

This got my friend to say this about his company:

    "So *that's* why we have so many V/Ps!"

Introducing the Code Kata project

One of the common themes that people talk about when it comes to craftsmanship is practice.  Dave Thomas made the corollary for programmers a few years ago in this blog post.  He brings up great points about not worry about the answer but instead focusing on how you got to the answer that you implemented.  It also emphasizes repetition meaning you should practice a kata frequently.

I love the idea of the kata but I found I had a few ideas that could make the process more effective and prove to have wider adoption not only in the ruby community but all programming languages.  The ideas I had could be summarized as follows:

• Authoring - I wanted a consistent way to write a kata that would clearly illustrate the requirements through details and examples.

• Administering - How do you take a kata?  I wanted a way to step through the requirements and measure progress by how many requirements I completed and how much time it took to complete them.

• Setup - I wanted to be able to chart my progress over time by using source control to keep track of the code for each time I took that kata in an automated fashion.

The result of these ideas is the kata gem.  Check the github page for all of the details but briefly it provides the following:

• An RSpec like DSL for authoring katas using descriptive keywords like requirement, detail and example.

• A command like tool to self-administer a kata by stepping through the requirements

• The ability to automatically create a distinct github repo for the kata you wish to take allowing for later code review.

Now that we have tools in place to make us more productive in writing and taking katas we just need katas to test ourselves with.  I have created the code katas project so that everyone has the opportunity to contribute and take advantage of the efforts put forth. 

If you just want to take a kata that is part of the project it is very easy to get started if you are used to using rvm and bundler.  Just clone the repo:

change into the cloned repo:

Install your bundle:

Now you can setup your github repo to take your kata:

At this point you can cd into the created directory and view the repo in your github account. You can commit to it but should ignore it in the code_kata project.  All the goodies like autotest and kata are installed so you can follow TDD best practices without any work on your part.

In a separate terminal window you can then administer the kata to guide you through the requirements for the code you need to write:

You are off and running to practice regularly!

What the project needs though are obviously more katas.  String calculators are great and thanks to Roy and Katacasts for inspiration but more can be done.  Translation and updating of the original katas from Dave Thomas would probably be a good start but what ideas do you all have?  For the code kata project and submit your ideas for everyone to grow and get better!