Drive-by consulting

Understanding the way a business works, then giving advice on how it could be improved is the lifebread of consultants. This however needs time, preparation, experience and knowledge, int that exact order. Still there are times, when you just have to improvise all of those.

If all goes well, I will soon be joining the ranks of a prestigious company offering consulting services. I’ve been on sabbatical for about half a year, and have not had anything to rush for.

Just a week before the deadline for closing the deal on my next contract I’ve received a call from a friend, who recently started in angel investments. He asked, if I would be free to have a look at one of their startups. The angel investors are too busy to do it themselves, but there seems to be a rough patch, the company needs to overcome. They needed an instant consultant. I put on the emergency lights, and in half an hour I got to the scene.

The scene I arrived was just another of your cosy early startups, two adjoining rooms, with sense of thrown-togetherness. With the high ceilings, it resembled an overinflated, chaotic dorm room, thankfully without smell of rotting socks, food and objects better left unnamed.

Upon impact I joined an owners and investors meeting, where the angel investors, who summoned me, came forward with their concerns. The team is very promising, they said, but after the first results, the speed of progress diminished, and the quality of the product sank dramatically. They asked for the team’s opinion. This was a critical point where I would have just turned around and left, if went differently. But the CEO has admitted to all that, as well as stated they are baffled by the outcome and have no idea how to improve. This was frank, outright honesty, that was required, if we wanted to do the otherwise impossible, and turn things around.

During the meeting it transpired, that we are just in the sweetspot of time for changes. They are developing an online application for use by the masses, and are to be sold to large providers. They had great ideas for feature, but had no time to properly implement them, so a major scope simplification was already done. Still time slips out of their hands, and they hardly achieve the goals. They have realized the problem, realized that they need help, but still are not disillusioned about the company. It turned out, their lease was up, and would be switching offices soon.

I’ve seen a number of problems from the start, but all could be chalked up for the relatively little experience they had in running a company, as well as the unrecognized need of transformation from R&D to production mode.

Since I had no time to study them,  prepare an agenda, we kicked off with the first  chapters torn out from the book of management. 

Vision and roadmap

We all know what we want to do, and how to do it, don’t we? Of course! Not.

The first goal was to define the goals for the next release. I’ve first asked for the functionality of the product to be defined. It was done overnight and I was quite impressed. It’s not worth spending too much time polishing it, but you must define your target. Understand and visualize what obstacles you must overcome. Assess the value of the parts, so you can focus on pursuing them in order of importance.

During the next day, the feature list was broken down to user story one-liners. It’s not much and way of the charts mandated by the Scrum framework, but there is an understanding of the features among the participants, also we are playing for time here on both sides. We have reached in two days, that the features and broken down to individual tasks, all individually set to business value. No story points or estimations are involved yet. Too early to jump so big, so fast.

From this we can and will branch to two directions, quantity and quality.

First of all, the quantity: functionality. The first actual backlog was produced on the fourth day. It is prioritized and the first sprint is created  by simply taking the first part of the list. It will be used to assess the velocity of the team, as well as for refining the way the tasks are defined later. Right now it’s too high level, but we have to go with it.

The second focus is on quality. Since the vision and task management was completely missing, testing was a shot in the dark. Using the business value and the approximate expected usage frequency, a test suite can be defined. The suite will be designed, so the tester will know what to do for testing sprints, releases and will have a pre-presentation checklist as well, so preproduction, customized applications can be verified to avoid the well feared “demo effect”.

Time management

Time management is something that is not thought in school, little it is required for passing university. It is mandatory for running a business, as well as living a normal not overstressed life.

We started with the CEO, he seemed together from start, and I’ve felt, that he’s quite organized to start with. Still there seemed to be quite a few points to improve on. I’ve introduced him to the basic concepts of GTD. It was not a big change in the way he organized his tasks, as he already had a similar system in place, but task collection got more focus, and he seems to organize them a bit more rigorously now. Even if he goes back to his original system, he had positive assurance, how very important task organization is.

The other person in dire need of help seemed to be the CTO. He is running a tight ship being the only one overseeing the entire architecture, doing most of the backend development, helps in solving ad-hoc issues and does all the system administration, technical support, etc., that comes up in a wide radius around him. He’s just a nice person all the way down to the core, who doesn’t seem to know how to say no. Observing the way he works, he is getting interrupted all the time. He throws down whatever he’s working on, and helps out without hesitation. This is great, and he seems quite good at context switching. Still there is a need for him to be able to concentrate on the framework development, quality assurance, etc. Things, that require long patches of concentration.

To enable him I suggested to go through the tasks he needs to do in a sprint, and assign ‘Do Not Disturb’ timeslots as required. Make this information available in his calendar before the sprint starts, so others would know about it. And most importantly make sure it is easily known for the others, he cannot be disturbed. I’ve suggested him to utilize the classic ‘Cloak of invisibilty’, by wearing a visibility jacket, funny headgear,  or whatever, that’s easily spotted and understood. Also a box for chocolates is to be placed next to him, and anyone breaking the rule should  donate. This can become an office practice, so when needed people can work in peace.

Priorization and Delegation

This is a concept easier said than done. Both the CEO and the CTO are swamped with tasks. Even if they could do things faster, than their colleagues, there is just too much to do. We had several discussions about delegating the tasks to others.

To do so, they must first set up the boundaries. They need to define themselves, what tasks are to be solved by them only, and which are the areas they would never do. The later is always to be delagated, but the areas in between are also a subject to delegation. They must decide based on urgency and their own workload, if they can handle a task, or should they delegate it to someone else.

They should also be aware, that they will have to verify if and how the delagated job is done. Still, even if they know they could do a better job, or do it faster, they must make time to do the more important tasks.

Tooling and scheduling

We set up a ticket tracking and a documentation tool, to provide vision for the team and a portal to monitor their tasks and progress. It’s set up using basic Scrum templates, with several simplifications, to remove some of the formality, and reduce administration overhead. It’s based on the idea, of

Start as simple as you can, you can overcomplicate it later.

They also set up group calendars, so they can track people’s availability. In the calendar we are setting a few fixed weekly milestones. First item on the day is the stand-up. There is a second short stand-up after noon, to see the progress, until they get used to the task tracker. The first three days of a sprint are spent on development and testing the previous version, which is followed  by a bugfix day. This goes on until the acceptable quality is reached. The last day of the week is demo day, retrospective and sprint planning.

Once the team picks this rhytm up, they can introduce better estimation methods, measure speed, visualise burndown. Eventually they will reach a fully matured development model.

Conclusion

I feel honored to be the one given the opportunity to work with this team. It is such a great feeling to watch this bunch of youngsters, and see how organized and disciplined they are becoming, in such a short amount of time. In my opinion it is not my doing, but theirs. I feel they already knew most of what I told them, and all I gave them was the positive reassurance they needed to proceed. But that’s just the very definiton of beeing a consultant, isn’t it?

We still have a week to go, as my originally planned stay is extended. During that week I’ll try to step back and observe their behavior if there is anything that can be  improved further . 

I’ll try to keep an eye on them from now on. Whatever happens to the company will only be answered by time itself. I wish them good luck, and hope they make it on the market, if not this time, maybe with the next idea.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.