Teams that write unit tests go faster

In the fast-paced world of start-ups, it’s common to overlook the importance of writing unit tests*. With limited resources and short timescales, many consider it a luxury rather than a necessity (if they even consider them at all).

The long-term impact is far from marginal – if you’re lucky enough to start getting to scale, you’ll regret not investing in them early on.

However, even in the short term, writing unit tests can speed up your delivery. Here’s how 👇

🐛 Bug Reduction

Unit tests enable teams to catch bugs early, before they reach production. This not only improves user experience, but also saves time and resources in testing, debugging and hotfixes.

Quicker Changes

Good unit tests encourage modular, less complex code. This makes it easier to implement changes and add new features. Furthermore, unit-tested code acts as its own documentation, reducing the time needed to understand how the code works.

🔄 Frequent Releases

With a solid suite of tests in place, the risk associated with each release decreases. Developers and stakeholders gain confidence that the new changes haven’t broken existing functionality, enabling more frequent releases and quicker feature rollout.

👥 Fewer People (& Cost)

Unit tests reduce the number of people required overall. Less resource needed for manual testing and debugging, and a lower overall cost of change & maintenance as a result of the tests encouraging less complex code.

🌱 Why Early-Stage Start-ups Should Care

Many early-stage start-ups don’t invest in unit tests, especially when the development team is small. However, as the team grows, their absence becomes increasingly detrimental. Adding unit tests retroactively can be a herculean task, particularly if your codebase has already turned into spaghetti.

In summary, unit testing is not just a “nice-to-have”; it’s a strategic advantage. Even if you’re working with a lean team, the benefits far outweigh the initial time investment. The sooner you start, the faster you’ll go.

Avoid the messy middle with hybrid working

Either have regular set office team days or choose fully remote, but avoid the messy middle of “come in when you need to”

Firstly a few disclaimers: This article doesn’t intend to compare or argue the merits of either fully remote working or co-location/hybrid. Secondly, these are my views and not those of my employer or any other organisation.

As things are gradually getting back to normal, many organisations are formalising their hybrid working policies. Some are choosing to have set office days – including my current organisation where our Product & Tech leadership (which I’m part of) made the decision to take this approach early 2021. You can read about our rational here. It’s not long and saves me repeating it in this article.

Others are taking the “come in when you need to” approach. This generally means if a team needs some face time for activities that benefit from in person interaction, they arrange to come into the office together. Otherwise do what suits you (the individual) best.

Why “come in when you need to” is the messy middle

When I try and arrange to meet up with friends who are now spread across the country (or even old work colleagues locally for that matter) it’s a military effort finding a time when everyone is free. Usually we have to schedule months out in advance. Even then things fall through as often as not.

I’m hearing similar stories from organisations currently taking the “come in when you need to” approach – teams finding it a struggle to get everyone together in person at the same time, especially when they’ve now hired people geographically further out from their offices. I’d imagine this gets exponentially harder when you want to get a few teams together who are, for example, collaborating on a shared outcome.

For working parents I see it as a particular issue. Most parents I know don’t have five full (i.e. 8am-6pm) working days of childcare (due to the expense). It’s usually a mix of paid childcare, grandparents and then parents splitting shifts on drop-offs and pick-ups (thankfully at my current employer we have flexible working hours which allows you to do this). In my experience at least, it’s a highly disciplined and drilled exercise, needs a routine and is difficult to change on a whim.

“Hey, why don’t we all go into the office tomorrow and workshop it in person?”

What if you’re the only parent on your team and now feel like the “difficult” one because you can’t just always change your routine that quickly? Now they’re all going in anyway and you’re missing out?

From an HR perspective, it’s ambiguous and difficult territory. What if someone says they won’t come in? Is that a conduct issue? When you have set days for everyone it’s pretty simple, they’re the same polices you had pre-hybrid working for those days. In the “come in when you need to” world you’re going to require a very clear definition of “need” and most likely, new and complicated colleague policies.

