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


Hidden Tension Between Sales and Development

Our boss once said:

 “There are people whose superpower is getting the signature on the dotted line”.

This may seem fairly obvious to other people, but to me, it was not. After all, a sale is an agreement to deliver a service (we are in the consultancy business) wouldn’t the people best placed to make the sale be the people who will do the actual delivering?

Well, I was wrong, as it turns out sales is an entirely different process from development. Sales tend to be more aggressive and charging while the development is more gentle and steady. These two forces complement each other, except when they don’t.

In this entry, I will be exploring some causes of conflict between the two teams and how they can be resolved for a stronger overall team.

Commitment to deadlines

Sales tend to be the first contact with the client. In some cases the client’s deadline is not arbitrary, something in their business environments such as trade show, shopping season or investor pitch is coming up. As the sales person, it is in your best interest to promise the client that whatever they need to be done will be done by that date.

The engineering team, on the other hand, has another belief set concerning deadlines, specifically:

    You can manage to deadline and let scope vary or manage to scope and let deadline vary.

This means that the engineering people can either work on a stripped down version of the product before the deadline or make no hard commitments but get it all done.

The problem then comes when the development team is given an engagement that just can’t be delivered within an already committed timeline.

To resolve this issue, the sales team should never give a time commitment. I mean this in the strictest sense, not a date on the calendar, not a range of days not even a ballpark figure without first consulting the development team!

Handling of issues

Let me let you in on a little secret, the dream of building a product from solid success to solid success is a beautiful one but only a fantasy. Nothing can save you from missteps in any non-trivial development.

To the sales team, problems are there to be solved. After all, we promised we will get this thing done and by God, we will!

The development team on the other hand does not like playing catch up, rather they would prefer to have a new planning session where commitments are renegotiated.

My take is that during times of great political risks, candour is a vital behaviour that maximises your chance of a positive outcome. After all, maybe, just maybe what you think is a big issue may turn out to be trivial to the client. Or it may be so important that they chose to have your work exclusively on that issue. Either way you have allowed them to exercise their proper role as custodians of priority of their product.

Unexpected “Aha”

During the normal course of development, the team may land on a great idea that would make the product 10X better. Of course, the same idea would also have the same impact on a competitor’s product.

If this is not a perfect opportunity for up-selling, I don’t know what is.

Perhaps because engineers are not typically compensated on basis of sales per quarter, they tend to see things in a different way. You see, human knowledge is never contained in one person. It grows from the relationships we create between each other and the world, and still, it is never complete.

Then to the engineers, this new knowledge seems like a gift to be given to the client team.

I believe the aim of any good engineering team should not just be to deliver to spec but also to delight the client with a beautiful product. Yet in the same vein, no development work should ever be done without explicit approval by the client. What may seem brilliant to you maybe garbage to someone else.

I will sue you

Whenever someone blurts out the words “I will sue them, you wait and see” I immediately get the impression that they have no idea how arduous the legal process actually is.

When serious issues arise in the project such as the client trying to poach the development team, the immediate reaction may be to channel all the energy used to win the client to now battering them.

Engineering culture, on the other hand, carries with it a different tone:

    Customer collaboration over contract negotiation

Yes, the client signed a contract, yes it seems like they are now trying to screw us over, no we will not aggravate the situation.

I believe that any contract is undersigned by a genuine human relationship, furthermore, this relationship is worth more than any piece of paper. Barring cases of outright hostility, all measures should be taken to preserve the relationship.

Have you ever experienced any tensions between your developers and your sales team? Talk to me in the comment section below or on my twitter @jchex


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


Why you should never give off the cuff estimates


This had been one of my longest meetings thus far. You see the team I was in, I was the only developer. The rest of the team was made up of different professionals including designer, UX specialists and animation engineer. Each of us was giving an update on what we were working on. From the buzz of the meeting I heard my name mentioned and the boss asked me “So Chencha how long will it take to enable applicants to use their existing profiles in their applications?”. Without much thought I immediately replied “five days”. The boss typed my response into her mac and moved on. Five days later an email comes in from another team lead asking how do they use the feature that allows applicants to attach existing profiles.

Since then am much wiser and would almost certainly never commit to a schedule just like that. Yet this scenario plays out in software agencies everyday. The client, the manager and sometimes fellow developers expect an immediate answer in days of when something can get completed. Giving an off the cuff answer to this kinds of queries is usually a bad idea.

In this entry, we will explore why this type of estimation is cancer to your project planning.

You will not remember to factor in less visible activities

Asked to give an estimate, most developers will think of the classes, methods, services and other such technical considerations. What will not immediately bubble up will be things like: Time supporting the current version, meetings, organizational commitments, emails etc.

That is, unless you keep a detailed log of all activities, you are highly likely to forget the more mundane ones. The problem is that even mundane activities take time to get done.

It would be wise to keep in mind H.L Mencken quip

    For every complex question. There is an answer that is simple elegant and wrong

With this then it is more important to ensure that the estimate you give is correct rather than it was given quickly.

