Passion, care and the Agile Manifesto is really all you need.

As I sat with a professional services team at my client, launching into my tried and tested description of what agility means and how to do it sustainably, the last 11 years of my life flashed in front of me and I saw something that I hadn’t realised before. It both scare and energised me.

My typical approach to this particular exercise is to begin by introducing my audience to the Agile Manifesto – the spark of the movement. I remember to use that word – ‘movement’ because I truly believe this is what those who truly do agile software development are part of.

Then I pretty quickly move on to processes (or process frameworks) – the ‘how’. I do this partly because I assume that is what folks want to hear – “enough of this happy clappy, pie-in-the-sky bollocks. Show us the meetings, the artefacts and stuff we can put on our CVs”.

I also do it because I hadn’t really stopped long enough to consume the manifesto, to meditate deeply on it. And that might be because I wasn’t ready.

Well now I am.

As I wrote the 4 value statements on the whiteboard, time stopped. For context, here is the Manifesto for Agile Software Development:

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

What actually triggered this epiphany was a simple question:

What would it take to fully understand each of those value statements deeply and live them deliberately – every day and in every facet of your team or organisation?

If you imagine a journey to increased agility was a 12 step program where you couldn’t proceed to the next step without satisfactorily completing  the preceding step,  then seeking to seriously answer that question would be steps 1 – 11 and mostly like a ‘formal’ process or framework like Scrum or SAFe would not even feature.

Don’t be fooled – this stuff is complex. Take an even modest attempt at going a little deeper into the first value statement – ‘ Individuals and interactions over processes and tools’ – :

  • Who are the individuals, what are the interactions? How do we know they are the right ones?
  • What personal and professional skills and competencies does each individual need in order to participate meaningfully in these interactions? How do they acquire and develop them?
  • What conditions sustain meaningfully interactions, how we create and maintain them?
  • How do we continuously sense that the interactions are not yielding what they are intended to yield? What do we do when that happens?

This is not a remotely exhaustive list, but they are considerable questions. In my mind, these are not ask-once-and-forget questions, they are to be asked and answered regularly.

There is even an earlier starting point.  Do we have the skills to ask the right questions?
Tools like powerful questions, clean language might be useful places to look to gain those skills. I have met far more people who suck at asking the most effective questions than not.

Now I’m not saying don’t do Scrum or use Kanban or XP or whatever the flavour of the month is. But it is very possible that you might do those and not enjoy the agility you seek, worse still you may get lost in process and without a solid understanding of these fundamental first principles you will struggle to regain direction.

I am saying go deeper into these 4 statements. Fight the urge to go into processes and the tickboxes. Do not simply ask questions and pat yourselves on the back that you answered them – actually execute on the answers. Make those answers make a difference to your work and your life.

And oh, if any of your answers is ‘do process X’ , then please consider getting one of these:

http://i.giphy.com/xT0BKGkoBW46ip9OvK.gif

Make a donation and I'll speak with, coach, train or mentor your team for 1 day.

A gift for your company or team.

If your company/team needs a spark to improve it’s delivery capabilites, perspectives, focus, vision, value system and (no tomatoes please) culture. Then I have a gift for you. I’ll trade you a spark for £500 before 5pm BST,  Thursday, May 12th 2016.

If you or your company donate a minimum of £500 to my camino walk for ME/CFS  – and thereby help me reach/exceed my funding target of £3000 by 5pm  BST, on Thursday, May 12th – then I will come to your company/team on a mutually agreed day in July or August to help you improve how you deliver software or any products or service.

Whilst there is no magic to it – just experience, honesty, empathy , a desire to cut through the bullshit and help your company/team rise to new heights. I’ll bring my experience of working with  1500+ people and  180+ teams over the last 11 years as a coach with some of the worlds most successful companies.

Things I can help you  with:

  • super easy way to plan your releases (or even get rid of releases entirely)
  • getting pragmatic on just how agile you need to be to get where you want to get to
  • get *everyone* working together to increase value delivery
  • focus more on sustainable value delivery versus some whacky velocity
  • waste a lot less times in meetings

Just think about it – but not for too long – then donate.

Tick tock, thank you.

ps. Open to everyone, everywhere but… I’ll pay my way to Europe based teams/companies. Anywhere else we need to talk about travel costs.

The Process Delusion

We do Scrum (or Kanban or SAFe or..)

How often have you met people – usually executives and management at conferences or other spaces outside of their company and they proudly proclaim ‘we do Scrum’.
I meet them alot – not only at conferences – on planes and more worryingly in their own companies. It’s like the Sixth Sense – only with Process.

