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.
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.