Improving Requirements (Strengthening Waterfall)

One of the weaker phases in waterfall product development is the area of requirements.  Unclear or incorrect requirements are recognized as a major cause of grief on projects, if not outright disaster.

What is your feeling about the relationship between the requirements document and the ultimate product delivered?
How readily does the requirements document map to the required functionality?
Does it include a description or list of functionality that is out of scope? (“Thou shalt not…”)

In general, part of the problem is that there’s no real QA process on the requirements document, typically, only a user sign-off.  That’s an approval, not a QA process.  If the document is much over 10 pages, this is about as useful as handing someone a globe to use for direction to someone’s house for a holiday dinner.  You’re lucky if you even wind up in the right town, let alone the right neighborhood.

Typical waterfall environments have a QA function, usually for testing the finished product  Too often they only get involved late in development, often after all coding is allegedly done.  Why restrict their role so much?

Get them involved sooner, and involved with the analysts creating that requirements document. Involved, meaning interacting and talking directly to each other.  QA is designing the tests and should be able to identify unclear areas of the requirements, perhaps even missing parts. To flesh it out further, the QA group designs the tests based upon the requirements, and the business (not the BA who did the requirements) then reviews the test structures for completeness and accuracy, closing the feedback loop on the requirements document.  That process is independent of coding; it can start before any coding.

Another wobbly area is the clarity of the requirements for the developers.  Of course, clarity is only important when the document is actually read.

Another way to have some QA process for requirements is to have something similar to a peer review for coding, but in this case, instead of code, it is the requirements that are reviewed.

Come up with your variation of a QA process for requirements, one appropriate to the culture of your organization and resources available.

Cultivating the Zone

In the zone: usually we think of this state in terms of athletes, or creative artists: musicians, writers, dancers, poets.  Yet it’s not just for individuals, but for teams and groups as well; an example is the hyperproductive IT developer teams, mostly associated with XP and Agile practices.  Psychologists seem to prefer the term, “in the flow”, and that’s how you’ll find it in Wikipedia.

Think of it as an alignment of deep skills and a clear, achievable, meaningful task; a state of resonance between reality of the moment, the task to be accomplished, the skills brought to that situation, and an exceptional focus on that task.

It’s not just highly productive, or good solid work; it’s exceptional, out of the everyday mode of doing.

It’s never guaranteed; no sure recipes for entering into that state.  It cannot be forced.  But it can be encouraged and cultivated, nourished; allowed to happen.  Impediments to it identified and removed.

Some conditions probably necessary to achieve this state are:

  • The person or team is skilled in their field, perhaps deeply skilled.  A sense of mastery, pride in those skills, and some confidence in their use.
  • A bit redundant, that they have to enjoy what they’re doing.
  • The task is well defined, perceived as achievable, but challenging.
  • A high degree of focus and concentration; absorption in the task at hand.
  • This absorption can result in a feeling of being one with the task. The person becomes the work.
  • A feeling of fluidity, less difficulty than normal, performance seen notably above the usual.

How can we cultivate the conditions to help get into the Zone?  We, as individuals, as managers, team members, project managers, setting up an environment that allows this to happen:

  • Minimize distractions and encourage a sense of focus.  For some this means suitable music; for others, quiet; for some teams, something to impart energy. Perhaps a sign outside the team area, “Do not stick fingers in the cage.”
  • Make sure that tasks and goals are well defined and achievable. But don’t micro-manage.
  • Create an environment of minimal worries.  A sense of safety, isolation from threats.
  • Encourage a culture of mastery of the relevant skills, so that the basic tools are extensions of our thoughts. The thought effortlessly becomes the action towards the goal.

Don’t be concerned about rewarding this behavior: being in the zone, feeling that flow, is its own reward.



Supporting Application Development

Methodologies or frameworks for the infrastructure to support Application Development (AD) is an interesting topic by itself, but one I’ve seldom seen mentioned or described, despite ITIL.  Even in companies that are following ITIL practices, the procedures are not often accompanied by feedback mechanisms to further improve things.

For example, do you trace incident or problem reports back to application change requests?  For major changes to application software, compare the post-implementation defect levels for different application groups.  Investigate the differences and consider ways to improve application development practices.

Many organizations believe that by designating support staff as level 1, 2 or 3, that they’ve established real procedures.  Other than “expected time to resolve” criteria, I’ve seldom heard of any real process analysis associated with those categories.  Nor have I heard of processes for a more organizationally flat structure.  A process needs to be more than assigning a severity level and contacting a software vendor.