Then with the slightest of prodding – examining what they produce, how they produce it, who they produce it for, what feedback they get – and how often they get it, what they use the feedback for and how quickly they apply it – the delusion begins to become clear. This is what I call the Process Delusion:

The Process Delusion is the  pretense – for whatever reason –  that you are doing something a certain way for certain benefits but there is little or no evidence that you are doing it or getting the expected benefits.

Let me say straight off – I applaud the willingness of anyone in any organisation who tries out any process to get some improvement.

It takes recognition that something needs to improve. So many just live with the gross imperfections – often the downright insanity – of how they work. I’ve met them. Through whatever path they came to this point, they don’t really give a crap about what they are asked to to do. They’ve arrived at a place where they gave up or never started trying to improve things for themselves or their organization. But I digress.

So, willingness to try is wonderful. But it is – sadly – not enough.  It is like taking out gym membership. You get kudos for recognising you need to get fit and ‘well done’ for taking out the gym membership. But the real applause comes when – most importantly – you start to see actual improvements. And that takes persistence and focus.

How does the Process Delusion play out in your team or organisation?


Photo by Michael Gwyther-Jones

Do you feel appreciated, punk?!

Computer says ‘appreciate Mike’

Corporates are a funny bunch. There is a process for everything. Even appreciation.

A couple of friends of mine in different companies recently celebrated significant milestones of service. An HR system notified someone to initiate an order for some official commemorative items and also sent an email to their respective managers to ‘put it on their radar’.

The first – for 5 years of being with the same organisation – earned himself a piece of glassware. The kind that is heavy and feels and looks significant. It also looks like the kind of thing that is still sitting on a shelf of the charity shops with no obvious use to anyone.

My other friend celebrated 15 years at a different company. There was a Friday afternoon presentation by his manager( who incidentally was 11 years old when my friend started at the company!). For such a long tenure, he received – with thanks – a voucher for £100 and a clock.

Being a confirmed nomad and allergic to the long term effects of corporations – I would never tenure anywhere long enough to warrant anything beyond chewing gum – pre-owned chewing gum at that – so I was curious about their experience of being recipients of corporate appreciation by policy.

It’s about the choice

My glassware friend was somewhat at a loss about what to do with this chunk of glass. To make things worse, he Googled the manufacturer of the piece and discovered – much to his disgust – that it cost about $50.

Now my friend lives somewhere $50 goes a fairly long way and to discover he had no choice about the way in which it was spent –  when it could have made a real difference to him as cash – left him pretty turned off.

I made the same mistake many people make when we talk about material things – we got through a list of other material things we think could have been a better ‘gift’. Would he have preferred a $50 bottle of whisky, a contribution to a dinner with his partner or a book or who knows what.

As I pursued a relentless list of other things he might have valued more – he put it simply

Mike, being offered a choice is all that I wanted. To have been asked what I wanted or offered the cash

This is when I realised the deep importance of checking in with the person you think you are appreciating – especially when you are demonstrating it with a gift.
Offering them a choice can avoid so much negative stuff. I wonder how my friend’s non chalance about his glassware would be perceived by those responsible for the process of him getting it in the first place. My hunch tells me it would be received as ingratitude.

What thrills me might not thrill you

My other friend  – with his unsolicited time piece – agreed wholeheartedly about the issue of choice.

He wouldn’t have chosen cash, but he really would have appreciated a call from the CEO. He said he feels he has contributed so much of his life to this organisation and the people he feels he is supporting have never reached out to say a personal “Thank You”. It has been company All Hands, video broadcasts and other ‘efficient’ channels. He pointed out that:

Even the the Queen of England demonstrates personal gratitude and celebration with centenarians and  people who have been of valuable service.

As we spoke more,  it turned out that  a simple 2 minute phone call demonstrating genuine interest by the CEO of the company would have entirely made his day! It got me wondering what the job of the CEO was. If it wasn’t about connecting with the people whose toil makes the business valuable, then what is it?

Appreciation is double loop learning

One of the new foundations of effective and efficient process work is double loop learning. This is where we formulate a goal,  for example

We want to demonstrate our appreciation for long tenures of service

Then we devise a program to reach that goal – for example:

We will give people who have worked for 5 years a piece of crafted glassware and a funky timepiece to people who have served 15 years

Double loop learning in this case suggests that once you have done the program,  gather learning about whether the goal should change – not simply the way you are doing it. I heard no evidence that either of these employers had either the interest nor the channels to gather the learning, let alone the intention to apply anything to their original goal.

If either of these employers even remotely thought about Double Loop Learning, they would simply ask how the recipients of these gifts felt about what was offered, how it was offered and what might have helped them feel better appreciated. I am absolutely sure that even a tiny act of genuine inquiry would have yielded that the goal must change along the lines of:

We want to help people who have served our organisation for years to feel appreciated for their long tenure

Can you tell the difference?  I hope you can. If not – ask me.

What are your experiences of corporate appreciation?

Did it lift you up and make you feel deeply appreciated or did it leave you feeling meh?
I’d like to hear about either and everything in between. Tweet me, comment or otherwise make your opinions known.

Happy days.

 

I ❤️ Agile Testing Day Netherlands

I’ve just been to Agile Testing Day in the Netherlands. And I loved it.

It’s been over two years since I last participated in any agile conference events.
Back then I had felt underwhelmed by most things on offer. My head was in some ‘post agile’ place that I couldn’t find anything authentic enough to attend. Also, as a serial organiser/facilitator of gatherings and unconferences I also didn’t want to be involved in organising anything.

Anyway – out of the blue –  Madeleine Griep from D&H events the organisers of the Agile Testing Days conferences contacted me to present a keynote at their Netherlands one-day event. The Agile Testing Day Netherlands is in its second year and – according to Griep  – had doubled its attendance in one year. Pretty good for a young event. The more established Agile Testing Days in Berlin is in its 7th year, runs over 3 days and enjoys attendance of 600+. So  – really good pedigree as  an event.

I said ‘Yes’ but didn’t really know what I was going to be talking about. For me, these events are about provocative thinking, inspiration and connection. So whatever I wanted to share had to bring people a degree of all of those aspects.

Whilst there was a significant proportion of the attendees dressed in suits and many were consultants of one form or another, there was also a large contingent of actual testing professionals whose daily lives are spent trying to make their products demonstrably better in the face of immense disrespect and organizational pressures.

What really delighted me was that in one single day, an attendee could explore the present – tools, techniques and anecdotes of how their peers are doing things – and the future – like in Rachel Davies’ talk about testing at Unruly. Whilst at the same time they can go deep into product testing and zoom out in how they might effect change in their organisation with a keynote by Olaf Lewitz on Integral Quality

I certainly learnt a lot by attending and was delighted to hear that my keynote was well received. Here,  for your viewing pleasure,  is the slide deck from my keynote. There is no audio but you can get the main thrust of my talk.
If you get the opportunity please check out the Agile Testing Days conferences – either in Berlin or in the Netherlands.

Read this before 'you eat your own dog food'

It has always amused me when people – usually men – say their company or team ‘eats their own dog food’. It has always struck me as a very ‘macho’ thing to say.

I’ve searched for the origin of the phrase ‘ eat your own dog food’ – there seems to be a couple of places it could have come from, but its wide spread technology industry usage dates back to 1988 in Microsoft.

Of course the point of ‘eating your own dog food’ is to demonstrate that you have confidence in your own product and can learn – and improve – from your own internal use of it.

Before I continue – let me say that I think when done correctly, using your commercial product internally can be a very powerful learning and empathy building experience.

Here are some things to consider before ‘eating your own dog food’.

Is making dog food mandatory likely to increase joyful adoption or encourage resentful compliance?

A couple of places I have seen have made ‘dog food’ mandatory. Usually the order comes from the top by someone concerned that the product has quality or user experience problems.

In my experience – how people work and the tools they use should not be made mandatory or imposed in any way. If the product solves a problem that the user has, then they’ll use it. If it doesn’t – that itself is some valuable learning. If it has to be forced then the data you get from the dog food experience may not be authentic.

Understand the risks to your business

You might argue that if your product brings a business to its knees, you would be better off experiencing that yourself first. Or not.

As much as you might not realise it – your company knows more about how your product works – or should work – than your customers. This insider information is hard to ignore.
So invariably, the product as used internally does not often cause the same effects as when used by your customers. Or if they cause the same effects – the knowledge your employees have masks the perception of the effects in a way that your customers’ users don’t.

For example – I had one customer who made security scanning software – the stuff that sits on your machine and scan files and access. Their CTO encouraged their teams to ‘eat their own dog food’ with some dire results.

Given the nature of the work they were doing, the software completely crippled any kind of software development on the employee’s machines. The order remained, except the developers – choosing to do work rather than remain frustrated – tampered with the configuration by effectively disabling it.

