When things go wrong

Have you ever noticed how colourfully the best-laid plans disintegrate when they come head to head with the real world?

The popular adage

Whatever can go wrong, will go wrong

seems to hold its own.

In the world of software development, its common to have an agreement with the stakeholders the product you are developing will be fault free and meet their needs. What then happens once the delivered product fails to meet these agreements?

Yes, even with Agile, sometimes you miss the mark and now have to hash it out with the client.

In this entry, we will be looking at how such situations can be handled in a way that makes you better for it.

Raise issues as soon as possible

As I have mentioned before

Bad news does not age well

In my experience, the most tempting reason for withholding information about the fires going on is to try to fix it before anyone else notices. Sometimes the strategy works out and you are solid. Most times, it just doesn’t. What ends up happening is you dig an even bigger hole for yourself.

Years ago when mobile phones had just hit the market, I was playing around with my parent’s phone, somehow I ended up turning it off. When I turned it back on, it requested a PIN. So I did what any reasonable child would do, started guessing! The effect was the SIM locked and the phone now asked for a PUK. Again, I continued guessing the numbers. In the end, the SIM card permanently locked and we had to part with Kshs 2000 to get a new line. If at any one point before the number blocked I fessed up, the problem would have been trivial to solve.

In your own professional practice, when a problem arises, drop the hero mentality and instead see if you can enjoin the other stakeholders to jointly solve the problem.

Take the journalist approach

It’s very easy to blame. After all, our brains love certainty even when there are no grounds for it. Thus when an issue comes up, it is easy to blame another stakeholder or even yourself.

Even if you are right, it doesn’t matter, the problem is still there!

My personal philosophy is never let any good disaster go to waste. If you have encountered a problem, this is the time to establish the what, how, when and why. By probing the incident, you will end up with insights into how you can improve your work process.

As a side effect, you learn how to separate the facts of the issue from the opinions formed around it. Humans are attached to their opinions, thus by focusing wholly on the facts, you are able to get a more productive approach going.

Prioritize the relationship

A Pyrrhic victory is a victory that inflicts such a devastating toll on the victor that it is tantamount to defeat.

In almost all engagements, the relationship is more important than the product delivered. We will allow great latitude for someone we trust.

Problems are by their very nature divisive, you must fight the urge to prove yourself right and the other parties wrong. When things do go south, this is the time to think deeply how you can use the opportunity to instil even more trust in your clients. No one is perfect, this means mistakes are inevitable, it is however quite valuable to know the other person will always be straight with you.

When complaints do come, the contract is not your shield and defender. Even if you somehow captured this case in writing and thus are not to blame, the client is not happy and that is a problem. It is better to then engage in a conversation to find out where you misunderstood each other and how best you can mitigate the situation with the remaining time and resources.

Keep moving forward

Peter Palchinsky was a Russian engineer who came up with a formula to improve almost any process.

first: seek out new ideas and try new things;
second: when trying something new, do it on a scale that is survivable;
third: seek out feedback and learn from your mistakes as you go along.

There you have it, to grow you must make mistakes, the key is to ensure the mistakes are survivable.

Thus after the mistake is done, comfort yourself, see it as a ladder to even greater things. After all, if it did not kill you, you learnt something from it.

How do you handle missteps in your own organization? Talk to me in the comment section below or on my twitter @jchex

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to achieve consistent estimates

 

 

At the iHub, we work on multiple projects with multiple teams sometimes all at once. The process of software estimation is perilous at best even when there is only one team working on it.

Our situation is even more complex with individual developers serving in multiple teams and sometimes in a team of one!

Getting to consistent estimates across this various scenarios is not easy. In this entry, I will share some of the tips we have found to work in the past.

Find a common denominator

Estimates usually come in two flavours, days or story points. Ideally, estimates should always be in story points from which you derive days of work.

Unfortunately for most people, story points are just not intuitive. This means they make a great tool for establishing the work to be done but not a particularly great one for communicating the same.

Thus to establish consistency in communication, all our estimates are communicated in ideal days.

