5 (Bad) Practices in Software Development–Will We Ever Learn!

Many books written by authors such as Mike Cohn, Lisa Crispin, Roman Pichler, and Jurgen Appelo, for many years now, have documented various processes and practices that work well – AND – they also outline practices that don’t work.

My hope – is that someday – teams & management will actually heed the good advice in these books.

So this is a personal account of some of the things documented in these various texts that really don’t work.

History says – if you do these things – you will likely fail.

Disclaimer:  this is a list of things that I have seen over the years – made by many organizations – in many industries.  Maybe you agree – maybe you don’t – It’s my blog & my opinion and I’ll say what I want (until I am censored by the Gestapo) – yay internet!

#1 – Failure to Enable Your Team!

Stop forcing arbitrary rules on your teams – all this does is cause friction.

Management still thinks it’s a good idea to dictate the rules to the team vs. letting the team make their own rules.  This disables a team – management should enable a team.  Letting teams make their own rules (within certain boundaries) lets the team know that they are responsible for their own destiny and it’s the responsibility of the team to figure out what works and what doesn’t.  Management should guide or “lead” vs. dictate.  Command & Control management is a thing of the past and does not work in creative, white collar industries.

#2 – Distributing Teams Across the Globe

All too often – the product owner is no where to be found.  They are located in some city across the globe.  This makes getting decisions made, questions answered, and planning done in an efficient & timely matter – next to impossible.  This normally delays everything.

If you are on a team that is fortunate enough to have a product owner – hopefully that product owner will be at arms length and easily accessible.

The same principle applies for distributed QA, and distributed engineers.  If you must distribute – there are better ways to enable distributed teams – than forcing all teams to collaborate directly at very inconvenient times.

#3 – Trying to Have SCRUM at the end of the day – WTF!

Scrum is for engineers (you know… the people that actually make this stuff work) to plan out what they are going to do today and to keep each other accountable.  It’s a 5 minute standup to say how you added value yesterday – how you will add value today – and any OTHER meetings that you need to have today.  If you are talking about other projects – or asking questions – you are wasting our time.

It is not (how many times must this be repeated) a status meeting for managers (chickens).  It is not a detailed planning diatribe where everyone looks into rally (or whatever planning tool) you have and reads from the list of what was done & wasn’t done.  If you want to know the status of the sprint look at the burn down chart – WTF – that’s why they exist – use them – it’s a bar chart – it should make total sense.

Normally – teams that have scrum @ the end of the day are trying to facilitate some chicken (manager) that is in another time zone that thinks they need to attend the status meeting… so what is wrong here… well, it’s not a meeting for the manger, its not a status meeting, and it doesn’t help me to have my team’s daily planning meeting at the end of the day… since its already over.

Here is an idea… let the team “have their scrum” in the AM – and have any chickens look in rally whenever they want – or send a recording of the SCRUM to the chickens!  Chickens tend not to talk in SCRUM – so why they need to be there is beyond me.  Email & other tools can be used to bring chickens into the loop.

Why do we need chickens?  to manage, answer questions, make decisions, help with planning, enable teams, buy doughnuts, count beans… None of these require chickens to be present in scrum – In-Fact – this is why scrum master tends to not be a “manager”

#4 – Writing User Stories that Suck!

Its simple – there is a template – it looks like this:

“As a <type of user>, I want <some goal> so that <some reason>.”  Here is an article written by an industry PRO – that believes this is a great template to follow and why…

If your user story doesn’t follow that format – chances are – it sucks!  Why?  Because it does not tell the people building the software – who wants what – what specifically the user wants – and why the user wants to do something…

Here are some good user stories:

As a user – I want to click a button and transfer funds from my checking account to my savings account so that I move money in between accounts. 

As a user I want to click a button on screen and view my account usage so that I can see why my bill costs as much as it does.

As a user I want to select a driver and click a button to view all deliveries that they have not completed so that I can see on the screen how many deliveries they have left to do.

