RSS Feed

Latest Entries


First time here?


Thursday
Sep052013

What's your Position, Velocity, and Acceleration? by Neal Tibrewala

About Neal: Neal Tibrewala is the head of software development at L5 Software Group in Austin, TX

As a software consultant for 25 years, the thing that I've found the most useful is measuring to figure out where you are and where you're going as a team.

Let's take something like the number of known defects in a product. Most software projects track their defects using some kind of defect management tool.  Therefore, a team could know that they have, say 100 known issues with a certain product.   This is their "position".

Is this good?  Is this bad?  Is action required to address this fact? Often, someone will make a gut call at this point and say that it is either "fine" or "bad" and try to make a change.  I would argue that change is premature at this point.  As a team, having 10 defects or 100 doesn't tell you if you're in trouble.

Smarter teams will say:

"Aha!  We should track our defect rate instead!"  

Indeed, tracking your defect rate is the next step.  Take a certain fixed time period, say a scrum iteration, and track the number of defects fixed and new ones discovered to see the total number of open defects at the end of each iteration.  This is called the team's velocity.  In the example above, the team with only 10 defects could be accumulating new ones at a rate of 10 per iteration, and the team with 100 could be decreasing them at a rate of 10 per iteration.

Clearly that means the team that's bringing defects down instead of up is the team on the better course, right?   Maybe not.

The final step is to track your acceleration.  This is looking how the defect rate changes over time.  The team with a defect rate of +10 per iteration could be learning, thus, the following iteration be at +8 defects, then only +6, etc.  While the team at -10 per iteration could be slowing down, thus be fixing 8, then only 6, then -4, etc.  

This number is either plus or minus 2 defects per iteration per iteration (2 defects/iteration^2).  This is the team's acceleration, and this is the number that should be looked at most by the team's leader.

Learning will always impact position and velocity.  Spending time learning will slow a team down in the short term, but acceleration, measured over a long period of time, is the surest sign of a team that's learning or not.

A team that's not only able to adjust their position, but also control their velocity, is the kind of team that you most want to encourage. Changes that affect acceleration are powerful tools as they can have drastic impact on velocities over time.  Likewise, they can serve as early warning indicators as slowing velocity can be seen far before a project gets into visible trouble.

Friday
Aug162013

Audio Book - Notes to a Software Team Leader, Now Available

Good news everyone !

After more than a year in the making, the text version of my book for team leaders is in final production stages, and the audio version is now already available.

You can purchase the audio book in this link, or on Audible.com 

I had it professionally narrated, and I think this book has some sound advice that will actually help you at work.

The Audio book contains 4 hours of professionally narrated audio in 31 chapters. Here`s a sample from chapter 1:

 

 

The audio will be available in several formats:

  1. Separate Chapter Based mp3s
  2. An .m4b file playable as an ITunes Audio Book

All these will be included in the zip file that you get upon purchase if you get it at gumroad.com (audible has their own format which is not DRM free I'm afraid).

I hope you enjoy it. I know I never have enough time to read all the books I want, so I`m happy that this book`s content lends itself to an audio format, that one can listen to in the car or in a gym.

If you have any comments or feedback, please let me know in the comments :)

 

Roy

Thursday
Jun202013

Be a Book Reviewer for 'Notes to a Software Team Leader'

Want a free book? Willing to review it on Amazon when it is published? Willing to give me valuable feedback?

Fill out this form.

Tuesday
Jun182013

Audio: Preface–Notes to a Software Team Leader

Here is a little experiment. Below is the audio version of the Preface of my upcoming book “Notes to a Software Team Leader”.

 

I am thinking of turning this into a saleable audio book. How much should I charge for the entire book, with each chapter being an mp3 (book is about 110 pages)

and where should I sell it? (I do not live in the US, so cannot use Stripe)

Monday
Feb252013

Developing Critical Team Thinking

Borrowing a few terms from critical thinking, this is another map, or model, of how I feel I need to guide my teams. When do I feel like I have successful gotten my team where they could have been all along?

Here is a great quote from this PDF file on critical thinking:

From the cognitive scientist’s point of view, the mental activities that are typically called critical thinking are actually a subset of three types of thinking: reasoning, making judgments and decisions, and problem solving.

I say that critical thinking is a subset of these because we think in these ways all the time, but only sometimes in a critical way. Deciding to read this article, for example, is not critical thinking. But carefully weighing the evidence it presents in order to decide whether or not to believe what it says is.

Critical reasoning, decision making, and problem solving—which, for brevity’s sake, I will refer to as critical thinking—have three key features: effectiveness, novelty, and self-direction.

Critical thinking is effective in that it avoids common pitfalls, such as seeing only one side of an issue, discounting new evidence that disconfirms your ideas, reasoning from passion rather than logic, failing to support statements with evidence, and so on.

Critical thinking is novel in that you don’t simply remember a solution or a situation that is similar enough to guide you. For example, solving a complex but familiar physics problem by applying a multi-step algorithm isn’t critical thinking because you are really drawing on memory to solve the problem. But devising a new algorithm is critical thinking.

Critical thinking is self-directed in that the thinker must be calling the shots: We wouldn’t give a student much credit for critical thinking if the teacher were prompting each step he took.

—D.W.

the last part hit home on many levels about what it means to coach someone to learn a new skill.:

Critical thinking is self-directed in that the thinker must be calling the shots: We wouldn’t give a student much credit for critical thinking if the teacher were prompting each step he took.

Learning a new skill  means that they do not need you there to continue doing something. that you are no longer a bottleneck.

A self organized team is a self-directed team, as far as critical thinking is concerned. But we want our team to not only be self directed, but also effective, by avoiding common pitfalls as as discounting new ideas, seeing only one side of an issue, etc. Learning to be effective is to acquire a set of new skills, of each of these pitfalls, if they occur for members of the team.

A critical thinking team uses novel ideas, not always blindly applying templates to different problems, but always experimenting, and finding new, better ways, of doing new, or even the same things. there is always something new to be learned.

As I usually say, if everyone is too comfortable, you’re not learning anything. so something new has to jump into the equation in the form of a new experiment (‘what if we did no iterations for 3 months?’)