What are your company’s infrastructure processes for supporting AD efforts?  What are the feedback mechanisms in those processes, such as periodic reviews?  If you were an infrastructure manager, how would you know how effective has been your support for AD, and where there may be perceived deficiencies?

Does each organization have a clear view of major plans and events for the next 3 to 6 months?  Does the AD area have any clues as to when systems is thinking of upgrading the version of the DBMS, or other essential software?

Hint to infrastructure:  if an AD team is pedal to the metal on delivering to the business, 2-3 weeks notice that you’re planning to upgrade to a new version of some key component is likely to be greeted by less than rabid enthusiasm.

Hint to the AD manager:  if you have not budgeted in time, resources and tooling (test scripts, etc.) for at least one version upgrade per year of the DBMS, and at least once every other year for the OS, some rude surprises may await you.

A tale of non-communication, with details altered out of sympathy:

Application development has a software product from a vendor, with much in-house enhancement.  In their published plans for the next quarter, AD had included an upgrade to a newer version of the product.  They knew that a newer version of the DBMS than currently used by the application would be needed for it, but since that newer version was already in use in-house by other applications, they were not concerned.

When the specific requirements became official requests to the infrastructure, the fun began.  The newer version of the DBMS required a newer version of the operating system than was currently used by that application.  And their servers were only marginal for the newer level of the OS; a hardware refresh was recommended.

The newer version of the OS not only brought along new run-time libraries, but used newer versions of compilers.  Even without any hardware refreshes, the regression testing alone for the DBMS and OS upgrades added significant time to the overall project.

Lesson learned:  frequent regular review of upcoming plans, including details as “DBMS version xxx needed.”  A review, meaning a meeting (even if virtual), with some communication, should be held.  Make sure the right people are talking to each other.

Choice is a Gift

 In traditional development methodology, tasks are assigned to the developer, usually by their manager or by the project manager.  In an Agile environment, the team is self-organizing.  Managers accustomed to hierarchical or command and control cultures find this unsettling, almost heretical. But repeated studies (e.g., Forrester) have shown Agile teams to be more productive.  Within the Agile community, one even discusses a team becoming hyper-productive, as though achieving an elevated state of awareness, transcendent.

 My assertion is that giving the developers the ability to choose is a major contributing factor in that increased productivity; furthermore, that this can be applied in non-Agile environments.

 It is not just the selection among different options that is empowering, but the detailed involvement in the decision process.  With that involvement comes a commitment of mental energy, an increased degree of being invested in the outcome.  The ability to choose is by itself a reward. 

 Effective choosing cannot be done in a vacuum.  As a manager, part of your role in giving a team the ability to choose is to make sure that they have correct information, as rich a context as possible for their decision;  where this fits within a larger view.  Your ability to communicate your vision is an essential ingredient in the outcome. 

 One must factor in the nature of the team:  how experienced they are; their knowledge of both subject and technology; their interaction with each other.  The degree of guidance you provide is part of your art as a manager. 

 Trust is key: bi-directional trust. You trust them, but they also need to feel that you have their back covered. Do you trust them enough so that YOU take responsibility for their choice?  If your boss comes asking, it’s still your responsibility.

 Choice can also inspire creativity, options as a gateway to innovation.  You believed the options were A, B or C, but once the team got actively involved in the decision process, they came up with a supersonic rainbow that did it faster, more reliably, and made the users happier.

 As a manager, it takes courage to trust your people and give them the gift of choice.  Reward them with this, do it wisely and well, and don’t be surprised if their excellence exceeds your expectations.


The Virtual Water Cooler

A key to excellence in managing remote staff is to go beyond formal communication and status reports, to have regular, frequent informal exchanges.

For example, encouraging creativity and innovation often requires interaction beyond the confines of formal channels. In a real office (as opposed to virtual), casual conversations, around the stereotypical coffee machine or water cooler, facilitate these types of contacts.

To really succeed in remote management, you need a virtual water cooler. Think about your own experience with communication outside formal channels or settings. Think about all that you heard or learned at gatherings at the local pub.

Think of such a channel as one for information gathering, listening; occasionally an exchange of ideas, a conversation.

A simple way of creating a virtual water cooler is for a manager to be available in a chat context (e.g. chat room), or for instant messages, at a previously posted time.

If there’s some news or event in the company, industry or larger context, pick that as a topic, announce it, and make yourself available.

If you seek to increase unity among members of a distributed group, facilitate communication. For example, once a week, have a different team member present some tech news or tidbit that they found interesting. But the manager MUST attend those meetings. For others, it should be optional.

Strengthen the sense of a shared mission, a shared vision.

Communicate outside the direct and most immediate, to allow room for the remarkable.