Are you still agile?


Some of the most basic principles in productivity are ignored on the basis of it being too stiff. For example, the advise you should put everything you want to do on the calendar is usually met with some form of trepidation, after all, who wants to live their life in a straight jacket!

Yet, there is a certain freeing dimension to it, you now can be sure what you want to do actually has some scheduled time to it. This effect however only kicks in if you also realize you own your calendar, you can switch things around if you wish, subject of course to other work constraints.

Agile practices offer you a similar kind of freedom. In fact it does you one better, you can even change the structure of some of its most prominent variant, scrum, to whatever best fits your organization!

But then, when does agile stop becoming agile?

In this entry, I will be exploring some of the core characteristics of agile which I believe if you are not doing, you need to call your practice something other than agile.

Is there a timebox?

Scrum depends on timeboxes.

I believe a timebox is so important, it’s not even just a scrum or even agile principle, it is a life principle!

A timebox does to your life what a budget does to your finances. Without a budget, your money will likely disappear to the first expenses which happen to occur. A budget helps you be mindful of other important expenses which may not be as immediate but are as important.

In a previous entry, I discuss why and how to timebox.

If you ever find your team working endlessly with nothing to show for it, you are probably violating these principles.

Are features working?

Life happens, sometimes you are just not able to deliver on everything you said you would.

I used to work with a developer whose goto statement was:

This is just about done

It seemed all features were 90% done and nothing was ever 100% done. Thankfully, he has since moved past this stage and now provides fully functioning features useful to our end users.

If you find yourself in a similar state and still continue as if nothing has happened, then you are living in some form of denial.

As humans, we are good at recognizing when something is done or not done. The various shades of incompleteness bring nothing but confusion to the team.

It is tempting to mark a task/feature as complete if it does look nearly complete, but as our product manager likes to remind me:

If you tick of this feature, you are being dishonest with yourself, it needs to first reviewed, integrated and documented

Is the backlog prioritized by business value?

After being with Twiga for a couple of months, I was getting quite confident in my knowledge of the product.

In fact, I was quite sure I knew more about the product than say the agents its meant to serve who only use it as opposed to us who build it.

Such hubris never takes you to a good place.

I was relieved of this disillusion from a field trip where I observed one of the agents use a trick to quickly add a new delivery, a functionality not officially provided.

At this moment, I came to realize the end users of a product have access to a certain view of the product not available to myself or anyone else in the development team. Just because you wrote it does not mean you have hands-on experience using it.

This incident taught me not only an important lesson in humility but also, your backlog should not reflect your priority, it should be an expression of what your end users care the most about.

Are there estimates?

A common pushback when asking for an estimate from the developer team is we have no idea how long this will take.

I don’t think this is ever true.

Let’s take an example of my trip to work this morning. Will it take exactly one hour from my gate to the office?

Probably not.

Does saying it will not take one hour of any use? Does that mean it will take 2? Maybe 12 hours? Of course, I know from experience this is also not true.

In fact, I can say with confidence, over the last 30 days, it has taken me between 30 mins to 1.5 hours to get to the office. With this information, I can guesstimate with 90% probability if I leave the house at 7 am, I will arrive at between 7:30 and 8:30 am.

The numbers above may not be pinpoint accurate but they sure as hell do communicate a lot more than I will not reach at 8 am.

Furthermore, if I now actively start tracking my estimate vs actual values and reflecting on possible causes of variance. I generally get better at my estimation.

The questions above are not meant to be comprehensive, but I have come to find by constantly asking them. We are able to evaluate if we are still on the right path in our process.

How do you know you are still agile? Talk to me in the comment section below or on my twitter @jchex


Sources of uncertainty in a software project

Years ago, I discovered the power of process. Through the work of David Allen and his GTD Process by following a simple process I no longer dropped balls in my work.

When I started managing people and projects, I figured if there is a process for managing my life, surely, there must be one for managing teams. As it turns out, there was, scrum is an incredibly powerful technique for enabling teams to self-organize and deliver value.

On this path, I have come to realize the process is not enough. In fact, it seems the question “What is our process” is not as valuable as asking “How are we managing our risk”.

It seems no matter how much you stick to the process, the universe has an unlimited number of curve balls all lined up for you.

In this entry, we will be looking at some of the more common sources of uncertainty in software projects.

System requirements

Time and material model of software development is still dominant. I don’t even blame the industry, after all, once you get high enough in the organization, features against a budget is a first good approximation of the ROI of your dev teams.

