Monday, June 27, 2016

Hard Systems vs. Soft Systems




If you live in a densely populated metropolis and have to deal with the traffic congestion in your everyday work and life, you would understand the inconvenience and the stress it brings.

Of course technology can help. For any given day and time, to get from A to B, you can always rely on GPS navigation device or App coupled with real-time live traffic data feed to find a fastest route. Although this does not solve the overall congestion problem, it helps individuals alleviate some of the trouble and stress. This is the concept of “Hard System” in which the problem is well defined (To determine a fastest route to get from A to B), sufficient data about the problem can be collected (Live traffic data are gathered), and scientific analysis or tools can be developed (Navigation software uses algorithm to find an optimal route).


But on the other hand, the problem of traffic congestion is not so easy to analyze and solve. The traffic patterns are very dynamic and unpredictable and are attributable to many interwoven factors. It involves many interconnecting highways, roads, and streets with traffics from many different sources such as schools, shopping trips, work, tourists. Weather plays a big part in influencing the traffic. On a foggy, rainy or snowy day, the traffic definitely gets worse. The day and time also matter a lot. Rush hours and weekdays see much heavier traffic. Furthermore, the overall economy, the immigration policy can also impact the traffic in a larger perspective and scale. There is no simple way to describe, model, analyze and solve the overall problem. That is why traffic congestion problems are forever unsolved and even get worse overtime in major cities. This is the concept of “Soft System” where the problem is complex and even ill-defined, facts are complicated and may not be evident or even agreed upon by all stakeholders, data are hard to collect let alone to analyze, and no optimal solutions exist or can be found.

In the late 1960's systems researchers in the University of Lancaster, UK led by Peter Checkland developed a new approach called Soft Systems Methodology (SSM). One unique characteristic of this approach is its emphasis on the understanding of the problem before even attempting to solve it.

Thinking is only the means, not the end. The end goal is to solve problem. But to solve problems, we have to understand them first. Thinking has to begin with seeing first.

Saturday, June 11, 2016

Scrum Team and Self-organization (Part II)


Self-organization as a concept and a phenomenon has its root in systems theory.  It is a key characteristic of a complex adaptive system.

In a complex adaptive system,  a large number of diverse component parts interact and form a cohesive, robust, and resilient whole that exhibits emergent properties and achieves higher order in the absence of intervention or control from external forces.

Natural scientists first discovered these phenomena in natural systems such as a colony of ants, a forest, an ocean.

Engineers attempting to create better, larger, and more complicated systems such as a satellite, a power plant, or an enterprise information system apply the lessons and principles learned from the natural systems to improve the structure, design, and functions of the engineered systems.

Social scientists also find similar phenomena in social systems such as a community, a stock market, an economy and follow the suit by applying scientific knowledge and engineering techniques to effect social changes and to improve human conditions.

Self-organization enables a complex adaptive system to evolve from an initial chaotic, dysfunctional state into a cohesive, functional state. Self-organization also makes a complex adaptive system more robust and resilient to perturbations and uncertainties from its changing environments.

Now let's get back to our original question: Can a scrum team achieve self-organization? or phrase it in a different way: Is a scrum team a complex adaptive system?

A team consists of members who interact with each other to achieve a common goal. In traditional project management, a team is led by a team lead or a project manager and has well defined roles and responsibilities and top-down command and control hierarchy. Clearly, this type of team does not conform to the definition of a complex adaptive system which is a bottom-up grass-root organism without controlling forces imposed from the above.

A scrum team by definition consists of a scrum master which is a servant leader, a product owner which is the liaison of the end users and the champion for the end products, and a development team whose responsibility is to design, build and deliver the products to the end users in an incremental and iterative fashion.

The size of the development team within a scrum team can vary and even the guideline varies as well. Some say 5 plus or minus 2, others say 7 plus or minus 2. The rationale here is that the development team should be cross-functional in that all necessary disciplines are represented (for example, designers, developers, testers) but at the same time should have minimal number of people in order to achieve efficiency and effectiveness in communication and collaboration.

