Paired Project Management

You probably have seen some of the statistics on project success rates, or more aptly, the rate of the lack of success. The Standish Group’s Chaos report is often cited as one source. There are numerous causes, but one suspects the statistics are even worse for projects of greater complexity.

There are multiple factors to project complexity: the impact strategically or financially to the enterprise; the overall stability of the environment; degree of uncertainty (in multiple dimensions and constraints – from, “is this definitely the right path?” to “will key resources remain”); the number of different disciplines involved; severity of social or legal impact; etc. Far too often, project managers don’t evaluate complexity at project initiation, only realizing the project is of significantly more complexity when difficulties are encountered.

Rule of thumb in planning:
the more complex an undertaking, the more likely any one individual will miss some key element.

One of the interesting practices in the Extreme Programming (XP) movement has been use of pair programming. Two programmers sharing a keyboard and monitor, working together. The typical dynamic is that of driver and navigator; periodically, they switch. Necessary conditions include compatible temperaments as well as cultural support in the team and organization. There are other factors, well discussed, as the use of this practice is about two decades old. Numerous articles discuss paired programming, its benefits (e.g., knowledge sharing), difficulties, and variations.

One of the results of this has been a significant decrease in defects. This is key towards the suggestion: for projects of greater complexity (starting at the upper range of medium), to better ensure project success, use a pair of project managers.

In addition to the need for compatible temperaments, the working environment needs to be supportive, with management not hostile to the idea.

During the initiation phase, having a 2nd knowledgeable viewpoint helps minimize likelihood of anything being overlooked in creation of a work breakdown structure (WBS); better communication planning; more inclusive and clearer risk identification and management strategies.

During project execution, .having two different people allows for more tailored stakeholder management, more bandwidth for individualized communication. In meetings, one can lead the meeting, with the other having the focus on analyzing the meeting dynamics, better able to avoid conflicts or facilitate their resolution if such arise, or even just taking better notes than one person trying to handle both.

If things start to really go badly, it is advantageous to have two perspectives, two sets of experiences upon which to draw, to turn the situation around.

Evaluate project complexity and success rates in your environment. If those rates are not satisfactory for projects of greater complexity, try paired project management.


Islands of Competence

“Islands of competence” is a term devised by Dr. Robert Brooks, psychologist at the Harvard Medical School, to refer to the distinct strengths that each individual has.  Instead of focusing on fixing deficiencies, it changes to one of identifying and reinforcing strengths.

While his thoughts were about individuals, particularly those with learning disabilities, they apply to growth and development of any individual, and to teams as well.

Identifying strengths is challenging, either for individuals or teams.  As individuals we are acutely aware of our weaknesses, but oblivious to many of our strengths.  Teams may be even less aware of their special powers as a collaborative group.

Observe behavior over time; that should provide a starter list of strengths.  Ask the team, possibly in the context of a session on Lessons Learned, or an Agile Retrospective, especially after a product release.

The concentration on improving areas already perceived as strong should build self-esteem and team morale.  From that momentum, and feeling of confidence, it is then easier to cope with improving deficiencies.  That positive feeling improves the ability to face challenges and difficult circumstances, increasing resilience of both individuals and teams.


Dr. Robert Brooks


Innovation and Cognitive Diversity

 When we form a team, we tend to populate it with people whose thought processes are similar to our own. It’s natural, in part because it’s easier on us. People whose priorities and thought processes are distinctly different from our own are potential sources of friction within the group.

 But when there’s a need to address complex issues, come up with innovation, combine components in new and value-enhancing ways, then having a team that is cognitively diverse is of benefit. Cognitive diversity means diversity in how we think, in how we perceive and prioritize those perceptions.

 There are some necessary conditions for cognitive diversity to have benefit: team members have to be able to get along with each other, and to work together towards a goal commonly agreed upon.

 Cognitive diversity implies that some members of the group will perceive the world differently, and have distinct mental toolsets associating those perceptions. The interaction between cohesive yet distinct viewpoints allows for fresh solutions, perhaps combining existing processes or elements in new ways.


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.

