New feature development vs defect fixing

One of the challenges faced by smaller organizations that are usually strapped for resources / manpower is the decision to build  new features versus fixing defects in  the existing product.

At a high level, there are  two ways to approach this dilemma. One, the company can allocate a percentage of  each employee's  time to defect fixing and new feature development. I'll call this the 'Time  Allocation' method. The  allocation can happen at various levels of granularity. For example, the  decision can be to allocate 30% of an employee's time to  defect fixing and the granularity can be set to one  week. This would mean that 12 hours (30% of a normal 40 hour week) would be spent by the employee for defect fixing every week. It wouldn't matter whether the employee spent 2 hours and 24 minutes (12 hours divided by 5 weekdays) every day or if he/she spent one and a half days (8  + 4 hours) on fixing defects.

The other  way to approach a solution to this problem would  be to have dedicated teams working on fixing defects and rolling  out new features. I'll call this the 'Resource Allocation' method. Each team would have managers who would review the product roadmap (for new features) or the defect backlog (for defect fixing) and manage the teams responsible for working on them. The  team members are focused on their area of work and are free to develop optimal working styles or methodologies to maximize productivity.

So, what are the pros and cons of each method and how does a company go about choosing one approach? Well, the pros and cons must be fairly obvious, but I have listed some below. Ultimately, the approach that an organization adopts is very subjective  and needs to be  taken with the understanding that there is usually no ideal solution. The factor that could make  or break the solution is actually the ability of leaders to convince team members to own and take pride in fixing product defects. It's not easy, but if team members can realize that fixing defects goes a long way towards making the product usable and more appealing to its customers, it will make it easier for organizations to deliver a stable and successful product.

	Time Allocation	Resource Allocation
Focus	Focus of team shifts frequently from defects to new features and vice versa	Allows team to stay focused on one area and develop expertise
Morale	Less impact on employee morale because everybody is working on both defects and new features	Defect fixing has a stigma associated with it and can cause teams that are working on them to feel like they are being made to do "dirty work"
Productivity	Possibly adverse impact on productivity because team members find it difficult to optimize their way of  working because of the varied nature of their work	Teams can try and develop efficient ways of working that could, over  time, have positive effects on their productivity
Release Management	Release management may be a little more straightforward because  the same team is working on both defect fixes and new features	Coordinating defect fix releases, branching and merging code frequently and various such activities could be more complicated because two separate teams are involved
Testing	Testing may turn out to be slightly easier because a single team has visibility and  control into  the code  that is  being written, so there is  less  chance  of  regressions	As code merges and branches happen during a release cycle, there is an increased chance  of the wrong code creeping in which could impact regression testing. Also, when two separate teams are involved, there will invariably be a blame game when regressions are identified

The use (and abuse) of Excel

In the role of a project manager over several years, I have observed Excel being manipulated and coaxed into doing things it was never designed to do, in my opinion. The culprits are usually project and program managers who need some kind of tool to monitor, track and control projects.

Let's face it. Excel is good at crunching numbers. It's also good at creating and displaying charts/graphs based on crunching those numbers. What it's not good at is displaying images that are not based on numbers or depicting non-numeric data. One example is Gantt Charts. I've seen  Project Managers  color bunches of cells on a row to simulate a task's duration. Another Project Manager I knew used to draw a vertical red line with arrows at each end to indicate the  current  week on a project plan (Gantt Chart). For this, he used the caret symbol ('^') to simulate the upper arrow tip, a 'v' to simulate the lower arrow  tip and the pipe ('|') symbol to show vertical lines. These are extremely clunky and laborious ways to achieve an objective. There are  many tools that are designed to present this information and it is far more sensible to use them rather than force Excel to do it.

The worst part is when senior leaders in an organization are impressed with such Excel artifacts and decide to make it the "template" for others to use. Then, other Project Managers  are forced to bend over backwards and use these complex templates for their own projects even if they hate them.

Agile for Product Management and for Project Execution

Here are my  thoughts on the use of  Agile methodologies for project management and  product management.

Although a lot of companies implement and practice Agile methodology in its purest form, it makes sense for a lot of companies to pick and choose what parts of the Agile manifesto make  the most sense, given their specific situation, where they want to go and what they are looking to achieve.

In my opinion, the Agile way of working can provide a lot of benefits in the requirements definition. The use of personas, scenarios and stories are a very effective and engaging way for the product owner to convey the details of what is  expected from the product. The discussion of acceptance test cases during the elaboration of stories is also very useful for both the product owner and  the implementation team (developers and testers). This method of product definition is  far more  effective than writing long, boring requirements documents in MS-Word with chapters,  sections and formal language trying to describe what the product owner is  thinking.

