It cuts both ways: Technical competence. Having highly competent people on your Team can make or break your project.

Genius, geek, propeller-head – just some of the labels we place on people who are gifted in technical insight and skills. And it’s great when they come through for the project, solving a difficult problem that’s been holding the Team back.

Yet you must also be familiar with this scene: You’re meeting with the Team explaining your vision for a new product or feature, and as you’re talking you glance across at the major brain in the room. His eyes are glassy; he has that distant look about him.

An impact, either way
Yes, he’s started to make decisions, design the architecture, code the system, right there, in his head.

And while this hyper-productivity may be admirable, it’s questionable whether it is functionally effective towards meeting your project’s objectives. After all, you haven’t finished imparting the vision.

The code that’s written at that moment, in his head, may have a significant impact on your project’s success. Has he heard everything of significance? Has he factored it all in? How strongly is he able to exert his will over others? Are other team members included or squeezed out from that point? If he’s made a wrong call, does he have the emotional intelligence to back down?

Technical competence can be a powerful ally to market place success, but it can just as easily confine your product to the ranks of the also-rans.

Reaping rewards comes after mitigating risk. Bringing the Team’s technical competence to bear at the right time and in the right way will give your product a shot at greatness.

Whenever I can I like to spend time with customer care people, trainers, sales people, and those who support our products in the market place. Why? Because as a manager I must always be aware of how our products are being portrayed to customers and users: Over the ‘phone, in emails, in Help and FAQs, in training, in sales demo’s, everywhere.

In his book On War, published posthumously by his wife in 1832, von Clausewitz wrote, “We fall into error if we attribute to strategy a power independent of tactical results.”

Is your strategy being made impotent by rudeness over the ‘phone, poor grammar in emails, incomplete or inaccurate Help, dour trainers, or over-promising and under-delivering sales people? You need to find out.

On second thoughts, don’t. Whilst the truth is sometimes spoken in jest: “Our software wasn’t released; it escaped,” customers and users feel the brunt of poor, error-ridden software.

It’s an imposition to treat them as your testers. It’s not what they pay you money for and they don’t deserve to be treated that way.

Your strategy of continuous integration doesn’t mean you abandon quality. Resist the urge to unleash the animal in you.

McAfee Releases Buggy Patch for VirusScan Enterprise

Blackberry releases new firmware to fix buggy Storm software

Google releases buggy Chrome for Mac OS X and Linux

WordPress 2.8 Buggy Release is Out for Download

Players Furious Over Buggy Grand Theft Auto IV PC Release

Why will a software design process always be an idealisation? David Lorge Parnas, a Canadian early pioneer of software engineering, gives us his reasons:

(1) In most cases the people who commission the building of a software system do not know exactly what they want and are unable to tell us all that they know.
(2) Even if we knew the requirements, there are many other facts that we need to know to design the software. Many of the details only become known to us as we progress in the implementation. Some of the things that we learn invalidate our design and we must backtrack. Because we try to minimize lost work, the resulting design may be one that would not result from a rational design process.
(3) Even if we knew all of the relevant facts before we started, experience shows that human beings are unable to comprehend fully the plethora of details that must be taken into account in order to design and build a correct system. The process of designing the software is one in which we attempt to separate concerns so that we are working with a manageable amount of information. However, until we have separated the concerns, we are bound to make errors.
(4) Even if we could master all of the detail needed, all but the most trivial projects are subject to change for external reasons. Some of those changes may invalidate previous design decisions. The resulting design is not one that would have been produced by a rational design process.
(5) Human errors can only be avoided if one can avoid the use of humans. Even after the concerns are separated, errors will be made.
(6) We are often burdened by preconceived design ideas, ideas that we invented, acquired on related projects, or heard about in a class. Sometimes we undertake a project in order to try out or use a favourite idea. Such ideas may not be derived from our requirements by a rational process.
(7) Often we are encouraged, for economic reasons, to use software that was developed for some other project. In other situations, we may be encouraged to share our software with another ongoing project. The resulting software may not be the ideal software for either project, i.e., not the software that we would develop based on its requirements alone, but it is good enough and will save effort.

“For all of these reasons,” Parnas says, “the picture of the software designer deriving his design in a rational, error-free way from a statement of requirements is quite unrealistic. No system has ever been developed in that way, and probably none ever will. Even the small program developments shown in textbooks and papers are unreal. They have been revised and polished until the author has shown us what he wishes he had done, not what actually did happen.”

I was interested to read an article in the latest edition of The Economist about W.Edwards Deming (1900-1993). Deming, who was awarded the Order of the Sacred Treasure, second class, the highest Japanese award ever given to foreigners, for his efforts in helping improve product quality in Japanese companies, is once quoted as saying: “If I had to reduce my message for management to a few words, I’d say it all had to do with reducing variation.”

Management, Deming argued, is responsible for 85% of variation. Reduce the variation, increase the quality; this was the foundation of his advice.

The Agile Manifesto values working software over comprehensive documentation. In agile projects working software is the ultimate quantification of your project’s status. This may take some getting used to.

The signatories to the Agile Manifesto are not saying that technical documentation doesn’t have any value. Not at all; they’re simply emphasising the value of working software over comprehensive documentation. They’re saying that as working software should be the team’s goal, if producing detailed documentation for tradition’s sake is getting in its way, then it is time to adjust how much paperwork is produced.