Agile User Stories and Application as Persona

In Agile, requirements are communicated via user stories.  Traditional user stories use the form, “As a …, I want to …, so that I can ….”.  For example, “As a first time user, I want to be able to create a user name and password, so I can securely do transactions.”   That enables functional requirements to be captured as user features, but still does not address the often critical “non functional requirements” (NFR) in an Agile framework.  NFR are items sometimes associated with infrastructure, such as capacity, scalability, reliability, availability, or security.

One approach to including NFR in an Agile context is to create user stories based upon the application itself as having a role or persona.  For example:

“As an application, I want to be able to process xxx transactions per second, to be able to handle peak monthly demand.”

“As an application, I want to be resistant to SQL injection attacks, so that my transaction integrity remains valid.”

Appropriate acceptance criteria need to be included; phrasing those can be challenging in these cases.

Extending the concept of the application persona further, it can also be used for other aspects of the application, such as user interface or user experience.  Those may fall outside the straightforward transactional features covered by more typical user stories; use it for the more qualitative ones, the fuzzier parts.  The usual guidelines still apply: make the story as granular as possible;  and to include acceptance criteria.  Acceptance criteria can be very difficult to create when one is trying to specify aspects of user experience as quality or beauty.

Taking this further still to the more general case of product development, including the difficult cases of ad campaigns or branding, the concept of the application or product as a persona remains tenable.

E.g., “As a brand, I want to be able to highlight the excitement of using our products, so that I can …..”

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.



What’s Missing From Your SDLC

Having an SDLC (Software Development Life Cycle) documented is not to provide a minimum effort on development, or something to ignore, and keep writing programs as the mood strikes.  It’s part of an effort to follow best practices, to deliver high quality software on a repeated basis.  Even Agile methodologies can have an SDLC.

SDLC’s usually cover the core of the process of software creation, from initial requirements through design, coding, testing, integration, user acceptance, etc.  Some key elements are often overlooked, or considered not to be part of software development.  I’d like to suggest that you think about some areas that might improve the quality of the software you create if they are part of the SDLC.

Production support is not just about maintenance and fixing defects.  It’s about the ongoing improvement of what you delivered, preparation for the next release; part of the SDLC.  It’s about empowering the users, giving them the ability to fix their own problems when possible and reasonable; giving the right tools to the first level of support.  Not just documentation, an FAQ, or online Help, but items like creation of an error log and error trapping.  If the application has a database or data store, did you design a quality check on stored data, not just relying upon front end edit checking?

Does the application offer its users the opportunity to report problems, or give feedback about the interface they use?  What are the processes you envision for the ongoing improvement of the product?

Some SDLC’s include a Lessons Learned as part of closing out the development effort, project wrap-up.  The problem with that is it doesn’t do any good for the project in question, since that’s over, and seldom is examined either for the next release or by other projects.  Taking a page from the Agile approach of a retrospective for each iteration (sprint), why not do a Lessons Learned at each major milestone in the project, so the project can actually benefit while still in progress.

Security reviews should be part of the SDLC for all applications, not just web apps, not just for external facing ones.  How vulnerable is your application if another behind the firewall is compromised?  Security is part of the design process, not just something during the testing phase.

Security challenges are constantly changing, and some level of awareness needs to be part of the mindset of developers, not just IT security professionals.  Look towards organizations like OWASP (Open Web Application Security Project) as a resource.  Their Top Ten Security Risk list might startle some of your peers.

The Department of Homeland Security has some excellent resources, such as a National Vulnerability Database  as well as checklists and guidelines.  Look around their site.

Security is often a nightmare for developers, but there are people, organizations and tools to help you.

Look at your SDLC, think of the ongoing life of your applications, and what might enhance their quality.  The SDLC is an ongoing opportunity for process improvement.