Standard. Methodology.

Professions establish vocabularies. After achieving consensus about definitions, professionals can communicate more precisely and quickly. I offer some candidates to our professional consensus here on terms for software development projects. What would you change here?

Let’s agree with guidance from the American National Standards Institute (ANSI®), quoting a joint standard of the International Organization for Standardization (ISO®) and the International Electrotechnical Commission (IEC®), that a standard is, “A definition or format that has been approved by a recognized standards organization or is accepted as a de facto standard by the industry. (As defined in ISO/IEC Guide 2:2004)”.

I suggest we consider a methodology to be the specific set of training, development processes, tools, templates, and controls a particular software development team uses to structure its work. A methodology includes reference (as needed) to specific tools, communication channels, approval meetings (and lists of attendees appropriate for each), document templates, development languages, and responsibility assignments. Harold Kerzner used the phrase “forms, guidelines, templates, and checklists” during his May, 2007 Omaha presentation advocating effort to detect and document best practices.

There is power in the statement that by this definition, a methodology is a company standard, with corporate leadership taking the role of “recognized standards organization”. Following the lead of the ANSI guidance about standards, I focus here on industry standards.

That definition doesn’t specify that a methodology is documented. (This is the “you cannot not have a methodology” argument. You might not have a repeatable or consistent methodology…) As team sizes and project sizes grow, my impression is that few experienced professionals on either side of the waterfall/agile discussion would recommend no documentation of the methodology.

Many of the agility models (the Agile Manifesto®, in fact) advise caution about excessive documentation. I agree. I have seen methodologies that seemed to have everything “plus the kitchen sink” in them. They were hard to understand and so difficult to use that teams did only those parts that were well enforced. After some point of growth, it makes sense to require that for everything added, something must come out of the methodology. Simple is better. Focus is great!

Examples:

  • The Project Management Institute (PMI®) publishes the PMBOK® Guide as a standard. At one point in its history, many project managers considered it a standard because they accepted PMI as “a recognized standards organization” (from the definition above). I hope that’s still true today (grin). Many people outside PMI probably consider it more powerful today that ANSI listed the same document as a U.S. standard (ANSI/PMI 99-001-2008®) and that IEEE® listed the same document among its standards (IEEE Std 1490-2011®).
  • A company’s methodology is the collection of policies requiring particular practices (perhaps requirements to use particular templates for documents; perhaps requirement to use a particular inter-project corporate-level shared resource for change management or version control or lessons learned (or other); perhaps in a waterfall environment, requirement for a phase-end tollgate or phase review (or any of many similar terms); perhaps in a Scrum environment, a requirement to use a Daily Standup and a Product Backlog).

