November 2016 – Tech leadership

Dangers of underscoping

A typical negotiation between the development and the sales goes like this.

Sales: The client wants us to build awesome feature x, that is their key value proposition. However, they also need feature a,b,c since their competitors already support it.

Development: That is great, we have met and discussed the work. It seems like it will take about 9-12months to get it done.

Sales: That is not possible, the deadline is in 3months

Development: There is no way we can deliver anything reasonable in that time

Sales: Ok, 6 months maximum

Development: Seriously we did not pull our estimate out of thin air, it will take 9-12 months

Sales: Ok then we will just have to resolve this with the boss

The boss: Hey dev guys, get it done in 6 months

Development: That time is not enough

The boss: That was not a request

Development: Ok

If you have been in this position before, you know it is not a pretty place to be. The pressure is incredible and you are made out to be the enemy. Yet I will argue that through it all, you should stick to your estimates. Especially if the estimates incorporate everything you know about the project.

You see when you back down at this point, you have not saved yourself, you have only traded a less evil (angry boss) for a bigger evil (failed project).

I suppose you are wondering how a software project can fail from an overly optimistic schedule. Well in my experience, that happens through the following ways.

Tight deadlines are missed by huge margins

You would think that the tight deadline would reduce the actual time taken to write the software as compared to the original estimate. At worst it would be the original estimate.

It never works out that way. In my experience, once a tight project misses its deadline, all bets are off. The actual delivery day can be the next day or months from now.

Design is ignored but at great cost

I have said it before and I will say it again. Software development is not a clerical activity. Yes, I know it seems like all there is to it is typing code and that’s it. In reality, typing speed has little bearing on the speed of development.

Now when the schedule is unreasonably tight, the emphasis switches to coding. Developers are rated by lines of code or commits/day. Important activities such as design are tossed out. After all, how do you know if that guy is actually working or daydreaming?

Eventually, design missteps will come to bite you when you discover that development can not continue unless you rework great parts of the application. Then even world class typing will not save you.

Developers will lose morale

To get any creative accomplishment, you need time and energy. Time is easy to enforce, energy on the other hand is not. Thankfully developers tend to be naturally motivated.

This form of intrinsic motivation will get you a long way but only if you allow it to flourish.

In ancient wars, if you were captured, the enemy would at times subject you (and other prisoners) to a death march. The essence of it is that the enemy would make you do intense labor on a march until exhaustion and finally death.

While a late project will not kill you, it still gives rise to the same emotions of hopelessness to the developers who have to work on a project that they know will fail.

Important activities will fall by the way

Important activities tend to not be the most urgent ones. This applies to software projects more than anywhere else. Having a looming deadline means that the team will focus on the most visible parts of the application no matter their importance. Eg beautiful carousel on the home page instead of writing proper interface to the payment gateway.

As you can imagine, this mounting technical debt will one day come collecting.

An even more subtle effect is that the developers will stop putting any time to their own self-development. You will thus slowly but surely corrode your competitive advantage. Even worse your best developers will eventually leave the organization.

I hope this has convinced you of the importance of sticking to your guns.

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

Growing talent via software reviews

The joys of being a new techie. That special time in your life when you have just learned MVC and now think you know everything. Good times.

Of course, everyone else in the team wishes they could slap the smugness out of you. Still, the energy is good and that is what will help the coder mature to a master engineer.

This will however not happen by itself. The senior team members must nurture the new talent.

One of the most potent ways of doing so is through a software review.

Unlike a retrospective, a software review is technical. Its focus is on the craft of software development rather than product improvement.

Some common outcomes of software reviews include:

Robust design
Code that is easier to maintain
More literate code. See Name well or go home
Fast growth of talent

So what exactly do you need to do to run a successful code review?

Before the review

Invite all developers on the team to the meeting
Ensure that everyone has access to the latest code
Highlight the objectives of the review

During the review

Gather everyone around one computer, or project code to a screen
Reiterate that the only goal of the session is to improve the design of the code, not to attack anyone. The entire team is responsible for the product no matter who wrote which line of code
The developer who wrote the code walks through the code explaining it along the way
Trivial details can be skipped
The other team members can comment on various aspects of the code such as naming scheme, reliability of external services and even choice of language if appropriate
Discussions on alternative paths are encouraged. This is meant to be a lively meeting, all ideas are valid
Improvement suggestions can then be agreed on by the entire team.
This process can be repeated for all team members

After the review

Team members should go ahead and implement the recommendations that were collaboratively arrived at
Remember the goal should always remain to improve the code

Have you ever carried out a review before in your own organization? How did it go?

Talk to me on my twitter @jchex or in the comment section below.

How to run a productive retrospective session

The Japanese have in their dialect a strange word, Kaizen.

It simply means “To change for the better”.

Now scrum is an iterative process. That simply means that you don’t just do everything in a linear fashion. Rather you do the best you can in the first round, review it and then do it again with the lessons learnt, rinse and repeat. This is our Kaizen.

Yet of all scrum practices, retrospectives happens to be the least likely to get done and if done likely to be the least effective.

A retrospective is simply the act of reflecting on the work that has been done during the sprint and seeing how it could have been done better.

In my opinion, the dismal effect of retrospectives arises from the fact that when improvement is brought up, the mind immediately assumes that something was being done wrong in the first place and now we are “improving” it.

This view could not be further from the truth. You see Kaizen philosophy is all about accepting change and making it work for us. This has nothing to do with being wrong or right. We could have done the best work but Kaizen tells us that there is still something that we can improve.

A good retrospective shines, it is the only way that a team can be truly agile.

You can tell you are running an effective retrospective when:

The entire team is engaged
Problems identified are depersonalised
The team, rather than individuals feel responsible
Each iteration, your process improves

So how do you steer your team towards more productive sessions?

Do it for the right reason

Don’t use this meeting as an opportunity to evaluate individual developers. In fact, don’t even use it to evaluate the entire team. The only purpose that you should have for this session is to identify valuable lessons from the just elapsed sprint that you can apply to future sprints.

Discussions on individual developer performance should be done in private.

Encourage open communication

Tell the team you encourage everyone to be open and that there will not be punished it. Here is the important part mean it!

Show genuine appreciation for all input that team members give. You don’t even need to agree with it, acknowledgement is usually enough.

Come up with an action plan

I am surprised at how many meetings I attend that leave without any actionable.

The team must identify.

Things that were done well that they should continue doing
New practises that could be incorporated into their software development process
Practises that are not beneficial and need to be stopped

The team must then commit to making the changes that they have identified.

Fun but no personal jokes

No matter your culture, do not allow anyone to make jokes targeted at any one individual. It is hard to know how the butt of the joke will receive it. Being an already difficult meeting you don’t want to make it any harder.

Don’t shy from hard conversations

As humans, we naturally avoid anything that can hurt us. Conversations on what went wrong have the capacity to hurt us because:

Stakes are high. The client paid you and messed it up
Emotions are high. No one wants to be blamed for the issues on the board
Opinions vary. There is almost certainly going to be different takes on the events that passed during the sprint

The only way you can improve thou is by having this crucial conversation.

See the book Crucial Conversations for more insight.

How do you ensure your retrospectives are productive? Talk to me on my twitter @jchex or in the comment section below.