This reflects the emphasis of individuals and interactions from Agile Manifesto:
"Individuals and interactions over processes and tools"
This also reflects the emphasis of face to face conversation from agile principle #6:
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
This results in a overall scrum team size of less than a dozen people. In practice, the average scrum team size is even smaller. a complex adaptive system typically have large number of component parts. In another words, critical mass is needed to generate the dynamic behavior and to allow for the resilience and robustness to develop over time. Small group may be easier to communicate and collaborate, it does not generate the critical mass.

Another aspect of scrum is the emphasis of the role of the scrum master. A scrum master is the opposite of a traditional project manager or team lead in that it does not provide management function of command and control. In contrast, it is a servant leader and its primary goal is to protect the team from external influence, to facilitate communication and collaboration,  to remove impediments, and to enable the team to focus on the tasks and deliver the products. In one of the agile projects I have worked on, we call the scrum master "Super Mom" to reflect the similarity of the role and the same initials (SM). This makes the scrum team somewhat like a closed system instead of an open system which a complex adaptive system is meant to be.

From the above, we can clearly see that agile methodology and scrum process put some structure and constrain around the makeup and function of a scrum team in terms of size, roles and responsibilities, and interaction with external entities such as end users, subject matter experts, and stakeholders.

The structure and constraints find its roots in the traditional project management and make the scrum team less a complex adaptive system.

Additionally, several characteristics of a complex adaptive system are missing in a scrum team.

First, a complex adaptive system typically starts in a organic way in that component parts are not "hand picked" by an external force but rather are naturally formed together organically such as a flock of birds or a schools of fishes.

Secondly, component parts within a complex adaptive system are typically equal and diverse without supervisor-subordinate relationship and clear distinction of roles and responsibilities. They are sometimes called agents. The emergent properties of a complex adaptive system come from the free and seemingly random interactions among the parts and also with the environments.

Lastly, it takes time for a complex adaptive system to form organically and to transition from chaotic state to a harmonic state. The time boxing nature of scrum and the limited time duration of projects do not provide the time needed for a scrum team to adapt and grow naturally.

The conclusion is that a scrum team is not a complex adaptive system and cannot achieve self-organization naturally or organically.

This is why scrum teams struggle to self-organize.

Scrum Team and Self-organization (Part I)

Among many agile frameworks (Extreme Programming, Kan-ban, Lean, etc.), Scrum has become prevailing and dominant over the past decade. Many organizations from businesses to government agencies adopt scrum as they move away from traditional waterfall methodology to agile methodology. Some follow agile and scrum strictly and religiously, others mix it with waterfall in a hybrid attempting to reap the best of both worlds.

Ken Schwaber, one of the two co-developers of Scrum process, both among the 17 initial signatories of the Agile Manifesto, wrote in his book "Agile Project Management with Scrum":
"For Scrum to work, the team has to deeply and viscerally understand collective commitment and self-organization. Scrum’s theory, practices, and rules are easy to grasp intellectually. But until a group of individuals has made a collective commitment to deliver something tangible in a fixed amount of time, those individuals probably don’t get Scrum. When the team members stop acting as many and adopt and commit to a common purpose, the team becomes capable of self-organization and can quickly cut through complexity and produce actionable plans."
This echos one of the 12 principles behind the agile manifesto:
"The best architectures, requirements, and designs emerge from self-organizing teams."
The key phrase here is "self-organization" as a noun or "self-organizing" as an adjective.

Even though many agile and Scrum practitioners are preaching "self-organization" and trying hard to improve the effectiveness of the scrum teams through self-organization, the results are mixed.

From many years of practicing agile and Scrum in both small scale and large scale information technology projects ranging from private to public sector, I witnessed teams struggle to form cohesion and to deliver the outcomes promised by Scrum. Many of the projects are short-term ranging from a few months to a year or so, by the time the team has gone through the forming, storming, and norming phase and you start seeing the light at the end of the tunnel, the project deadline is approaching which leaves little time for the performing phase. Much of the fruits from the initial team learning and development effort goes underutilized or even untapped.

This leads me to think about "self-organization": 
  • What exactly is "self-organization"? 
  • Can a scrum team achieve self-organization? 
  • If yes, how can the team achieve it? 
  • If not, what are the impediments? 
  • Can the team achieve some level of self-organization under some circumstances?
More to come. Stay tuned.

(picture from https://www.mendix.com/blog/the-road-to-adopting-scrum-team-composition/)