Thursday, January 09, 2014

What is your problem? - Part 3: Descriptions

Months ago, I wrote about problem reporting within teams, making a general distinction between good problem reporting that leads to a solution versus insufficient reporting that causes the involved parties to lose precious time during a critical situation.

Now it is turn to look at these from the perspective of software development, which may turn off audiences interested in the general topic, at which point I incur in the blunder of assuming anyone beyond my friends in the field read these.

Technical notes, your problem is not someone else’s problem…

There are always those moments in software development where your overall quality assurance process fails your customers and your standards, at which point you must publish a technical note about it. For our project, the template of a technical note requires 6 fields:

  1. problem description. A general view of of the problem. This is a very difficult topic for most developers who have not been exposed to the problem reporting techniques covered in this series, in that general is confused with imprecise. This topic is therefore the focus for this posting.
  2. symptom. List of externally observable behaviors and facts about the system upon occurrence of the problem
  3. cause. List of internal and external triggers for the problem, with special emphasis on those that can be triggered (and hopefully fixed) by the customer versus those that are internal to the product and require a product fix.
  4. affected environments. Complete list of prerequisite software and hardware where the problem can be observed, including versions and releases.
  5. problem diagnosis. Symptoms and causes give a good indication as to whether the problem matches what a customer is seeing, however, the customer needs certainty before moving on to the next field
  6. problem resolution. The ultimate cause for a customer ever reading through a technical note, how can the problem be either fixed or worked around. A common problem in our internal reviews was that original drafts incurred in the mortal sin of limiting themselves to listing the upcoming release where the problem would be fixed. The customer always expects an interim solution to the problem, even if imperfect.

…so how do I know what is your problem?


To paraphrase one particularly troubled internal draft, we had the symptom, cause and description all folded into the problem description field stating that

“search for records may be incomplete due to a [private] database being corrupted upon execution of a [series of commands]” .


At that point, we applied the criteria outlined in the previous posting to determine whether the problem reporting to the customer would lead to a decision or to confusion:

  • What is the expected behavior from the product?

The description can be somewhat ‘reversed’ and allow one to infer that search for records should not be incomplete. However, this indicates what the product should not do instead of what it should do. For the technical types, this kind of wording tends to make the author look sloppy at best, disingenuous at worst.

  • What is the observed behavior in the product?

The description alludes to incomplete results, but results can be incomplete in so many ways, such as not containing all records that would match the search criteria, or containing all records while missing some fields in each record.

  • Does the reported problem happen to all units of the product?
  • Does the reported problem affect the entire product or just portions of it? If so, describe the portions?

The ‘product’ here is the operation executed by the user. Is it all searches that are affected or only certain searches?

  • Does the reported problem happen in all locations where the product is used? (this forces the problem owner to have actually sampled the problem in all locations where the product is used) ?

Locations can be read as systems. If the product can run on multiple operating systems and depend on various versions of middleware, is there any enough information about the kind of systems where the problem occurs? Is it all of them?

  • Does the reported problem happen in combination with other problems?

This particular point would not apply to original problem description as the problem happened independently of other problems, as a function of search parameters and system operations preceding the searches.

  • When did the problem start? If you don’t know, make it clear you don’t known and state when you first observed it

When reporting the potential problem to a customer, the starting date would translate to the release number where the problem would be first observed.

  • What is the frequency? Continuous, cyclic, or random?

The problem description was reasonably clear about the problem being continuous. At least in my opinion, continuous can be assumed whenever considerations about cyclic or random occurrences are not explicit. In other words, I would consider really poor form for those types of frequencies to be omitted.

  • Is the problem specific to a phase in the product life-cycle?

The problem description was reasonably clear about the sequence of operations that would lead to the problem, indicating the problem to affect the system runtime phase versus planning, installation, configuration, or any other.

  • Is the symptom stable or worsening?

The problem description did not mention increasing degradation of results, but it is worth asking that question during a review process prior to publication of the technical note.

From problems to satisfied customers

This is an area to be approached with energy and patience while coaching people who are new to any field in the industry. Describing problems, as a function of language and critical-thinking, is not a purely exact science and requires prolonged periods of practice and feedback to be mastered.

