Doing the opposite
A few months ago I decided to change my approach at work. I was frustrated with what I felt were unnecessary constraints and so decided to go completely against all the assumptions associated with my role.
My role is partly to analyse upcoming work and break it up into more manageable chunks before it’s picked up by a developer. But so much of what I did at the time seemed to have been based on faulty logic. So I asked myself a question: what if I took all the preconceptions of my role, then did the opposite?
Before I go any further, exactly what were these preconceptions anyway? Firstly there was an unspoken assumption that requirements should not change once development had begun. Now I know what the agile manifesto says about encouraging changes: they’re to be welcomed, because they lead to greater responsiveness to customer needs. But if you had asked anyone in my office, especially a developer, you’d have heard the opposite: teams hate changing requirements, and many consider them to be the biggest obstacle to producing working code. This could also have been extended to apply to the list of what tasks were required, rather than just the tasks’ details themselves. Many developers would have objected if either of these had changed too much after development had begun.
The second preconception amongst people like me was that we shouldn’t have too much technical knowledge. There was an assumption that for someone like me, having too much technical knowledge was not an advantage; on the contrary, it was a hindrance. People often took this to mean they should keep their “requirements” entirely separate from the developers’ “solutions”; that is, the type of technical proposal that they felt was the best to meet the problem at hand. So began a chronic separation — one between the people deciding what work should be done, and the people actually doing the work. This is bad news.
I’ll share a quick aside here: the fact that these teams and specialities all exist, and that each has its own specialist subject, says something quite dangerous to me about the prevailing mindset that put them there. It’s a mindset that’s built around having separate teams for each discipline, with each piece of work experiencing multiple handovers as it passes in turn to each specialist team. ‘What’s wrong with that?’, you may ask. Nothing, in theory. But in practice every time a handover takes place, you’re increasing the probability of an error taking place. Look at any service industry: the more times a product changes hands, the more likely it is a mistake will be made. How do you get around this? Simply, by redesigning your work teams and processes around the way the work flows. Retrain teams and reorganise them in such a way that a single team can do everything required by a customer, without needing to hand off anything. Following the Second World War when resources were extremely limited, in Japan, Toyota’s production factories invented novel ways of restructuring the production line to match exactly what demands — specifically what new car orders — were being passed to it. The improvement in speed, combined with the accompanying boost in profits, made the Toyota ‘way’ famous on both sides of the Pacific. Unfortunately, by that time Western businesses were already modeled on the mass-producing factories pioneered by Henry Ford at the turn of the twentieth century. These factories claimed economy of scale as the way to make profit, and pioneered the “any colour, as long as it’s back” industrial mindset. This mindset has survived right up to the present day, as we see Western businesses “off-shoring” their back office or service functions to far-away countries in attempts to leverage “economies of scale”. What they don’t see when they do this, is that while the “cost per call” (the cost of each unit) may go down, the amount of errors — waste — and the resulting extra work — failure demand — that this approach generates, means their overall costs sky-rocket. Companies that study the type of demands they receive, and then restructure their organisation to meet those demands as quickly and cleanly as possible, completely remove this sort of failure. It’s a lesson that many companies are still a long way from learning.
Anyway — back to my story.
The next assumption was that all of the analysis of requirements should take place before development began. It was assumed here it was poor form to begin development work without a full picture of the requirements; that this was bad or insufficient planning.
Another assumption was that each team member should have a particular specialism, such as development (often further sub-divided into front-end development and back-end development); testing; commercial or financial analysis; product management; release management and — of course — design itself. The list of specialities went on and on. This of course relates closely to what I said earlier about not being encouraged to delve too far into development. In fact, this extended to all teams and roles; basically preventing individuals from venturing too far into a specialism other than their own. If you strayed too far into someone else’s role, you would soon realise just how protective each discipline was of their own specialism.
Finally, there was a widespread preconception that all requirements should be documented. This meant not only the immediate changes but every single requirement associated with a project. This was possibly caused by a nervousness that most project members seemed to share: a nervousness that any requirement — no matter how small or trivial — may be omitted from a report or a planning session. This anxiety supplanted any reasonable assumption that if a requirement was important enough, it would sooner or later have found its way back onto the backlog.
Once I had identified each of these core assumptions —and you can sense from my description, what I feel the impact was of each of them — I then asked myself, what should I do differently? To quote Mark Twain, “Whenever you find yourself on the side of the majority, it is time to pause and reflect.” So I asked myself here, what would happen if I were to do the opposite of all of the above for a week? Or a fortnight? Or even, more than a month? I began this experiment several months ago. I will now set out exactly what I chose to do differently.
1. I decided to not just tolerate changes to designs, but actively encourage them. I went out of my way to change the designs as frequently during development as possible. Also, I tried to change the contents of the work backlog frequently as well, meaning that various tasks the team had committed to at the start of the ‘sprint’ (each work iteration, that usually lasted two weeks) had become descoped by the end, and several other pieces of work were brought into scope much later during the sprint.
2. I immediately started going out of my way to amass as much technical knowledge about the product, the work carried out by my team, and all of the various processes conducted by the rest of my team. No longer would I sit out of team discussions, merely because they were “technical” and I was not. Equally, I threw myself into “coding katas” which took place on a regular basis between all of the developers in my department, and I enrolled in an online subscription service that offered coding tutorials.
3. In a bid to challenge the assumption that the teams doing the development work should NOT be the teams deciding what work should be done and in what order (as indicated by the organisation splitting each discipline up into separate teams), I temporarily removed the role I had of “decision maker” and “feature prioritiser”, and insisted that this responsibility now lay with the Developers. I reasoned that I could contribute to the decision-making process, but with two conditions: one — I would have no more say or influence than any other member of the team (possibly less, as I lacked their Development knowledge) and two — I would have to justify my contribution by taking part in development activity, as outlined in the step above.
4. I ceased treating all designs for the project as having to be concluded before development work began. Previously, I had imposed a deadline on myself: all analysis relating to a new feature had to be concluded before development of that feature began. During this period, I ceased to do that, so that I could now continue to research a feature after the development of it had begun.
5. I immediately ceased to believe that each team member had one single specialism. This meant that whereas before I would have treated myself as a subject matter expert in ‘analysis’, and my colleagues as relative experts in their fields of development and testing, I started to see us less as experts in these fixed fields, and more as team members who all had to work together. I started to take on work that was outside my specialism, and I encouraged those round me to participate in the creation of designs.
6. Finally, I stopped documenting requirements alongside designs to the extent that I had been doing beforehand. This applied to several areas: firstly, I drastically cut the length of the backlog, from hundreds of individual items to a list of half a dozen sprint-level goals. My reasoning there was that the team could only work so quickly, so as a result it would take them several months to work through a backlog that was half a dozen items long; any more than that would just be a waste, because by the time they had worked down the list to the remaining items, the business landscape would have changed anyway and alternative design needs would have emerged. Secondly, I reduced the amount of detail that I put on any one single ticket; this was because, I realised, the amount of detail I had been putting on the was previously wasted anyway, because not all the facts about the requirements were known, until the developers started working on it.
So what happened, during and immediately after my week-long experiment?
1. As a result of seeking changes to the backlog, I found that myself and the team became far more open to conversations with our business customers. Although the developers found it a little frustrating to often have the details of their work changed mid-way through, overall they did not find it that disruptive. However, the small downside that they experienced was largely nullified by the huge benefit experienced by the service team we supported: the increased amount of feedback they could give us, and the increased responsiveness that they experienced from us, as a result of being able to change requirements midway through, made this change well worth it.
2. After throwing myself into technical discussions and trying to absorb as much technical knowledge as possible, I soon found myself comfortable enough to contribute to and enjoy the technical discussions within the department. This became particularly obvious during the coding katas that happened fairly often within the department. Overall, my attitude changed as a result of this experiment: I began to see myself as less of an expert, and more of a student. Placing myself in meetings where I was the least experienced person by a considerable margin was frightening to my ego, especially at first, but hugely beneficial to my knowledge, and it taught me a lot in a short space of time.
3. The impact of this change was extremely interesting and I would like to study it more, and for longer periods. The first most noticeable effect of involving the team more in decisions, was that some did not like it, whilst others did to varying degrees. I realised quickly that people respond differently to responsibility, regardless of their so-called rank or status. Some people want a more active role in decision-making, whilst others would rather just follow orders. Overall though, when the team took greater responsibility for their own work the results were fascinating because generally the team’s morale, engagement and energy all went up. This may be evidence that any team regardless of industry will contribute a lot more energy and effort when you give them more responsibility.
4. No longer having to conclude analysis of a feature before it moved into development immediately had an impact on my personal workload within the team. This meant that immediately my workload went down, because I had longer to carry out the work. I continued to think about and talk about pieces of work, after the developers had started building the item in question. This led itself to holding far more conversations with the developers, and I found that the work became less fixed, and felt less like a series of fixed handovers and more like an ongoing conversation between myself, the developers and the service team that were our main internal customers.
5. After ceasing to view everyone as having one single specialism, I began to view myself as a student in every skill that the team practiced: these included front-end development; API development; unit test writing; acceptance test writing; manual user testing; release management; and customer research. As a result, my average experience level in all of these subjects went down and I began to see myself immediately as far more of a student. However my desire to learn new skills and my openness to being taught new practices rose far more than I expected.
6. Stopping documenting customer requirements to the extent that I had before, had an immediate effect on my workload: it went down, which was no surprise. I had expected my team-mates to experience this change negatively because they would now have less material to rely upon when developing tickets. However, in practice this was not felt as keenly by them as I’d expected. Although the developers did notice a difference, it didn’t have the level of effect I’d anticipated, which led me to conclude that the material being written on the tickets hadn’t been relied upon as much as I’d thought. Instead, the developers began to talk more: both to me, and to the service team who were our main customers. Rather than having to rely on a static document, they found they had to rely more on conversations with us, and this had a noticeable effect on the whole team dynamic. Like some of the other changes mentioned, it made the work feel more collaborative and less like the completion of a contract.
So overall, how would I categorise the effect of these changes? Well — I originally intended to run my experiment for a week, then two, then four, but as time went on I began to see less and less reason for going back to the way things had been done before. So how about now? And does this mean that I’ve abandoned all practices that I used to associate with user design? No, it doesn’t. Clearly there is a time and place for every approach, and I am the last person who would ever advocate completely abandoning all documentation. However, what the above experiment taught me is that the teams who experience the largest gains and work the best together, are those willing to expand their ideas about roles and responsibilities, and to become more flexible in the face of changing requirements. What I found was that the preconceptions I used to possess made my role more fixed and rigid, and that being a part of a team meant that my rigid attitude affected everyone else too. However, when I became more flexible and willing to experiment, the opposite happened: the entire team felt the positive benefit of my new, flexible approach.
I believe that my team, my customers and myself all benefited enormously from the experiments described here. So my advice to people who work in IT shops is this: be willing to experiment, and to expand the definition of how you view yourself within your team. Ask yourself, what are the rules and boundaries — particularly the unspoken ones — that you are imposing on yourself. Are they put there by other people? Or are they just imposed by you? Either way, I believe you will find — if you’re willing to step beyond those boundaries — that there is a huge amount to learn and to gain. Be willing and prepared to question everything that you do, on a frequent basis. You will be amazed at just how valuable asking yourself those questions will prove to be.