Dev Mantras — A Team Charter Anti-Pattern

The content in this blog was originally presented at the Melbourne LAST 2019 Conference at Swinburne University in July.

I’ve always been an avid traveller and back in 2000 I travelled to Egypt on a group tour. While I have many great memories (and photos!) of the pyramids, the Valley of the Kings, Karnak and Abu Simbel, there is one particularly strong memory that’s got nothing to do with ancient monuments.

One of our group members was from America and I noticed that he often touched a bracelet on his wrist. This bracelet had four white square beads with a letter on each that spelt “WWJD”. Intrigued, I asked my fellow traveller what it meant and he replied that it stood for “What Would Jesus Do” and it reminded himself how to act whenever he found himself in a position where his principles might be challenged. Despite not being religious it struck me as a simple, but powerful way to remind oneself to behave and make the best decisions.

Roll forwards another 5 or so years, and I was lucky enough to find myself working in one of the first organisations in Australia to begin adoption of Agile. For someone used to working in a Waterfall manner, or at best using RUP (Rational Unified Process) it was a revelation. I found the Agile Manifesto a source of inspiration whether an event was related to software or not. The principles communicated by the manifesto reminded me strongly of that conversation about ‘WWJD’ all those years ago.

Since then I’ve had had many years working with agile teams at a variety of clients and employers across a diverse domains. And regardless of the framework being used I’ve also referred back to the agile manifesto for inspiration.

If you have run, or participated in an agile project kick off, you will know the value of giving your team that same inspiration; providing vision about what success is, and guidance on how they should make the best decisions to get there.

During an agile project kick off, many of you may have used team charters and project sliders, and have reviewed non functional requirements to gain a shared understanding of team behaviour in regards to working together and with others.

I’ve used team charters many times, but with reflection I feel that we are often parroting tripe statements that provide no real value or guidance. “Being Respectful” or “Listening to other team members” are hardly bold statements about how we should be behaving with our colleagues.

Many of you will have combined a Team Charter with Project sliders to communicate what’s important from a stakeholder perspective. While I agree that they are effective in capturing what factors are more important than others, they are not great tool for communication unless you can memorise the actual positions of the sliders. Even then, it’s hard to articulate when what this means and put it into action to manage the project. In my opinion the agile manifesto, with its opposing factors does a better job of guiding teams on what is important.

The last thing often tackled by a software development team is usually the non functional requirements (NFRs). While I’ve seen some teams successfully include non functional requirements as part of their user story acceptance criteria, they are often something that’s not given focus until the end. To make matters worse, NFRs are frequently huge documents running to tens or hundreds of pages in length — and often the only prioritised using MoSCoW (Must, Should, Could, Won’t). While the purpose of NFRs is to provide guidance on what’s important when designing and engineering your solution — when we are confronted by a tome of requirements it’s easy to lget lost and not understand what’s really important.

So faced with a team charter, project sliders, and non-functional requirements how is a team meant to understand what the key focus for their project, and how do we distill this down into a a few succinct passages, that can be used to guide out team, much like WWJD?

What if we could simplify all this down to three development mantras that describe the most important factors that influence the team, the project, and the engineering of the solution?

In this section I’ll talk about how the development mantras evolved while working with a new team on an Open Banking initiative for one of Australia’s largest enterprises. For those of you unfamiliar with Open Banking, it’s about your right to access data about your banking and to share that data with other, responsible parties. My colleague Mark Hume Cook does a great job of describing what it’s all about if you are interested.

This project was one of DigIO’s first engagements with the client, and to demonstrate our capability we needed to get results quickly. We’d also touted our experience delivering value using agile methods but the technologies being used were new to many in the team and also to the client. Industry requirements were still under review and interpretation differed across the banks — the only constant that we could expect over the next few months was change. Despite all of this, the high level non functional requirements were pretty clear — we needed to build a lightweight scalable solution that would be able to cope with tens if not hundreds of requests a second.

As a team, we needed to get runs on the board and demonstrate demonstrate that we had competency with the new technologies, so that the client was confident that they had made the right choice of partner. Keeping momentum was more important than getting the 100% right perfect answer or outcome, especially given changing requirements. Our Team Mantra became “Tempus Fugit” or “Time Flies”.

We tried to live this in everyday actions and ceremonies — at standup we encouraged team members to call out when they thought something had been stuck in a column too long. When we had outstanding questions that needed to be resolved we put them up on our “I Don’t Know” register and talked to them every standup to make sure that we where closeing out knowledge gaos quickly.

From an engineering perspective, we needed to build fast scalable APIs. We faced the challenge that we had a number of other systems that needed to integrate with us, and they all wanted us to include information that was unique to their use case. Since this information wasn’t necessarily even in the same back end systems, retrieving it could potentially slow down our response times. . We validated with the program architects whether speed was more important that serving the needs of every intergrated service. As a result our Engineering Mantra became “A Fast Concise service was more important than a slower more verbose one” . We repeated it to ourselves, and when asked to include additional information in our API we’d hold ourselves accountable for any increase in response times.

From a project delivery perspective, we were dealing with constant changes in industry requirements, and adjustments in our client interpretation of the them. In additition, there were teams that were still rolling onto the program, some of which were working in a waterfall manner. This meant that if we waited for things to settle down before starting work it would be months before we began building software. We needed to embrace a culture of change, and not get upset when we needed to update (or sometimes rewrite) code that we had developed earlier. One morning a team member was airing their frustrations about having to rework some code and their colleague responded “Rework is better than No Work”. This became our Project Mantra — something that we’d repeat to ourselves many times over the coming months.

This mantra drove a variety of different behaviours as it was no longer acceptable to wait for something to be finalised before we commenced work. We found ourselves having discussions with other teams and agreeing on , and implementing, APIs based off interface specifications discussed in Slack conversations rather than formal documents. We also took in work that wasn’t fully understood from a business perspective. As a result we gained a deeper understanding of how the software would work, and the actual business rules — and despite the overhead of rework we were actually getting things done at a faster rate than if we’d waited around.

These mantras became central to the way we approached much of what we did. We placed them on our team wall as a way to remind ourselves, and those we worked with, what we were all about. I can remember a time where a team member commented in a Scrum of Scrums that they couldn’t start work because the requirements weren’t ready, and a colleague from another team saying “What? I thought rework is better than no work?” — this was aone of many times that our Mantras were used by another team to hold us accountable for the way we worked.

Ultimately we found that our mantras helped us to make better decisions as a team, make give us guidance on whether we should take on new work, or even how we engineered the solution. It was no accident either that the thee mantras reinforced each other — making quick decisions, developing fast software and being comfortable with change work together to make us successful.

So the next time you are about to start a new team, I’d ask that you consider keeping it simple, and boiling it all down to a few mantras that can really be understood and acted upon by the team. After all, WWJD? ;-)