I’ve a strong suspicion (I know it’s the case in some places) quite a few organisations taking the “come in when you need to” approach aren’t doing so because they see it’s working, but because they’re still in wait and see mode. Why? Primarily I’d guess, fear of attrition in a highly competitive labour market. I predict that as more organisations come out formally with set office day working patterns, others will follow.

Choose set days or go fully remote?

Like I said in my disclaimer, I’m not out to argue the case for either remote or co-location here, just highlighting the situation I see as the worst of both worlds. If you can’t see set days working for your organisation, then perhaps it’s worth looking into whether fully remote is a better option.

Line management in Agile Teams

Line management is currently on my mind as I’ve moved to a new company (VP Engineering, team of 30+ people). Coincidently it’s also something I’ve recently been asked about by a peer in a similar position. Modern management practices tend to frown on line management as it smacks of traditional organisational structures. However – out with line management tends to go any formal pastoral care for staff as well as inexperienced or unqualified people getting left to deal with complicated situations with little or no guidance.

Below is advice based on my experiences. I’m happy to answer any questions, but I don’t present anything here as a shining example of good or bad (“where’s the Holacrocy dude?”), just stuff that has worked well for me over the years.

Everyone needs good guidance
I wrote this article on Roles & Responsibilities in Software Teams over 5 years ago and have used these effectively in 3 companies now. I find it really helps for everyone to be clear on what’s expected of them, it certainly makes the line managers job easier to have something which defines positive (and negative) behaviour.

Team Lead as line manager for the team
In my roles above, the Team Lead is basically line manager for the team. Their most important line management duties is regular 1-2-1s with their team to make sure everyone’s happy and productive and catch any situations or issues arising quickly. The Team Lead will also deal with team related line management issues, such as approving holiday, work from home requests etc.

The CTO/VP/Director/Head of Dev (i.e. me) will have more frequent 1-2-1s with the Team Leads than other team members so there’s a good feedback loop and any issues can quickly get escalated if needed.

Team Lead != Lead Developer
I intentionally separated these roles of Team Lead and Lead Developer, as being good technically does not make you a good people/line manager (see the Peter Principle). In many teams I’ve looked after the same person holds both roles, but not always.

Ultimately I’m the Line Manager though…
When it comes to more substantial issues such as anything requiring expenditure (e.g. pay increase requests, training) or performance issues that the Team Lead cannot solve himself (e.g. when you’re getting near the realm of disciplinary proceedings) that’s where I will take over from/support the Team Lead. Ideally a team can work through most of it’s issues, but not always.

Line managers need good guidance and training
Looking after people comes more intuitively to some than others, but either way it is a discipline people need training and guidance on – how to give good feedback is a great example as are good listening skills. I make an effort to mentor Team Leads in my 1-2-1s with them, but it’s good to have wider organisational initiatives too.

Pay reviews and performance appraisals
I’ve written up about my experiences with pay, performance and feedback previously. I consider regular 1-2-1s (with Team Lead and myself) to take the place of annual performance appraisals. However most companies still do pay reviews annually, which means some form of annual pay review meeting is required. As something I’d consider a more substantial line management issues I personally take responsibility for those pay review meetings with all my staff.

 

 

7digital Development Team Productivity Report 2013

Last year (2012) I published data on the productivity of our development team at 7digital.

I completed the productivity report for this year and would again like to share this with you. We’ve now been collecting data from teams for over 4 years with just under 4,000 data points collected over that time. This report is from April 2012 to April 2013.

New to this year is data on the historical team size (from January 2010), which has allowed us to look at the ratio of items completed to the size of the team and how the team size compares to productivity. There’s also some analysis of long term trends over the entire 4 years.

In general the statistics are very positive and show significant improvements in all measurements against the last reported period:

  • a 31% improvement in Cycle Times for all work items
  • a 43% improvement in Cycle Times for Feature work
  • a 108% increase in Throughput for all work items
  • a 54% increase in Throughput for Feature work
  • a 103% improvement in the ratio of Features to Production Bugs
  • a 56% increase in the amount of Items completed per person per month
  • a 64% increase in the amount of Features completed per person per month

