Plans, Strategies, and Uncertainty

“It is difficult to make predictions, especially about the future,” is an insight attributed to about two dozen sources. Actually, any one of us could have said this for it’s certain we’ve all had an intuitive feel for the truth revealed by these words. This is undoubtedly why we work so hard to tease out the details about what the future may hold by making plans, laying out strategies, and running scenarios based on our version of the best data available today. Each of these tools are employed in an effort to reduce uncertainty about the future. But which tool to use? Therein lies the rub. The answer, rather unhelpfully, is “It depends.”

  • How complex is the problem space?
  • How well is the problem space understood?
  • What is the availability of resources (time, money, people, materials, etc.)?
  • What is the skill level and experience depth of those tasked with developing a plan or a strategy?

Stated simply, creating a plan and sticking to it is ideal for simple, well understood, small scale problem spaces where one or more resources are limited. They work if the individual or team tasked with finding a way through the problem space is inexperienced or lacking skills required by the problem space. As complexity and uncertainty increase, the way forward benefits with a more flexible approach. This is where it’s helpful to have a strategy, something that is more than a single course of action. Rather, a strategy is a collection of possible paths, each with its own set of plans ready to be implemented if the need arises. Working a strategy requires a higher order of skills. It requires systems thinking that has been tested and vetted for competence rather than just a shallow claim of being a “systems thinker.”


Image by Maddy Mazur from Pixabay

The Limits of Planning Poker

As an exercise, planning poker can be quite useful in instances where no prior method or process existed for estimating levels of effort. Problems arise when organizations don’t modify the process to suite the project, the composition of the team, or the organization.

The most common team composition for these these types of sizing efforts have involved technical areas – developers and UX designers – with less influence from strategists, instructional designers, quality assurance, and content developers. With a high degree for functional overlap, consensus on an estimated level of effort is easier to achieve.

As the estimating team begins to include more functional groups, the overlap decreases. This tends to increase the frequency of  back-and-forth between functional groups pressing for a different size (usually larger) based on their domain of expertise. This is good for group awareness of overall project scope, however, it can extend the time needed for consensus as individuals may feel the need to press for a larger size so as not to paint themselves into a commitment corner.

Additionally, when a more diverse set of functional groups are included in the estimation exercise, it become important to captured the size votes from the individual functional domains while driving the overall exercise based on the group consensus. Doing so means the organization can collect a more granular set of data useful for future sizing estimates by more accurately matching and comparing, for example, the technical vs support material vs. media development efforts between projects. This may also minimize the desire by some participants to press harder for any estimates padded to allow for risks from doubt and uncertainty, knowing that it will be captured somewhere.

Finally, when communicating estimates to clients or after the project has moved into active development, product owners and project managers can better unpack why a particular estimate was determined to be a particular size. While the overall project (or a component of the project) may have been given a score of 95 on a scale of 100, for example, a manager can look back on the vote and see that the development effort dominated the vote whereas content editors may have voted a size estimate of 40. This might also influence how manager negotiate timelines for (internal and external) resource requirements.


Photo by Aditya Chinchure on Unsplash

Teams, Tribes, and Community – 0.1.0

Several months ago, I made bold decision: Take command of the helm for a brilliant tribe of diverse creative thinkers dedicated to helping each other succeed. This is the first of an on-going series of posts – maybe once or twice a month – describing this evolving effort.

For an extrovert, this might not have been a bold decision. But in my case, you should know I designed the card that card-carrying introverts carry. So this decision involved a more thorough application of my already robust decision-making process. On a professional level, this may be the most significant challenge I’ve taken on to date. Will my years of experience with forming and guiding teams help this tribe further their success? Will I be able to find the gravitational force that holds us together and the spark that keeps us inspired? These are open questions. They are also questions that occupy much of my thinking.

We are not dedicated to achieving a single goal or moving in a unified direction. We each have our areas of expertise and independent business goals. We are much more a tribe than a team. As such, I believe we will be guided more by tribal dynamics and models than team rules and policies. The path is not clear, but this much I know…

  • There is no leader of this tribe. Not in the sense of a single person who’s responsible for setting the direction and making all the decisions that impact the organization. There is no “Chief” or “Czar” of anything. I’ll fill the role of Launch Commander and Flight Commander in order to get us organized and moving forward. However, I have been clear from the start about my intention to structure our tribe on principles of self-organization.
  • The emphasis is on simple and accessible technology and easy ways to organize meetings based on Agile principles and practices – lean coffee, for example, has served us well for our initial meetings. What has emerged since then are more involved and interactive meeting formats, such as client role-plays and accountability exercises. Keeping things simple and remaining mindful of barriers to participation is vital. Too many tools with too many logins risks the creation of a Tower of Babel. For now, the weekly video call is the center-point around which we all meet. This in itself is enough of a challenge given the global participation. Other than this, email is the acknowledged primary channel for asynchronous communication.
  • We are not accepting new members. Whether or for how long this remains the case is undecided. We have discussed various ways of introducing new members, but have decided to decide on this issue later. The circumstances that brought each of us together created a unique bond of trust and familiarity with each other’s business interests that makes the introduction of new members a risk to maintaining these relationships. At the moment, we are tipped slightly toward being on the large size and everyone acknowledges if we grow much bigger the meetings may become unmanageable and the interactions less valuable. Since trust is foundational, none of the details related to who we are and what we discuss will be revealed in this space. My writing will be limited to the general case of what I discover from having participated in and helped guide our tribe. It is my hope this may help others with forming and guiding their own teams and tribes.