If you want us to build you software that doesn’t suck AND does what the user wants the first time around – help us out and write basic user stories that don’t suck!  Furthermore – if you do write user stories that do suck – do get bent when your team hits you with a flurry of questions trying to figure out what you really want.  If your team hits you with a question storm – that is a good thing – they are engaged.  If your team asks no questions – worry – this is a problem.

#5 – Failure to Prioritize Bugs

I love it when this happens….

• QA Finds a bug, QA asks engineer what to do, Software engineer says – lets follow protocol – lets have a conversation with PMO – its not part of this story – its not blocking any story from moving forward – lets bug it, document it, communicate the action taken (i.e. email everyone) and move on.  It is also reported on the quality reports in our agile management tools AND shows up in defect backlog
• Next planning session takes place – engineering team asks product “hey, are there any bugs that we want to fix in this iteration…” – PMO says nope.  We say – are you sure – what about this one… the customer is going to find this at some point… and we are going to have to deal with it… – PMO says nope – team says ok…
• 3 months goes by – customer finds said bug – someone (namely customer & someone higher than PMO) wants to know why this bug exists… someone has to explain… “engineering team told us about it… but we never fixed it…”

Here is how to fix this issue…

#1 Slow down & listen to your team – that’s why you employ them

#2 Pay down the debt every sprint because it’s just going to get worse

#3 Pay more attention to quality – that is why we have quality reports built into the process

#4 Stop using the bug list for things that aren’t really bugs as this causes a barrage of meaningless paperwork

Recommended Reading List

Here is a quick list of books by all of these authors that any agile software engineer, product owner, scrum master, or manager should read:

• Management 3.0
• Agile Testing: A practical guide for testers
• Succeeding with Agile
• Agile Product Management
• Agile Estimation & Planning
• User Stories Applied
• Essential Scrum
• Agile Product Management

Daily Standup Anti Patterns

This post is NOT about being agile or any other philosophy for that matter… it is about identifying patterns that keep people from starting the day in a productive fashion.

As a software engineer each day I participate in a daily meeting called a scrum.  My software engineering friends may be aware of this practice.

This is a simple post that outlines some of the anti-patterns that I have witnessed over the years of practicing scrum and why they are bad.

They are my observations and my opinions.

Here is a great post by Mountain Goat Software that outlines “The Daily Scrum Meeting”

Goals of the Scrum

- the “pigs” communicate with each other directly to determine a plan for today

- the “pigs” communicate with each other directly to assess the current state of the sprint

If you have other agendas for the daily scrum, then you probably are not committed like the pigs are or you haven’t taken your commitments to your peers seriously enough.

Anti Pattern #1

- the pigs give a report to the scrum master and that’s it

Why is this bad? Scrum master is a chicken.  Scrum master is not going to write code or fix bugs.  Look at your fellow pigs and talk to your fellow pigs.  Your fellow pigs are the ones in the trenches with you.

- A good sample – look at your fellow engineer and say “today we need to work on story X so that we can… “ then look at your QA engineers “get the code to QA”

- A good sample – "look ad your fellow engineer and say “I am ready to test whatever stories you give me today”

- A good sample – “I found some crazy bugs related to story X yesterday… John and I need to get together today and talk about these bugs”

Anti Pattern #2

- everyone sits down and one by one starts reviewing their task list via the task board being displayed on the overhead projector

Why is this bad?  Most people have short attention spans.  This level of detail is probably overkill and people will tune out.  Once again, if everyone is looking at the projector, your aren’t engaging your peers.  Chances are, people are spinning in their chairs, or checking Facebook on their mobile phones while you go through your task list.

- A good sample – “I am working on story X today – I will / will not / might be finished by Noon / Close of Business”

Anti Pattern #3

- people talk into a phone

Why is this bad?  This means you likely have a distributed team.  People focus on the phone instead of direct communication with their fellow pigs.  Typically the person on the other end of the phone is a chicken.

Anti Pattern #4

- props are poorly used in daily standup – meaning that if you are going to look at a projector why not view something that matters… like the iteration burn down chart OR the story board for the sprint