When someone without the proper tools and techniques for problem description encounter someone on the other side who will go out of their way to understand the problem, it is easy to mistake the positive interaction rooted in an act of kindness for the most efficient way of going about it. And not to use efficiency to dismiss acts of kindness as a fundamental value in the workplace, on any given day we would rather have that kind person interacting with more people rather than spend it all on a single person working without proper training.

Once you have put the right effort behind training people in this topic (or training yourself), you will have affected a transformation effect on people that transcends the topic and the workspace: people used to asking all the right questions and solving the right problems under any circumstance.

Monday, November 25, 2013

What is your problem? – Part 2: Real versus imaginary problems



To ask "What is my contribution?" means moving from knowledge to action.
The question is not: "What do I want to contribute?"
It is not: "What I am told to contribute?"
It is: "What should I contribute?"
Peter F. Drucker


In the first part I covered the general aspects of identifying and reporting problems. Now it is time to apply those concepts to my domain of choice: software engineering (minor apologies to the software gardeners out there, I will come back for you in a future posting) .

I use the Agile method as the backdrop because it has completely overtaken the field to the point of erasing debate on alternatives (defeated waterfall proponents are still called through the backdoor to fill the gaps with valuable contributions, but I digress) .

As a short Agile method recap, work is delivered in small iterations called stories and executed over relatively short intervals, called sprints. If you can tell a story while on the run (sprints, running, see what I did there?) , you know sprint durations can range from ear-bleeding single-week sprints to waterfall-bordering 8 weeks. Beyond 8 weeks, there be dragons and T-virus, walk backwards slowly towards the nearest door and avoid eye contact at all costs.

The drudgery of tasks…

A fundamental tenet of Agile method is that stories be written in the form of “As a [role name] I need [a feature] so that [I can achieve a goal]”.

I personally prefer to replace “achieve a goal” with “solve [one of my] problems”. There are far more people in this world facing immediate problems than people who have goals, and even for the people who have both, the immediate problems tend to grind one’s will and resources to execute on long term vision.

That is not to mean Agile should be cast as a reactionary method that can only tackle situations after they have become a problem, but that any complex project can be mapped to a mind-map of tasks, where each node can be represented as a problem to be solved.

… is no match for the challenge of a problem

The payoff for such mental gymnastics is that a problem statement engages, whereas a task dehumanizes, and success in software development hinges on engagement: on engagement between developer and customer, on engagement between user and solution, and as a more recent phenomenon, engagement amongst users.

It is part of many professions to walk into an engagement where the customer knows exactly what they need, are willing to pay for those services, watch you walk out of the door after completion and then deal with the next task in a master project plan.

That is invariably not true of software development for two main reasons: (1) our largely INTJ subtlety-loving personality is prone to invent dozens of different ways of achieving the same goal with dozens of distinct advantages and disadvantages for each choice, (2) we collectively get bored of those solutions more often than we should, reinventing the field every couple of years in a way that is utterly incompatible with what we once thought to be a good idea.

With all that said, as a prospective customer to a solution requiring software, whenever you engage a developer or a development shop, the first part of your homework is to be absolutely sure the problem you want solved is one of your top-most problems, lest you (or your company) may not sustain the motivation to see it through. As the person (or company) experiencing the problem, and this may seem outrageous since you are about to pay for contracted services, you will be integral part of the solution: there will be hard questions to be answered at some cost of time, intermediary solutions to be attempted, final validations to sign off, all activities that will require your attention and resources.

Know your problems…

As a prospective software provider, accepting a task at face value is a recipe for disaster.
A good software architect must know how to artfully act as a devil’s advocate while engaging a customer, not to blindly question motivations, but to understand why the customer needs a solution. In other words, a good architect will ask the customer “what is your [his] problem?”
I often hear from peers disgruntled with the fact a great idea was not accepted by a potential customer, at the same time failing to recognize the problem solved was not all that important to the customer.

… know thyself

In a previous project I joined a team which had developed an internal tool for analyzing log data from hundreds of products. At the time I was the enablement lead for the technology and really got behind it. We persevered for a long while to make our world-wide support team adopt the(internal) product. After a relatively extended period of … err…lukewarm responses, we changed our approach, meeting frequently with these support teams and also with another internal development team who was already successfully supplying tools to the support organization.