Not all dogs are the same – be clear which dog you are.

Sure you might be selling an email client – and you think everyone uses email the same as you do. Before you unleash dog food on your employees – make sure you know what kind of dog you are purporting to be.

Are you a small enterprise simply using email for inter company communications or are you a marketing agency for whom email is an art form? Knowing what kind of customer your company is, will help you exercise your product more comprehensively.

Also knowing what kind of user you are not reminds you not to have false faith in dog food – it is only as good as it is used. If you never exercise some parts of your product internally, you aren’t getting the early warning of how real customers might be using it.

How will you deal with what you find?

At a higher level – dog food is about feedback. Specifically getting real world usage feedback on your product from internal users.

The big question is  – what are you prepared to do about it when you get it and how quickly will you do it?

This is perhaps the biggest problem I see when folk use their own products internally. More often than not, the internal users have no way of getting the broken things fixed quickly – so they continue to endure it.

Where I have seen it work well – the feedback from internal users is treated as an express lane item – because it comes earlier than feedback from external users (who typically are not on the latest versions anyway). By ‘express lane’ I mean, the triage and categorization of the feedback – i.e. urgent bug, enhancement etc – happens very quickly. Repair/remediation also happens very quickly – depending on the stack – the same day.

I’d like to share 3 handy checklists items before you commit your company to eating dog food:

  1. Will this critically affect our ability to run our business?
  2. Which customer usage do we represent?
  3. Are we prepared to respond quickly to what this experience will reveal?

Good luck.

Why Scrum is designed for misuse.

Street Cred

I’ve been in the software development industry for 21 years,  using agile software development practices and principles for 14 years to actually deliver software. I’ve been working with Scrum for nigh on 11 years now and over the last 7 years I’ve coached over 120 teams and worked with over 1200 people.

With all this experience one thing has become clear – Scrum is broken.

How I assess the quality of any agile process

In theory, it seems all neat and tidy, but in practice it is abused, misused and generally ineffective. And I wonder why?  I have seen many more poor implementations of the Scrum framework than successful ones. Actually – let me be explicit about how I assess the quality of implemented Scrum.

For me the success of *any* organisation’s way of working – formal or otherwise – can be checked by simple questions that explore 5 fundamental concepts:

  1. Value: Do we know the value we seek to deliver and are we consistently delivering the maximum value?
  2. Flow: Do we understand how we reach that value and are we consistently reducing the time and/or increasing the ease by which we reach it?
  3. Quality: Do we understand how good our product and workmanship needs to be and are we consistently and demonstrably achieving it?
  4. Joy: Do we know what we collectively and individually need to be joyful and are we consistently meeting those needs?
  5. Continuous Improvement: Do we know what we need to improve across VFQJ and are we demonstrably pursuing those improvements?

This simple list of questions invites great questions and other avenues of inquiry. It can function as both binary (yes/no) and range (how well are we doing). Works for me – mostly.

The non-recipe recipe

The fundamental reason why Scrum – as it currently exists – is broken is that it is a set of instructions, roles, rituals and artifacts that purports to *not* be a recipe. But almost every one takes it as a recipe and they follow it. But there is not enough there to be a an all encompassing recipe – there can never be.

The trouble is that, as a product , Scrum needs these illusions of completeness in order that it is taken seriously . By and large this has worked. In a world that is seeking silver bullets, Scrum has succeeded beyond it’s practicality commands. It is by far the leading agile process framework in use today. It is in this illusion of completeness that lies the myriad of problems.

I remember in 2008 or 2009, there was a statement about there never being ‘Scrum 2.0’ – that Scrum was complete as it is. A perfectly chiseled gem that needed nothing removed nor added. This was clearly bollocks and persisted until politics and greed spilled over in the Scrum Alliance causing a bitter split between one of the co-creators of Scrum and the rest of the Alliance. All of a sudden a Scrum 2.0 in emerged in all but name.

When people have applied Scrum as a recipe the commentary from the unsympathetic dogmatics has been of the nature of:

“ScrumBut”

“Scrum shines a light on where you need to fix in your organisation”

“Scrum works, you just did it badly”

“You didn’t have buy in”

Overwhelmingly any reasonable objection to some of the design flaws – and design flaws can emerge after the fact , exposed because of a change of operating environment etc – is often met with “those people are resistant, they are against change”.

When Things Work, Its the Process – When They Don’t, It’s The People

I was first attracted to Scrum because I believed it would revolutionise the ‘world of work’.

