Changing Perspective

Intro

Procrastinating on so many things seems to have become my second job, so today is the day for change and to action!

I thought I would write a few articles (maybe a couple, not decided yet) about how my way of thinking or mindset has been changed in the last 18 months. I have been very lucky to work at a company that has a culture that is very special, I won’t say unique as I can’t possibly know if it is unique, but it is unique from the experience I have had in my career.

So this is just me sharing and maybe it sparks conversations within your circle, maybe it is something you also experience or maybe you don’t quite believe these things could actually work, whatever the outcome I thought it was better to write it down and share so that might help someone with something.

No Estimates No Deadlines

No Estimates – No story points, no how many days, weeks. Months - sometimes there is t’shirt sizing to help with capacity planning.

I must admit, I struggled with this to start, how does anyone know when they will get things done! 

There are no long running projects, the objectives are broken down into smaller local objectives, there are 2 or 3 objectives per cycle (usually 6 weeks) per team.

The team is in constant communication if something isn’t working, they learn early and adapt, the way of working that is encouraged is Pair Programming or Team Programming, so there are very few silos and sometimes a whole team will work on one objective at a time to ensure full focus.

The key here really is the no long running projects but rather small objectives, that are broken down even smaller.

The team communicate everyday in the way they get the work done and communicate every week about progress.

I should clarify at this point the Product Manager is part of the team.

With this no estimates way of working comes...

No Deadlines

That’s right! No delivery deadlines… I’ll wait as Project Managers regain their composure 🫣

Our product/engineering teams do not hear 'this needs to be delivered by xx date’. Instead they help shape what needs to be built to achieve an outcome, usually within the timeframe of the cycle. This allows them the autonomy, to build in the best way using their knowledge and expertise, this could be by delivering the smallest MVP quickly, gaining feedback and iterating over it throughout the cycle, or it could be a big build that delivers once during the cycle. 

The point here being, the people in the team are the experts, they are trusted to workout the best way to deliver.

The team communicate constantly, this means if something becomes bigger or not achievable in the cycle, the discussion happens as soon as this fact is known, so the approach can be changed and/or expectations are adjusted.

Why is this different to the other places I have worked? 

I would say every company I have worked for as developer or leader there have been deadlines. Mostly because this is what has been communicated to a customer at some early point in a conversation and so we must now stick to it or risk losing reputation. In some cases, the customer is internal, with no specific need to have something delivered by a certain date other than that’s what they were promised.

The delivery team is put under (undue) pressure to deliver something they very roughly estimated when very little detail was known, that undoubtedly changes scope throughout but without the end date changing. This is the same story whether following, Scrum, Kanban, Waterfall or a hybrid of these.

Any hint that delivery might be late, starts a barrage of meetings, accusations, blaming, re-planning… the result; Work harder and deliver when you said you would originally.

The expertise and knowledge of the team is disregarded, when they say we need more time to deliver to you the thing you want, with a good level quality and without hurting future development, there is no or little attempt at understanding the concerns and leadership very often fail at flying the flag for the team.

The team are not regarded experts and they are not trusted.

In the last 18 months, I have not had even one of those meetings or conversations. There have been conversations when a team perhaps is struggling to deliver, but the conversation isn’t centred around the delivery itself, but rather what has changed, what do you need and how can we help. We aim to understand what the team need to enable them again.

I will put my caveat in here, I know there cannot be a blanket statement, “we should all work like this” as that is never the case in Software Engineering. In my experience, especially in regulated environments, when the pressure is from an external authority and the timeline is dictated to you, you cannot have a fuzzy outlook.

However, I would say in the other majority, the deadlines come when something is communicated to a customer (external/internal) before all the facts are known, usually in a sales bid of some sort, to stop a customer leaving, keeping excitement/buzz, or to try beat a competitor. You may be able to placate the customer some what with the promise of a date, but what you sacrifice is the value of the engineering teams, the knowledge and expertise they bring, the churn of people coming and going, taking with them this knowledge and expertise and in the long run… you sacrifice people, their mental health, company culture and end up a place where people work for money and not for the passion of the business to succeed.