I’ve been lucky enough to be brought up to Agile software development within a mature team made of seasoned developers. Later on, I had the opportunity to help kickstart five Agile development teams. Based on this experience, let me tell you how trust is both the fount and apex of agile.
First, you may need to build trust to move to Agile
If your company has never experienced agile software development before, just being allowed to try it may require some convincing.
Maybe management doesn’t trust IT to deliver anything of value and don’t want to risk letting go. Maybe procurement people feel that outsourcing a large project for a flat fee it the best way to mitigate overspending (oh gosh, they’re so wrong!). It’s very likely some of them have been fooled in the past by someone claiming they “are agile” or that they’re getting tired of agile-as-a-buzzword. Most of all have misconceptions about what agile is (such as “agile is good for very simple projects but you really need V-Model to deliver complex stuff”).
While breaking some delusions may be necessary (“Wasn’t project X’s budget extended by 40% by the end of the inception phase, before a single line of code was ever written? Why do we persist in believing project Y will meet the final deadline, when we’re already one year late on work package 1?”), it can be unnecessary cruel. After all, management put their neck on the line on this so that have to pretend they still believe the deadline can be met (their experience is probably that any result is obtained by sheer voluntarism and harsh management).
Also, it is pointless or even counterproductive if you cannot get them to trust you can do better. Doing this requires you to (i) articulate how agile practices lead to a positive outcome and (ii) prepare your teams for the technical (for instance, CI/CD) and non-technical skills they need to incrementally deliver value through ever-changing, always-working software.
Agile as a virtuous cycle for trust
Once you get past those first hurdles, then Agile (if done well) makes its magic and helps build trust between the Team and users and other stakeholders.
Many times, I have seen business people, that were previously puzzled by our persistence not to commit on any hard deadline before we even get started, now amazed to see actual, usable (yet, functionally limited) software at the end of Sprint 1, and then marveled at how software could be improved without regressions even with a large codebase, and how keeping a high standard on quality made it possible to achieve velocity.
Moreover, I discovered in my latest experiences how a sprint review was meant to be more than just a product demo, and how the team sharing in-depth about issues they faced lead to the kind of “intimacy” from which trust springs. You can be demanding, but (unless you’re an a..) you can’t whip the people with whom you have such a transparent relationship.
Frequent communication foster trust. In many instances, I have seen my directs having a better relationship than me with people throughout the organization, because they could afford to spend more time with them.
In a context where the relationship between Business and IT is often (alas!) not an equal-to-equal one, it is not always easy to balance this need for a direct line communication between business people and developers (the manifesto say “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Business people and developers must work together daily throughout the project.”) and the requirement that the dev team be self-organizing. With teams being geographically distributed, the scrum board has often gone to Jira, and even though I LOVE Jira, I have never seen a coffee break around a virtual scrum board.
What is it in Agile that builds trust?
I have already mentioned transparency as an intimacy inducer. But that’s only part of the recipe. Here are a few items I feel are of utmost importance.
(a.) The principle of self-organizing dev teams leads to better allocation of the decision power. By better, I mean that decisions are made by the right people, i.e. those who have the context and skills to make them. Business people drive the features roadmap and tech people make technical decisions.
Note the frontier can be blur and may require the team to stand up for their own expertise (for instance, I have seen three teams being lead by business people to design three different account creation and authentication workflows, none of which followed any UX best practices.. what a loss of time!).
Self-organized teams leads to highly-motivated people who show much better ownership of their product.
(b.) Quality. Focusing on working software and indefinitely sustainable pace means agile teams have high quality expectations. They tend to shift error left *in the development workflow. A developer won’t see a story that doesn’t verify the *definition of ready, a reviewer won’t review code that has failing tests, a tester won’t test unreviewed code, etc.
Velocity, again, is a by-product of quality. Not something that you try to compromise against quality. I knew our business people had reached a threshold in understanding Agile when, during a review, they mentioned that they didn’t want to team to overdeliver if it were at the expense of quality.
(c.) Risk mitigation. Agile teams focus on delivering working software. That means they’d rather deliver a *walking skeleton *(a fully integrated software that doesn’t do much) than a fully-developped front-end with no back-end.
Tough tech questions are faced and resolved (or changed upon) early on in the development process. Furthermore, the iterative and collaborative nature of the process allows for error correction, feature adjustment, prevents a single dev from getting stuck alone on a tech issue, etc. Business people get to decide every second week on what’ll be delivered next, leaving very few one-way doors to cross.
No one is smart enough to produce a detailed specification of a large software up-front. The iterative process also enables all stakeholders to focus and gather on small-size issues and features. This is why, in my opinion, Agile is particularly suited for large, complex projects.
Like love, trust is a decision
A humble manager will soon realize that, if they want to keep control of everything, they’ll end up with demotivated people delivering software that will last one year (at best) and then be only fit for the trash.
Unlike 20 years ago, it is now possible for tech teams to produce long-lasting, yet ever-changing, software assets, possibility for which Agile is a key enabler.
It all starts with a decision, to trust. I urge you to make it :)
Top comments (0)