Breaking down large software requirements.

mikeluntLeave a comment

Decrease your iteration length. – The Agile answer to how to overcome the problem of breaking down these seemingly large requirements. At first, it sounds simple, but after giving it some thought, it sounds like a Greek philosopher’s answer to the meaning of life. (i.e. Neat answer, but what do I do with it?!)

The two dilemmas that teams face when breaking down requirements are (1) a reluctance by software engineers to develop in a (perceived) less-than-efficient mode and (2) how to use multiple people in a common area of the code, where the ‘9 mothers and a baby’ theory starts to show (no pun intended). I won’t go into all of the ROI reasons to offset both these fears because they are well documented in any Agile process book; however, there are some different ways to brainstorm the large requirement question.

In general, decreasing the iteration length may be taken in its literal form. If using a 4 week iteration, switch to a 2 week iteration. If using a 2 week iteration, the team might experiment with fully accepted story cards within a 1 week iteration. Assuming the team is already using a 2 (or less) week iteration, another way to consider the breakdown is by considering what would be done if only 2-3 days were given to accomplish part of a larger task and demonstrate some progress, no matter how small. Unless the answer is ‘give up and quit’, there is some part of the requirement that can be done in a shorter period of time. As stated before, the team must trust the counterintuitive notion that this approach will not result in the most productive use of everyone’s time.

Since many problems are too large for one person to code within one iteration, it only makes sense to use multiple software engineers. One way to look at using multiple people is to consider a drastic approach of being forced to solve the problem of how to write a ‘say hello’ program with equal participation from 3 people. While a completely ridiculous way to solve this problem (not to mention a ridiculous problem), each person could rotate typing the code on a single keyboard. The point is to highlight that every problem could be broken down (components, classes, methods, etc.), and once again, the team has to make a leap of faith that the paybacks in familiarizing multiple people with more of the code and the benefits of demonstrating working software will make the team more efficient over the long term.

Last but not least, teams can approach the requirements breakdown phase as a mental competition. While many engineers like to exhibit their problem solving skills, the team can make the breakdown process a problem in itself. Peer recognition and other forms of compensation can be added to help change the old mindset of cranking out code to put food on the table. In this case, the baby gets new shoes when high quality code is delivered frequently and not when the super engineer works 24 hours straight to code something no one else understands, which will take 3 weeks to test in the quality.

The overtime trap

mikeluntLeave a comment

This article about excessive overtime in the IT industry reminded me of a question I was asked about how meet a release date when the project was behind. While there are many things to try, asking the team to work additional overtime was low on my list, and here’s why.

Anyone who has worked in the software industry for any amount of time knows that releases can and often do have highs and lows in terms of work hours. If the team has been cohesively formed, development and QA engineers will most likely work extra as the release date approaches anyway. While a last extra push over a couple of weeks or so might help cleanup a few last details, the effects of doing this for many weeks will often cause the project to be delayed even further. This is because tired and burned out engineers will make more mistakes, which will create more churn and code chaos. In addition, if any team members quit before the release is complete, the project could take a serious setback and potentially fail. So, what can be done? Fortunately/unfortunately, there are three fundamental things.

  • Decrease scope. If the project is using an Agile approach, this won’t be an issue because the team will maintain a releasable state for the majority of the project. Some will often mention decreasing the quality, but this is essentially decreasing the scope since releasing a quality product was a requirement in the beginning.
  • Adjust resources. Adding people is a favorite suggestion for second and third level managers to make, and it never hurts to reevaluate the team. Unfortunately, software isn’t the same as building a highway, and in some cases, the additional resources can consume time from the key contributors and stretch the release date out even further. There are some interesting variations on this suggestion ranging from adding subject matter experts to help the existing team all the way to adding resources in specific areas, such as testing. With an Agile approach, resources are typically fixed, but if there are multiple Agile teams, some teams may be able to take tasks from another team that has encountered roadblocks. In addition, if the Agile teams have been formed over time as cross-functional teams, it becomes much easier for alternate teams to be able to take on extra tasks with minimal training time.
  • Push the release date. If no compromises can be made in either of the first two areas, moving the date will be required. When using an Agile approach, everyone agrees to the three laws of software development, often referred to as the iron triangle, and in this model, additional iterations will added until the desired scope is achieved.

The Other Side of Product Management

mikelunt3 Comments

There are many jobs that a product manager may do, and while most focus the vast majority of their time gathering requirements and selling the products to the sales team, I contend that another equally important role is necessary. This role involves selling the engineering team on the value the new features or changes in the product will have for the customer (and ultimately the success of the group). In other words, for a product to be successful, the engineering team must be motivated to implement the product manager’s feedback. Many projects have failed or been plagued by engineering feature creep because the team did not have confidence in the information stream coming from the product manager(s).

One way to motivate engineering groups is with statistics and objective data showing the value to the customers. Ideally, revenue projections per feature would be great, but this is on par with predicting the weather. Another approach is showing raw historical data on the number and names of customers who have requested a feature; furthermore, having historical revenue data for what each customer paid would be a welcomed bonus. Information like this would provide teams with some objective justification as to why priorities have been set and take the obscurity and mystique out of a proposed new feature set. Unfortunately, this information rarely seems to make a backlog or requirements document. It could be as simple as keeping a spreadsheet with the top 25 features and noting the customers who requested each feature. In addition, it seems like a good sanity check for the product manager to validate intuitions and cross check with others in the company.