Non-examples:

  • No company’s methodology is an industry standard, if only because it depends on tools, databases, training, and past shared experience not available outside the company.
  • No standard is a methodology. (Ever read a job ad stipulating that successful applicants will “use PMI methodology”? At one level of precision, that sentence means little!)
  • “Agile” and “agility” are not methodologies. (Recently I heard Susan Courtney (of Nebraska Blue; Apr 2012 AIM Institute Technology Leader of the Year) forcefully and committedly advocate agility and suggest (about software development life cycles, SDLC) that companies don’t understand agility if they want to “implement a new SDLC called ‘Agile'”. I agree with her; a company needs to change more than the SDLC to increase agility. Agility depends on a wider and deeper partnership than that. And provides more benefits than just an SDLC change.)

Between the concepts of standard and methodology is a set of guidance generally not as accepted as a standard or not as specific as a methodology; some call this group models or methods or frameworks or processes. There is considerable variety in the terms used (example). Let’s use model here, though it’s not a perfect label for this group.

Models help us select methodologies. Though the following is a (very!) partial list, examples include:

  • The original paper about waterfall. In my experience, it’s very common to hear reference to “the waterfall model”. (Interestingly, Royce didn’t use the word waterfall, though his central diagram clearly resembles a waterfall. This paper makes a strong point about the need for adequate documentation in a software development effort.)
  • Mary and Tom Poppendieck’s 2003 book, Lean Software Development, An Agile Toolkit (ISBN 0-321-15078-3). (This is a valuable contribution to software development thought and arguably had the most pivotal early impact in associating the concepts of Lean manufacturing with software development.)
  • The PMBOK Guide. (Though also a standard, it provides much of the detail typical of this middle group and allows considerable latitude in implementing company-specific details. Far more than not, agility models are consistent with the PMBOK Guide. The Fifth Edition of the PMBOK Guide is due out in 2012/2013; I’m betting agility models will have lots of impact on the new edition.)
  • The Scrum Alliance® summary of Scrum. (By the same token, I acknowledge the power to the statement, “That’s a standard! The Scrum Alliance is the “recognized standards organization”.)

How best can we make use of these concepts? Here’s one vote for our teams (maybe our companies; in the ideal world, teams have a role) using guidance from standards and models to define everything we need in our methodology (and not a bit more!) And applying the specificity that distinguishes a methodology from a standard.

Who’s Your Competition?

Bo Pelini is the head football coach at Nebraska. That first hyperlink is a bio that starts with, “It is about the process.” The phrase expresses a mindset for Bo, judging by how often the public has heard that message from him. Sportscasters say he tells the players that, “They are their own barometers.” Or, “They’re their own standard.” Or not to worry about the other team; if Nebraska players execute the plays right, the game results will take care of themselves. (That last one demonstrates considerable confidence in his coaching staff, eh?! He’s a leader to them, too!)

Is your mindset non-competitive? Do you compete with peers? Or with an idea?

My experience suggests non-competitive mindsets are the least common. We commonly teach aspiring members of our workforce that we and our organizations achieve more if we and they set goals and track progress toward achievement. The PMBOK® Guide devotes one of the largest of its five “Process Groups” to “Monitoring and Controlling”. At the start of each Sprint (or Iteration) in Scrum, teams set goals for the Sprint in a Sprint Backlog. At the end of each Sprint, teams focus for a time on what went well (so we’ll be more likely to do it again) and what didn’t go well (so we’ll be more likely to try something else). Maybe goals and competition with them are intrinsic parts of the human condition.

Some problems in our organizations relate to competition. On a sports team, two players at the same position “compete” for playing time and for approval of team, coaches, and fans. There are parallels in the workplace. It’s too common that people react with jealousy, sabotage, and other attributes and acts we’d rather not see in our organizations. (Or … in ourselves!)

At the same time, some benefit to our organizations relate to goal-setting. It is one way people notice when there’s a better way to complete a process; they consider (and sometimes choose) to improve that process. It is one way people widen the breadth of their thinking and base decisions on more information. (They avoid “rearranging the deck chairs on the Titanic”, or what some mathematicians call “suboptimization” or “local optimization”.) Goal-setting is one way to introduce a feedback loop into our decision processes. And each point this paragraph makes about people applies also to our organizations.

Is Bo Pelini competitive? It’s just my opinion, but I’ll say the veins sticking out on his neck after something doesn’t go Nebraska’s way is powerful evidence! I’ll say … he’s competitive.

I conclude Bo Pelini is teaching Nebraska football players to compete against an idea: the “perfect” game in which each player executes every plan as assigned and adapts as intended. Because Bo establishes that emphasis, players at each playing position focus on each other as teammates rather than as competitors; they work hard to develop the skills they contribute to the team. The players learn to think simultaneously at a position level (“Who am I supposed to block this play?”) and at a team level (“This play is supposed to achieve [I don’t know–a running back running the ball through a particular gap; whatever]; if the player I’m to block is out of the play for any reason, I’ll find another way to contribute to the larger goal.”)

I suspect Bo chooses this coaching mindset in part because it helps his players focus on cooperation with teammates and skills they contribute to the team. He believes teams work better when team members cooperate.

I suspect Bo feels the team is stronger if all players focus on doing all they can to help the team win. And avoid focus on comparing themselves to teammates. He seems to want them to feel that if they focus on being the best player they can be, the playing time will take care of itself.

I see parallels for those of us serving less visible teams than Nebraska football. My examples come, of course, from software engineering projects.

  • A clear and accepted team goal (say, completing the software tool a customer needs to implement their planned new business process) is valuable in helping team members make supporting decisions and independently adapt to unexpected conditions. It encourages initiative and free thinking. (Some in the U.S. military use the terms “Command Intent” or “Commander’s Intent“.)
  • Teamwork may be achievable, but it is more difficult if a team “knows” that two teammates want a promotion (or raise, bonus, or recognition award) only one can get. Maybe those two people sabotage each other. Maybe those two people are exemplars of good behavior, but teammates suspect otherwise.

NCAA Division I athletics (and software engineering projects) are tough enough without optional obstacles! I like Bo’s coaching mindset.

Hmmm … college athletics are supposed to be education, right?! Maybe they’re working beyond the teams! Thanks, Bo!