It became clear that our log analyzer tool, however sophisticated in what it could do with log files, required memory capacity that, although readily available to our development team, was unthinkable to a support engineer. This tool also had the ability, developed at great expense, to shift the memory requirements to a relational database to cut down on memory usage, but deploying and maintaining a relational database was equally unthinkable for an audience which had no expertise in managing such systems.

The question no one asked…

At the same time, meeting with the more successful internal development team revealed their key selling point to the support organization: their solution was based on a SaaS model and the support teams could access most of its function through web interfaces, avoiding the need for high-end systems and the costs of installing and maintaining new tools. Their tooling also integrated with another SaaS offering where customers submitted all the supporting information, including the all important log files, for any problem reported in the field.

In the end, building (or selling) a log analyzer to a support team which routinely performed log analysis seemed like a success story in the making, but it failed to recognize two key aspects:
  1. Their most common activity related to log analysis was to isolate error entries in log files, then use snippets of the log entry on Internet searches (incredibly effective) , a feature absent in our tool.
  2. All the information used by the support teams resided on virtual services, requiring only a web browser on their machines, which side-stepped the need for high-end systems.
At the time, and this was a remedial approach to not having asked the “what is your problem” question first, we decided to harvest the log the analysis internals from the tool, put it under the web-based interface already being used by the support team and surface the analysis results through a page that only contained warning and error messages, with a quick link to an Internet search based on the error message.

…is the problem no one had

Had we asked the harder questions first, the answer would have been a SaaS version of the patent we filed a few months later, where log files submitted to customers were automatically analyzed, cross-searched on websites, and results ranked according to their rate of incidence in results. At that point I left the team for other reasons, but I am told they kept on delivering on that vision.

Something fantastically useful eliminates a problem that is really at the center of someone’s attention, and not something you set out to improve, however successfully. Success also involves far more than technique and technology. In fact, too much technology may just put the solution out of reach for the target audience, in requiring system upgrades, training, and adaptation.

In closing, I end with a quote that symbolizes the consequences of offering a solution on the basis of vision without sufficient understanding of the problem, resulting in one of the costliest mistakes of the kind in recorded history:

We could hardly dream of building a kind of Great Wall of France, which would in any case be far too costly. Instead we have foreseen powerful but flexible means of organizing defense, based on the dual principle of taking full advantage of the terrain and establishing a continuous line of fire everywhere.André Maginot
December, 1929

Wednesday, October 30, 2013

Critical thinking and cows in the field

imageI heard this fictitious story as a joke some 20 years ago from my college-time great friend, Walfred Tedeschi, and it has stuck with me for all these years, first for the good joke that it is, then as a profound lesson in critical thinking.

At a gathering in the University, three students see a cow in a nearby field. One of them is a Mathematics student, the other a Physics student, and the other a Software Engineering student. Note: The fields and order of participation changes depending on who tells the story, and I can say as a Physics student at the time Fred would not agree with my recollection, but it goes like this:

The Math student hears a mooing sound to his left, about 100 yards away, turns around and says: “Look, a cow” .

The Physics student, turns around in the same direction, then adds: “A spotted cow”, with a slightly overbearing emphasis on the word “spotted”.

The Software Engineering student analyses the situation for a few moments, then concludes:  “At least on the side we can see.”

That punch-line is the one aspect that makes or breaks a great professional, in that it surfaces how different people may perceive the exact same situation (there is a cow in the field) with varying degrees of details and how those details may be factual (the visible side of the cow is spotted) or inferred (a cow spotted on one of its sides is likely to spotted on the other side) .

I don’t think this is the basis of a new philosophy graduation course, but it is worth telling people starting in their careers, both in the leadership and exact science fields, to guide the way in which we reach conclusions and how we trust information while making decisions or establishing a new hypothesis.

Later in life people may question why a cow in the field was even worth noticing, or whether the students were so distracted by the verbal sparring that they missed the sight of a golden unicorn a few hundred yards to the other side, but that is a story for a different time.

Friday, March 08, 2013

Crowds in the clouds, a brave old world

Sometimes, I like crowds.

I will soon be flying home, back from Las Vegas, where I had the privilege of attending IBM Pulse's conference.

The opportunity to meet in person many colleagues and friends from all over the world is equal only to the opportunity of listening to some of the most prominent voices in the technology field, from some of our brightest colleagues, from analysts, from business partners, and specially from our customers.