The only problem with this view is it ignores the aspect of time.

You see, the more the time, the more the events which imply the business has evolved at a rate dictated by its market and innovation pace. It follows previously valid and useful requirements are no longer aligned with what the business needs.

I have come to find, in real businesses, there are no well-poised problems. What you will have to learn to deal with messes.

How will you cast these problematic situations to problems your dev team can solve?

Available engineers

The advent of coding schools has really helped alleviate the general problem of lack of developers. Unfortunately, they have not done much for the population of senior developers.

It’s very different to build a toy problem that calculates tax to be paid vs building a full-on accounting module taking into account all the nuances of the Kenyan tax code.

Even if you are able to solve the problem of getting experienced engineers in, you now face the secondary problem of ensuring they understand your business.

I have been in two-hour brainstorming sessions to understand how to map common directions parlance to how our business thinks about locations. How do you onboard this knowledge to a new engineer?

What would you do if your longest serving engineer receives an offer from Google?

Organizational politics

Your first true brush with power will be in an organizational setting.

As long as you had sane parents and teachers, probably the worst that could happen to you would be a good spanking, nothing to fret about.

Your boss, on the other hand, has the ability to infringe some major pain in your life.

In this kind of setting power can be used to trump reality with disastrous effects.

HiPPO (highest paid person’s opinion) means the organization may never achieve alignment. How can you build a software product when different stakeholders in the same organization demand mutually exclusive features?

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


How to mess up an already messed up schedule

In the recent past, I have found myself where no project manager wants to be. A deadline is fast coming and despite commitments from the developers, unless Jeff Dean joins the team you are screwed.

I will admit, on the way here I made a lot of mistakes, the most important being I failed to bound my uncertainty. You see when we started missing key milestones, I knew for sure we would not make the release date. The problem is I didn’t know how much we were to miss it, would it be a day? a month? a year?

In such situations, panic is practically inevitable. It’s only the most sophisticated companies that don’t jump into the code and fix model at the expense of a solid development practice.

In this entry, I will be sharing some of what I learnt and what we did to get to where we were.

Add more staff

If takes 5 painters 8 days to paint a house, how long would it take 10 painters to paint the same house?

You must have come across such a question in your high school math. How well do you think it plays out in the real world?

Suppose the contractor painting the house is in a tight market, after the first 5 expert painters, it became much harder to recruit new painters so the remaining 5 are either novice or intermediate, how does the math work out then?

What if the house must be painted sequentially?

What am alluding to is the ideal situation never plays out in the real world. These models gloss over a reality known to all managers, people are fundamentally unequal, diversely endowed in mental capacity, agreeableness and stick-to-it-ive-ness.

Further, new members are generally not as productive, no matter their technical knowledge, they are lacking in domain knowledge which is arguably more important.

In short, when its crunch time, you are better off sticking with your existing team.

Cancel continued education

Let us think for a second about the painters from the last section. If you are the owner of the house and you know there is a tornado coming your way, would now be the best time to be painting?

When faced with a crisis, the immediate reaction is to shut down all optimistic activities. What is the point of learning if you will never get to use the knowledge?

In this case, continued education will act as our proxy for all long-term capacity building activities which have no immediate tangible benefits.

The problem with this approach is you never really fix the fundamental problem. For example, when we noted a certain technology was not working out, the solution was to double down on what we already knew, this solved the problem then but later the same problem manifested but now in a different form, new features suddenly had an exponentially longer delivery time.

Even in the most dreary of times, you can not afford to ignore the education of your developers. It’s one of the key factors which when there encourage motivation and when not there drain it.

Extend the work day

There is something visceral about seeing people in the office doing the work. Just like the number of painters problem, the number of hours per painter is a variation of the same kind of thinking.

Here is what David Allen has to say on the topic:

 How much does it take to have a good idea?  Zero.  You don’t need time.  You need room in your head

I don’t believe any developer can code continuously for more than 6 hours. Add in breaks and you have a hard limit on a 9 hour work day. Anything more and you literally have zombies in the office, let them go home.

Software development is a creative exercise time does not matter as much as clarity of direction and mental space to think through ideas. This arises naturally when the developers have had a chance to rejuvenate themselves and spent time with their families.

Further, an insidious outcome of this move is people find a way to compensate. Suddenly people are sick more often or even just spend more time goofing around.

In conclusion, when things go wrong, don’t panic, orient yourself to the new reality come up with a revised plan and stick to the process.