Reducing waste by making your goals visible

Metrics are good, but they’re not enough. If you want metrics to drive change, they need to be visible. Not just to managers, but to the team. The right metrics, visible to the team, drive improvement. Visible only to management, drive control. Visible to no-one, drive nothing.

Good metrics need to be communicated clearly and persistently. There needs to be a continual focus on whatever the priorities are. If it’s out of sight, it will be out of mind. If it’s digital, rescue it from individual screens that are easily covered up.

It’s why kanban boards can be so effective when used well. It’s easy to see when the team is taking on too much work, or where there’s a queue waiting for tasks to be pulled. The board radiates information to the team, about how much work is in progress, and who is working on what. It becomes the centre of communication about tasks and removing waste. Make it physical, if you like, and the team is co-located. Use Post-its. Let dog ears and grubbiness indicate age. Do your backlog pruning via environmental effects – older & more used notes are more likely to fail behind the radiator and get lost.

Put (work-related) personal tasks on there too. Keep yourself honest. It’s good for the team to know you’re reviewing CVs, or preparing for that strategy meeting, or learning Haskell the hard way.

But keep it clear. Use a Kanban if WIP or queueing are your key metrics. Use Scrum if velocity and deadlines are key. Use a dashboard if that makes your priorities and progress clearer.

And make sure your key priorities (4 or less please) are visible at a glance for the team, and easy for anyone in the team to explain to a passerby. They don’t need detail, but pointing to a big pile of waiting tasks to justify recruiting a new tester is a clear message.

Little UX wins #littlejoys

I’m no expert in user experience. So I’ll let others talk about the personas, the end to end journey and bringing joy. I want to talk about the details.

Those papercuts that slice away at you, that just make things a bit more work. The things that spending 15 minutes watching users makes you scream at yourself for putting your users through it.

But it doesn’t just affect technology. Here’s a list of papercuts I’ve noticed, either because one company has fixed them, highlighting the pain that everyone else puts you through, or because they annoy me. Reflect on your experiences as a user. What delights you and annoys you?

Things I like

• Waitrose Meat in foil trays store the sachet in the cardboard cover, outside the foil tray, so no meat juice on them. This is a great example of separating concerns so that the raw, unsafe meat never comes in contact with the sauce until it has been cooked to make it safe.
• Double tap to wake. The on button on many phones is small, and often hard to reach when on the table. Phones that allow a full screen action to wake take advantage of Fitts Law and their large screens to make that common action much quicker.
• Lenovo N22 carrying handle. Many people carry their laptops without a bag. When you have a cheap, light, knockabout laptop, embrace it, and give it a handle. Bonus: teachers can carry many at once.
• There’s also a bundle of wonderful examples here: UX out of electronic spaces http://uxpa.org/upasiteredirect/index.html/uxmagazine/lets-get-physical/?utm_content=bufferea7eb&utm_source=buffer&utm_medium=twitter&utm_campaign=Buffer

Less good

• In my house, there are some lockable windows and some button operated (for fire safety upstairs)). On the button windows, you push and then turn. On the lockable ones, you turn the key to release the button, then turn. Every time, I push the button to open those windows, see the locked window depressed and think it’s unlocked. Every. Bloody. Time.
• Something that needs better feedback rather than relying on transferable knowledge that many people are bad at : estimating size. Why does no microwave rice have a visual indicator of 2cm for the tear? So many packets have “tear here” and printed perforation. Why not “stop here”?

What papercuts have you seen, and what user experience interactions give you joy?

Peer Reviews and Feedback

Peer review is an essential component of a functional team producing quality software. It allows knowledge transfer, stops obvious and sometimes not-so-obvious bugs reaching production, and it aligns everyone to process and coding standards.

In some companies, “peer review” is manager driven. The technical lead or architect reviews the code, and no-one else can. They become a bottleneck. Don’t do this.

In some companies peer review is handled asynchronously, for example by pull requests. This is great for smaller teams or time-zone distributed teams, and for code that the whole team should review (new framework added, security fixes, for example) but the cost is that it increases the cycle time by introducing a delay (which could be minutes or could be days) between code being submitted, reviewed, reworked and accepted. Unless they do optimistic merging, which I’ve already dismissed.

In some companies peer review is done by pairing. One person types, the other reviews in real time. Reviews the requirements, security, UX, coding standards. This removes the feedback loop, and encourages greater reflection on each line of code, and the wider context, because the review isn’t coming in raw.

Some companies use a mix. Pair for some, or most work, but still leave space for pull requests so that other experts can review, and feedback, and understand that feature.

But however you do it, the feedback is key. I’ve seen a few people on Twitter talk about pull requests being too late, because of the feedback loop. Once the toast is burnt, it’s useless. Which is valid, but that also suggests to me a culture where the feedback talks about the result rather than the process. “This toast is burnt” is ineffective feedback. It states a fact without providing a learning opportunity to understand how not to burn it next time. And pairing doesn’t always provide that opportunity either. What might look, when copying someone else, like an odd coding convention, might be the difference between a successful release and a crippling SQL injection attack. But you need to ask why.

Some people, especially devs, are far more comfortable asking why on their keyboard, when they can reflect themselves, and research the concepts. Equally reviewers tend to be harsher in the pseudo-anonymous situation of conversing with a code diff, than talking to someone face to face. Reviewers have got to the stage of telling me they feel guilty about comments and then apologising face-to-face, but standing by the desire to see the best possible code committed.

Yes, there are definitely problems that shouldn’t make it as far as a pull request, but if you have those problems, ask yourself why there’s such a big gap between code writing and code review, why your mentoring process didn’t pick up on that issue, if the feed on process to Dev needs its own review. My experience, if something is broken in the pull request code, it was broken before that code was written. And you need to teach that developer how to use a toaster the way the rest of the team does.

---

 

If you want to continue this discussion, there’s some great threads to follow here:

https://twitter.com/perhammer/status/832224083383291904

Code review is inherently too late for collaboration, especially if there's a power dynamic like blocking someone's next action. https://t.co/98CEPSxSUc

— Brian T. Rice (@BrianTRice) July 12, 2017

Boy it's hard to get people to take conceptual corrections at the point of a code review.

— Peter Abrahamsen (@peidran) July 12, 2017

Measuring the wrong thing

Process improvement requires measurements. How do you know what to improve if you can’t see where things aren’t working, and how do you know you’ve made the right change without seeing those numbers going in the right direction?

But measuring doesn’t mean you’re measuring the right thing, and measuring the wrong thing can lead to the wrong outcomes, and can be very harmful (see Liz Keogh’s talk on perverse incentives )

The key to the success of any metric is that it is owned by the team so they have complete control over the changes needed to affect it, so they feel ownership, and that improving the metric has a useful business outcome.

Metrics that I’ve found useful in the past include:

Number of bugs introduced by a release.

This is a tricky one to work with because it can easily be a perverse incentive, and the feedback cycle can be slow, especially with the usual 6-12 month release cadence. However, on one waterfall project I took over there was a strong negative perception of the quality of the code, and big count was a useful proxy as the customer had access to JIRA so the big list was already visible. Reducing this number was a combined effort where testers and developers had to approve requirements, developers and testers invested in automated testing at all levels, and testers joined the developer daily stand-up in order to catch bugs before they were released “have you checked that page in Welsh?“, “We found problems on that page last time because IE was too slow“.

Number of releases per month.

On an agile project we noticed that releases were getting held up because testing was slow and produced a lot of rework, which were then tested against more features that had been pulled from the backlog, increasing testing time. Each release also took half a day, so we had to schedule them carefully.

So we set a goal of focusing on releases for a month and measuring how many we did. There were other measures within that, such as monitoring work in progress on the testers, time taken to do a release, and cycle time from start of development to live release, but they all drove the big number, visible to the whole company, of more quality releases.

Questions answered per day.

This can be a very useful metric for research projects, especially when following a fail fast approach, when you want to prove something can’t be done before you invest in doing it. In order to do that, you need lots of questions with quick answers, to accelerate learning. Any answer, positive or negative, is progress. It means we have learned something.

“I cheerily assured him that we had learned something.
For we had learned for a certainty that the thing couldn’t be done
that way, and that we would have to try some other way.” – Thomas Edison

Age of Pull Requests

Successful agile projects rely on peer review, either via pairing, or a formal review process such as git PRs (and I won’t discuss that in this post). However, when we started working with these on one project, we discovered that we were building up a large debt of Work In Progress because the team wasn’t incentivised to review each other’s code, so one of the developers set up a nag bot for any PR older than 4 days. It lasted 2 weeks before it was no longer needed.

What about you?

What metrics have you used to incentivise the team? What problem were you trying to solve, and did the metric work?

The importance of confidence

Have you ever been given a project to deliver and thought you can’t do it? That you don’t know enough, that the deadlines are too tight?

Ever felt like panicking?

Have you been on that team, and somehow still delivered, with absolute pride in what you’ve delivered, bar a few teething issues?

As a leader, to inspire your team, you need to exude confidence. Confidence in the outcomes, and in the team. You don’t deny problems or paper them over. Hiding is a sign of weakness. But the team needs confidence to deliver and they get that from you.

If you’re not confident, don’t fake it. Revise the outcomes to a scope you’re confident in. Narrow your horizon. Get answers to your doubts, and support to conquer them. When times are tough, it’s your job to set the right expectations that the team can believe in, and deliver on. It’s your job to find a clear path through the chaos. Or it’s your job to help them pick up the pieces and move on.

These are the tests of your leadership. If the team can weather the crisis, if it can keep it’s collective head whilst all about are losing theirs, then you have earned the right to be a leader.

Be confident. But be authentic.

Government insecurity agencies

Given the SSL attacks that could be traced back to classing secure encryption as weapons subject to export restrictions, it’s clear that government security agencies have a deep conflict of interest that has led to significantly reduced security protection for their own citizens.

It’s clear that the Ransomware (or Ransomware as diversion) attacks on UK and US hospitals and many other sites are directly due to the NSA backdoor toolkit that was stolen earlier this year. Because if the government has a back door into a system, or an encryption platform, everyone has a backdoor, even if they don’t have access to it yet.

Which is why it’s great to see the EU outlawing backdoors in order to protect us as patients, service users, and data subjects, and I completely expect this will apply, like GDPR, to any system holding EU citizens data. So when the UK puts on its “we need a back door” legislation, companies need to choose to trade with the UK and compromise their security, or trade with the much bigger EU and protect their customers.

Encryption is like a lock, but it isn’t. It’s like a safe door, but it isn’t. Abstractions help to frame the problem, but they can obscure the issues. They make lawmakers think that what applies to banks applies to data.

(note: bank processes are optimised to replace credit cards because security works best when you can throw away a channel and start again if it’s compromised; this includes reversing transactions – which is hard to do when it’s the release of your personal data that needs reverted, rather than a row in a ledger than can be corrected by an additional row).

Encryption isn’t the problem. The San Bernardino iPhone had no useful intel. All the recent attackers in the UK were known, reported, and could have been tracked if they were prioritised. Banning encryption will have about as much impact as banning white vans. Breaking encryption weakens our security, threatens international trade especially with the EU, and when security holes lead to attacks on our hospitals and other infrastructure, bad security threatens our lives.

But so long as we’re afraid of terrorism, it’s OK for the populous to suffer?