An #Agile Self Check

We’re in the middle of a design sprint for Psychological Safety Works that will likely -and “hopefully”- result in what we call “a DUH feature”. It will be a reminder for the team leader to do what they need to, so their team stays on track in terms of Psychological Safety. 

In this case, it’s an intensely simple feature that we are building as users of our Team Lead dashboard asked for it - a list of interactions they should have with each team member and notifications to accompany it. Being that it’s so very basic, it brings out all kinds of major themes. 

We get to think -again! - How lucky are we that we get to do exclusively that whereas most people struggle to remember they should- of heavy concepts such as “What is a team really?”; “How much humanity and focus on emotions are there to be had inefficient leadership?”; “If some actions a lead has to take are common sense and integral part of human interactions why don’t they come naturally and why do they need reminding?”

As a product owner I have other considerations even during the design process in terms of the full backlog (and we’re a young start-up, our dev and implementation are so cross-departmental it hurts!) and the eternal internal conflict between wanting to make an intensely simple, clear and easy to use feature while knowing that will be hard to defend sales-wise to non-users in this world that expects complicated and magic and to protect from the copy-cats scratching at the gates, but ultimately, I have to count breaths, I have to lead from behind and those considerations have to pale to allow the design process to take over and for my super talented team to do their thing unencumbered.

At PeopleNotTech we have a harder task than most other software making houses as we’re flying blind in completely uncharted skies (is that a thing?). 

In most other enterprises, to be agile and get anywhere, you "just" have to obsessively listen to the customer and execute. We don’t have the luxury to do so unquestioningly, as we’re educating and guiding the customer with the work tool we've created as it emerges hot off the press. There’s no best practice in terms of software that helps humans work together in a psychologically safe way, or of solutions that have been integrated to augment a team’s day-to-day performance, so we have no established existent people practice that we simply better or refine, but instead, we are building the need and acceptance of it at the same time. 

When you make inroads in new ways of work and help new mindsets and practices that are on the cutting edge themselves, you’re testing academic hypothesis and common sense and ultimately continuously learning at the same time that you teach. It’s a unique position we’re in, and we’re very lucky but at the same time, it requires even more flexibility and endurance from our own team than most others.

And there we have our dog food. We design mostly for DevOps teams and we are as agile, as straight-to-live and as cross-functional as they come. We design mostly for teams that have a degree of working remotely and we’re all remote ourselves. We preach continuous learning and flexibility and courage while ensuring the team has psychological safety and we get to test that every day in our own backyard as we build these things.

It’s definitely hard at times but it’s beautifully meta and it’s absolutely fascinating and it keeps us all growing. If nothing else, this design sprint will leave us with candidates for New Year’s Eve resolutions - both as individuals and leads and as a team so that’s a win right there as the year is drawing to a close and we'll get some days to relax (and finish reading The Unicorn Project!).

So consider this post a joint moan and gratitude piece this week and tell me what keeps you grounded in the unpleasant task of deep thinking and how long since your last #Agile self-check in the comments, please.

May your design sprints be uncomfortable and your features be DUH!