Lean Projects - Part 1

I have had the pleasure to start a new job for a very well established agency. As with every company, managing projects is not easy. However, what makes this company particularly interesting is the shear growth they are going through.

As with any start you get the opportunity to look at things from a different point of view. This has given me the ability to asses the way things are done. What I will present is how things currently are done and the parts that I don't personally like. This points will be discussed and I will propose a way of addressing them, which I call Lean Projects.

Project Management

The system of choice for managing a project is called podio. The cool aspect of this tool is that it keeps all communication in one place. Emails should not be used to communicate in a project. All tasks are created and tracked under the specific projects. A lot of tasks are created by the project managers and assigned to the developer. Sometimes these tasks will take precedence over what is currently being worked on. What are some of the issues that I have found with this approach?

1. The tool doesn't show not you overall visibility. This makes it really hard to prioritise and forecast, or even plan.
2. The tasks are assigned to developers without always knowing what they are working on. Unfortunately this approach is reactive and it causes too much context switching.

Time sheets

The one thing that I have disliked about this tool is that each individual enters the time they spend on each task. Why don't I like this?

1. No one tracks time efficiently.
2. The time is never really accurate.
3. If you have estimated a time you are more than likely that you will just enter that amount.

So we got introduced to an expansion pack for Scrum Development Pack for podio, however it still records everything in hours. I have worked in a few agile projects and I have found that this process does not work for software development.

So why do they do it? Well this is quite simple. In agency work it is all about billable hours. These billable hours are then passed on to the clients. No billable hours = no money = no job. The last statement is a reality however it makes me sad thinking about it that way.

Requirements

As with any business that delivers software we need to gather requirements. This currently is achieved by meeting with the client. We have some great people that really understand the client and the product. Once the meeting is over, all of this is documented in google docs. These docs are first used as a WIKI and then cleaned up to turn into a requirements document.

The developer will add questions to this document that will be answered by either someone internally or the client. The idea is to try to get all the requirements down so that the developer can estimate. Does this sound like waterfall?

Estimates

Since we have the concept of billable hours we need to estimate the time it will take for a feature to be built. Estimates are done for multiple features, once that is done it is often multiplied by a factor to give it some padding. This estimate is needed as the client needs to sign of on it. So how is this estimate carried out? Well from what I can see, it is done as a gut feel, or as I've heard it by using your life experience. What are some of the issues with estimating in this manner?

1. One does not always know what needs to be done and people tend to be very optimistic.
2. Studies have confirmed that most people's intuitive sense of "90% confident" is really comparable to something closer to "30% confident".
3. No one ever thinks about the non functional requirements.
4. A lot of assumptions are made, which usually are wrong.

Some great articles on this topic:

1. Why Software Estimation is Hard
2. Why is Estimating so Hard?
3. Estimation is Evil – Overcoming the Estimation Obsession

Planning

Unfortunately I have not been involved in any planning session, though I expect that this is due to me just starting there. They have a concept of a WIP meeting. During these meetings we go through the whole list of projects that are being worked on. After this we are taken through all the new work coming up. This meeting goes for about 30-60 minutes. This is done once a week with the whole team.

My first impression is that it is too much information to deal with at the meeting. This reminds me of a really big standup where half of the team just switches of.

As a development team we meet every day to talk about what we are doing, however I find that we jump into solution mode rather than do analysis. This is hard as we are nerds and we like to think that way. The rest of the teams seem to meet quite regularly too, which is always great to see.

In part 2 I discuss how we are going to tackle each of the issues