Month: June 2016

Scrum, one of the most important developments in management of software projects. The benefits of practising scrum are manifold. Implementing even one aspect of it is guaranteed to give results.

Yet while the mechanics of it are really easy to understand. Scrum in 4 easy steps. Getting the most value from it necessitates that you understand the principles that underlie the methodology.

You see while scrum is just one way of doing things, it espouses a deeper set of truths that all successful software project management practises must possess in one form or another.

Today we shall be looking at this three core principles.

Visibility

I don’t care what the Become a master developer in 21 days article said, Code is hard. For the uninitiated, there is little difference between python and heliographics. Unfortunately this has been used as an excuse by development teams and their managers to basically close their eyes and hope for the best.

This does not need to be so. Scrum shines light right into the development process.

With scrum you get:

1. An agreed definition of done. That way all stakeholders can test the software
2. Project standards. Ensure team members can understand each others code.
3. Progress metrics. Progress can be seen by all.

Inspection

Visibility would not be worth much if there was no one to see.

Scrum encourages frequent inspection of the work done to ensure that it meets the agreed quality and does not deviate too much from expectations.

This means that defects are captured earlier in the process and can be fixed rather than downstream where the efforts would be much more.

A side effect of this kind of process is that non performers are detected quickly. In a good number of cases this leads to push back on adoption especially if the said non performers possess political clout.

Scrum provides for this through:

1. Daily scrum
2. Sprint review

Course correction

The model of Predict and Control has been proven to be ineffective in software projects. This is because software is necessarily complex The heart of software engineering.

As such it makes no sense to pretend that the final product will be what was detailed in the spec document initially. Instead scrum allows the team to adapt to emerging truths as they work on the software and the managers to provide for deviation.

It does that through the processes:

1. Sprint planning
2. Sprint retrospectives

In a nutshell those are the principles underlying the practise of scrum and most other agile methodologies.

Have you exercised this principles on your own project? Tell me on my twitter @jchex or in the comment section below.

An aeroplane is one of human beings greatest achievements. Flying one of this beasts is a complex endeavour. Yet air travel remains one of the safest modes of transport, have you ever wondered how they do it?

A key factor in airline success is the preflight checklist.

Before any flight the cockpit crew go through a rather bizarre ritual. The copilot calls out each control on his list and the pilot makes sure each the switch is where it needs to be. No matter the years of experience or knowledge of the plane, this ritual is still carried out.

You see the checklist is not there to tell the pilot what to do. That is the work of the aviation school. Rather it is to ensure that nothing is missed.

Before we launch our own projects into production, we need a similar list.

Below is the list I use myself, I literally have it pinned on my wall, hope you find it useful

Look for and remove dd tags

In laravel there exists a special method called dd short for dump and die. This is an extremely useful debugging tool. This checklist item should remind me to actively look for and remove all debugging aids in my code.

Ya ain’t gonna need it

The truth is that you are not likely going to complete all the features you set out to do before the next client presentation/deployment. This item reminds me to gracefully shutoff paths to this features. Perhaps redirecting to a In progress page or logging stats of how many times users tried to access the feature.

Squash it

I find it counter productive to spend too much time fixing a bug. So at times I push it back to the backlog to be worked on at a later time, when my subconscious has had sometime to chew on it. Before launch however this checklist item reminds me to definitively deal with the bug.

How fast can you go

Now is the time to see if your app can handle a thousand hits a second or the equivalent of such a load. This can be as simple as writing a curl script to bomb the staging server. For more advanced projects, a profiler like newrelic will be an invaluable tool.

Fake it till you make it

Sometimes some pages just have to return fake data or a really watered down version of the original feature. Now is the time to make that call. Also Ya ain’t gonna need it is always an option.

Grammar nazi

This is the time to go through user facing documentation to ensure the English does not betray my kindergarten teacher. A spell check through the view files also comes in handy at this point.

Do you have a project completion checklist?

Share it with my on my twitter @ jchex or on the comment section below.

 

A fine Monday morning finds me sitting across the client. Clearly a powerful executive. Next to me is my immediate boss negotiating for our side .This particular meeting has been called because the client needs to go over our proposal. So far all is good and our price and timeline seems fair.  All nice and dandy before this conversation happens:

Client: We like the product concept, do you think would be too much work to build an Android app as well? A lot of our customers are on the platform

Project Manager: Not a problem what would you like added

Client(Pointing items on the proposal): This and this screens

Project Manager: The team can definitely handle it, what do you think Chencha?

Me: Yes we can

Client: How long will it take and how much will it cost us?

Me: I will have to sit down with the team to evaluate and prepare a new proposal

Client: That is ok, but what about a ball park figure?

Me: At the moment we can’t tell but we know it can’t be more than 4 weeks

Client: That is too long and we must have the android application before our launch in June

Me: I am sorry that is the best we can do

Project Manager: But of course we will meet the target we understand the urgency of this product

What just happened there?

Before I explain let us first delve into some definitions.

What is a software estimate

A guess for the time it will take your development team to complete a task.

What is a target

A point in the schedule to meet. Think about it as an ideal deadline circled in red on your calendar

What is a commitment

A commitment is an agreement to complete a task within a certain time frame.

Yet there is an insidious relation between mixing up the terms and ending up with a failed project.

In preparation of your proposal you have to give an estimate. But you and the team understand that at best the estimate is just an educated guess. The release schedule which represents your target is also based on that guess. The problem is that for most work, the target is set externally to the development team. You then end up in this awkward situation where the client and thus your business would rather have you massage your numbers to ensure that the release schedule hits the target date.

In the case above we had put in our best estimate for the project which the client would have wished was shorter but accepted it none the less. Problem now was  he wanted more things done and did not want to adjust the schedule commensurately.

Even worse the project manager just agreed to a near impossible schedule. And here is where we get to our last term, commitment. While you can easily renegotiate or even publish new estimates and thus targets. Commitments for most part are legally enforceable agreements.

Now while the project manager in this case meant that we could estimate the extra work to get done by June. The client interpreted that as a commitment to get the work done by June!

By trying to please the client, we have just found ourselves in a situation where the client will likely not be happy with the time it takes us to complete the project, no matter how fast we are!

Thankfully remedies exist for this exact situation:

1. Separate size estimation from time estimation. See Invest in user stories
2. Separate costing from estimation. Bill per sprint
3. Ensure to explain to the client that estimates are just guesses
4. Select a project management model that shows progress. Agile practises are perfect for this

Have you ever been in a situation where the distinction between estimates, targets and commitments came into play? Share your experience on the comment section below or tweet to me @ jchex