“That is, whilst there is value in comprehensive documentation, we value working software more.”
-Signatories to the Manifesto for Agile Software Development

In addition, a number of the principles behind the Manifesto elaborate on this value:
- Working software is the primary measure of progress.
- [The team's] highest priority is to satisfy the customer through early and – continuous delivery of valuable software.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

How versus why
Finding the right balance between documenting and doing is an art that still causes much frustration in the lives of developers. And clearly not all documentation is bad. For example, sometimes end-user documentation is used as a criterion for ‘Done’. Sometimes it’s used to document decisions for team continuity. And documentation may even be needed for regulatory compliance. I’ve found it’s OK to leave the team to answer two simple questions: Is the documentation valuable? Is the team better off for writing it?

In my view this Manifesto value really addresses the project’s efficiency: The ‘how’ of the technicalities. The agile leader though, may be more interested in artifacts describing the project’s functional effectiveness: The ‘why’ of the business. This is because you are responsible for the software beyond its manufacture: Why you invested in it, and why it complements your broader business plan.

I’ve had great success using these documents to capture the business essence of an agile project. They convey stakeholder expectations of the project, the user needs the product will meet, and how the product will evolve once in the market. In my experience the benefit these artifacts bring to the team far outweighs the cost of producing them.

I strongly encourage Product Owners to produce these documents because they connect very deeply with the project through this process. Then, when the hard product calls need to be made, they’ll find the answers within them. And their confident, consistent decisions will earn Product Owners the respect of the other team members. Stakeholders will feel safe in their hands, too.

Business case
The purpose of the product business case is to set out: Stakeholder expectations; a mapping of the user needs to features to benefits; the proposed financial model; market opportunities identified; and, a product positioning statement. The product strategy outlined in this document should be consistent with the organisation’s business plan. (3 pages)

Vision
This is the chance to describe what the perfect product would look like—the outer bounds of market and functionality. The vision is derived from the business case and illustrates the problems that must be solved to reach the product’s goals, yet it should not be constrained by what is technically possible for the team. (3 pages)

Data sheet
This document distills out of the vision the principal features of the product, and their related benefits, in user language. If software was still sold off-the-shelf, this would be the promotional material printed on the outside of the box.(2 pages)

Overview
This artifact contains as many of the product’s features and related benefits that have been conceived at this point, in more detail than the data sheet, but still in user language. The overview, like the data sheet, still honours the product vision. Because it communicates how the Product Owner has interpreted the vision, when reading the overview team members often say, “Oh, I didn’t know you meant that. We’ll have to talk it through.” Then if proposed features and benefits need to be discounted for any reason, everyone is aware of the base off of which this is being done. (10+ pages)

Product backlog
With the previous documents in place the product backlog, which is a prioritised list of tasks described as user stories, becomes a doddle to produce.

Road map
So too with the road map: The release plan of future functionality is often a quarterly snapshot of the product backlog in a form that could be presented to internal and external stakeholders. Although some executives shy away from publishing the road map externally for fear of raising the market’s expectation of future functionality, I’ve found the benefits to outweigh the risks. The market appreciates that you have shared your plan for the product, and in turn it can participate more meaningfully in setting priorities.

I will elaborate on each of these documents in future posts, as well as provide templates of these documents for download. Be sure to look out for them.

Despite using many efficiency tools scarcity of time is still a fundamental problem for most of us. Technology is supposed to restore time to us, but often we’re left wondering, “Where has all my time gone?” It’s wasted by being ineffective, even efficiently ineffective! This is why we often feel that we’ve been busy yet nothing has been achieved.

Which is more important to first get right: Effectiveness or efficiency? Intuitively many choose first to be effective: Just get it done, worry about doing it properly later. This approach may produce short term gain but it is disastrous in the long run. Even though some things may get done, doing them inefficiently takes away from the enjoyment of our work, depletes our energy and momentum, and causes ineffectiveness; this is true for individuals as well as teams.

Efficiency and effectiveness
Yet our role as managers—shareholder proxies—is to ensure the long term sustainability of the businesses entrusted to our care. We give ourselves every chance of success when we focus on efficiency first, and then effectiveness. Form before function. Quality before quantity. How before what. Efficiency, or the ratio of output to input, results from following the correct form. Effectiveness is the power to produce an intended result.

This introduces the other dilemma many of us face: What is the intended result—the function or purpose—of our efforts? It’s not enough to be effective; we must be functional, or purposeful, in what we do. In applying our efforts efficiently we need to strive for the vision we are intended to serve. Self-service may be effective but it is rarely functional to the organisation.

In getting to grips with your purpose you should analyse your answer to this question, “For whom or for what am I here?” It may be interesting to hear your team respond to this as a gauge of how plugged in they are to the corporate and product vision. And keeping this vision front of mind in turn helps guide you and your team towards the correct form.

Why is it important to master these fundamentals? Because you can waste a lot of time by being effective but not efficient—getting there at any cost; by being efficient but not effective—efficiently doing the wrong thing; and, by being effective but not functional—a bad attitude that affects everyone around you.

Adding value is about being efficient and functionally effective. As an agile manager you need to drive from vision to form to function to fulfilment, both for you and the people you oversee. You’ll save a lot of time and regain the enjoyment and satisfaction you get from working as hard as you do.

What tasks are you doing efficiently but which are functionally ineffective?