September 3rd, 2021
In the spirit of transparency and candour, Kevin and Jill publish weeknotes reflecting on the what and why for their team.
Kevin’s Notes
This… was a tough week for a few reasons. First, the existential angst of summer’s end crept upon me, as with school firing up again next week, my free time will be reduced to approximately zero. Second, I was proper fatigued from a casual 20-hour stroll in the woods last weekend, and this type of physical drain tends to affect my mental stamina as well, manifesting as a low-grade languor with a hint of depression. And finally, it was just a plain hard week at work, not for any actual cognitive labour, but rather challenging discoveries, associated reality checks, and an emergent knowledge of the hard roads ahead to get meta-projects to where they need to be.
How to break this down. Disclaimer: I’m going to be vague and dance around around things. We strive for transparency in this forum, but due to the sensitive nature of the work, we can’t spill all the beans (unfortunately — only my personal journal receives that level of candour).
Intuition does not say what things mean but sniffs out their possibilities. Meaning is given by thinking — Carl Jung
So we’ve hit an inflection point in a major initiative. The signs have been there for a long time (Jill will speak more to these patterns), but we failed to act decisively at a few critical junctures. As I conduct my real-time retrospective, one prominent theme throughout this process is the quieting of my intuition and going against its signals. Experience (in my case, over a decade of digital projects, in all types of roles) tends to provide one with a set of heuristics for quick reference. This works well, this doesn’t, do X in Y situation, etc. To expand on Jung, you receive the conscious ping born of repetition, but it requires further clear-eyed analysis and synthesis to determine appropriate outputs and actions.
Our problematic current state in the project was avoidable if we’d listened to our intuition early on, even though it would have necessitated hard conversation, disruption, delay, and churn. But instead, we accepted the positive narratives conveyed and trusted the parties involved to execute on their accountabilities. And we let this accrete over time, gaining momentum and becoming increasingly difficult to course-correct.
We’ll have plenty more to say on this matter in the weeks and months to come. Oh, the joys of having committed ourselves to these weekly reflections.
Other stuff:
- Harry starts Tuesday, our new service designer! Harry’s skill set is as wide as it is deep, and I’m thrilled to have him bring his passion for civic design to the ministry.
- I met with some folks from the OCIO to discuss V2 of the BC Government’s digital framework. I’m honoured to provide thoughts through the systemic design lens and hope to continue contributing to this critical piece of work.
- We finally issued the SOW for the EPD design research scope! Looking forward to reviewing the vendor responses.
- And finally, I spent a very limited amount of time working through ideas for CAS reporting design approaches. I’ll need to block more free space to refine these initial sketches for structure and coherence.
Long weekend, cleanse my soul. I hope everyone enjoys some downtime in this transition to September.
Jill’s Notes
Trust is a dangerous thing. I routinely attempt to lead with trust and create space where teams feel like they can take risks, try new things, and use their best judgment to solve problems. Loosely quoted from one of our senior leaders — no on likes exec-u-techture — aka when a non-technical leader tries to architect your system. So I stay out of the weeds — or attempt to.
My strategy as leader hinges on structuring high-performing teams, removing bureaucratic barriers and asking plain language questions. I trust my gut and experience to evaluate the responses (ditto to what Kevin said above re: intuition). That strategy only works if you have clarity on how the team is working and you trust the answers are presented with enough skill to be truthful. I wouldn’t ask an electrician for medical advice, but if the electrician was wearing a white coat and standing in the hospital, how do I tell them apart? That’s kind of how I felt.
This week resulted in some serious reflection on that management strategy. So rather than highlight our first 6-months of success as a branch — let’s hold that. There are hours and hours of reading on how to avoid agile anti-patterns—lots of opinions, many helpful tips and some garbage (I particularly like this from NetSolutions).
Antipatterns are common solutions to common problems where the solution is ineffective and may result in undesired consequences. An antipattern is different from bad practice when:
1- It is a common practice that initially looks like an appropriate solution but ends up having bad consequences that outweigh any benefits
2- There’s another solution that is known, repeatable, and effective.
I’ll pick on three practices that are top of mind — and yes, each could be a full-on essay of which I’m not the expert that should author:
1. Miscommunication — or a straight-up lack of it.
individuals and interactions over processes and tools
— agile manifesto
This has certainly gotten harder in our digital not-collocated environment. I cringe when I see a long back and forth thread on a Teams channel. That issue could have been solved in a 30-second call, and after 10 minutes, there are still three versions and interpretations of the story (hence why 2. is listed below). A high-performing team will hop on the “bridge” or video call, as my former Mines Digital Services team likes to call it. There is no hesitancy to put their heads together and solve a problem quickly. They trust each other.
As a leader in this digital world, it’s hard to see if teammates are working well together, even talking, much less pair or mob programming. Without the face-to-face banter or even the unstructured discussions, coffees, or lunches, it can be hard to build any sense of accountability or shared responsibility as a team. That makes it so incredibly important to add structure to meetings and ceremonies. It also relies on strong leadership internally and ensuring teams and product owners have strong mentors and coaches. We must set them up to succeed. I’ll own that we didn’t do that well.
2. No shared understanding of scope — and its changes
I witnessed individuals — I’m deliberately not using the word team — interpreting scope in vastly different ways at month 7 of a 7-month project. Wow. The scope is not fixed in an agile project (remember the picture below?).
But the interpretation of the scope by the team needs to be shared. It needs clear acceptance criteria that everyone understands. A lot of this is technical. I’ve certainly learned that technically there is always a quick way and a right way. Sometimes quick is right, sometimes it isn’t, and I simply don’t know which is which. With this, we go back to trust. Challenge the team to answer the question, “if this is a higher priority, what are we leaving off?”. Watch if it’s always the same person answering. Invite the others to validate, discuss, and counter. Don’t give up until you get the answer. There are no scenarios where the answer is “nothing” — meaning no impact on resources, time or quality. “Nothing” should be your red flag that there is a lack of clarity or understanding of the scope shift. Any team running at a sustainable pace will feel an impact to a change in scope.
Lastly, that lack of understanding can lead to gold-plating. We certainly saw this recently. When you have different opinions, when you don’t increment, and when you have team members and subject matter experts who have comfort zones, you build what you know. We all fall into this trap. When you are really good at something or know it really well, it’s hard to do the things you aren’t good at or see other perspectives or needs. I often remind my product owners to take off their hats and remember who is in their backpacks. Meaning, who are you building for, what other personas — those in your backpack — and what personal bias are you taking out of the equation when considering value — by removing your hat. Instead, you do the thing you like or know, and you nail it! But did you need it to be that robust, that detailed or focused on those two users? And what was the cost to the product?
3. Deferral of risk until right at the end
A big part of incremental delivery, or why I gravitate to it, is tackling some of the more risky pieces first. You’ll hear things like “end-to-end” or “get it into production early.” I read that as eat the risky stuff early, so you have a better idea of what you have left. In government, that might mean getting the Privacy Impact Assessment started on day one — or engaging the OCIO early on security — and it certainly means getting your application up, hosted, and pushing code in all relevant environments. More of the value now and less of the risk later.
Again I’ll take us back to trust. A team can always demo locally, hide the real issues, and push out the risky stuff. In many cases, we own a share of responsibility corporately for creating processes that can be challenging to navigate for new team members. But it ultimately comes down to asking those questions and pushing hard to understand the answers.
When we end up at the end of a project with all risks on the table and a “big bang” release as the only option, I can’t help but feel like I failed. I’ll always remember the line from a pseudo released reflection report on a large failed IT project:
One that is worth stating upfront is that the programme had many talented, passionate, well-intentioned people working in it,both as public servants and contractors.
This is certainly the case here, and we are not in “failure” territory, a more uncomfortable reality ripe with learning. I’ll choose to take it as such. In this case, the team was not greater than the sum of its parts. But the parts shouldn’t be thrown out.
Week in sum
In terms of the rest of the week. Well, I feel like that was most of it. Getting ready for the Deputies to return next week, preparing briefs and notes to answer those impending “I’ve been thinking” questions we all know will come after a full month of reflection by our leaders. A much-needed long weekend ahead of what will be a multi-month push. Send good thoughts and bright ideas. I’ll need them.
