What you do next matters.

Agile platitudes to share

I was thinking about some agile platitudes that I like; some that I hate; and some that I hear without giving them any real thought.

My interest was piqued when I saw a comment on LinkedIn about “Being Agile rather than doing Agile”. The article asserts that the phrase is lazy thinking and I agree.

But I also know there are organisations that have forced agile practices on people – release trains, sprints, and stories, for example.

These organisations have done nothing more than cause people to rename their release plans, weekly reports, and requirements. They have made people do “agile things” without letting them actually think in an agile way, or “be agile”.

I started thinking about some of the condescending rubbish I hear and how some of it was once insightful. Or that is insightful in some contexts, yet meaningless in others.

I also wondered if there is a sh**ification effect that goes like this

  • Someone says something insightful and it makes others think
  • Others are impressed and share the comment because it makes sense to them
  • More people hear the comment and know others are impressed so they also share the comment
  • At some point, those sharing the comment fail to know why it is impressive but keep saying it. They hope it impresses others, but people basically sit there feeling like they should agree to be polite.
  • The people who originally had the insight continue to use the term. They understand the context of it. They find it a great shorthand way of encapsulating a bigger idea. But when people don’t have the context, they sit there nodding, without really listening or thinking about it.

Lets look at some specific platitudes that I have been pondering …

SEP fields and sinking boats

One of my pet hates is this. People know something needs doing, yet they ignore it because it is someone else’s problem.

This is the famous SEP field from the Hitchhikers’ Guide to the Galaxy. A book that contains many references to be referenced on agile projects..

Sometimes I fear that there are people would happily sit in a sinking boat; as long as they knew someone else would be blamed for not fixing the leaks.

So a saying I have used is

Everyone in the team is accountable for our success (yes and responsible too).

Then others will say

If everyone is accountable then nobody is accountable

But what do we mean?

I mean you should speak up and you should help regardless of what you job description is. Being proactive beats being right about your role.

  • But the same words could mean “we are all equal and we have the same expertise, skills and decision rights”.
  • Clearly if the code writer want to agree coding standards then they can ignore my opinions. If you are the sponsor who is accountable for the budget (or the PM or the owner) then you have final say in what we do or don’t add to scope.

But wait, there is more …

We are all on the one team

This is one I don’t say

We don’t have any silos here. We are all on the same team.

This might be insightful

An extension of all being accountable is that all our various tribes, departments, factions and divisions are on the same team. We all want happy customers and we all want to be rich. So it makes sense to have OKRs and old-school strategy maps and things.

We do NOT want finance, HR and engineering to pull in different directions or to compete negatively over budgets and kudos.

Siloed thinking has caused big issues and competing factions in an organisation often precedes calamity.

It is also lazy thinking though

We evolved as a communal species that collaborates exceptionally well in small groups.

So being in a squad/team/gaggle/swarm/murder/flock/family gives us a sense of identity and a way to make sense of our world. Of course we want to be part of the organisation but we naturally think in smaller terms.

Being in the same team/flock/pride/family/nest means we can collaborate as a team and support each other. We can set shared goals and we can understand each others work. We can then align with other groups.

So humans will naturally break into groups of 7, 25 and 125, plus or minus some number.

Trying to remove silos completely would just create a vacuum that people would fill by joining the coffee club, bubble tea bevy and boring lunch skippers.

There are many more platitudes to share than there are fish in the sea:

I only hire smarter people than me

We want good people to be unleashed

We want to hire people who “lead at all levels”. We want empowerment. But these things are not achieved by saying we want empowerment, they are achieved by empowering people.

So in a good team I want to ensure that everyone has a voice and that if I am the leader then I facilitate the joint power of the collision of everyone’s ideas.

But that does no come from telling people I want to hear their views, it comes from the collision of their ideas, the joint sense making and the agreed focus on action, all of which the leader is accountable for, but powerless to enforce.

In fact even the assumption that people are waiting for me to empower them and that I have the right to un-empower them seems a dodgy if you think about it long enough.

Maybe, just maybe, I am too pedantic here

When I hear someone say they only want to hire smarter people than themselves in their team, I imagine they think I hear them say that they want to work with awesome people and let them thrive rather than hold them back.

But my literal interpretation is this – if you keep hiring smarter people than you, like Captain Kirk hiring Spock, and you keep being the boss, like Captain Kirk returning for a new series, then at some point you are getting in the way.

If you end up being the dumbest person in the team and simultaneously you are the most senior, most highly paid person, then the logical step for the Spocks in the team to take is to sack you. Then they can let a smarter person take over and they can all move up in the world.

You can head off to a team of dumber people and start sacking them as you replace them with smarter people. But eventually you will end up in a quandary.

If you want to be the dumbest person in the room it makes logical sense that you should also be happy to be the lowest paid. And if you are the dumbest person in the team I suspect you are not the right one to identify the intelligence needed in smarter people and differentiate between them.

This seems quite different to what I imagine the boss means, which is that they want to continue to have a good salary while leading excellent people by coaching and backing them.

So where does that leave us?

Applying this to the real world

I had fun writing this article and I am humbled by the opportunity to share my thinking so you can take it on if you want.

But actually I am not that humble and I wrote this for fun, regardless of your approval.

If you don’t approve them I will not be humbled, I will just lazily think “you can’t please all the people all the time”, safe in the knowledge that Steve Jobs rejected the idea of the iphone when he first heard it (really?) and the are no foolish opinions, just different perspectives.

But being comfortable with my grasp of platitudes won’t change the world.

So lets look at how we can choose between platitudes and authentic conversations in a real world (ish) situation.

Lets assume there is a designer who wants to do great design work but faces multiple clashing priorities.

I won’t reveal that her name is Veronika because she would be embarrassed. But I will reveal that she is passionate about what she does and always holds herself to a high standard. Doing bad work causes her stress and doing good work gives her energy.

One day, hypothetically, this designer needs to work on the designs for some awesome potential value, but she is not sure of the scope and there are multiple teams already rushing to deliver.

She worries that people are not aligned and that she will either rush work, deliver less than the best she can or have to do rework in a rush when we finally see the gaps.

You and I are talking to her when voices a desire to do something to make things better. Should we say:

  • Look inside for the answer lies within;
  • Lets leave the decision on what the design should be to the last responsible moment;
  • We are a safe to fail team so don’t worry, it will be a learning experience and not a failure if they designs turn out to be an embarrassing disaster of epic proportions; or
  • That sucks, what do you want to do about it?

Let’s go with replying with “that sucks …”.

The unnamed designer says she wants to call key people into a workshop even though she is not sure it is her role.

She wants to run through what she believes are the steps needed to clarify the goal and next steps. If she can do that she wants to do a customer journey, which is a design thing.

Should we say:

  • That is called sprint 0 and it is a scrum thing and though Scrum is not the same thing as agile, it is also an agile concept. Thus I endorse this behaviour:
  • If everyone is accountable then nobody is, so don’t run a workshop until you scan the environment for likely Rascils to be responsible and accountable to run it for you; or
  • Don’t ask me. I only work with people smarter than I am, so you should get them to use the wisdom of the crowd to use emergent discovery which will uncover the core value proposition and then you can start with the customer; or
  • Good idea, can I help you list who we think should come and then I can come along and eat any snacks you have in the meeting.

I would go with “Good idea…”.

Of course I would validate that the snacks are worthwhile before turning up.

I might also suggest checking with key people before the workshop to avoid duplicating what has already been done and making sure we get buy-in.

Platitudes are fun but real conversations lead to real action. And real action is what leads to really good outcomes.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.