Month: August 2016

 

What is the shortest sprint planning meeting you have ever walked into?

For me, it has to be one that went like this:

    Developer 1: Ok so let's keep this short so that we can get back to work
    Developer 2: I agree, this place has way too many meetings this days
    Developer 1: (Laughs) True true
    Developer 1: So you will do the backend I do the frontend
    Developer 2: As we always do
    Developer 1: Awesome meeting over!
    Chencha : But what will be done in the sprint?
    Developer 2: What is on the TOR doc

At that moment I thought they were playing a prank at my expense. Sadly, they weren’t. As it turns out they did not know what to discuss on this particular meeting.

On this entry I will be sharing some of the discussion points that I have felt led to a more lively sprint planning session.

Break down requirements to user stories

Unless you are one of the lucky few who work with clients who understand agile, you are probably stuck with a legally enforceable TOR. Still no need to despair, we can still recover.

Use this time for you and your team to actually break down the massive document to user stories. Pin the stories on the board or trello. Depending on what your team usually uses to visualize work.

Use planning poker

Planning poker is a technique where individual developers give their estimate by first writing it down in private and showing it to the rest of the team concurrently. This ensures the estimators don’t influence each other.

Once the estimates are made, don’t just stop there. Ask the person with the highest or lowest estimate why they think the item is of that size. This practise should elicit some discussion within the group.

Establish objectives

In the 80’s, professor Noriaki Kano came up with a model that classified customers preferences. Basically there are features that the customer just can’t do without and there are some that the customer wouldn’t know they want until you show them. You must weigh the features you aim to develop on this scale.

Have the team discuss the project and distill the objectives of the project.

Once this is done, the project will achieve efficiency advantage in the trade-offs that they will inevitably have to make.

Break down user stories into tasks

User stories are rarely small enough to code. This meeting presents a great opportunity to discuss the tasks that make up a user story.

Take the case of this user story.

    As a customer
    I want to search the store
    So that I can see what is available

Now that story can be broken down to

1. Install elastic search
2. Connect elastic search to laravel
3. Write endpoint logic for the search term
4. Return response as json
5. Write html to display the results

Developers can deliberate and come up with the most exhaustive list of tasks possible.

Determine velocity to use

The general rule of thumb is to use the last iterations achieved velocity for this sprint. This meeting presents an opportunity to review the rule and see if it makes sense in the current context.

Respect the Timebox

The purpose of this entry was to discuss how to make your meeting more lively. However if you push it too far, the team may not look forward to the next meeting.

Ensure to state how long the meeting will last before it starts and respect that timebox, no matter how fun or engaging the meeting becomes.

How do you liven up your own meetings? Talk to me on the comment section below or on my twitter @jchex https://twitter.com/jchex

 

How would you like to shave 20% of your development time? How about 80%?

As Peter Drucker once put it:

    There is nothing quite so useless as doing with great efficiency something that should not be done at all

Vendors and the tools they produce help us avoid coding up features that could be more cheaply bought.

They come in all shapes and sizes including:

1. Open source libraries (apt-get, bower install, composer install, pip install etc)
2. API services (Apigility, NLP tools, Lorem generator etc)
3. Cloud services (Firebase, Queueing , Realtime push etc)
4. Frameworks (Django, Laravel, Angular etc)

And many more.

Considering how crucial all this vendors will be to your application and by extension your business. How do you choose which ones to use?

In this entry we look at some of the considerations to make when choosing a vendor.

How long has the vendor existed?

Experience is a harsh teacher but it teaches true. You want the builders of your tools to have undergone the test of time. Being a new product, your application is guaranteed to be teeming with bugs. You don’t want to ever be unsure if the bugs are in your code or the vendor’s code. Having a mature tool means that the vendor’s bugs have mostly been taken care of so now you can worry about your own bugs.

You should of course ensure that their experience has informed their iterations. Look at the release notes for signs of improvements over the various versions.

Are they committed?

For commercial products, it should be evident that the product they are peddling is an important one in their portfolio. Peripheral products suffer the risk of abandonment on short or no notice at all.