These interactions are an anchor in reality that cannot be taken lightly and at the same time are an anchor of a scale and relevance that are almost impossible to comprehend. This conference has become the equivalent of a small city of over 10.000 people, which is created and torn apart in the span of a few days. I wrote what I could during the conference, but Twitter only goes so far to convey the sense responsibility that comes with working in the information technology field.

In the view of CEOs, information technology is now the most important aspect of the their companies' future. It is also a critical aspect to the future of the entire world. Connectivity and smart devices are shaping an entire new dimension of interactivity between people, governments and the enterprise.

The democratization of technology... 
 
If you lived your career through the 90s, for a while it seemed technology would only get faster, until it became totally interconnected and different altogether.

For the first time in modern history (and I use 'modern history' very judiciously here) , self-organization, information sharing, and merit-based leadership have allowed crowds to emerge and galvanize quickly, and somewhat effectively, around subjects ranging from designing a new product, to funding new ideas, to fighting against tyranny and oppression.

The world is small again, and technology has rescued fundamental aspects of human nature from the incomprehensible and ever increasing size of our world population. Easier access to means of production enable people to become direct producers once more, weakening the hold of wage-to-capital relations; pervasive access to means of communication eliminates barriers between individual producers and individual consumers, it reconnects people with their power to decide their destinies and ultimately reconnects individuals with the rest of the world in more meaningful and direct ways.

...is rewriting the books on capital ownership...

The power of the masses puts tremendous positive pressure on leaders from public and private spheres in ways that even the most jaded of citizens cannot refute. Crowd-sourced projects like Domino's Ultimate Delivery Vehicle or movements like the Arab Spring are evidence that the mere existence of crowds can make executives and governments see and engage people in a whole different light.

Open and free platforms for supporting virtual communities are already part of daily activities for a large portion of the world population, 3D printing is maturing at a rapid place, new materials and more efficient recycling technologies will further reduce the importance of capital in human initiative.

In the not so distant future, you will be able to ship a toy to a shop across the country and get it "restructured" in a recycling unit that can reprint the raw materials in the format of another more interesting toy for your growing child

Imagining the gadgets of the future, however exciting, is not nearly as interesting as imagining the dramatic implications to economic and social relations of the future. Micro-financing is a fantastic example, closing the gap in democratizing the access to means of production, a reality for many small businesses in less developed areas of the globe, with rates of default that are smaller or equal to those of traditional bank financing.

Fantastic initiatives like the one from Marcin Jakubowski, outlined in his TED talk titled "Open-sourced blueprints for civilization", also point the way at closing the gap on intellectual capital. Ever increasingly, people are having more access to knowledge, means of financing, communication, and production, than ever before.

...and on social relations

Cities are learning how to integrate immediate feedback from the general population into their own management systems. Researchers are also exploring with how to understand the sentiment of a city. Technology is not only reaching the masses, it is starting to understand the masses, and that is only the beginning.
 
Regardless of how one may question the motives of companies and governments, it is important to realize that what we are seeing now, however unprecedented, is also a very small step in enabling a different future for humanity.

For those skeptical and suspicious of technology, the only message is to accept it without fear, because the only other option is to become part of a lost generation. The advancements are not here to rob us of our identity and individuality, they are here to restore these qualities in ways modern civilization has long forgotten.

Just like when technology evolution surprised everyone for not being just about making things go faster, and while everyone is grappling with the evolution of the new small world, technology will change the very nature of society and the economy itself.

The new companies and the new governments

Companies will be challenged by customers and employees to achieve a sustainable model that is not based on the ownership of capital, of intellectual property, or of distribution channels. Governments will be forced to adapt to collective participation far beyond general elections. Failure to invest in education for creativity and to adapt the education curriculum for a new merit-based economy will land millions of people in a fairly uncompetitive heap. Allegiances will be formed to communities, not to companies or to countries.

Successful economies and business models will thrive on unlocking the power and creativity of individuals, in forming communities of individuals with large overlaps between personal goals and business goals. Being competitive will be more about doing things that others cannot do than about doing things cheaply and more efficiently.

Being in the technology field for a relatively short (or long) 16 years, I cannot contain my enthusiasm for the things to come in the next 5 years, let alone in the next 16 years.