Whatever the outcome, it’s been more fun thus far than I’ve had in a loooooong time.


Image by Youssef Jheir from Pixabay

Achieving 10x

Crossed paths with an old but still relevant conversation thread on Slashdot asking “What practices impede developers’ productivity?” The conversation is in response to an excellent post by Steve McConnell addressing productivity variations among software developers and teams and the origin of “10x” – that is, the observation noted in the wild of “10-fold differences in productivity and quality between different programmers with the same levels of experience and also between different teams working within the same industries.”

The Slashdot conversation has two main themes, one focuses fundamentally on communication: “good” meetings, “bad” meetings, the time of day meetings are held, status reports by email – good, status reports by email – bad, interruptions for status reports, perceptions of productivity among non-technical coworkers and managers, unclear development goals, unclear development assignments, unclear deliverables, too much documentation, to little documentation, poor requirements.

A second theme in the conversation is reflected in what systems dynamics calls “shifting the burden”: individuals or departments that do not need to shoulder the financial burden of holding repetitively unproductive meetings involving developers, arrogant developers who believe they are beholding to none, the failure to run high quality meetings, code fast and leave thorough testing for QA, reliance on tools to track and enhance productivity (and then blaming them when they fail), and, again, poor requirements.

These are all legitimate problems. And considered as a whole, they defy strategic interventions to resolve. The better resolutions are more tactical in nature and rely on the quality of leadership experience in the management ranks. How good are they at 1) assessing the various levels of skill among their developers and 2) combining those skills to achieve a particular outcome? There is a strong tendency, particularly among managers with little or no development experience, to consider developers as a single complete package. That is, every developer should be able to write new code, maintain existing code (theirs and others), debug any code, test, and document. And as a consequence, developers should be interchangeable.

This is rarely the case. I can recall an instance where a developer, I’ll call him Dan, was transferred into a group for which I was the technical lead. The principle product for this group had reached maturity and as a consequence was beginning to become the dumping ground for developers who were not performing well on projects requiring new code solutions. Dan was one of these. He could barely write new code that ran consistently and reliably on his own development box. But what I discovered is that he had a tenacity and technical acuity for debugging existing code.

Dan excelled at this and thrived when this became the sole area of his involvement in the project. His confidence and respect among his peers grew as he developed a reputation for being able to ferret out particularly nasty bugs. Then management moved him back into code development where he began to slide backward. I don’t know what happened to him after that.

Most developers I’ve known have had the experience of working with a 10x developer, someone with a level of technical expertise and productivity that is undeniable, a complete package. I certainly have. I’ve also had the pleasure of managing several. Yet how many 10x specialists have gone underutilized because management was unable to correctly assess their skills and assign them tasks that match their skills?

Most of the communication issues and shifting the burden behaviors identified in the Slashdot conversation are symptomatic of management’s unrealistic expectations of relative skill levels among developers and their inability to assess and leverage the skills that exist within their teams.


Image by alan9187 from Pixabay

There Will Never Be an Agile 2.0…

…for the simple reason there was never an “Agile 1.0.”

Claiming to have crafted “Agile 2.0” would be like publishing the “Declaration of Independence 2.0” or “The Laws of Thermodynamics 2.0.” The Agile Manifesto is foundational. It is a statement of first principles that underpin a mindset from which a mountain of tools, techniques, frameworks, and practices have been created.

As to methods, there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.Harrington Emerson

As a tool, its utility comes from providing a stable base from which we can clarify complicated problems. Much of the 2.0 stuff I’ve read adds complexity and complication to a simple set of values and principles. In this regard it reflects research that shows people are more likely to add to solutions rather than subtract.

