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

Sources of change in a software project

 

Change is an integral part of the software development process. It’s what makes software soft. In fact, change is so important in software that it get’s it’s very own line in the agile manifesto

    Responding to change over following a plan

It’s been a long time since software teams believed in the unchanging quality of requirements documents, but we are yet to fully understand where change comes from and how it affects us.

It costs far much more to make core changes during development than it does at requirements. Boehm and Papaccio estimate it at 50 – 100 times more. Even with the advent of agile techniques, it is still worth it to control change as much as possible.

In this entry we shall be exploring the various sources of changes, this should hopefully help you anticipate and identify impending changes as soon as possible.

Change from the customers

Of all the sources of change, this is the one worth most consideration. The reason is that as a consultancy or even engineering department, you want to harness change as a competitive tool for your client.

No matter how well you run your requirements gathering sessions, there are requirements you are bound to miss. This is because knowledge builds on knowledge ideas on ideas.

To illustrate this point, think of a car. The first car was a very basic box with wheels that happened to move. But from this idea, people began asking questions such as:

  • Why can’t the seats be more comfortable?
  • Why do I have to be hot in the car?
  • Why do I have to manually change gears?

Today, these previously extraneous features are deal breakers.

In the same way, once development has started, your customers are guaranteed to have new ideas as they see your progress.

In this kind of situation, you want to carefully weigh your options. You don’t want to do exactly what the customer wants you may end up always chasing after the new shiny thing. You also don’t want to completely ignore their wishes under the guise that you know best.

Change from sales and marketing

This part particularly affects product companies.

The product owner declares this Big Hairy Audacious Goal

    We will build a one stop best in class application within the next 6 months

This is a great goal and everyone is excited about it. The engineers get to work “banging” it out. Somewhere within the development window, the competitor does a release that you had not even thought about. The sales team also wants to be able to sell the new feature so they insist that is also put in the product after all our product is best in class right?

It is tempting to think of your application as a big checklist of features, this is dangerous because then you will be locked in competition with other firms to produce more and more.

Kelly Walters makes a compelling argument in Agile Principle 8: Enough Is Enough! that you likely don’t need to develop 80% of the features.

Perhaps then the product owner should have come up with a better goal say

    We will build a product in the next 6 months that will improve our customers margins by atleast 10%

Change from developers

Developers, my favourite group!

More than any other stakeholder, developers have the highest intellectual and emotional investment in the project. They are the ones who had to deal with the design flaws, unexplainable bugs and late night coding.

Yet to them, requirements are usually provided as a checklist. In this case am also looking at a list of user stories as a checklist. Without an organising theme, developers will do what they do best, write the best-designed code that they can conceive off.

The problem here is that the devil is in the details. Your DBA may end up writing code that shortens query time from 10ms to 1ms. This is great, except for the fact that no one really specified that they have that requirement. Another example would be where your front end engineer goes out of their way to guarantee that the settings page will work for all screen sizes.

I believe by actively watching out for this sources of change, you will be in a better position to manage them when the changes do come.

What are the sources of change in your own projects? Talk to me in the comment section below or on my twitter @ jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

What is in an estimate?

 

It is easy to think of an estimate as one figure. Intuitively, it would seem that a feature such as a user management dashboard should take 5 days to build.

When we ask for an estimate from a developer, then what we expect is this single number.

Yet this single number can be quite misleading as we talked about in Why you should never give off the cuff estimates

You see the number of days it will take to complete any feature is not some kind of physical truth, rather it’s a derived quantity.

In this entry, we shall be looking at how the variables that determine the final delivery date interact with each other.

A trip home

I live and work in Nairobi, once every while, I travel to my hometown in Kisii county. Suppose I called home and told them am coming, the very first question they would ask would be

    What time do you expect to arrive?

This question is a simplified version of a client asking a developer, When can I expect feature X?.

Based on my experience travelling home, I probably would be able to give my family a solid estimate fairly quickly. But let’s suppose I did not know much about the trip, then how would I go about coming with an estimate?

How many Kilometres are there between Nairobi and Kisii? (Size)

This is the most important variable and the only one that exists independent of my activities. The distance between Nairobi where I am and Kisii where I want to be is representative of the work that needs to be done.

It is highly likely I would be able to agree with other people on the distance if nothing else.

If our estimate of the distance was to vary, then we probably don’t have a shared understanding of where we are trying to go. Eg if I estimated the distance to be 500km and my brother estimated it at 800km we are probably talking about different destinations or thinking of different roads.

In software, story points are used to indicate the size of the feature. Estimates of story points from different team members tend to cluster around the same value. In case there is a lot of variation, a discussion should ensue. It is probable that there is some misalignment in what the feature is about.

What are my means of transport? (Velocity)

When it comes to speed, means of transport is the most important factor. Will I, for example, be walking, driving or taking a flight. The different means have speeds that once more cluster. For example, walking can be done at 5km/hr driving at 100km/hr and a flight at 800km/hr.

Velocity is likely to vary even for the same classes of transport.

In software teams, velocity is measured via either story points/sprint or features/week. I personally prefer the first measure. While you can estimate this value, the most accurate values would come from looking at how you have performed historically. That is, what is the average velocity you have experienced over the last say three sprints.

The velocity is determined primarily by the skill level of the team followed by the morale and number of team members. In engineering folklore, it is said that the best engineers are 10X as productive as average engineers. Whether this is literally true or not, from experience, I know that progress is much faster with a senior team.

In an ideal situation, how many hours will it take me? (Duration)

The road to Kisii is full of perils. From a couple of black spots, flash flood areas, escarpments and corrupt public officials, there is a lot that can delay your trip. Even with none of this dangers, something as simple as having lunch is likely to increase the time it takes to get home.

So when we think about the ideal situation, we must think of the sunniest day where everything is clear and you maintain a constant speed from Nairobi to Kisii.

To derive duration we can, therefore, employ some basic math:

    duration = distance/speed

By using this computation, we can then arrive at the ideal time it will take to arrive.

Similarly, in software, we can calculate the number of story points or features we will deliver in that time period.

    time to delivery  = story points to deliver / velocity
    weeks to deliver features = no of features / features  per week

In practice how long will it take me? (Calendar time)

In real life, you have to eat lunch. Our task at this time is to determine how much time we will take considering the vagaries of life.

Suppose from previous trips, I know that I usually face some delays such as:

  • Jam at the escarpment (1h)
  • Slow traffic at flood plains (0.5h)
  • Lunch (0.5h)

Once I have arrived at my ideal duration, I would then need to add these hours to it to arrive at the calendar time.

    estimated calendar time = ideal time + expected delays

Similarly, in software, there are a lot of factors that affect feature development that is not part of development. In the entry When to ignore historical velocity we talk a bit about such factors.

So then for the software team, once you have arrived at your ideal duration, you can now add in external factors to the estimate to come up with the calendar time. This value is what the client and other stakeholders will likely be interested in. To ensure the estimates are dependable, consider some of this tips

Do you decompose your estimates and in what way? Talk to me in the comment section below or on my twitter @ jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail