The Agile Manifesto states: we have come to value individuals and interactions over processes and tools. Tools and techniques are not enough for running your projects, you need 'people tools' as well. We all know that for instance developers and customers fighting abouth who did what wrong doesn't make our projects finish early, yet it is hard to stop doing it. Especially when the pressure is on. This workshop provides tools and processes for individuals and interactions, to help you take a step towards peaceful, effective projects.
Anyone who wants to become more effective through:
After this workshop, you can:
The Balancing Act has been run before at several international conferences, like Agile Open, XP Day Benelux 2005, XP Day Germany 2005., XP Days France 2006, SPA2006.
While observations are the ultimate foundation of high integrity communication, they are not enough. Our human world and our organizations -almost any given part of it- are (boundlessly) complex and diverse. In and of themselves descriptions of these systems can overwhelm :-), as many early OOT projects have shown us by the mere volumes of use cases produced. (If management would not have stopped them I have no doubt they would still be at it).
The very concept of root causes discourages us from seeing the feedback loops of systems theory:
While theorizing, we make assumptions about how things work. We make these assumptions by abstracting features according to what we think is (contemporary) essential. --Fred Brooks's Essence & Accident
Deducing consequences of the assumptions and comparing these with observed data is one way of looking for patterns in the vast ocean of data. Root cause analysis and contemplating underlying causes can please our desire to understand and may suggest new kinds of patterns to hunt for in the data.
We can argue that the only way to effect organizational change while maintaining high integrity is by studying body language, because only that language is close enough to human hardware that one can be reasonably sure about what is happening and because the 3D world is the source for grounding our theories.
Higher level human languages using visual images and words are complex and poorly defined. Their involved and ambiguous semantics make it impossible to be sure what is happening or anticipate what might happen. So it seems impossible for one to know, with our usual documentation, how it can be translated to a design on the operational level; in some cases, working on the frontline of new technologies, the only way to find out is by "trial and error", by experience and by frustration.
Each human involved is a complex system and bound to make meaning and assign value differently. Even if it was possible to have some idea about The True Meaning of an gestalt, it seems impossible to simply feel confident that an individual correctly implements the intended meaning of an organisation.
Let's get with reality; sole use of body language for organisational purposes is infeasible and higher-level languages like visual languages and verbal languages are essential for creating and communicating different perspectives.
From any such set of seemingly conflicting communication pressures, the lingo of security and reliability can provide neat goals to aspire to for communicating the different perspectives in a gestalt:
|
Target independence |
Language used -in any dimension- for creating perspectives have no personal meanings attached for any of the stakeholders. |
|
Mathematically defined semantics |
Language used for different perspectives have mathematically defined semantics for deducing what could be the human or cultural effect. Otherwise it is impossible to deduce even what "could be" the effect of a system change. |
|
Proving translation correctness |
Personal languages of stakeholders have mathematically defined semantics. Otherwise it is impossible to "prove" (verify) that interpretations by stakeholders are "correct". |
|
Correctness of translator |
Change artists focus on congruence and perspectives are derived from the semantics of the organisational gestalt, stakeholder and enterprise (business) languages. |
|
Validation |
Change artist behavior is seen to be congruent, creating effective feedback loops with (potential) stakeholders - change comes from within and takes building trust between all stakeholders involved |
|
Visibility |
Change artistry artifacts are written clearly and clearly related to enterprise (business), stakeholder and perspective semantics. The design is visible to all involved and makes emotional attachment to the design possible. Without this, stakeholders will not see the design of the gestalt as significant, and will not fully participate (not be fully present) and there will not be a community of interests. --Jerry Weinberg It is helpful if the mathematically defined syntax is synonymous with the visible artifacts presented to the stakeholders. If it isn't, then there is a translation risk as well as a level of effort risk. --Stiles Roberts |
|
Availability |
Semantics for both change artistry and stakeholder languages is made available for peer review and feedback - safety and trust levels are high enough. |
The evolution of sense is, in a sense, the evolution of nonsense. -- Vladimir Nabokov
The development characteristics of traditional companies create a tight coupling of products and or services to company resources deployed in a series of multiple overlays; multiple managers and projects for each product or service and resource overlay; and organizational structures made up of groups performing similar functions. Specific management departments have their own proprietary approach to company management and this creates multiple administrative domains with poor interoperability between them.
Sum up all of these independent resource consuming partial solutions and we have a patchwork landscape and environment that is inefficient to travel, complex and expensive to maintain. Company management involves many processes, procedures, tools for internal reorganizations, block detection, performance monitoring, security, accounting, billing, all within a boss-employee relationships between management and regular employees. Techies in such companies have only basic development functionality with little ability to control activities or make determinations beyond the scope of technical system development. Operations performs the bulk of the work, processing raw data coming from employees, making determinations and instructing each individual employee which actions to take. This skewed relationship is inefficient in a number of ways: there is little sharing of thinking resources because the types of employees were designed independently.
Also, each management function in a traditional company, like financial, HR, development, has its own way of working and human staff and their own performance requirements. Company management functions must know each employee and his or her preferences on an individual basis which imposes additional time and complexity when introducing more agile ways of working.
On top of that, company management departments were designed to support corporations and organizations or development teams at a particular point in time to work with contemporary technology. Each organization did this independently (in good spirit of the not-invented-here-syndrom) and nobody seemed to concern themselves with system level interweaving. Data related to a particular department or function and to a particular management line were integrated throughout the network (or not!), causing a major synchronization problem in turn making evolving products or services, company technologies and company management processes virtually impossible to do in a cost-effective, timely and competitive manner.
"The future is ever a misted landscape, no man foreknows it, but at cyclical turns there is a change felt in the rhythm of events." -- Robinson Jeffers (1887-1962)
"The future is made of the same stuff as the present." -- Simone Weil (1909-1943)
In the future, evolutionary agile value nets can provide manageable flexibility points between value net, receivable deliverables, technologies and organizational & business structures. Each aspect is likely to evolve at its own independent rate:
Technology:
Receivable deliverables:
Organizational & business:
"A complex system that works is invariably found to have evolved from a simple system that worked." -- John Gall
Nynke wrote this nonsense beginning of 2004. Now it is time for everything else ...