Wednesday, January 16, 2013

The Agile Enterprise - Communication, collaboration, and cooperation

I received a link to an article titled "Team Collaboration the 2.0 Way", extolling the virtues of Web 2.0 collaboration over regular communication and wanted to register a point I often make in association with the notion of an Agile enterprise:
Collaboration does not foster cooperation, collaboration is premised on the need for cooperation.


Saturday, December 29, 2012

The Agile Enterprise - On hierarchies and management


“Accept the fact that we have to treat almost anybody as a volunteer...”
Peter Drucker


The first article of this series covered the topic of self-organization of teams inside an organization, which raises the question of whether such arrangement should lead to the formation of hierarchies amongst people and teams.

As with any free-market, every need has somewhat of a measurable value for a consumer, and the aggregate demand may be sufficient to create a market for that need. That context helps reshape the initial question as:
"Does a self-organized team have the need for a boss?"
Gary Hamel proposes a mind-bending leap in "First, Let's Fire All Managers", which ends in a far less absolute question on how to balance the free-markets advocated in the first part of this series with the kind of coordination afforded by centralized decision making in the hands of a single manager. Before solving that apparent conundrum, I also add the wisdom of Peter Drucker, who once wrote:
"The most efficient way to produce anything is to bring together under one management as many as possible of the activities needed to turn out the product."
The conceptual subtlety here is that management must not entail hierarchy.

Hierarchies are not evil...

Whereas there is an unquestionable market demand for someone who can coordinate activities across market contributors, it does not immediately follow that a hierarchical arrangement should be formed between that coordinator as a manager and the people producing the work as employees, let alone an arrangement where that ability for coordination is morphed into the responsibility to evaluate and compensate the other members of the team.

However, this reasonable subtlety does not negate the possibility that some individuals do possess all required attributes to coordinate work within a team and also to effectively manage the people in that team from a human resource perspective. Some of the people with those attributes, and I intentionally do not call them managers in the traditional sense, will go even further and demonstrate the ability to inspire and strategically guide the team.

If at some point in the creation of a product or service, a team surfaces the need for those attributes, they will naturally seek one or more individuals that can play those roles, but it is somewhat unlikely that they would transfer absolute power over their work and evaluations to the hands of a single person.

...nor permanent

On the other hand, to force the opposite end of the argument, and keeping in mind the information market proposed in part 2 of this series, imagine that someone with a Steve Jobs-like talent and track record advertised the formation of a team to create a new product within the organization, it is conceivable that a number of people would be willing to relinquish some level of autonomy in order to be a part of that team.

In the worst case, also keeping in mind the frequent rotations proposed in part 3 of this series, people who eventually regret the arrangement can somewhat easily find a new home in a different team. Without the proper support and eventual success, hierarchies can disappear as quickly as they were formed, once the last employee leaves the manager.

Extending the exploration to large organizations, which I somewhat arbitrarily define as companies with 1000+ employees, where it is not unusual to find 5 or 6 layers of management, the principles that govern the need for the next layer of hierarchy remain unchanged. If the team does not voluntarily submit to the guidance and personnel oversight of a new manager, there is no support for that level in the hierarchy.

In a traditional organization, that model can still work and has worked for several decades, if not in a less efficient arrangement and with potentially unnecessary layers. As a rule, these layers are nearly impossible to break down and even in the rare episodes of reduction in management lines, these are often watershed moments in the history of a company.

Leaders first, managers later...or never

Self-organization does not preclude the notion of hierarchies and traditional management, but offers a natural mechanism through which people can form these hierarchies in a way that is dynamic and in alignment with personal interests and business goals.

There is still considerable room for research and experimentation on the organization models required to govern the interactions between large numbers of self-organized teams in a concerted way.

Primordial laws of supply and demand between multiple teams are unlikely to work well for sectors of the industry with longer product cycles (automotive and pharmaceutical come to mind) , so that a unifying force and long-term vision remain essential.

What is not essential is the collusion of those two elements with the formation of hierarchies. In fact, virtually all managers out there would rather lead than manage, largely held back by unimaginative HR policies that continuously deposit the responsibility for evaluations and compensation onto their shoulders, a topic for an upcoming posting.

Tuesday, December 04, 2012