Home window film to beat the heat

mikelunt2 Comments

One of our recent house projects was aimed at dealing with the Central Texas sun. The key reason for this was a desire to get rid of the heat pockets around our windows when the sun was in its afternoon path. The options we considered were (1) new blinds, (2) solar screens, and (3) window film. After a lot of research, we decided that new blinds wouldn’t really help the situation, plus without some protection from the outside, the blinds would just continue to take a beating. After looking at several houses with solar screens, we could see that the screen material would start to sag rather quickly, and the almost black windows are not as visually pleasing from the outside as those with window film. (Obviously, this is just one opinion.) In addition, looking out through the solar screens does not provide as crisp of a view, so in the end we focused our attention on the window film.

The real question was does the film help with the heat, and the answer is emphatically ‘yes’. Here are a few specs on some of the various films we used. After having the film for a couple of weeks, there is a significant difference around the windows. While the specs say that 50-60% of the heat was blocked, my perception is that the air around the windows is 30-40% cooler, and the heat pockets throughout the house are virtually gone. In addition, when we arrive home at a time when the program is set high, the house is not unbearable, and my rough calculations say the house is 5-8 degrees cooler than it was prior to the film. That doesn’t sound like much but consider how long it takes for an air conditioner to drop the temperature that many degrees.

In the end, the cost was in the $1500 range for all the windows from Sunsational Solutions, and we were pleasantly surprised to receive a refund check from the city for making energy saving improvements, so the cost was reduced several hundred dollars. As an added bonus, the glare on the TVs throughout the house has been decreased to a point that is it not noticeable; consequently, HD looks just that much better. Here are a few pictures I took to compare the differences.

Window without any film or screen. (They missed this one but will be coming back to get it.)

Window without film

Window with solar screens. (The neighbor’s house…)

Window with solar screens

Window with film. (Subtle contrast with the stone…)

Window with film

Not a review of ‘True to Our Roots’

mikeluntLeave a comment

While I was incredibly impressed with True to Our Roots: Fermenting a Business Revolution, I’ll spare all readers with another review of the content that can be had somewhere else. Instead, it’s much more beneficial to comment on an aspect that the author just touches in a few places but doesn’t seem to emphasize. To give a bit of background, the story is written by the CEO of Fetzer Vineyards, Paul Dolan, who helped transform the vineyard and a large part of the California wine industry into a ‘environmentally and socially conscious’ industry. While doing this, he grew the company at double digit earnings increases for ten or so years, and now, he is promoting this sort of change in corporate business policy to all companies and industries.

Dolan’s sale to the corporate world seems to be based more on the moral and socially responsible aspects of making these changes to business, but he doesn’t seem to accentuate the aspects that might have a bigger impact in converting the CEOs of the world, such as increased sales and higher profits margins. Here are some of the advantages I see from adopting the Fetzer philosophy, if the philosophy alone isn’t reason enough.

1) Employees that are motivated by more than money will work harder, work for less, and enjoy working much more.
2) Consumers will prefer an earth-friendly product over the contrary at the same price point, and in many cases, consumers will pay a premium for these products.
3) Consumers prefer purchasing products from companies with happy employees.
4) Companies that engage in these practices are often publicly awarded for making strides in environmental and social change.
5) In many cases, converting operations to an environmentally sound approach can lower operating costs over the long term.

CxO interpretation: lower costs, increased sales, higher productivity per employee, less employee turnover, free viral marketing, increased brand awareness

The “A” Word

mikeluntLeave a comment

I’m often amused when someone says something is “Agile” in the software business. While I’m no expert, if there is such a person, it’s always interesting to see how almost any process can be classified as Agile regardless of how much water you can hear falling in the background. For instance, I recently heard of a new so-called-Agile approach that involved filling out a Word document to propose certain defects be fixed in the product as it neared the end of the release. It was justified the new approach (1) created a new process on the fly to allow change in the product and (2) was promoting change by allowing team members to submit change proposals. On the surface, it seems harmless enough, but for those that can’t read between the lines, this process ultimately creates a nonessential accountability hurdle which will make change much more difficult by requiring a form document.

So, begs the question, when is an appropriate time to throw out the “A” word as justification for a change in process? I would argue it should only be used when the proposed change meets the four tenets of the Agile Manifesto. Unfortunately, this seems like a cliche and/or and easy copout, so how about a few of simple guidelines that might trigger one to double-check the Manifesto. (I would argue these guidelines might be a good test prior to implementing any process in any business, but that off-the-cuff suggestion might be a tad haughty.)

Does the new process:

1) Increase the amount of time needed to make a decision by creating throwaway artifacts?
2) Primarily exist to make someone or some group accountable in the face of failure?
3) Attempt to minimize the amount of live interaction needed between one or more groups?

If you answered “yes” to any of these questions, it might be a good time to reflect on the change and reconsider the assumption of Agility.