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

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to communicate your release plan

A release plan is simply the dates you expect to deliver on major milestones for your project.

The beauty of scrum and its sister methodologies is there isn’t too much ceremony around this information.

Really, once you get past trivial projects, you very quickly realize what is to be built is not very well understood. Any plan you come up with that ignores this fact is guaranteed to become a source of pain in the future.

I see planning as a search for value, if well done, it helps us answer the most important question for any software team. What should we build?

Its a consideration of the features, resources available and important dates. This then illuminates a possible path for development.

I find it ridiculous that some people write a detailed document complete with dates and then think they are done with it all and no further revisions are needed. A release plan should reflect the current context. This means the format you choose should be one that helps you best express your most current thoughts.

In this entry, I will be looking at some of the formats I have found useful for communicating release plans.

Outcome buckets

In a previous entry, I talked about Why I don’t assign deadlines by date

For context here is how tasks bucketed into weeks would look like.

Well, as it turns out, planning your tasks as such is also really good for presentation. You can very easily get a sense of when you expect things to be completed.

Even better, the system communicates a level of uncertainty, because you don’t have an exact date for any of the tasks, you know it can be delivered on any date within the bucket and the plan would still be true.

For highly uncertain outcomes, you can increase the size of an individual bucket, say to 1 month. This communicates to all stakeholders there is much more risk to the outcome but we will get it done early if we can.

Spreadsheets

Maybe it’s my finance background talking, but I must say I love spreadsheets!

I find it to be one of the most powerful tools to establish coherence of thought within whatever your team is working on.

As part of our communication kit, spreadsheets allow us to play around with the quantitative bits of our plan. For example, if we need to model what would happen if a story point takes 5 days to develop as opposed to 3 days, it would be trivial to do so with the tool.

There is a perception in the business world anything on Excel is more serious than on a goofy tool like Trello. The perception is wrong but since its there, why not make use of it?

Gantt charts

A Gantt chart is a staple of the project management industry. They are highly visual and easy to understand. As you can tell from the fact am using a stock image here, I am not the biggest fan of them.

TeamGantt sample
TeamGantt sample

 

The problem I have with Gantt charts is it doesn’t communicate the uncertainty inherent in any software project. Furthermore, when a date changes, you don’t immediately see how such a change escalates across all other tasks and further how the other outcomes are now more likely to take more time.

Not all of it is gloom and doom, because of its visual nature, its far easier for non-techies to grok it over say a spreadsheet.

Furthermore, for a high ceremony executive, a Gantt chat will likely fit better with the rest of the reports they have to go through for the rest of the day.

How do you communicate your own release plans? Talk to me in the comment section below or on my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Why you should always have an explicit agenda

I started my journey into the world of programming using PHP. Then there were no regular meetups in the community or at the very least I did not know of any.

Being one of the most popular languages of the day, it did not make sense to me why this was not happening, so I made a call for the first event. This was the first time I was organizing a community event, was not sure how it was going to go but my purpose was clear, meet and discuss all things PHP.

The turn out was good, the session started and essentially I said, welcome and discuss!

Nothing happened, everyone just stared at me blankly.

After a few painful minutes, Kirui, my boss at the time, swooped in to save the session. He took over and on the board wrote:

What will do for the next year?

What kind of events are we interested in?

What speakers are we interested in?

As if by magic, this constraint on what is to be discussed infused the session with energy and I learned a valuable lesson, one in which I hope to pass on to new group leaders today.

The group has now over a thousand members who communicate regularly on telegram and meetup.com

In this entry, we will be looking at why your meetings should have an explicitly stated agenda.

Provides clarity and support to the meeting purpose

A meeting without a purpose is a useless one. The purpose of the meeting answers the question, why are we having this meeting?

Even if you have one, you need to know when you have been successful in the meeting. This means you not only need the why you also need the how.

An agenda communicates your plan of action to meet the purpose.

In this way, you are able to iron out any inconsistencies within the group and have an objective way of knowing when you are done. No one likes 2-hour discussion sessions.

Help in self-governance

Life is what it is, at times you may need to step out of the meeting midway, perhaps leave someone else to deputize you. A clear and agreed on agenda means you have the confidence to do this and when you come back, find the meeting is still on track.

What I have come to realize about good teams is they give you leverage, allowing you to do 10X or 50X what you could do by yourself. But the only way to achieve this is if you are in alignment.

For directors, ie your direct reports are managers themselves, it is useful to thrash out what their agendas with their reports will look like. In this way, you get more clear and consistent results without having to attend each and every single meeting.

Agendas are not meant to be dictated from on high. By having a short discussion on what the agenda items should be, you reinforce within them the mindset they are in charge and you get viewpoints which would otherwise be inaccessible to you.

Understand when the agenda needs to change

There is a saying by Lewis Carol:

If you don't know where you are going, any road will get you there

Even as you run your meeting, you must remember, the agenda serves the purpose of the meeting and not the other way around.

An explicit agenda by definition specifies what is not to be covered. This provides a chance for the team to tell you what you may be missing and just as importantly what need not be there.

You then have the chance to remove what is not absolutely necessary to achieve your purpose.

Meetings should be time-boxed, if the allocated time is 30 minutes and you realize there is absolutely no way you can cover everything, then reduce the scope, remove some items from the agenda.

With an implicit agenda, such value budgeting is not possible, so what happens is you either blow past the end time or worse cover only the first items with no concern to their value in relation to the purpose.

Do you normally have a stated out agenda at the start of your meetings?

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

Facebooktwittergoogle_plusredditpinterestlinkedinmail