The Agile Enterprise - Part 3 - Frequent rotations

"The only way that has ever been discovered to have a lot of people cooperate together voluntarily is through the free market. And that's why it's so essential to preserving individual freedom."
Milton Friedman

This series started with a different title ("The Commanding Heights of the Enterprise") and this final part made me rethink the title as  "The Agile Enterprise".

As a quick summary, part 1 of the series covered the notion of teams self-organized around goals set by customers. Part 2 covered the need for an information market that supported people in the formation of these self-organized teams.

This chapter covers a challenge surfaced in the previous installments of the series: alignment of rotation choices with project boundaries.

Whereas a person and the prospective team may agree that the rotation of that person into the team is mutually beneficial, it is often the case that the dates in the contract between that person and his current team cannot be reconciled with the starting date in the new team.

Every opportunity has its time...

In traditional organizations, transitions require careful planning and a fair amount of negotiation around availability and alignment of dates between the parties, to the point where these kind of reassignments end up becoming relatively rare.

Rare events have a way of picking people's interest and there is no shortage of stories about employees who made unconventional decisions, or were forced by external events, to radically change their job responsibilities. Assembly line workers becoming quality assurance champions, HR managers becoming sales force supervisors, and many others.

Whereas the collective message positively reinforces the need for people to be open to change, statistics can often lose to the power of an individual case study. The isolated stories cannot help one realize the average scope and frequency  of transformation that can be absorbed in a hierarchical organization before posing a logistical nightmare.

…but not all the time
 
The inspiring story of a construction supervisor becoming a supply chain analyst over the span of 2 years may be an excellent morale booster for someone feeling stuck in a hapless assignment, but does not mean an HR director will welcome all construction supervisors in the company to attempt the same leap in the following day, nor be able to cope with half of the organization applying for similar job transfers within 6 months.

It is worth noting the job rotation technique employed by many companies, where new employees are moved across different positions in order to understand the various aspects of the business.

Job rotation is a positive tool in its own right, but also has a well-known set of drawbacks, chiefly amongst them that it is meant as a training process perceived as a cost-center. That is also the reason why company-orchestrated job rotation tends to cover only the first few years, or even months, of one's career.

A wartime culture...

Tension hardens steel and pressure stiffens concrete, much in the same way tension and pressure make organizations more brittle. People familiar with a given task can execute it faster and with better quality over time, which is welcomed by a command and control structure reminiscent of desperate wartime needs.

In the two world wars, specially in WWII, efficient pipelines, repetitive action and sheer numbers were a key factor in winning the conflict. Helped by the threat of survival, these work force arrangements were also a key driver of highly structured organizations, underpinning a rebirth of manual labor that would make Frederick Mayor proud. Even as knowledge work subsequently came out if its forced intermission, the management practices that served the world for over many decades of conflict are largely still in effect.

In the past two decades, an ever changing business landscape and the subsequent need for adaptability are the new driving forces tearing through that post-war model. When company areas are compartmentalized, as postulated in part 1, the compartments are inherently misaligned with market needs, with collaboration and teaming becoming the difference between success and a product inadequate for its target market.

In that scenario, constant rotation of people across different teams achieves several key benefits for a organization aspiring to business agility:
  • Trust: People more familiar with each other know what to expect in a critical situation.
  • Awareness: People who understand the reality in different areas of the organization can better support the efforts in the organization and innovate in areas where there are efficiencies of scale or synergy of skills.
  • Skill seeding: Strengths in one area can be actively implemented in different areas. High-productivity techniques, ranging from technology to product management, can be shared, tested, approved or discarded more frequently.
...needs a war

Increased trust amongst people in different parts of the company and awareness of their contributions to the business foster a shared culture and prevents the formation of silos.

Back in 2006, I attended a session in Hursley where a panel of senior executives discussed the future of the software industry. In the discussion, one of the biggest impediments for progress in larger companies ended up being the lack of trust amongst internal divisions, on how difficult it was to marshal skills and resources towards initiatives that would obviously benefit the company if all parts could trust each other.

One of the panelists went as a far as stating that in some cases it was easier to partner with external companies, even competitors, because at least they could put contracts in place and make progress under the duress of potential lawsuits.

After the long exposition, I introduce another Commanding Height of the Enterprise:

Organizations must have internal policies that orchestrate orderly and frequent flows of employees across the company as an integral part of everyone's career plans.
Note the distinction between "orchestrate" versus "require" in the previous paragraph, which embodies the entire theme behind this series, where the alignment of personal responsibility, context, and personal interest are the key drivers of business results.

Unlike job rotation, the requirement for rotation in the modern enterprise is a necessity of personal progress within the company rather than a necessity of the company to expedite comprehensive training of selected employees.

Employees have in their best interest to rotate frequently as a means of growing their awareness of the business, which in turn improves their ability to enlist for areas where they can contribute the most; and also to establish their reputation, in order to facilitate their acceptance in prospective teams.

 Agility is a discipline

In order to solve the challenge presented in the first half of this article, I must introduce the notion of Agile practice.

For those not familiar with Agile practice, and in a nutshell that will utterly infuriate Agile advocates, the overall concept is based on intervals of time called “sprints” where work is delivered in “stories” prioritized by the product customers. Teams are organized in small groups (less than 10 people, ideally 4 or 5) , which in many cases follow a procedural variant known as “Scrum”, named after the the designation for the pre-play huddle seen at rugby matches.

The Scrum team gathers everyday in a stand up meeting where each person briefly describes what he has done since the last meeting, what he commits to do before the next meeting and whether he has any blockers preventing him from achieving that goal. The outcome of each sprint is expected to be ready for deployment if the customer so chooses.

Sprint duration may vary, but should be long enough to contain the smallest amount of meaningful work for a customer, and short enough that the team does not lose momentum or focus with fewer opportunities to get customer feedback sessions at the end of each sprint. In the software industry, as an example, duration typically ranges from 2 to 6 weeks.

Agile practice started in the software development world, which was once aptly described as a service industry that operated under the illusion of being a manufacturing industry. The notion of incrementally delivering the final “product” is a better fit for the artisan methods used for software development and customer requirements that swing in lock-step with changes in the customer business priorities.

Larger undertakings require far more resources than a an Agile cell can support, which requires a hierarchical arrangement of teams. There is sufficient material and experiences supporting this kind of arrangement. I particularly like the work of Scott Ambler summarized in “Agility@Scale”.

The Scrum Alliance also offers a balanced set of resources covering the application of Agile in different industries, ranging from direct creation of a finished product all the way to the C-level management team. Within those resources, there is a must read by Alexandre Magno, titled “An Executive Scrum Team” (http://www.scrumalliance.org/resources/1833).

Fluid allocation of resources

Agile execution enables efficient rotation of people across projects, by defining project boundaries in sprints rather than relatively indefinite intervals of time. In the classic model of execution, where people are assigned to organizations rather than projects, one of the major challenges to get people to self-organize around goals is to secure a release date where the loss of personnel by the ceding organization does not cripple its execution, but at the same time does not prohibitively overshoot the project start date in the receiving organization. In the traditional enterprise, that perfect window may happen a handful of times in someone´s entire career.

In the modern enterprise postulated in the “Commanding Heights” series, healthy initiatives require a handful of transfer opportunities every year, so that all parties involved in a transfer, from initiative stakeholders to the employees enlisting to participate in these initiatives, have more flexibility in trying out new formations. There are still leadership positions for which rotation cannot be executed as frequently, but Agile practice also introduces the notions of Epics (longer series of like-themed stories) , so that certain people will still enlist into projects for longer stints than others (e.g. a project manager, a release lead, or an assembly line engineer) .
 
In closing

The future of the modern enterprise hinges on the following main points:
  • Self-organization of a work force familiar with the role of their products and services in the world, and with an acute awareness of benefits and consequences of their decisions for their customers and for their own careers.

  • Free(er) flow of information as a way of connecting people and teams: Absent legal limitations – security regulations and privacy laws come to mind - free agents in a micro-market workforce must be able to freely share information about their work with other free agents, so that teams are aware of talent they can utilize and people are aware of initiatives where they can fit.

  • Agility: All knowledge-based work in the enterprise must be executed within the principles of Agile practice, supplying frequent transition points for the free agents to align around market initiatives as they unfold.
The next articles of the series will be shorter and explore specific aspects of these main points. The first topics will cover trust management and transition steps from a traditional to a modern enterprise.

LinkedIn