To be sure, this has come back to bite us once or twice where the client confused ideal days with calendar days but all in all the gains in shared understanding made for a worthwhile trade-off.

Review stories from similar past projects

Hofstadter’s law states:

It always takes longer than you expect, even when you take into account Hofstadter's Law.

Obviously, this is not a physical law, but you would do well to be mindful of it.

Thankfully, well measured past projects cut through our biases and reflect on us the truth.

For example, one of the more successful projects we worked on, our initial estimate was 5 months, as an e-commerce platform we were sure we understood everything related to it. In the end, it took 8 months from the first commit to a fundable version.

In current projects, we keep this hard lesson in mind as we think of the estimates we provide to clients. Particularly if a client wants a similar application, we now know how long it takes to get it done.

By having such a repository of past projects and the time it took to complete it, disparate teams can base their estimates on them and come up with consistent results.

Estimate some stories together

I expect developers to be very good at writing clean code that has a solid architecture with minimal coupling. I am however quite forgiving if they are not exactly masters of the black art of software estimation.

Still, the more estimators you have, the better. Groups will do wonders to the quality of the estimate.

Even if you will need the developers or individual teams to do their own estimates, it still makes sense to have a session where you work on it all together first.

How do you ensure consistent estimates in your organization? Talk to me in the comment section below or on my twitter @jchex

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Working with sceptics to new practises

 

 

There comes a time when you must introduce new practises or processes to your team.

Don’t expect it to be all smooth sailing, especially for well-established teams. They will question it. Unfortunately, it’s very easy to convince yourself that by virtue of your title you can push the practice and have it adopted whole heartedly

What you want to think of is the distinction between compliance and commitment.

Here are some of my suggestions for working with your sceptics.

Let them see the benefits

It’s bad enough you are introducing a new system for them to use it better work!

In leadership, it’s easy to assume what you know is correct and others are wrong. This dangerous assumption means you push practices that have no other value besides inflating your own ego.

If the practice is beneficial, then let the people see it. By adopting the practice, you should be able to show them via anecdotal evidence of its success and how it benefits them.

Provide training

The knowledge that is painfully obvious to you is likely foreign and unintuitive to your team.

Hanlon’s razor captures it beautifully:

Don't assume bad intentions over neglect and misunderstanding.

Training can be very useful in this respect, by running even an hour session with the team showing them how the process is done, you can make a lot of headway in getting them to adopt it.

Celebrate vocal sceptics

There is always that thorn to your flesh. The individual who is very vocal about your changes and how stupid they are.

The natural human reaction to such hostility is to close them out or attack them.

I suggest you instead keep an open mind and assume the individual is questioning the methods not you as an individual.

As such, invite them to all relevant process improvement sessions, let them air their views. Genuinely take them into consideration and address what can be addressed.

Hopefully, they can become your champions, if not, then maybe they can disagree but commit.

Have Backbone; Disagree and Commit. “Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.”

    ~ Jeff Bezos

Challenge them to do their best so that they can prove you wrong

All processes introduce a level of drag into the system, in effect what was getting done, gets done slower. The benefit usually lies in improved quality and less rework.

That’s of course if your process is a good one, there is always the chance you are wrong and unnecessarily burdening your team.

So teach the team the easiest way to shove it in your face is to do their best at this new practice and if no benefit accrues, you will be forced to reconsider.

While obviously a dangerous move, they can choose sabotage, if it works it will provide compelling evidence, enough to move them from compliance to commitment.

Show don’t tell

This is a particularly useful heuristic in many areas of life including the change in the process.

One of the great commandments of science is:

Mistrust arguments from authority

You want your team constantly engaged in a constructive disagreement with you, that’s how you get the most creative ideas out of them. If they become “yes men” your innovation capacity effectively shrinks to just one person, you.

By allowing for disagreement you then have the chance to show your new method will be of benefit to the organization of which you are all part of.

How do you introduce new practices in your own organization? Talk to me in the comment section below or on my twitter @jchex

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail