Consensus and Running code

Recently I’ve been tech lead for two teams. One team is very much under command and control. The other has been running a lean procress for a year or more.

By lean I mean they have a team led continuous improvement process in place

Both teams are doing basically the same job. Same features. Same domain. Different projects. Rarely in business do you get a control group.

I’ve been lucky enough to see this in action.

One team is approximately 8 times quicker. The team that has removed it’s impediments because they are empowered to.

The other team is under terrible pressure and as such results and performance measurably decrease.

Now that I’m “in charge” of both teams I’m not able to stand by and let this continue.

1. It’s not humane

2. It’s not effective

3. It’s not economical

4. It’s not humane

I’ll merge the lessons learned from both teams and align their efforts, perhaps not so much an epiphany as an affirmation.

Keep coding. Keep testing. Keep talking.

I love measuring. In my academic life I was an instrument maker, data analyst, there was a whole department devoted to “Instrumentation, and Analytical Science” or DIAS for short. My hobbies of scale model building, or running are all about measuring. Measuring performance or measuring tiny bits of plastic.

Number one rule of measuring: Measure the right thing.

Number two rule of measuring: Measure it again.

My last project going by the project metrics was a complete and utter failure. Double the cost, and longer than expected. A big red X on the chart and under constant scrutiny.

Originally posted by randomstuffs2

But that doesn’t reflect the success of a project which I would hold as one the best that I’ve worked on. 

What’s the difference? Why the huge difference in perception of success.

Well let’s look at the numbers. 600 days estimate. Cost 1200 days total and was two months late. Pretty disastrous. But to look only at this does tell you what happened during the project.

Scope changed numerous times, the total of the estimated work completed, including that which was thrown away was about 1100 days. So our estimates actually aren’t all that bad.

Nor does it look at the customer engagement, the cross functional team building and integrating processes, the increase in code quality, or finally the end user delight in what was produced. (yes that word delight was actually used)

Originally posted by the-richest

Some of these are intangible and difficult to measure. At least it requires more ingenuity than simply measuring the number of hours you spent in the building. 

But you can measure customer satisfaction through surveys. You can measure the decrease in support calls for the feature in question. There are scores for the technical debt which you can measure using static code analysis.

These outcomes are far more important to me than the costs. I could produce something cheaply and it be far harder to maintain and not provide the same customer benefit.

The takeaway for me is to look for outcomes or benefits to be measured rather than simply the cost.

Spent a satisfying couple of hours replacing the air con blower in the car. Just like meccano with more dirt and swearing but less cut fingers.

The wonder of youtube is you can ger instruction videos for everything. Thanks go to wheelsandmotors.com

https://youtu.be/D81_DI667NA

We are nearing the end of quite a big project and clearing up the last few bugs and issues. We are working in a very agile way. Tester are coming up with scenarios and quick analysis done, and fixes made. Maybe it’s because the features are now better understood by all involved, or because we have “consensus and running code” but it’s all just so much better at this stage. I think we need the “clearing up” approach of a tester paired with a dev much more commonly. One for lessons learned

Today I’ve had a niggling knee pain just under the right kneecap. It’s kinda annoying but nothing too crazy. In hindsight, I did have a loose cleat last week and just tightened it up without too much thought.

I wonder if that has put my foot out at an angle? Putting pressure on the inside of the knee. Strange how something so small can make a difference but if you are going to do 1000′s on pedal strokes, it had better be right.

A very worthwhile session yesterday with those members of the team not on holiday, facilitated by the marvellous @Leannegallacher. 

I struck me that, when work has gone relatively well, customer demands met, and generally a positive outcome, like this last sprint, it is so much easier to pick out what you can do better.

It’s when things go bad that it can be difficult to pick out what is going wrong and what to change. Every team deserves a bit of work that goes OK so that they can observe what goes well and what can be improved. Might be hard sometimes to carve out some work to do that. But the benefits are worthwhile.

So this is a reminder to even in the midst of a difficult transformation, give yourself the room to do one part in a controlled way and see what the difference could be.

The last few days I’ve been catching up with Agile for Humans podcast. And in particular the #noestimates episodes. I thought it might be a fun exercise to look at the fixes and features in our product for the last 3 months.

Given number of items completed versus the work days between drops. The team now completes around 3-4 items per day. Up from about 1-2 items per day.

What is also interesting is that there was a step change in velocity when I insisted the testers got involved in the design stage for a particular feature. This mostly consisted of they adding tests to user stories and identifying failure modes (they are testers after all).

I intend to present these findings to management, I don’t think I’ll tell them about #noestimates just yet though. I don’t think we are at that stage of an agile transformation yet. Should make for an fun retrospective on Monday.