In addition, the concept of a backlog  that combines  user stories for new features as well as enhancements and bug fixes results in a clear model for prioritization from the product owner's perspective.

Now, on to the not-so-good or the complex part. On the development side, there is a lot of churn. Figuring out the number of stories that can be accommodated in a sprint or what to do when a story takes longer than a sprint or what happens when a story is deprioritized in the middle of a sprint or what happens when the estimate for a user story is found to be grossly inadequate can be extremely difficult. All these are tough questions and are difficult to tackle  without a really good  team with a  really strong leader. It's  not for the faint of heart. Test Automation and Continuous Integration can help to mitigate a few of the difficulties but I don't think it's enough. The next best thing to do is the factor in the time spent on refactoring, bug fixes, research and other "sundry" activities when the development capacity for a milestone or sprint is computed. This will also help in computing the velocity of the team which, in turn, helps more reliable and consistent predictions of the amount of work that can be taken on by a team in a sprint/milestone

On the development side of things, implementing Agile will necessitate certain prerequisites. For instance, it would need a team that is filled  with generalized specialists. People who can do a lot of things well and also one  or more specific things really well. It  also needs teams with a certain amount of stability in terms of change. In other words, teams with members that stay together  for long periods of time.

So, in a practical world, the above requirements are usually tough to ensure. Therefore, a hybrid approach to Agile adoption is needed. One area that Agile can cause a lot of misunderstanding is in the emphasis of working software over documentation. People misinterpret this to mean that Agile frowns upon documentation. However, I would like to look at it differently. I feel that Agile's recommendation is that greater priority should be given to developing or creating the software rather than documenting the requirements, the design and other such artifacts. In their opinion, the time is better spent developing the actual software that satisfies the requirements.

However, against this,  we must take a realistic look at the way teams are organized and function over time. In most cases, teams  get built and break up as members join and leave the organization or move up or down in their career. Teams also change in the amount of expertise they possess in a specific area, domain or technology. So, a truly Agile team is difficult to build and sustain over any great length of time. Also, as teams change in their composition and experience, it is important to continue the momentum of software development. This is made easier if the new team members have access to some form of documentation that would help them ramp up and start being productive sooner. So, documentation in some form is essential to build productive, scalable and sustainable Agile teams.

Metrics, KPIs, analytics, et al

The importance of metrics, KPIs and scorecarding for a small, growing company cannot be overstated. Adding a layer of analytics, especially predictive analytics, can provide a significant boost to its performance, in my opinion.

The first step in this should be baselining. Baselining will let the company establish a base for comparison in the future and will need the company to monitor / track/ measure various KPIs and metrics for a predetermined period. The degree of accuracy in the baselining will depend on the patience that a company has. If a company waits for a full annual cycle to gather and record the various KPIs/metrics, they would have a clearer picture of the current state which allows for the vagaries of company performance over several quarters. This is especially true and significant for companies that operate in a cyclical industry.

Baselining beyond a year will, in my opinion, not provide significant enough benefits to justify it. The cost-vs-benefit graph would  be a downward curve that quickly tapers off in terms of benefits beyond a year. Baselining for less than a year would be perfectly fine for a company with a steady stream of revenues across the quarters in a year.

A company like Procter & Gamble, which deals in common household products and consumables will usually have a steady stream of revenues across the quarters of an year. In contrast, companies like Amazon would typically have revenues weighted heavily  towards the end of the year when holiday shopping (Thanksgiving, Christmas) is at its peak.

The advantages of baselining beyond a year is to compensate for  non-organic factors or extrinsic factors like the economy, oil prices, currency fluctuations, etc. Baselining for an year will allow the company to visualize and take action on organic or intrinsic factors affecting the company’s performance.

The roots of a tree

As a company creates and executes on its growth plan, it would be a mistake for it to focus only on revenues and profitability. These are only the visible factors; the part of the iceberg above the surface of the ocean, if you will.

Imagine a tree that grows as you water and nourish it. What you see is only above the ground as it grows bigger, taller and wider. However, without your knowledge, the roots are actually growing downwards, deeper into the ground and wider to establish a greater hold and create greater stability. If the roots don’t do this, guess what happens? When there’s a storm with strong winds, the tree is going to topple over.

Similarly, in a corporate context, as a company grows its revenues and  profits (above ground), it needs to ensure that it strengthens its internal infrastructure, which includes the IT infrastructure, the technology platform, the HR policies and benefits that attract and retain the best employees, the sales and marketing strategies, etc. If a company focuses mostly or only on revenues and/or profitability, I would be pretty nervous about the consequences.