Agile transformations to make stakeholders "happy" reduces trust
Organizational culture is moulded by many forces, often conflicting in nature or incentives. Recognize there is no perfect "stillness". You will only find success in learning how to balance them.
🔐 This is a preview from my next booklet that is free for your viewing pleasure during TDD February. Afterwards paid subscribers will continue to have access to this as one of their benefits.
Stakeholder trust
All transformations start with someone looking for a problem. Transformation isn’t entirely organic. Not in a business at least. There’s always an enthusiastic person who drives the initiative.
Engineering culture is the opposite. Especially in smaller and younger businesses with less than 100 engineers. Culture is shaped completely organically.
Organic processes that define culture are without fail driven by stakeholder trust.
What makes a good stakeholder?
ability to make business decisions
accountable for final outcomes of a project or product1
understands the business domain and is able to share it with the engineering teams
Not all stakeholders are the same. Sometimes there’s more than one. At different times a stakeholder role may be split up between several people.
Engineers who make technical decisions need to be in a fast feedback loop with the stakeholders who make business decisions.
Ultimately you want someone who has full accountability that is also willing to ask for help and share responsibilities. If you don’t know who that is within your company—it might be you.
Default culture
Imagine an organisation with very few formal engineering disciplines. Code reviews, standup meetings, some shape of scrum. Planning sessions, roadmaps. Architecture diagrams in miro.
I know you. I work with you. Your form of organization are my most amazing clients.
Think about it. What an average CTO or engineering manager would consider good practice is actually slowing the team down:
code reviews for merges
pull requests
standup meetings
sprint planning and estimation.
They’re busy-ness optimising activities. They slow things down. Why are they there?
Because: These processes are your backbone for stakeholder trust.
They give:
Visibility
Guarantees
Split up work into moveable, plannable pieces
Accountability
Confidence
Tread with care, have a plan
If you’re about to push for extreme programming, TDD, pairing, continuous delivery2, all the power to you. I will help you. But understand this: you are improving and replacing an old process that may be inefficient but is very good at maintaining stakeholder trust.
So the baseline for improvement is not “Is <TDD> helping us be more efficient, deliver faster, better?”
The baseline for measuring improvement is:
“Did introducing TDD help us improve our business capabilities without eroding stakeholder trust?”
This is where most process improvements fails and fail again. Integrate stakeholder trust into your initiative by being transparent about what it is you are doing. What works. What doesn’t. What’s your plan of attack?
Your efforts to improve the way you think and work in software deserve their own roadmap. More so than your project.
1 Planning Extreme Programming; Fowler, Beck