DevTeamPerformanceReportApr12Apr13 (pdf)

The report includes lots of pretty graphs and background on our approach, team size and measurement definitions.

A brief summary of the last 4 years:

  • Apr09-Apr11* Cycle Time improved (but not Throughput or Production Bugs)
  • Apr11-Apr12 Throughput & Cycle Time improved (but not Production Bugs)
  • Apr12-Apr13 All three measurements improved!

*The first productivity report collated 2 years’ worth of data.

It’s really pleasing to see we’re finally starting to get a handle on Production Bugs and generally things continuing to improve. It’s interesting to see this pattern for improvement. We haven’t got any particularly good explanation for why things happened in that order and curious if other organisations have seen similar patterns or had different experiences. We’d expect it varies from organisation to organisation as the business context has a massive influence. 7digital is no different from any other organisation in that you have to be able to balance short term needs against long term goals. If anything else our experiences just further support the fact that real change takes time.

We must add the caveat that these reports do not tell us whether we’re working on the right things, in the right order or anything else really useful! They’re just statistics and ultimately not a measure of progress or success. However we’re strong believers in the concept that you’ve got to be able to “do it right” before you can “do the right thing”, supported by the study by Shpilberg et al, Avoiding the Alignment Trap in IT.

We hope you find this information useful and can help other teams justify following best practices like Continuous Delivery in their organisations. We would of course be interested in any feedback or thoughts you have. Please contact me via twitter:@robbowley or leave a comment if you wish to do so.

Pay, performance and feedback – an experience report (and where we are now)

I’ve written up an experience report on my recent adventures trying to improve the way we do pay reviews (it’s more interesting than you might think).

Like many companies we’ve been struggling with a problematic pay review process. In our case the feedback mainly revolved around it feeling arbitrary and lacking transparency. Around the time we were discussing this the Valve Handbook got posted, within which it talked about their peer review & stack ranking system:

“We have two formalized methods of evaluating each other: peer reviews and stack ranking. Peer reviews are done in order to give each other useful feedback on how to best grow as individual contributors. Stack ranking is done primarily as a method of adjusting compensation. Both processes are driven by information gathered from each other—your peers.”

Awesome, you get rated by your peers rather than a manager or HR person, who has no idea what you do (not that we did that anyway)! I liked this idea a lot and got to work on doing our own version. I started with a trial peer review survey with one team. There were some positives, but it mostly went down badly. People really didn’t like the stack ranking and also that I only asked a few high level questions with the answer being a score out of 10. So we went back to the drawing board. We got representatives from all our teams and held 4/5 sessions where we broke down the larger themes (Skill, Productivity, Communication, Team) into more detailed and objective questions. After a lot of persistence and effort we finally put this all together and we had the survey! Which I promptly canned…

Trying to measure performance

The fundamental problem I was (naïvely) trying to solve with a peer review survey was to bring in a degree of measurement, which would hopefully mean people felt the pay review process had a quantifiable aspect and didn’t just come down to one person’s opinion. However we were getting into the terrain of incentivising our people based on individual optimisations (rather than organisational or team goals & objectives) and – most disturbingly – the anonymous feedback aspect just felt very wrong. It was and is completely contrary to our culture and the things we stand for. The trade-offs simply weren’t worth it. Regardless of the unpleasantness of anonymous feedback, everywhere I’ve heard of using ranking/measurement schemes have really bad stories to tell, such as Microsoft and GE. Warning signs everywhere.

Don’t mix pay reviews with feedback