10 years on and I’m deeply disappointed. It did not revolutionise the world of work. Instead it got gobbled up by the Death Star of Work. If it had any early promise – for me it was that it would promote unprecedented collaboration between the people focused on delivering value and the people consuming it.

It may have had some success in some organisations – but this is far from ‘changing the world of work’. A tiny street maybe, but never a world!

Of course a process doesn’t do anything – people do. But how a process is designed has a huge impact on how readily the people take to it and how easily they can use it for the intended purpose.

More often than not I see a growing perception of infallibility of a process and an overwhelming blaming of the teams and individuals who play the Scrum roles. I feel deeply sad and angry at this.

Multiple single points of failure

Scrum Master, Product Owner and Team all collaborating beautifully – each with its clear role and responsibility – what’s not to love?

Except that in *most* companies roles are so entrenched and siloed that this is the worst thing you could do – add more roles that become siloed. I hear you scream – “yes but the problem is the organisation and not Scrum” – and you are both right and wrong.

You are right because it is the organisation that is siloed and you are wrong because adding more roles when you *know* that most organisations are siloed is a dumb idea. That is like asking the morbidly obese to incorporate 3 more meals – however small – into their already dangerous diet.

Defined roles and a culture of collaboration are difficult bedfellows in any context. Especially in the context of trying to explore value through . Defined roles present an extra hurdle to overcome as we truly try and work together.

I have seen product development be disastrous for many reasons and the most common one is the single point of failure problem. Examples abound:

  • Overworked, overextended and ineffective Product Owners;
  • Scrum Masters left to single-handedly be responsible for improvement and impediments and latterly ‘coaching’ the team.
  • Teams that aren’t to effectively own their tools, their craft or their collaboration.

Rituals become checklists vs  achieved outcomes.

If I have to walk into another planning meeting that is schedul for 4 hours because Scrum said so – with the hope that somehow the information we don’t have about the work we are expected to commit to will magically appear – I may have to shoot some unicorns.

Sprint after sprint, people do the meetings, the stand ups, the reviews etc. Scrum Masters – bless ’em – scour the communities for how to make their standups more interesting. Velocity is going up, teams are 7±2 people – things in the product backlog read like ‘As a …, I want…”. The process seems to be working perfectly.

Yet software is still sitting on the shelf. Customers are not getting anything to feedback on. Developers still don’t talk to customers.

Velocity becomes a stick to beat teams up

So velocity is not a defined part of Scrum – but it is a defacto part of Scrum implementations and it is both a arbitrary and crude measure of something.

Velocity doesn’t mean what you think it means. It is about capacity,not speed It is *always* historic and never comparable to any other team and barely comparable to the same team over time.  Sure it is a number and numbers can be compared – and that in itself is a problem because the human factors that help that number pop out are deeply flawed in most organisations.

Thankfully, the #NoEstimates movement is bringing some well deserved improvement in thinking in this whole area.

Of course you need a measure to know how you’re doing. But velocity is a poor one. The emergent product and how well it is meeting the needs it was intended to meet is the ultimate measure – sadly many organisations are unable to get this – so they overdose on the measure that came with the process.

So narrow as to be quickly redundant

I was in the market for car seat a few years ago and was faced with buying something that was super specific for my son at his then age – he was 3 years old – or buying something that would support him till he was 8 years old.

Guess which I bought.

Scrum purports to be for ‘new product’ development – and I wholeheartedly agree. Except I don’t know *any* teams that only do ‘new product development’.

Even if  a team that started out with only new product development – after their product reached its first users – their work mix would need to change. The fixes, bugs and so on that are different classes of work and different service responses change the mix. You could use Scrum to do these classes of work – but that would be akin to picking your teeth with a vacuum cleaner.

And this is just product related work – but what about the work everyone needs to do to continue to improve? The Human Development work? How about using Scrum for that?

If Scrum was the only thing you did – and many organisations adopt it as such – then it would get misused pretty quickly because getting shit done always trumps following a process. The question is how much of a hatchet job do we have to do to the process to get the shit done.

Scrum Shows You What Needs Fixing, It Doesn’t Fix Them For You

If I had a penny for every time I’ve heard this, I would be rather rich.

Of course Scrum should fix something – everyone I have ever met in a company *know* what is wrong. They don’t need a fancy methodology to tell them what is broken. They need something to help to try and address the problems and Scrum does not not address any of those.

If the problem that Scrum fixes is exposure of problems then it needs to be pitched as ‘a framework for exposing what is preventing you from doing joyful, fulfilling new product development work’.

It ain’t all bad.

