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.
Feedback is immensely helpful for our individual growth and team performance. And yet giving feedback can be a challenge. How can we make it more likely that our feedback will be well received and have a positive outcome?
Being able to give and receive feedback creates a huge opportunity for us, and yet for many people even the term “feedback” is loaded with negativity. Lets see if we can find some better ideas and words to help us with this important skill.
Psychologist Marshall B. Rosenberg, creator of Nonviolent Communication (or NVC) proposed that when we communicate, we are really only saying one of two things: “Thank you” or “Please”. In other words we are either expressing gratitude or making a request. How could this idea help us with giving feedback?
“All people ever say is THANK YOU (a celebration of life) and PLEASE (an opportunity to make life more wonderful)” Marshall B. Rosenberg PhD.
Thinking of “positive feedback” as giving thanks and “negative feedback” as a request to behave in a different way, gives feedback new meaning and opens up a new vocabulary. A compassionate request providing an actionable alternative way of being has the potential to be far more valuable to someone than simply pointing out their limitations!
Say Thank You often
Expressing appreciation isn’t difficult. It is just a case of being clear about what it is someone is doing and why this is helpful. Here is one simple way of achieving this:
Developing a sense of gratitude is good for us, mentally and even physically. Sharing appreciations publicly not only celebrates our colleagues. It encourages others to do likewise and helps to create an open feedback culture within the team.
Asking someone to behave differently takes more care, however it needn’t be that difficult either. NVC gives us a more positive way to frame our requests that is more likely to receive a compassionate response from the recipient. Consider the following example expressed in a form inspired by the NVC request:
Lets examine the request a little more closely by breaking down each part:
I am noticing…
Jane identifies her teammate’s behaviour i.e. interrupting Pauline and Sunil and gives examples of when this occurs e.g. in their planning and design meetings. These observations are expressed in a way that is without judgement or diagnosis, while the examples provide clarity.
Starting with observations of just what the person is saying and doing is important. Often we form an opinion of someone, but when we try to identify the actual behaviours that led us to this diagnosis, they prove elusive. If you find you are struggling to identify the person’s behaviours i.e. just what they are saying and doing, then maybe you need to wait, observe more closely and reevaluate the basis for your request.
The greatest benefit comes from identifying repeated behaviours that are having the most significant and detrimental impact on the individual and or the team.
This makes me feel…
In the example, Jane is feeling frustrated and anxious because her need for respect and equality for others isn’t being met by her teammate’s behaviour. In this situation, by expressing her emotions and her underlying unmet need, she is more likely to elicit a compassionate response from the recipient. This inventory of feelings shows the full range of emotions that we may experience. Thankfully in professional situations the range is more limited making them easier to identify and express.
The ability to identify and communicate our feelings and emotions is an important life skill. Our feelings point us to the unmet need that is driving them. This knowledge gives us an opportunity to find strategies for getting our needs met that are not in conflict with other people’s strategies for meeting their own needs.
A common misinterpretation is to say something like “This makes me feel… like you do not care about the work“. Note that this isn’t expressing an emotion. It is actually making a judgement about what you think the other person is thinking! If you find yourself doing this, reflect for a moment on the emotions you are feeling, not what you are thinking. This will help you to identify the need that is not being met by the recipient’s behaviours. Just as with feelings, humans have share many needs. Here is an inventory of needs that may help you identify your own in a particular situation.
From now on, it would really help…
Finally, Jane asks her teammate if they would let Pauline and Sunil explain their ideas fully their design meetings. This would meet her need for respect and equality. The request is expressed as something the recipient can actually do, as opposed to asking someone not to do something. This is clearer for the recipient and reduces the possibility that the request will be met with a defensive reaction.
Equipping ourselves with the tools to be able to give feedback is the first step. The form described above is inspired by the NVC process. Another approach similar to NVC, is the Feedback Wrap from Jurgen Appelo’s Management 3.0.
Whichever you prefer, both help us to say the things that need to be said. As long as we say it from the heart, with good intention towards the recipient and the team, we won’t go far wrong.
I’ll leave you with Dr Rosenberg talking at an NVC workshop…
The examples shown above are taken from TeamSense, a fairer way for team members to exchange frequent meaningful feedback.
I have a lot of empathy for HR people these days. They have many difficult challenges but it seems only one, blunt instrument with which to tackle them all. The Performance Appraisal is required to provide answers to an array of gnarly questions e.g.
How much should people get paid?
Who gets promoted and who gets fired?
How do we tell people they need to improve?
The trouble is that Performance Appraisals really aren’t very good at determining any of these things. As anyone who has participated in one will know, they are time consuming and happen too infrequently for goals to be meaningful or for people to learn from the feedback they receive.
Other problems are well understood. Feedback is given by only one person who, being human is prone to bias. The feedback flows in one direction only i.e. ‘downwards’ from someone who is in a position of authority. This is hardly conducive to the kind of conversations that might help people to introspect and grow.
Leaving aside personalities and competence, sometimes there isn’t always sufficient trust for people to be candid about their shortcomings with the person who ultimately controls their career. It also creates an enormous challenge for review managers, who often feel uncomfortable with the arrangement and who would appreciate candid feedback themselves.
Finally, Performance Appraisals are especially damaging for Agile teams, where collaboration is highly valued and easily undermined. Some Agilists have even suggested that people refuse to participate in Performance Appraisals altogether. No wonder everyone, including HR, find the whole exercise frustrating and demoralising.
15 years ago, I was attracted to Agile because it empowered people challenge ineffective and wasteful practices. Surely there is a better way? Something that is inclusive, frequent and fairer to all concerned.
360 feedback to the rescue?
These too are heavy, costly and mostly reserved for those considered to have the greatest potential. Subjects are often able to ‘game’ the process by selecting who rates their performance. Finally participants don’t get to see the feedback directly, receiving a filtered version which has been “assessed” by a “superior”.
360 peer reviews feel like a step in the right direction but ultimately suffer from the same problems as regular Performance Appraisals i.e. they are too infrequent, not inclusive and can be gamed. Not much help for an Agile team.
HR meet Agile, Agile this is HR
Thankfully, there is now a growing recognition that the traditional approach to Performance Management (TPM) doesn’t work and overall, does more harm than anything else. TPM enforces hierarchical culture.
Not surprising then that the drive towards increased business agility has created a movement away from TPM to something that embodies the progressive values of modern organisations, such as respect, autonomy and engagement. That something is called AgileHR and more specifically… Agile Performance Management (APM).
When it comes to pay, we begin by acknowledging the ideas popularised by Dan Pink about motivation. Pay people enough to take the issue of money “off the table” and whatever profit sharing we do is carefully considered to incentivise teams and collaborative working. One example of an alternative reward system is Happy Melly’s Merit Money. There is still lots of work still to be done in this area, but at least it is starting from a better understanding of how people behave.
Next, let’s consider Agile for a moment. Fast feedback through customer collaboration enables teams to be given more autonomy, self-organising around clear customer objectives. In this setting teams are held to account for their performance and develop greater trust with their customers and stakeholders.
The greater transparency and accountability of Agile changes the game. It creates the possibility that teams can now be responsible for their own performance management. The team just needs a practical way to be able to accept this responsibility.
Enabling performance self-management
So how does this happen? A good place to start is by establishing team agreements that give the team ownership of their Performance Management process. This includes the ability to inspect and adapt it to their needs as necessary. They discuss and agree the competencies that are important to them as a team, the cadence of the feedback and the face-to-face interactions they will have at the end of each review cycle.
Assurances need to be provided around confidentiality and anonymity so that people are able to be candid and give meaningful feedback. Team members are also given full control of the feedback they have been given. This enables them to have confidence that no one else can see their feedback without their knowledge and prior agreement.We provide appropriate coaching support to help team members act on the feedback they receive, and also for the team to call for help if it has a problem it cannot resolve.
Enabling the continuous exchange of feedback between everyone in the team creates a lot of feedback, so we need be really smart about how it is gathered.
The first part is for team members to give competency ratings. Relative rating is light and fast, providing context for the supporting verbal feedback. Because everyone is exchanging ratings, the wisdom of the crowd helps to eliminate individual bias.
Carefully formulated commendations and recommendations recognise great competency behaviours and suggest ways in which people can improve. Capturing this feedback throughout the review period, when behaviours are observed and relevant makes it more meaningful and less onerous.
Appropriate visualisations provide a way into face-to-face coaching conversations that develop an individual team member’s competencies and those of the whole team. The nature of these conversations having been agreed by the team up-front.
The traditional approach to Performance Management is ineffective and a poor fit for Agile teams. Sadly, 360 peer reviews aren’t much help either.
An Agile approach to Performance Management is one that is aligned with the principles of respecting people, fast feedback and learning. It would be inclusive, frequent and treat everyone equally. With appropriate support, it is possible to remove the need to have any one person responsible for Performance Management, eliminating a further impediment to team self-organisation.
TeamSense makes the frequent exchange of meaningful feedback between team members viable. Individual and team competencies are made visible and provide a way into conversations that drive improvement. It enables Agile teams to take responsibility for their own Performance Management.
When I saw this meme, I just had to laugh. Then it got me thinking about how wrong this picture really is…
It is a total fallacy to suggest that there isn’t any planning (or plan) with Agile development or that Agile results in poor quality.
If anything, there is more planning with Agile development than with traditional “plan driven” projects. It may not seem like it, because planning is a continuous activity happening as the work progresses. The “plan” itself is expressed in a very different form i.e. as an ordered list of work items that can be continuously re-prioritised by the business, to deliver the higher value items sooner. This kind of plan supports better commercial decisions. It is clearer to everyone where we are now and better at forecasting how long it will take/cost for further items to be delivered.
Unlike traditional “plan driven” projects, Agile development is all about quality. Quality becomes the responsibility of the whole team, who work to a robust Definition of Done. This ensures that each item of work isn’t considered complete until it is of serviceable quality. The steady release of functionality to the customer not only delivers value to them sooner, it provides fast feedback making it easier to manage risk, especially those around getting the product increments into live.
Agile avoids the situation alluded to in the picture through highly discipled engineering practices such as Refactoring, where the internal structure of the system is continuously improved with the support of automated testing.
Agile does a better job at managing risk and stakeholder expectations, leading to better outcomes.
If absolutely necessary, Agile practitioners will compromise on scope, but never quality. With traditional “plan driven” projects the quality is compromised because the quality assurance happens at the end, where it gets squeezed by the inevitable and unforeseeable problems that will emerge.
In my experience, projects that begin with a long up-front planning/design phase still ended up with software that looked like the wires in that picture. This happened because when the plan/requirements/design/architecture were established up-front, it was impossible to know what was really needed and what the best technical solution would be. By the time anything got delivered, it was late, of poor quality and didn’t do what the customer had now discovered they really wanted.
The Agile approach enables planning that is far better at dealing with the emergent nature of software product development. Planning is continuous and quality is key. It is highly disciplined and difficult. It isn’t often you see it being done well, so maybe people can be forgiven for misunderstanding what Agile is really all about.
We all want to be able to do a good job and get paid, but what else is important to us? Is there any value in sharing this with each other? I discovered that talking about this together had a surprising benefit.
A while ago I learned how helpful it can be for teammates to take a little time out to discuss what really matters to them, as individuals and as a team. We all want to be able to do a good job and get paid, but what else is important to us? Is there any value in sharing this with each other? I discovered that talking about this together had a surprising benefit. Recognising common values led to a greater sense of connectedness within the team. Recognising values which were not commonly held, and were causing frustration for some team members, led to greater understanding and empathy. The simple list produced from that discussion became our Team Values and marked the beginning of the team’s journey towards self-awareness and greatly enhanced performance.
Bringing everyone to a common understanding of what a particular competency means is the first step in enabling the continuous exchange of meaningful feedback within the team.
Since then, I have applied this learning to discussing the competencies that matter to the team. To help this discussion I like to use the cards (shown above). Each one has the competency name and a brief description on the front and some example behaviours on the back. Teammates can pass them around, talk about their relevance to the team and ultimately vote or in some other way select the ones they think most important. In addition there should be some blank cards, to allow the team to come up with their own competencies as they wish.
We go on to establish team agreements around the other aspects of our competency feedback process e.g. cadence, conversations and inspection point, however I believe the discussion around competencies is of value in its own right.
You can find out more about establishing team agreements for Performance Management and get the template for the cards here.