Why is this bad?  Well if you aren’t focused on each other and you are focused on invaluable data on the screen then you are missing the goals of the scrum.  At least a burn down chart shows you the state of the iteration and the story board shows you how much work is left.  Maybe this could save chickens from hijacking your scrum?

Here are some charts that matter, and they matter because at a glance you can see the state of the iteration on a day by day basis

 

Anti Pattern #5

- people in authority positions hijack the scrum for other purposes outside of the primary goals as stated above

Why is this bad?  Well, just like hijackers keep planes from getting to their intended destination, these meeting hijackers keep the team from getting to their intended destination, which is “What do we need to do to get this iteration done”

Possible resolutions – reserve the first part of the scrum for pigs only.  after the pigs are all on the same page, chickens can add whatever value or ask whatever questions they want.  And, after all the pigs are done, anyone is free to leave and we can all be seated to have further parking lot discussions or chat with chickens.  Possibly schedule other “status” meetings for a later time. 

Make no mistake, I am not advocating that chickens have no value to add, in contrary, they can add a lot of value.  I will advocate that often times chickens do not realize the distractions that they cause, but that is a story for another day.

However, we should either take care of our primary agenda first – which is to enable the pigs to get things done OR repurpose the meeting.

 

Anti Pattern #6

- scrum master is your boss

Why is this bad? It may or may not be bad.  It really depends on the boss.  If people don’t trust the boss, then they may hold back on saying some things that really need to be said.  If people are intimidated by their boss they may be afraid to say “I don’t have enough time to get this stuff done because there is too much stuff on my plate”.  If it’s the boss that is pulling stories into the sprint, that were never committed to in the first place, then pigs may be reluctant to push back on that and say “Hey we didn’t commit to that”.

Typically the only authority that a scrum master should have is over the process – not the people doing the work.  They should also have the authority to facilitate people and groups so that impediments are removed… once again, they are managing the process, not the people.

The Ultimatum Game

Today at the end of sprint planning, I asked our manager, “These user stories have no story point estimates and most of the stories have no task break downs (stories assigned to me were the only ones with task breakdowns / hourly work estimates).  Do you want the team to do story point estimation and task breakdowns for these stories, and let you know what is feasible for the next two weeks?”

The response was “I don’t care what the teams estimates are.  All of this work needs to get done.  So, make it happen.  If you want to do task breakdown, then go for it.  Otherwise, task breakdowns and story point estimates don’t help me deliver software any faster.”

This was said openly, in front of the rest of the entire team.

Admittedly, it wasn’t quite the answer I was hoping for, but I wasn’t surprised.

However, my interpretation is that this was an ultimatum.  After looking at the faces of the other engineers on the team, many of them just kind of had a “yeah whatever, here we go again” look.

My take on ultimatums when applied to software development is that they are seldom productive for the team or the business.  IMO they tend to do more harm than good.  Looking back on things, I tend to find that ultimatums work only for a short time and they will eventually backfire and the ultimatum giver will get stuck holding the bag.

I think these are the possible outcomes of ultimatums

• people will do the work until they get a better offer (which isn’t hard these days, especially for skilled engineers)
• people will do their best, if all the work gets done, then so be it, if not, then so be it
• some people (normally the loyalists) will work 12 & 14 hour days if they believe strongly enough in the vision
• some people will do the work and go on record saying that they don’t think the list of demands can be met
• some people may say enough is enough, I quit.

I think that ultimatums are probably one of the most damaging things that can be done to a team.  After the supervisor made the comment, I found myself thinking “I will get my stories done because I have done the task breakdown for my stories and the tasks seem reasonable.”  However, this is a horrible way for teams to think.  I think that the ultimatum is reinforcing silos and breaking down the team. 

I also think that ultimatums will open the door for people to cut corners and hope that no-one finds out.  This is a really bad scenario, because it can lead to bugs that make it to the customer.  We all know that when customers experience bugs, we loose value, credibility, and possibly a customer. 

Lastly, I think it is kind of demoralizing when your boss says “I don’t care what you think, get it done, or else.”  If this really was a life or death scenario, or there was a million dollar customer on the line, or someone’s livelihood was truly on the line, then the context would be different.  The fact is that there is nothing special about this sprint. 