I don’t hate Scrum – I’ve just use it long and deep enough to understand which bits I would throw away and which I would keep, what contexts I would use it in and which I would bury it so deep – no one would ever find it.

If you are using Scrum  – I beg you to question it all. Ask yourself, your team, organisation and customers whether this is really helping you and what you are really trying to achieve. Don’t even mention Scrum during that conversation – simply talk about ‘how are we delivering what we seek to deliver” .

As with most things, all this can boil down to simple choices.

Do you choose to blindly follow a process or do you choose to adapt your own way of working that is focused on value and joy?

Good luck whichever you choose.

 

 


Photo by mikecogh

Do Something Radical – Stop Preserving Your Career

Beware the language of powerlessness

How often have you heard any of these phrases or perhaps  used them yourself:

“Don’t rock the boat”

“Pick your battles”

“Keep your head down”

“That is how stuff works around here”

“These things take time”

Within and outside the organisations I work with, I hear over and over again the language of powerlessness – the language of C.Y.A – Cover Your Ass, the language of the status quo.

You joined to do great work, so go do it.

You,  like most people I know – some in the biggest and richest companies in the world – joined to do amazing things.

They joined to pursue the passion of figuring problems out , helping people , being of use or simply for the joy of making.

Along the way they acquired things – family and responsibilities. All of which make demands on time and money.

Along the way, they settled for the status quo and adopted the language of powerlessness – allowing unfairness and injustice to be done in the name of career progression.

You only have this one life – spend it wisely, do the great work now – you might not get another go round the carousel.

Go take calculated risks.

Start a business – you might fail or you might succeed, either way it would probably be the best thing you could do.

Speak out against the things that piss you off  – you might help change them.

Stand up for others at work  even against the opinion of authority.

Don’t be afraid to be vulnerable. You are human – show it.

Don’t tolerate your time being wasted – it is the only thing of real value you have and you have less of it every day.

Be the shoulders for others to reach further  –  that is leadership too.

Call things as you see them.

You might actually find you have a more enjoyable, impactful and inspirational career by not trying to have one.


Photo by Australian National Maritime Museum on The Commons

Screw Fast Feedback

Agile teams love faster feedback

Or so the mantra goes.
Legions of agile enthusiasts and countless books, conference talks, webinars and training course harp on about faster feedback as though without it the World would cease.

In the fantasy world we – agile enthusiasts – inhabit, the faster the feedback the better.

Entire hordes of agile nerds are finding ways to make technical feedback – compiles, unit tests and functional tests – faster than ever before. We have frameworks now that give you almost instantaneous feedback on the impact of changes you are making to code and the product you are building. We delight in making the mechanisation of feedback itself faster.

With all the emphasis and near-dogmatic fervor directed in favor of fast/faster feedback, I think it’s time for some perspective – screw fast feedback. I mean really – screw it.

Why do people who understand the value of fast feedback impose the idea on everyone else? There are clear reasons why you make the investment in discovering – and discovering quickly – what someone or something has to tell you about something you did. Whether this is software, a customer or anyone!

3 Reasons For Not Seeking Feedback – at any speed.

We – enlightened folk – prance around thinking the value is self-evident to man and beast. It isn’t.
Let me put more succinctly:

  1. If you are asking for it but not going to act on it – and yes, considered inaction is ‘acting on it’ – then don’t seek feedback.
  2. If you are asking for it and not going to act on it as quickly as you get it – then don’t  go through all the trauma of seeking it faster.
  3. If the source of the feedback is unwilling to give it to you quickly or even at all – don’t waste your time trying to seek it faster.

I have seen too many teams pursue the delusion of Continuous Integration but not write tests – the equivalent of asking for feedback – or not write enough tests to tell them anything meaningful. Then even when they get some feedback – “Red Alert: the build is broken” – it remains broken for days.

Don’t release your product early and often If your customer is not prepared to do anything with it when you release it . Why take the considerable pain of changing how you work to do something that no one needs. That is just dumb.

Every optimization you make costs you something – so think twice about what you will use that optimization for:

If it will not enhance the value you deliver, ease the flow of delivering that value, improve the quality of the valuable product or increase the joy of working on this valuable thing – then do not make the investment.

Why I wrote this

This piece is about giving the rest of the world a break from the pressure to seek feedback and act on it. I hope we can all get back to what works for each of us.

Note: On the subject of feedback, I care that you share your opinion about this post. If you tell me what you liked, I’ll do more of it, if you tell me what you didn’t – I promise I’ll consider doing less of it.