It’s this notion of a stable base that flummoxes people seeking to assign versions to Agile. First principles are often unassuming, their beauty and brilliance is masked by their seemingly simple codification of how things best work. Neither are first principles about absolute truths. First principles can have first principles. The first principles by which I use a wood plane are different from the first principles used by the tool manufacturer when milling the steel for the blade. My first principles of use inherit and extend the manufacture’s first principles of milling steel.

The Agile Manifesto identified elements in software development that are non-reducible. To be clear, there are other first principle elements not included in the Agile Manifesto and the Agile Manifesto doesn’t apply to every conceivable context. Twenty years of experience of applying it’s four values and twelve principles to other areas of business have revealed this to be true. They are not, nor will they ever be, an absolute truth. As our understanding of why they work so well improves, so will the underlying principles. Frankly, I’m impressed they have held up this well this far into the Internet Age. And I certainly don’t expect them to withstand every challenge or be as durable as the Declaration of Independence of the Laws of Thermodynamics.

So when I read someone’s declaration of “Agile 2.0,” the first thing I want to know is if their proposal precedes the first principles established by the Agile Manifesto or are they trying to do something else. So far, it’s always been the something else. There may be some interesting thoughts related to an alternate framework or perhaps a change to common practices, but I’ve yet to see anything revolutionary or even evolutionary.

A second thing I look for: Is the author working to falsify any of the principles and have they done a good job of presenting their argument. Again, this hasn’t happened. Mostly I read a lot of complaints about wording or ambiguity or history or stuff that is little more than efforts to tag the foundation with a personal style of graffiti.

I’ve yet to see Agile’s next evolutionary phase. I hope someday I will.


Image by 은주 송 from Pixabay

Cargo Cults in Management

 

I first read about cargo cults in Richard Feynman’s book, “Surely You’re Joking, Mr. Feynman.”

I think the educational and psychological studies I mentioned are examples of what I would like to call cargo cult science. In the South Seas there is a cargo cult of people. During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they’ve arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas–he’s the controller–and they wait for the airplanes to land. They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No airplanes land. So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they’re missing something essential, because the planes don’t land. (p. 310-311)

I was a newly minted biochemist and Feynman’s unique perspective had a significant impact on my critical thinking skills. It established a “cargo cult” sensor in my brain. As my career developed and branched out into other areas of interest, the ubiquity of cargo cult thinking became apparent.

In the work place, “cargo cult” thinking may not necessarily be a bad thing. As a tool, it can be used as an “as if” frame for working out the solution to complex problems or gaining insight into black boxes. By assembling all the known and visible elements and arranging them to match the form as best as possible its easier to see what’s missing.

If an executive’s minions are behaving in a way that reflects his or her approach to management, is that a good thing? Here is where business leaders get into trouble. Are the executive’s minions imitating or implementing?

Less common, executives attempt to adopt practices that are successful at the knowledge worker level. About a decade ago I had worked to implement an Agile software development process with a small and highly capable development team. It was a daunting task: completely re-architect and develop a poorly coded application while supporting the old application. (In 30 years, this was the first and only time I recommended a complete redesign and rewrite of a major application.) Of course, we started each morning with a “daily scrum” meeting – sometimes called a “daily stand-up” – before the team set off to immerse themselves in code. These are very quick (15 minutes or less) meetings where everyone literally stands up for the duration of the meeting. The idea is that by standing, attendees are less likely to drone on about trivial matters or issues that do not require the entire team’s input. Complicated issues are quickly identified and scheduled for more detailed meetings, if necessary.

Six months into the project it was very clear our approach was working and insofar as the coding effort was concerned, we would be successful. The senior executive to this effort seemed impressed and decided to switch to a “stand-up” meeting format for the executive team meetings. They were “stand-up” meetings in name only. Rather than a once a week meeting that virtually always extended way beyond the originally scheduled 60 minutes, I now had to attend daily meetings that went on for 45-60 minutes during which nobody stood.

There were other issues with implementing the executive team scrum meetings. The senior executive did a poor job of modeling the behavior he sought and there was very little control over the clock. Developers are smart people and they notice things like this even though they are not directly participating. Among those being managed, it does little to inspire confidence in the management staff.

Nonetheless, I like the idea of applying Agile methodologies to management meetings. After action reports, as used by the military, would also help. There is also a place for storyboards and retrospectives. But implementing these and other elements would require a significant learning effort on the part of the management team. Not because the methods are difficult to understand, but because the MBA mindset of many management teams would have to loosen up a bit for the requisite unlearning to become possible.

Rethinking the idea of “management” in the context of Agile principles and practices blends quite nicely with many of the things I’ve learned around the idea of “Management as a Service.”

References

Feynman, R. P. (1985). “Surely you’re joking, Mr. Feynman!”: Adventures of a curious character. New York, NY: Bantam Books.


Image by Free-Photos from Pixabay