February 2016 – Tech leadership

Tips on managing your backlog

You are just from a specification meeting with your client. With you is a big list of features the client wants to see on the application. Probably its all in your notebook or note taking app. What do you do with it?

Today we shall be discussing some basic techniques on how to properly manage your backlog.

First things first

Note apps we’re simply not designed with engineers in mind. A productivity tool is needed. Trello is one such tool. Simply create a new board, put in every item to be worked on into the tool.

Some candidates for backlog include:

User stories
Work tasks
Areas which you/your team needs to gain competencies in
Major bugs (For ongoing projects)
Tech stories (The invisible work that developers see. An example would be migration scripts)

Involve clients and developers

Once you have your initial backlog list out. Its time to invite the clients and the team to view the items. This ensures everyone is on the same page about what exactly is to be developed.

Encourage as much direct conversation between the client and the developers who will be actively writing the code.

During this stage the client has the chance to prioritize what is important since they understand their business the most. The developers however are in charge of the estimations.

However this does not mean that the parties operate in silos rather the clients should explain why certain items are priorities and the developers should explain why they have given the estimates. This is not a formalized process, casual conversation is expected and encouraged.

Select first features for development

The first features will likely correlate with the top priority features but it will not be an exact match. The first features to be developed should be developed based on criteria listed below:

Customer priority. The most important factor to consider
Time to market: Chose features that can enable the application to be quickly tested by end users. This enables quicker feedback cycles.
Resource utilization: Ensure that everyone on the team has something to work on. Ie if you have a DBA there should be some DB work
Co-dependency: Some features will depend on others, ensure to build the most depended ones first

This is not an exhaustive checklist. Communication with your client and developers should land you on the ideal initial first set.

Break down Epics

Epics are user stories that are too big to implement directly. During meeting with the client, you probably gathered a lot of them. In fact at this stage your backlog is made up almost entirely of Epics.

Now is the time to break them down to smaller stories that you can easily track.

A good rule of thumb is if a user story takes more than 2 hours to develop it’s probably an epic. Assuming developer competency of course.

Focus only on current sprint

While it may at times be tempting to develop features directly from the backlog. Focus only on items on the current sprint. The items here can not be changed by the client and are easily estimate able. Furthermore you will be computing your metrics from the items on the sprint.

Backlog grooming

Anything that is not improving is guaranteed by entropy to be getting worse. The backlog is a living list and needs to be constantly updated to align with the priorities of the users and reality as it unfolds.

How do you manage your own backlog? Tell us in the comment section below.

How to give critical feedback

You get a frantic call at 2am at night from your most valuable client, their payment processing page is returning a 404. You jump quickly out of bed and login to github to see what changed in the code. You note one of your junior developers merged his local test branch to the main branch. What do you do?

The story above may seem convoluted but many product owners have nightmares of it and even more have seen a version of it play out in real life.

But today we are not going to go technical and talk about version management, no, today we talk about the developer. Yes that is the human being who just messed up.

Faced with this situation your initial reaction maybe to simply jump at this persons neck and strangle them, 18th century style. Yet doing this would be the most ineffective way to handle the situation.

In this entry we talk about techniques of giving critical feedback.

Bad news does not age well

Don’t keep the feedback to yourself no matter how bad it is. Tell the concerned individual as soon as is reasonable.

Telling them the news early allows them to see the effect of their mistake on you, the client and the organization.

The devil vs the person

Back in primary school, our disciplinarians used to cane us while saying “It’s not you am caning, its the evil inside you”.

In our anger it becomes hard to separate the person from the behaviour. No, your developer is not the devil reincarnate she just made a mistake, thats as human as it gets.

Point out the specific behaviour and have her correct that.

Get to the point

Illusion of transparency is a phenomena in which an individual overestimates the degree to which their personal mental state is not known to others.

With this information in mind, you may realize that the developer probably has no idea why you are fuming. If you fail to give specific feedback he will overtime come to the conclusion you are neurotic, a person to hide from, not listen to.

As a power tool, you may want to have the offender rephrase the problem he caused and the steps he plans on taking to prevent such an occurrence in the future.

The folly of sandwiching

The sages of old said it “If you wish to give bad news, first start with good, then the bad and finally more good”. This is really tempting to do since we want to protect the feelings of the recipient of the bad news. Yet in practise it never works as expected!

You see we humans are particularly adept at selective hearing. The developer will hear all the words but only remember the good parts. Not ideal to inspire any changes wouldn’t you agree?

Positive reinforcement

Sandwiching maybe a bad idea but that doesn’t mean you should throw appreciation out of the window! What you need to do is actively look out for changes that you want to see and reward them as they occur.

Negative actions and behaviours have a powerful emotional impact compared to positive ones. You must always be looking to compensate for this bias. Better to err on the side of compliments.

How have you dealt with mistakes in your workplace? Tell us in the comment section below.

Requirements | What you have been missing

While scoping requirements, sometimes we miss out on a big piece of it. We focus on what the product must do and forget about how well the product should do it.

In this entry, we are going to discuss some of the most common things we forget to scope.

Accuracy

We all know of the Salami fraud. Basically it’s the story of how developers in a bank managed to steal large amounts by charging only a few cents to a huge number of customers. The dudes are probably sipping Pina Colada somewhere in South America by now!

Point is, for different types of software, there are different requirements on how accurate the software should be. For a banking business, accuracy matters to the cent but for your personal blog, not so much.

Safety

More than ever software is part of our everyday life. Health happens to be part of this everyday life. You would not want your health monitoring app giving you wrong data even though it forms only a small part of your health management plan.

In this and many other such complex scenarios, software written should not add any unwarranted risk to the system.

Efficiency

High frequency trading is a form of trading carried out almost entirely by computers. The software that powers this systems are able to trade thousands of times a second to turn up profit even on very small margins.

For software engineers in Wall Street, efficiency separates those who drive to work in Ferraris and those who wash the said Ferraris.

Dependability

The software should do what it was built to do. Sometimes failure is allowed, I mean who cares that you can’t catch up on latest memes. Sometimes failure means jail time!

Usability

Software needs to be delightful to use.

Matt has a nice graphic on the same from Aaron Walters book Design for emotion

Maintainability

Software that can not be maintained is worse than worthless. What makes software so powerful is its softness. This property enables the business to get value from it even as its needs evolves. Software that can not be changed or can only be changed at great expense forces the business to stick to old ways.

Security

Privacy is a big issue for many people. Ashley Madison learnt this lesson the hard way Hackers Finally Post Stolen Ashley Madison Data.

If clandestineness confidentiality is a big part of your clients business, security is not a luxury.

How have you handled this types of requirements with your own clients? Tell us in the comment section below.