Honestly I think if I were a manager or a business owner, I would want to give my team the opportunity to buy into a plan and make a solid commitment to a plan.  I think that when you can get more people to buy into an idea or a plan, it has a better chance of success.  Sure, sometimes as engineers, we under estimate, but that’s where personal commitment comes into play.  I think that most engineers will try to get more done if they realize that they have made a mistake in their estimation, providing that the mistake was something truly unforeseen in their estimation, (the PM walking in the bullpen 1/2 way through the sprint with a new set of “additional must have features” doesn’t count).

The fact of the matter is that when the livelyhood of your business depends on engineering and technology, the engineering team is one of your most valuable assets.  I think we need to treat them like the people that they are.  We should trust their judgment because they are in the trenches everyday fixing bugs, writing code, and innovating, and (btw) I think that’s what they get paid for? 

We should seek out their advice and expertise; value it, and take it for what its worth, and by all means stop treating them like commodities.

Wikipedia has a great definition of “Commodity” –> “A commodity is a good for which there is demand, but which is supplied without qualitative differentiation across a market. Commodities are often substances that come out of the earth and maintain roughly a universal price.^[1]A commodity is fungible, that is, equivalent no matter who produces it. Examples are petroleum, notebook paper, milk, or copper” 

If they followed TDD this wouldn’t happen…

I ran across this in my email box today. 

 

I thought it was so funny, so I created my own mashup.  My version is a true story, so i guess that makes it even more of a zinger.  One day, my company decided to let go our quality lead and replace him with the product manager who used to be the operations manager.  The things that managers do sometimes baffle me.

Here is my version…

When is a software engineer ready to be a manager?

Tonight I was having a drink at a local pub with an old colleague, who happens to be a CIO.  At one point in my career I thought that I wanted to eventually become a technology executive for a large corporate enterprise.  Over the past 13 years or so I’ve had various titles such as data analyst, software developer, senior software developer, senior software engineer, architect, tech lead, lead software engineer, etc.

So it seems like the next step is to have some sort of “Manager” in my title.  Not that titles mean much these days, as I have worked with both good and bad managers.

In any case, I asked my friend “How does a software engineer like myself know when he should throw his hat into the ring and try to land a ‘Development Manager’ position.”.  He looked at me and said, “You will be ready when you are willing to let go of ‘how’ it gets done.  If you cannot let go of the coding aspect and rely on your team of engineers to do the work then you aren’t ready.  If you feel like you need to be involved at a hands on level regarding the inner workings of the technology and the deliverables then you probably want wait a bit.”

For a moment I was speechless and I looked at him like a deer caught in the headlights.  Looking back on the conversation, I think I was shocked at the idea of not spending 60-75% of my time personally building high quality software that customers wanted to use.

He went on to talk about his personal experiences saying that there came a point in his career such that in order to stay competitive with the other engineers in the market, that he would have to completely re-tool his skill set and learn totally new languages, database technology, etc.  Reflecting back on that statement, I realized that I was kind of in the same boat.  I started off on the VB6 boat, then jumped to the VB.NET boat.  Then I realized that C# made more sense to me so I learned C#, and I have been on the C# + SQL Server train ever since.  Thankfully I have C#4, WCF, WPF, Silverlight, MVC and all of the cool things that those new technologies and frameworks bring to the table, but I am not too sure how many more revisions of client technologies and SOA frameworks that I want to relearn.

From a coding standpoint, it seems like we are solving many of the same business problems that we were solving five and ten years ago.  It seems to me that the real winners are the companies and teams that can take the current technologies and mix them together in a slightly different way, to solve an age old business need. 

Who knows, maybe it is time for me to let go of the need to be in the trenches with my engineering buddies and help the business define strategies, build teams, and help the team deliver the solution that the business needs.

On the other hand, I get a lot of satisfaction knowing that people are paying to use something that I have constructed withy my keyboard, my creativity, and my own brain, brings me great satisfaction.  Letting go of that satisfaction sort of leaves me with an empty feeling.