Another problem is the survey would have been a kind of feedback mechanism. Imagine getting your results – all nicely presented in bar charts – and finding you scored really badly on one section. What the heck are you supposed to do with that?! I’m a really bad communicator? What do they mean by that? Who thinks that? Great, everyone thinks I’m rubbish but I’ve got no way of finding out why apart from going around everyone and asking them. Ouch! I am a big believer in regular 1-2-1s (I’ve talked about them a bit here). As Head of Development I start every day with a 1-2-1 with one of my department (I see all 35+ people as regularly as I can). Each team also does 1-2-1s (usually with their Lead if they have one). Each new joiner gets a mentor who they have a monthly 1-2-1 with for their first 3-6 months. By the time you get to a pay review their should be no surprises, no feedback that you haven’t already heard before.

Where we are now

Our latest attempt is heavily based (& in some parts very plagiarised, I have to admit) on the StackExchange compensation scheme. The peer review survey wasn’t a complete waste. I adapted the themes and questions from the survey we built into a set of core values we desire from our colleagues to be used for guidance. This is still very new and as yet unproven, but it certainly feels a lot better than where heading previously. I could explain in more detail, but it would be duplicating what I’ve said in the document/guide, which you can download here: 7digital Dev & DBA Team Compensation

Finally, a word on annual performance appraisals

I’ve only been employed by one company who ran annual performance appraisals and was far from impressed. It’s something we’ve consciously avoided for our tech teams at 7digital. I could go into more details as to why they are wrong, but others much more qualified than me have already done so:

Advice on running 1-2-1s

I’ve find 1-2-1s to be hugely valuable, I think it’s the most important thing I do.

Why?

How many times have you been in the situation where you were stuck on a problem and simply by starting to explain it to someone you solved the problem in your head? The point there is talking is a good thing in itself.

1-2-1s are also extremely good at catching problems early, often before you realised they were a problem. Retrospectives are great way of raising and solving issues, but they’re much more about the team than the individual. There are also a lot of things people are not comfortable saying in those kind of situations.

Here’s some simple advice for anyone running 1-2-1s:

1. Get the conversation flowing

It doesn’t really matter what about. Some people will be straight out of the gate venting all their ills (which is great!). Others find it harder to open up. There are lots of simple questions you can ask to get things flowing. Have an artillery of questions which come from different angles, which can also be useful if the conversation dries up.

Here’s some really simple ones I find work well. Try not to ask too specific questions:

  • How’s it going?
  • What have you been working on?
  • How’s the team getting on?
  • How have you been getting on since the last time we met?
  • Anyone pissing you off? Are you finding it hard to work with anyone?

2. Listen!

Once the person is talking try not to interrupt them or (something I’m really bad at) try to finish their sentences. When an interesting point comes up try responding with another question.

Often a conversation which starts as trivial will often evolve towards a pain point with the curious phenomenon that the person hadn’t even realised it was a problem until now. It’s important to try to allow the person to talk uninterrupted to allow this to happen.

Listen out for the issues. This is something that takes a bit of experience, but try to keep an ear out for (often subtle) things the person says which can be signs of greater concerns. When something does appear on the radar don’t interrupt, but when they’ve finished talking try and bring them back to it and see if there’s anything more to it.

If they’re ranting don’t stop them! It’s emotional and irrational by nature. Let them get it out of their system. Once they’ve calmed down they’ll be able to think more clearly.

3. It’s not your job to solve their problems, but help them to solve their own

Telling people what they need to do to solve a problem is generally not very effective. If you have thoughts, pose them as suggestions and ask what they think. Even better start by asking them what they think could be done about it?

No preaching!

4. Follow up

The next time you meet up (& this is why it’s important you are consistent with who you have your 1-2-1 with) follow up on the things you talked about last time and see if there’s been any improvement.

My “Agile Adoption is Fool’s Gold” talk from QCon London is now up on InfoQ

I did a talk at QCon London 2012 about my experiences with introducing Agile practices at 2 organisations (7digital and BBC Worldwide). It’s now available to watch on InfoQ:

http://www.infoq.com/presentations/Agile-Adoption-is-Fool-s-Gold

I regularly refer to my notes being available including links to many of the things I mention. You can access them here:

https://docs.google.com/document/d/1IN8e3UNvR1oRlvT9b_1gKHNkBE2E6fEx_dVSD3p–6g/edit