For open source projects, look out for a core team of long term contributors. You can bet this contributors have given their soul to the project and are not likely to give up on it now.

What would happen if vendor abandons it?

A lot of projects would wither and die if the project sponsor abandoned it. Some projects however have managed to attract a community around it and some even have an entire ecosystem.

The second kind of project is the one you want to use on your development. You can be sure even if the vendor abandons it, there will be a line of others waiting to support it.

Can you maintain the project?

If the tool is critical to your product, then you must consider your own ability to support it. In addition to the risk of abandonment, you also face the risk of the vendor evolving the product such that it no longer matches your priorities. If that does happen you must have carried out due diligence to ensure that:

• The source code is available to you
• The code quality is of an acceptable standard
• You have personnel with the requisite skills

How do you decide which vendor to use for your own product? Talk to me on the comment section below or on my twitter @ jchex

Managing software projects is not easy work, but once every while you do get a break. As the gods would have it, this was my day. Everything was going swimmingly well, we just had a couple of bugs to close before the client demo next week. The developer on the team was a solid engineer, his code quality said so.

On this particular day we were having our final review. 5 minutes into it, the developer is not yet in, no worries. 15 minutes later he is still not in, try to call him he doesn’t pick up. We suspend the meeting to the afternoon in the hopes that he will show up. Afternoon comes nothing, evening nothing. The developer goes on to disappear for the entire week, picking up only once to say “I will call you back”. The call never came.

In a previous entry I talked about Hidden risks to project success. Today I will expound on the biggest risk of all, human failure.

Paradoxical relationship between money and motivation

Developers for most part are self motivated individuals. In your hiring process you maybe shocked to find someone who has written multiple open source software, put products in the market and contributed to their community.

It easy to conclude that if they could do all that for free, then imagine what more they could do for money!

Unfortunately this conclusion is wrong. Somehow when you pay the dev to do the work they were previously happy to do for free, the magic disappears. I wish I had a cookie cutter solution for this phenomena. Still I have learnt if you can somehow find a way to give authority back to the devs, the results can be amazing.

Here of course I assume you are paying your developers reasonable rates.

Ineffective management

The field of project management has matured and is now a degree course. As it turns out, your PMP certification does nothing to prepare you to manage a software project.

It is said you can learn more from one failed software project than an entire lifetime in any other field. Software presents challenges that no other project presents. If I had to narrow it down to just one factor. I would have to say it’s the fact that the design is the product. To understand the gravity of this concept, imagine a building project. First the architect draws up the plan, then the builders get to it and get the building done. If the design is successful then future builders can reuse the design to build a new building. In short the work can now move to refining the process by which design is converted to product.

In software once the code is written the only work to be done is to compile it. Every new piece of software represents new design. The elements that can be reused are at best libraries.

This means as the project manager you have to deal with design problems and risks that are novel each and every time.

Unless the project manager understands this fundamental concept, they will continue with hacks that worked in the past such as:

• Adding more people to the project late to get it done faster
• Overly detailed project plans featuring Gantt charts, CPMs that are accurate to the hour
• Encourage Code like hell mentality

This tactics slowly kill the project from the inside out.

Hiring

There is no single factor that would give you assurance of the quality of your hire.

• Not their contribution to open source
• Not glowing reviews from past clients
• Not even a previously successful project!

The reality is you will eventually make a terrible hire. When that does happen the results can be disastrous. You will see it in poor designs, increased rework and communication break down.

Hiring them in the first place can be forgiven, what can not be forgiven is keeping them on the team. The rest of the team will degenerate in performance to match the poorest performer, do not assume that the new hire will be the one to catch up.

Ramp up time

When a dev gets into her flow, everything is magic. She merely needs to touch the computer and quality code practically writes itself.

Before this magic moment, there is time they just don’t understand what is going on. This is especially evident when you drop in a dev to an existing project.

It may take a few minutes to understand a concept note, but it takes days or even weeks to grasp the technical requirements that will bring that concept to life. Give your developer the time she needs to acclimatize herself to the project. Factor in that time when planning the project.

What are some of the personnel issues you have run into when running software projects?