Building our team - Productivity

As they say, we should start with the end in the mind. It helps us to navigate our journey with more control and confidence. It also helps the team to have clarity of their goals

What is the current expected result and what?metric?would show if we are making progress?

Photo by kris on Unsplash

In the leadership call, we reviewed the first metric that can be used to measure few months of the Sprint Process. There was a lot of insights and discussion on the use of practice and some data that was scary.

Backstory Before using Agile Methodology (Sprint)

1. We use to have ad-hoc development in the past
2. No Release Cycle at all
3. Planning was a chaos
4. Always in firefighting mode
5. No Predictable Profitability

We have overcome all of them and manage to have a business model that gives us the liberty to operate in a more scientific way and provide more value to our clients.

This story is about getting Good to Better

The money we lose each Sprint

So as a part of our practice, we record each hour of developers for the 4 working days within the Sprint. The capacity comes around 144 hours. The reason for this is to identify the gaps and things that need to be improved. Yes, Our developers only have the target of 10 Billable hours a month. It may sound very less but we are a Product company.

Happy Developers with less pressure would give us ideas, inspiration and quality. That would be more valuable to our clients. When we checked the data for the spring logged hours of 134 vs 19 billable hours in 3 weeks sprint.

Our mentor picked that out and identified that could be a leak in our business. We are putting 7 times effort only for developers remember we also have a Quality Assurance team to check there is no impact across clients and also Project Managers to lead the Sprint. We have recently hired an external Scrum Master to check on our process. All this adds up to the cost.

Pair Programming a boon or curse

I am a fan of pair programming. In one of the solutions to a relatively bad Sprint, I suggested running the whole Sprint using pairing. The 2 developers who worked at Sprint enjoyed it and were happy about it. However, as you can see the billing hours got affected but then the number of tests and some other part of the process was much better.

Is pair programming bad throughout the Sprint?

This could be a topic for a good debate. Our mentor's opinion was it looks like not an efficient use of time. I couldn't disagree with him because economically it made a lot of sense. The only argument I could have made was if we would have produce 60 hours of billing. We decide to do pair programming either at the beginning of the task or for a complex task. We have not completely let of pairing because not only the development team but our testing team do test the Product using the Pairing technique.

I still think when we pair the driver looks into the details of the problem while the navigator looks into the big picture. So the driver can drive around the potholes, pedestrians or passenger cars on the streets while navigators can figure if they want to right or left after 200 meters.

Our team's productivity hours

This is a question that was in our minds. How many billing hours will make us successful? How can we pay the best in the industry to keep the good people around? How can we attract good talent because we have a great product that generates regular income? We knew that 19 hours a Sprint is not a good number.

I asked this question to our mentor. He was not sure and don't know what is the right answer. However, we discussed and deliberate to conclude that the Overall Productivity even for 4 day work week could be 16 hours per week. That means each member should be in a position to add value for at least half of their working day.

The value need not be all in billing hours and we understand it may not. It can be improving our product, creating beautiful scorecard templates, making help documents easier to read, responding to tickets quickly and with compassion, improve the error message, create marketing content or other means of value.

We have a problem of low billable hours

Yes, we do. One of the reasons is that we work with Non-Profits and Think Tanks. Our clients depend on yearly budgets and funds from Investors. In their Revenue Model often than not we come under cost line item. They have only X amount of budget for Technology Tool. I am not surprised.

We have also not spread out of the space of Sustainability and did not tried into the red oceans of the Non-Sustainability Market. The offerings and services need to be at a different paradigm. Think of a Corporate Business world with Account Managers and Sales Reperensatatives knocking on doors all day long. The Speed of deliveries must be at an all-time high, midnight oils, long working weekends, firefighting mode etc.

I am not sure if I and Gautam are capable of overcoming the challenge of increasing the billable hours or entering into a new market. The primary onus is on me and I cannot make false promises or be a snake oil salesman to chase money for our reputation. If we had it in us we would be already making million pounds in revenue per year. We are far away from it. I can take risks however not at the cost of clients risk tolerance. I need to be at least 80% sure that we can deliver something before I commit to it. I am learning the craft of sales and marketing. Currently, it's close a friend whom you can trust and you know won't manipulate you.

You can read the article on Delight in the coming weeks where I propose a solution to this.

Value is what I would love to sell

The priority of Income Generating Tasks

We may not have the billable hours to work on. We definitely have a team that has time to create more value. One way to do that is by making the internals of the Products, their infrastructure and the supporting engineering practices rock solid. As they say, the height of the building depends on the strength of its foundation.

As leaders, we need to be working on the backlog tasks that could create Income in future for 73bit. Thus the team is aware that they could pick Income Generating Tasks. These tasks can come in various shapes and sizes. The big one we have is the Technical Debt. It means that the code is easy to change with the least impact on the rest of the system. Thus giving us the ability to make fast changes without any bugs. It is not about creating a Perfect System it's about responding to change more confidently.

Another area to improve is Performance we specific pages to few clients which take longer than 10 seconds to load or save. The current benchmark is to bring all page loads below 10 seconds. I am happy to say we have achieved it already. We have also enabled tools and techniques if any new is reported as slower. Once we complete other priorities we can focus on reducing the benchmark to 5 seconds. By the way, most of our page is already within a second. These are edge cases.

Robustness would be the next priority we have seen for some of our bigger clients. When the concurrent users increase over 150-200 our system slows a bit down. We are currently performing external stress testing using a third-party product. Thus measuring memory usage on each request and finding a solution to it. The target is to have the experience on the tool similar when you have 2 users or 200 users. There are many User Experience tasks that can be created to reduce the number of clicks, To automate some frequently done tasks, To send some email reminders with status updates on progress, To create story cards with insights on pending user/manager tasks, To create stats on email analytics etc

Our job as programmers is to solve problems and not write codes ~ Dave Farley

Share this post with your colleagues today!