The expressions “Build the right thing” and “Build the thing right” are helpful in connecting practices with outcomes and expressing how the two ideas are complementary.
Sometimes I speak with people who are not seeing that shipping sooner and more often is a necessary part of building the right thing. For these occasions I thought it might be helpful to make this more explicit.
Sometimes I speak with people who are focussed more on one consideration than the others. Though complimentary, they also compete to some degree for attention and resource and need to be appropriate for the situation – it isn’t just about more of all three. This ternary variation of the yin-yang idea represents that there may be tension between these considerations and that they need to find a balance.
Thank you to everyone in LinkedIn’s Agile & Lean Software Development Forum who contributed to the discussion that helped shape the idea.
It turns out if you have no control over your work, you are far more likely to become stressed – and, crucially, depressed. Humans have an innate need to feel that what we are doing, day-to-day, is meaningful. When you are controlled, you can’t create meaning out of your work. (Hari, 2018)
According to Johann, 87% of people don’t like their work. Thats a awful lot of unhappy and disengaged people. For years now, I have advocated a way of working that I believe helps change what Johann describes as an “epidemic of meaningless work” e.g.
greater autonomy gives us more control over our work
an equal voice in our teams gives us a sense that we matter
teamwork creates connection between people
alignment with a wider mission adds to a sense of purpose
These changes have certainly made me feel a lot more positive about coming into work, and many of my colleagues feel the same. But in spite of all the benefits, it has been observed that the degree to which organisations are successful in adopting these practices can vary. The reasons for this and what to do about it are the subject of much discussion especially around culture, leadership and how these can change. Johann’s article suggests an underlying cause to people’s unhappiness at work…
In its official statement for World Health Day in 2017, the United Nations reviewed the best evidence and concluded that “the dominant biomedical narrative of depression” is based on “biased and selective use of research outcomes” that “must be abandoned”. We need to move from “focusing on ‘chemical imbalances’”, they said, to focusing more on “power imbalances”. (Hari, 2018)
We take if for granted, but almost all organisations are hierarchical. Unless you are at the very top of the pyramid, there is someone who has authority over you, the extent of which is determined by how much the organisation needs you and you need your job. How this plays out in our day to day experience of work depends greatly on how people exercise this power. Some people use their authority to coerce subordinates, whilst others find ways of doing the work that are mutually beneficial.
Dr Marshall Rosenberg, psychologist and creator of Nonviolent Communication, contrasts to these strategies as “power-over” people as opposed to “power-with” people. He observes that…
Power-Over leads to punishment and violence. Power-With leads to compassion and understanding and to learning motivated by a reverence for life, rather than fear, guilt, shame and anger. (Rosenberg, M)
He posits that central to having “power-with” people is the belief that we are ultimately more likely to get our own needs met, if we first understand and consider the needs of others. Empathy is being present with someone to hear and understand their needs. It creates trust and connection between people. Self-empathy is being present with and connected to our own needs. It enables us to remain centred and helps us to achieve good outcomes for the whole.
For example, I may have a need for our work to be conducted in a sustainable way, and an idea about how this could be improved in our team. As a member of a self-organising team, I don’t have the authority to mandate that the team just try my idea. My colleagues almost certainly have a need for their views to be considered and to shape ideas before they are able to really give them a go. Self empathy enables me to understand that I also have a need to be recognised for ‘my’ idea, and to reconcile this with there being a better outcome for us all, if we collaborate and make it ‘our’ idea.
All sound a bit too ‘warm and fuzzy’ for business? Microsoft CEO Satya Nadella clearly doesn’t think so. One of his first actions was to give a copy of Marshal Rosenberg’s book to each of his execs in his efforts to address the “toxic culture” that he inherited from his predecessors. (Abadi, 2018)
The way of working I described earlier seems to flourish where those with power have confidence that, given clear objectives and support, people will deliver without having to be directed and controlled. There are practical considerations e.g. as well as knowing how to give people clear objectives and effective support, it also requires appropriate feedback loops that signal to engaged stakeholders that we are all moving in the right direction. But these can be all be worked out.
The opportunity, for those who can see the value, is to learn how to practice “power-with” people. Maybe this is the key to slowly dissolving hierarchies and creating working environments in which people’s mental wellbeing doesn’t suffer. Few people are fortunate enough to find their calling. Even if we do not all love our work, I hope that it is possible for it to be a positive, satisfying activity that goes beyond meeting our need to provide for ourselves and our families.
Most people are unhappy at work. The more we are controlled, the less our need for meaning is met. There is a way of working that better meets this need, by giving people greater autonomy, however the level of adoption varies. Maybe this variability is to do with how people with authority exercise power at work. Some use their “power-over” people to get things done. Some are able to develop “power-with” people to co-create mutually beneficial outcomes. Nonviolent Communication (NVC) is a way of developing “power-with” people. Maybe focussing on this could increase our success in transforming organisations into happier and more productive places.
Image and quotes Courtesy of Guardian News & Media Ltd
In this post I pay tribute to the achievements of an extraordinary team and reflect on what our experience, years before Scrum, XP and the Agile Manifesto says about the state of Agile today…
Like many before it, this particular project had all the potential to be a disaster. In 1993 document driven waterfall was the default approach with Big Design Up Front and all the testing at the end. And yet it was a great success, delivering a suite of innovative application software, on time with amazing quality and to industry acclaim. So why did it succeed when so many were failing? What were we doing differently?
Back then, we didn’t have a team board or daily stand-ups. We sat together and would talk often about what we were doing, how it was going and if we were struggling. When necessary we would pair up to solve problems. We were all fanatical about C/C++ and Object Oriented Analysis & Design. Ideas were white-boarded as a team and we would take turns to study and present design patterns to each other.
There was no build or test automation. We were just one small team and would manually pull each other’s changes as soon as they were committed, incorporating them into our individual development and testing. SourceSafe didn’t support branches, forcing us all to work on the mainline/trunk. Consequently, bugs and broken builds were quickly spotted, communicated and fixed as a matter of pride (or shame!). We had no testers and in addition to testing each other’s code as we went, we would all test prior to a release.
We didn’t have a backlog or use User Stories. Thankfully we were able to collaborate directly with a first class domain expert and resident user of the tools we were creating. We could discuss and understand the requirements with the minimum of fuss and documentation. Our project plans were kept simple, mostly a hand sketched outline on one side of A4. Just sufficient to set our stakeholder’s expectations, but leaving us enough room for manoeuvre. Beneath this we took a prototyping approach, exploring technical risks and enabling our domain expert to validate new functionality quickly. Because of the team’s discipline and technical skill, these ‘prototypes’ were of shippable quality.
We didn’t have time-boxed iterations or retrospectives. If people thought of better ways of doing things we would discuss them. Every Friday we would have lunch at the local pub and reflect on our week and chat about whatever. People would be gently ‘ribbed’ for their screw-ups and we would celebrate our achievements.
We were not a self-organising team. We were directed by our Team Leader, an exceptional individual with considerable technical ability. This enabled him to assemble a highly competent team and provide a strong architectural vision. Technical excellence aside, he nurtured a culture of curiosity, commitment and openness. He led by example, sharing his knowledge and giving us courage that the task was achievable. Whilst doing much of the ‘heavy lifting’ he also shielded us from the nonsense surrounding the team, in what was a very mixed up organisation.
It was challenging work but this experience showed me that software development could be successful, satisfying and at times even fun. With hindsight, the key factors contributing to our success are clearly visible and familiar:
Customer collaboration enabling us to “build the right thing”
Engineering discipline and excellence enabling us to “build the thing right”
Incremental delivery enabling better risk management and stakeholder engagement
Great leadership nurturing a team culture of openness, collaboration and learning
So what can this experience tell us about the state of modern Agile? Out of curiosity, I tried to mark up Christopher Webb’s epic “Agile Landscape v3” (shown above) with the practices that I believe contributed to our success, and that we would have identified with at the time. The only one I could find, before giving up with a headache, was “Onsite Customer”. The behaviours described in my story, as well as the four key success factors, aren’t represented on ‘the landscape’ anywhere. I’m not saying we wouldn’t have benefited from many of the practices illustrated, just that we didn’t actually need any of them to find an effective and more agile way of working.
Over the years, the mind boggling proliferation of Agile methods and practices has prompted many to try and bring people’s attention back to simple principles and values. This reflection, on a team being agile long before it even had a name, underlines the importance of keeping sight of what truly matters.