In a month we will run our third internal conference. This is supposed to be a full-day event, with one-of-a-kind sessions prepared and presented by our team members.

Here is the program:

I’ve been thinking about  the influences that might affect the team’s velocity recently. Every single product owner wants to have features delivered as soon as possible. It may seem that this race for a better velocity is the wrong goal and can lead to the ugly “Work faster, basterds!” solution. But that’s not the case in a good and healthy environment .

Here is the diagram I’ve sketched in half an hour to generate some ideas. Bubbles are activities, practices and other entities that can make an impact on the development speed. They can have either positive or negative effect. For example, it seems that only two things improve velocity directly: fast feedback and experienced developers. While there are many other things that slow us down, such us unplanned work, interruptions, multi-tasking, rework, high coupling and technical debt.

The cool thing about this diagram is that it asks very specific questions:

• How to deal with customer requests and reduce unplanned work?
• What to do with urgent bugs?
• How to do more training?
• How to have smaller batches?
• What to do about noise and interruptions?

When you ask such questions on a retrospective meeting, you can expect quite many good ideas. If you just ask:  “How can we work faster?”,  the answer would be silence and confusion.

Almost 2 years ago I published the Flow. Discover Problems and Waste in Kanban post. The idea was quite simple: visualize the flow of a single user story or bug, and track their life cycle to Done:

You can spot such problems like delays and re-work very fast this way:

Now we’ve brought this idea to life. The Flow chart for every user story, bug and feature will be available shortly in TargetProcess v2.22.9.

The chart gives answers to a whole lot of hands-on questions:

• For how many days has this User Story been in this particular state?
• Were there any delays?
• Was there any re-work?
• Who was responsible for the User Story?
• When were Bugs and Tasks added and closed?
• How much time was spent each day?
• Were there any impediments?

Let’s look at some examples. The user story on the chart below has been  in Open state for 25 days (it means, in the Backlog). Then it jumped right into In Progress state. Two developers (Alla and Vladimir) started working on it (so it was pair programming). They’d been working for 3 days and then the story was moved into Re-open state. This is quite surprising, most likely they had to switch to something else (no good). Then they got back and spent 15 days working on this user story. That’s way too long. Most likely there were switches as well,  so this should be investigated.

Starting from Oct-18 the progress was very good: development went smooth, tester found several bugs and they were fixed in 2-3 days. Finally, the user story was released to production with no more delays.

You immediately get a high-level overview: delays and up/down state transitions. It is a clear sign of some problems, the systematic ones or not known so far, but we already have some background info to start an investigation).

Let’s check another example. It looks like the user story on the chart below was taken to development right as it was added. That’s true in fact, since it was a customer request to which we reacted immediately. It was implemented in a single day, and there was a small delay before tester took it to the  testing phase. We found quite many bugs and fixed them in 2 days, everything is fine. But then the completed user story was hanging in Release Branch state for 11 days, and that’s no good.

We’re planning to extend this Flow Chart and put more information there (comments, attachments, etc.) The goal is to provide the complete production timeline uncovering hidden malignant patterns and problems. You should be able to get a high-level overview in an instant and dig into as many details as possible.

Here is the snapshot of our real TargetProcess production Kanban Board taken today (November 18). You can see what we are working on right now, what is in progress, what is in testing and what will be released soon.

Mastery by George Leonard is one of my most-cherished-books-of-all-times. I’ve seen this book mentioned on a tennis web-site, and not even once, as I’ve been digging the web for some nuggets of information on what in the world do people do to make their game perfect and enjoy it. Ironically, now I can see that these 2 searches are absolutely irrelevant.

I wouldn’t say that this book has unveiled some unknown truths. It gently reminds of the basics for any learning making readers aware that the mass culture quest for scoring, quick wins and quick fixes at any rate proves wrong in the long run and brings along the consequences more grave than one can imagine.

Calm face and full concentration. Check large size

There’re some important conclusions I have made for myself out of this book, to name a few:

The first and most prerequisite for practicing any art or hobby or job is that you got to enjoy it. Love doing it. Not reading about it, not writing about, not showing off before others, not thinking about the competition. George Leonard cites various examples of this sustained desire to just enjoy it, for example: Aikido black belts are never bored to practice simple moves finding newer and newer shades in what they do, going into focused trance, whereas boredom and hasty search for more tips and tricks are characteristic of shallow students looking to feed their vanity on the rich texture of any given sport or art.

Craftsmanship movement in software development tries to apply similar practices via coding dojo and katas. It is not clear whether this direct transition is good enough, but it definitely looks interesting.

Mastery is an unrewarding process. It’s not about getting 100% results.  It’s about following this path. Master is the one who deliberately takes on the fool’s mask, like court jesters. The point is that if you think of yourself as an expert in any given field — you’re full. There’s no more room for novelty. So, you’ve got to pour out of this glass of attained expertise to keep fit as an agile apprentice. The luggage of expertise steals the ability to enjoy your path of mastery.

Have you met agile experts that know everything and have confident answer to every question? Have you met agile experts that deny new things and believe in a defined set of principles? Beginner’s Mind is a great way to keep learning.

I’ve mused quite a lot on the Mastery book. I do have several hobbies -arts or sports- that I feel like I should practice, because I got talent for them — and I’ve actually practiced them for quite a long time — and I should definitely keep up with them. At some point I just got stuck. I couldn’t figure for myself how one can fit several hobbies and sports, and their diligent practice to a busy schedule — after all, there’s a job that I also love doing! How do I fit all these loves into a limited time?

I also noticed that in the process of getting stuck with this dilemma I seemed to stop actually enjoying those masteries. I would spend countless hours on the web, reading everything I could find on getting things done, finding focus, feeling superior to bloggers describing things that I know very well how to do.

The problem of choice has been chasing me all the time. Finally, it all came out simple. I also noticed that even if you read countless how-to’s, countless blogs, no matter of how many of those how-to’s you read, and how well laid out they are — it inevitably takes time for things to go home. Reading about something and understanding something from within are two different things. That’s why all the “getting things done” blogs and books are nothing more than someone else’s experience reports. Reading someone’s blogs will not solve your problems of gaining focus and concentration. It’s a substitute for what it’s all about — for practicing. I’ve seen people making a big deal out of GTD. All these GTD software, gadgets, hacks to block interruptions, you name it. Making a religion of GTD gives no more time to practice your mastery, that’s the point.

You’ve got to sit down and decide for yourself: what is it that you actually love doing? Once you listen to your inner voice — it all gets in place, like in a puzzle. There’s no need to think any more. If you really enjoy what you do, setting priorities is absolutely irrelevant, because what you enjoy doing now is the best thing you could do right here, right now.

If you still find yourself digging in how to’s and blogs, there’s nothing wrong about it. Probably your research reflex isn’t yet saturated, and you feel more at ease in a research, in a familiar comfort zone of consuming information on a soft couch.