Commitments are made to others

Unfortunately, many of us in the industry do not differentiate between estimates and commitments. By this I mean that whenever you say “I estimate that this task will take 3 days”, what the client hears is “I commit to getting this done in 3 days”.

In the entry Estimates, Targets and Commitments I delve more into the difference between the terms and how mixing them up comes back to bite you.

For this entry it suffices to say that the estimates you give as a developer feed into the plans of the rest organization. With so much weight, the opinion of how much time a task should take should not be done in a rushed manner.

Devaluation of the proper process

Typically, the estimation process is three step:

  1. Establish the size of the user story relative to other stories
  2. Establish how long it takes to complete one story
  3. Schedule the stories into sprints

Compared to just spitting out the first value that comes to your mind, this process takes a heck more time.

Yet this method still remains one of the most effective ways of arriving at dependable estimates. When you shortcut the process you end up unconsciously training the client to expect immediate estimates. This then ties you into a vicious cycle where your estimates are wrong, so the client asks for another set of estimates, which you then give off the cuff and they end up being wrong and the process repeats ad nauseum.

Accuracy goes off the window

By giving a precise value such as “this will take 3 days” you create the illusion of certainty. In reality, accuracy and precision do not always go together. Eg if I tell you “This will take me a week or so to complete” vs “This will take 5 days to complete”. Which one do you think is more precise? What about more accurate? Obviously the first one is less precise but will likely turn out to be true, the second one is more precise but if anything comes up and I no longer can deliver in five days then the estimate is no longer accurate.

With this in mind, you should then remember that estimates for user stories are given as a triangulation of the estimate given for other similar stories. This eliminates the need to be extremely precise since the estimates are relative.

Traditionally, it has been advised that you give a range such as “This will take 3-5 days to complete”. Personally I doubt the effectiveness of this strategy. Chiefly because being humans, we tend to conveniently forget values we don’t like. So you tell your project manager this will take 3-5 days but what they communicate to the client is that it will take 3 days. That is the range gets collapsed to a single value somewhere in the communication chain.

Do you give off the cuff estimates in your own organisation? Talk to me in the comment section below or on my twitter @jchex


Effective communication within software teams

 photo team-1928848_1280_zpsfklugriw.jpg

Humans are born with the ability and need to communicate. Their vocabulary initially consists of various types of crying: an empty belly, a wet bottom, cold feet, being tired etc. This vocabulary grows with age to include words, expressions and even writing.

By the time our baby is a productive member of a software development team, they probably have a couple of decades of experience in communicating under their belt. Unfortunately, this experience does not always translate to effective communication, especially for software development work.

What works well at the bar and other social situations does not work our as well in the development process.

In this entry, we will be looking at some of the steps you can take to make communication within your teams more effective.

Encourage openness

In government or at least as it is portrayed by Hollywood, they have a term “Need to know”. It describes data that is deemed to be very sensitive. Access to this information is restricted even for those with all necessary security clearance.

Somehow this mentality has seeped into how we do normal business. With the business people sharing only information that they think the developers need to build the product and developers only sharing what they think the client can understand and appreciate.

This insidious practice slowly erodes the trust that the team needs to communicate effectively. After all, how do you know if what you are hearing is all that there is or the other person is withholding something?

It is not enough to ensure that all information is shared, it’s equally important to give everyone a chance to participate in decision-making and the creation of new information. As humans, we naturally own decisions that we feel we had a part in making. This ownership leads to greater contributions of energy to the work being done.

This does not mean that everyone wholly agrees, it is enough that they can live with the decisions made by the group.

Keep the information credible

In the entry Is your backlog still relevant? we mentioned that if you don’t maintain your backlog it will atrophy and eventually be abandoned. This applies to all your other communication tools including documents, spreadsheets and other project management material.

Words are powerful, they give meaning and perspective, yet they only make sense in a context. The words used in your communication materials should be meaningful to all participants. In practice, that means avoid jargon as much as possible.

Eric Evans in his book Domain Driven Design describes ubiquitous language as:

   A language structured around the domain model and used by all team members within a bounded context to connect all the activities of the team with the software. 

This simply means that the language that you use should be meaningful within the context of the team.

It may be useful to have a project index describing what the words means especially for highly technical projects.

Keep it fun

By now I have started to gain a reputation as the “processes guy”. I don’t believe this rep adequately represents who I am. Rather, I believe that all we do should have some element of fun in it. If you don’t enjoy the process, no outcome is ever worth it.

This means that while you should respect the formal practices of scrum or whichever project management paradigm that you use, there should also be some room for informal collaboration.

This is what Alistair Cockburn refers to as osmotic communication, the variety of sensory modalities (visual, audio, touch, sense, etc.) that provide a rich set of collaboration clues

Even the ideas that come to the team members when they are not in an official setting should be captured in your project management system. As David Allen usually says:

    The Mind Is For Having Ideas, Not Holding Them

So then let your process allow for anyone who has an idea to express it as quickly as possible without having to wait for the next brainstorming session.

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