Some recommended reading for management types

I’m a bit of a management junkie as well as a programmer, which is fortunate as I’m now in a position of senior management (although I have to admit I still prefer coding to management). I wanted to recommend some good management reading to people in my management team – particularly regarding organisational strategy and leadership as we’re a small company growing up fast and need to think about these things more seriously now. I was also keen that nothing I recommended was too polemic, software development oriented or, ideally, containing the “A” word (although one ended up doing so).

I asked Twitter and the books below are the ones most recommended or looked most interesting for us. It’s by no means an authoritative list or supposed to be the “best” of anything. I just thought it was interesting enough to be worth sharing more widely.

The Goal

The Goal is a management-oriented novel by Dr. Eliyahu M. Goldratt, a business consultant whose Theory of Constraints has become a model for systems management. It was originally published in 1984 and has since been revised and republished every few years, once in 1992 and again in 2004. This book is usually used in college courses and in the business world for case studies in operations management, with a focus geared towards the Theory of Constraints, bottlenecks and how to alleviate them, and applications of these concepts in real life.[1] This book is widely used in leading colleges of management to teach students about the importance of strategic capacity planning and constraint management. 

Most recommended by those polled. I’ve also read it and think it’s great.

Managing the Unexpected

The unexpected is often dramatic, as with hurricanes or terrorist attacks. But the unexpected can also come in more subtle forms, such as a small organizational lapse that leads to a major blunder, or an unexamined assumption that costs lives in a crisis. Why are some organizations better able than others to maintain function and structure in the face of unanticipated change?

Authors Karl Weick and Kathleen Sutcliffe answer this question by pointing to high reliability organizations (HROs), such as emergency rooms in hospitals, flight operations of aircraft carriers, and firefighting units, as models to follow. These organizations have developed ways of acting and styles of learning that enable them to manage the unexpected better than other organizations. Thoroughly revised and updated, the second edition of the groundbreaking book Managing the Unexpected uses HROs as a template for any institution that wants to better organize for high reliability.

David Harvey, CEO of Vyclone and industry veteran recommended this because ” (1) it’s full of good stories, (2) it’s backed by _a lot_ of research, (3) no mention of the Agile or Lean words…”

How to Manage and How to Lead

Both recommended for being short, pragmatic and accessible. Thanks Marcin 🙂

Adrenaline Junkies and Template Zombies:Understanding Patterns of Project Behaviour

In Adrenaline Junkies and Template Zombies, the six principal consultants of The Atlantic Systems Guild present the patterns of behavior they most often observe at the dozens of IT firms they transform each year, around the world. 

The result is a quick-read guide to identifying nearly ninety typical scenarios, drawing on a combined one-hundred-and-fifty years of project management experience. Project by project, you’ll improve the accuracy of your hunches and your ability to act on them. 

Any book where DeMarco is involved is essential reading in my opinion. Not heard of this one before. Thanks Captain Crom!

Managing the Design Factory: A Product Developers Tool Kit

This text on product development combines the analytical tools of queuing, information and system theories with the ideas of organization design and management. The author aims to answer such questions as: when should we use a sequential or concurrent process; should there be centralized or decentralized control; and should the organization be based along functional or team lines?

Supposed to be a bit theoretically heavy in places, but worthwhile none the less. I hear Reinertsen’s name referenced regularly and know a couple of people who have been on his course.

Management 3.0

Management 3.0 is a course, a book, and an approach to inspire team members, team leaders, development managers, IT directors, project managers, Agile coaches, and HR managers, who face the challenge of transforming their organizations to an Agile mindset. We do that by providing guidance and practices, and by applying complexity thinking to the craft, art, and science of Agile management.

I’ve read this and really liked it. It’s obviously very “Agile” oriented, but starts by covering a lot of management theory and most things covered in the book could be applied far more widely than just software development.

How we do “innovation time”

This article is cross-posted from Blogs From The Geeks, the 7digital development team blog:

Assuming you had consent from up above*, you’d think it’d be a breeze to get an initiative like innovation time off the ground. Surprisingly at 7digital it took us three attempts before we got something to stick and speaking to someone else recently I found they’d had a similar experience. As we’ve had our “innovation time” initiative running successfully for over a year now I think it’s worth sharing how we’ve got it to work.

In our first two attempts we found the main reason it failed was putting too many barriers in the way.  We didn’t think it was right that you could work on production code, you shouldn’t do it on your own, it should be justified and approved by your peers, like a business case. Innovation really hates these kind of things. Ironically we thought having “sensible” rules like this would ensure people didn’t waste their time on things we didn’t think could be classed as innovation, but they were based on a fundamental misunderstanding of how innovation occurs.

If you’re even slightly aware of your history regarding invention and discovery you’ll see a large proportion came about by happy accident, mostly when trying to prove something completely different. It’s such a common event it has its own name – serendipity. I strongly believe you’ve got to have a really open mind and shouldn’t have any particular expectations or goals in mind apart from innovation itself.

So for our third attempt we tried to really strip it down. Here’s the rules we agreed:

Conditions of use of innovation time

  • There is no jurisdiction on how you use the time.
  • If you’re working on production code, or any application or tool which supports production code, you must do it properly i.e. follow the development team standards.
  • If you’re working on something unrelated to production code or existing applications you may work in any way you like. However if you wish for whatever you produce to be used in anger it must meet the usual standards (i.e. either write it to expected standards to begin with or rewrite it afterwards).
  • We should put anything suitable in the public sphere e.g. on GitHub and hosted where appropriate.

Allowance

  • You have 2 days a month you are able to request for innovation time.
  • Innovation time does not accrue – if you don’t take your allocation in a particular month it does not carry over.
  • If someone else does not use their allocation you cannot use it in their place.

Requesting innovation time

  • Request time through whosoff.com as “DevTeam Innovation Time” (we set up a special leave type).
  • It’s to the discretion of your lead developer (or head of development) to approve. (e.g. they may not approve if they consider that the ability for the team to function effectively will be compromised due to too many people being off or we’re really busy with something and need all hands on the pumps).

Accountability

  • You must create a wiki page with the details of what you did and what you learnt.
  • For each day you take against a particular activity you should have a diary-like entry with the date and who was involved.

Using our leave booking system was a particularly inspired move. It means innovation can be managed just like holiday – it shows up in everyone’s calendars and allows everyone to plan around your absence. It also means we can pull out stats on how much time people have been taking:

Interestingly out of a possible ~456 days in 2011 189 were used, making it “4.74% time”. Another particularly surprising observation was people took less innovation time when they were not feeling motivated about their usual work (we had a very painful database migration in the summer).

It really helps that we’re very team focused at 7digital (pair programming is really good for this) so it’s no great loss when any one person is away for a short time. It also really helps that we try very hard to work at a sustainable pace.

As for what’s been done we’ve had some really interesting and diverse projects. Many of them have simply been around investigating new technologies and ways of doing things rather than new product ideas (but we’ve had some of those too). I think in this respect a lot of the benefits are intangible, but that’s one of the interesting things about innovation – if you tried to measure it you’d kill it stone dead.

*I’ve no intention of going into the justification for initiatives like innovation time here. That would be another, very long article 🙂

The Robber’s Cave experiment

Someone reminded me of the Robber’s Cave experiment last night. It was quite an amusing study with a serious motive of showing how easily opposing in-groups and group hostilities can form. It also showed how having superordinate goals can counteract this phenomenon.

Basically, if you’re finding yourself in the situation (as, lets face it, we often are) of taking sides and forming prejudice about other teams or groups a la Lord of the Flies you’re succumbing to base, instinctive behaviour which was probably quite useful when we hunted in packs, but has little value in modern society.

Next time you find yourself in this situation, think about what superordinate goals you share with the “opposing group”, so that rather than back slapping each other about how amazing your group is and how weak and feeble they are, you can all work together to get what you want.