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

Why I don’t assign deadlines by date

 

Think about the last time you came from a working meeting. If it was a productive one, you came out with an action, who is to do it and a delivery date attached to it.

This is of course by now what is de facto in business on what it means to have a good meeting.

This is great and by doing so you would be ahead of most other organisations which run meetings like some form of social engagement.

Once you start implementing you are guaranteed to run into a new problem, how do you keep track of all those dates?

Think about it for a second, if you have 2 meetings per day for 5 days each with 5 actions, then by the end of the week you will have about 100 actions to track.

Modern day tools will keep track of the dates but in most cases, they just exacerbate the problem. You will likely end up with a whole lot of overdue tasks highlighted in a bright red. This constant reminder of missed deadlines is guaranteed to stress up any project manager.

There is a better way, consider assigning tasks to a week instead of a date.

In this way of thinking, instead of assigning tasks: task1, task2 and task3 to say 6th, 8th, 9th Dec respectively. You instead say task1, task2 and task3 need to be completed by the Tuesday of 10th Dec. Here the assumption is you do your weekly check-in on Tuesdays.

Now if you have more tasks you simply bucket them to another week say the week ending 17th Dec (another Tuesday).

In the example here, we have a fictional person planning a trip to the coast, in a discussion with the wife, they come up with several actions they want to be done, the actions are then piled up into buckets with each bucket indicating the final day the work should have been done.

 

So what is to be gained by using this kind of structure? Let’s explore.

Establish a rhythm

At the base of any complex system is some few basic concepts.

Salsa dance has the mambo

Genetic material has 4 nitrogenous bases: Adenine (A), Guanine (G), Cytosine (C) and Thymine (T)

Project management has the timebox

By chunking the work into weeks, it’s time-boxed. This comes with all the goodness brought in by them. In this case, a nice rhythm.

You now know every week, there will be something to celebrate as done.

You can easily tell when overcommitted

This is the starting verse of a song by Billy Joel.

Slow down you crazy child You’re so ambitious for a juvenile But then if you’re so smart tell me, Why are you still so afraid? (mmmmm)

Where’s the fire, what’s the hurry about? You better cool it off before you burn it out You got so much to do and only So many hours in a day (Ay)

In the age where what you are is what you produce, it helps to get a reminder to slow down every other while. The question then becomes, how do you know when you have over-committed yourself?

The method I propose here makes it very clear, if in the past 4 weeks you have been having a list consisting of 4-5 tasks, then you note this week you have 10 tasks, something is wrong.

Given the very visual nature of the structure, you will note the difference just by seeing the different sizes of the list.

Longer term planning becomes easier

Human memory is surprisingly feeble. When you walk into the office in the morning, its very easy to make sense of the situation, navigate yourself in such a way as to ensure you are not hitting any furniture on the way and definitely passing all the usual pleasantries. Yet if I was to ask you right now to close your eyes and then tell me exactly what you saw, most likely you forgot most of the details of the morning.

Despite this limitation of memory, we have evolved an ingenious technique of dealing with it, chunking.

Chunking in psychology is a process by which individual pieces of information are bound together into a meaningful whole

By having your work in weekly lists, it’s now easier to think about the week as a chunk as opposed to multiple disparate action items. The psychological relief once you start practising this technique will be worth it.

How do you organize your tasks? Talk to me in the comment section below or on my twitter @jchex

 

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Working with heavy documentation requirements

 

In a previous entry, we looked at how to work with minimum specifications. Unfortunately, in practice, this is not always possible.

Let’s suppose you have won a contract to build software to manage medical records. The software would be used by the government to collate records and process relevant statistics. How satisfied do you think the taxpayers’ representatives would be with some minimal documentation and criterion for “it works”?

While even in this cases unnecessarily long form documentation is still useless, I have come to accept it’s also part of the constraints you must live with in order to practice software development.

All is not lost, in this entry, we will be looking at how to build software when heavy documentation is a must-have.

Consider documentation as a story in the backlog

For teams still struggling to adopt a technical practice such as unit testing, the advise I give is simply put it in your backlog and then have an acceptance test for it. This practice will hopefully nudge the team to using it consistently.

In the same way, it helps to acknowledge that documentation is work, thus have it as an item in your backlog. Not only will you be tickled to remember it, it also makes the cost of writing the documentation clear to everyone.

Use continuous integration tools

One of the riskiest parts of your application is in its deployment. Thus the running jokes on the idiot who chose to deploy the update on Friday 5 pm have in effect committed the team to work the entire weekend. Organizations have evolved documentation to help derisk this activity as much as possible. This includes documentation on how to stage, set up environments and deploy the application.

Thankfully, a lot of this work can be automated away by using CI/CD tools. By carefully setting up your environment so that not only is it replicable but a bot can do it for you, then you eliminate the need for documentation related to it.

Even if you are not familiar with CI as a technical practice, I would still encourage you to consider adopting a Platform as a Service Tool such as the ones provided by Google Cloud or Heroku. It will cost you more but the savings in development time and headache will be worth it.

Insist on requirements as a point of discussion

Unless you are reading for leisure, any other kind of reading is hard work. Furthermore, most books out there are just not worth reading. Now, if authors whose primary work is to produce reading material are not doing a very good job of it, what about developers who don’t consider themselves authors?

It’s then better to remind yourself and the organization you work with the point of documentation is to enable discussion between the various stakeholders not necessarily to get a comprehensive view of the workings of this system.

This slight change in wording means whoever is writing the documentation writes it with a particular person in mind and keeps it short enough to support a discussion without getting bogged down in details.

Work to understand the goals of the documentation

Rather than viewing documentation as another drudgery you have to go through, try to inquire why the organization cares so much about having such heavy documentation.

Sometimes, it may be an auditor who insists on a certain quality level. In such situations, having a one on one discussion with them would help you understand what their goals and for your team to work on how to meet the goals in an agile manner.

Follow your own process

Scrum and agile in general works but just like any other process, if you don’t abide by its principles, the results may vary. Thus in your quest to reduce unnecessary documentation load, ensure you are delivering working software, talking with stakeholders, in general, being a good scrum team.

In this way, over time, you will be able to make the case just because your process is remarkably different, you are still able to achieve the goals of the organization.

How have you worked with heavy documentation requirements in the past? Talk to me in the comment section below or on my twitter @jchex

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail