Work Organization (Methodology) Definition ...€¦ · August 27, 2013 Work Organization Definition...

<<redacted>> Work Organization (Methodology) Definition -- Kickoff

August 27, 2013

August 27, 2013 Work Organization Definition 2

Agenda

A. Purpose and Roles● Definition of the governing group

Greg Lowes (facilitator)

B. Methodological styles● Structured methods → Agile Delivery● Hypothesis Driven Thinking → Action Research

David Ing (methods exponent)

C. Diagnosing● Identifying or defining (a) problem(s)


D. Action Planning● Alternative courses of action for solving (a)

problem(s)


E. Next Steps● Action Taking, Evaluating, Specifying Learning


Appendix● Agile Portfolio/Product, Estimating, Planning


Roles: Responsible for performance; Accountable for sign-off; Support to help on task; Consulted with two-way communication; Informed on one-way communication

Participants ...

R A S C I

<<redacted>>, Senior Vice-President, Strategy and Transformation

<<redacted>>, Chief Transformation Officer

<<redacted>>, Director, <<redacted>> Process Transformation

<<redacted>>, Business Process Analyst

<<redacted>>, Director, Transformation Programs

<<redacted>>, Senior Systems Analyst

<<redacted>>, Senior Business Analyst

<<redacted>>, Manager, Process Management


R A S C I

<<redacted>>,

<<redacted>>, CIO, Portfolio Mgmt & Solution Delivery

<<redacted>>, Chief Systems Architect

<<redacted>>, Senior Programmer Analyst



R A S C I

David Ing, Managing Director and Chief Scientist

A C

Greg Lowes, Director of Service Excellence R

<<redacted>>, Delivery Manager, Project & Quality Management & Testing

R

<<redacted>>, Mentoring Architect (BPM)

R

<<redacted>>, Senior Architect (ESB and BPM)

R


Goals for this meeting

● Revise / concur with project charter

● Appreciate the problematique (system of problems)

● Begin the cyclical learning approach (action research)


Project goals, objectives and business outcomes (current version, subject to revision)

● Goal:

● A standardized approach for <<redacted>> including methods and tools enablement for inception through deployment

● Attainment criteria:

● Concurrence on the documented approach by:

● (i) Transformation Team,

● (ii) IS/IT Team

● Business outcome:

● Transparency to progress <<redacted>> projects with deliverables and handoffs

Project charter, <<redacted>> Work Organization Definition ...


Scope (current version, subject to revision)

Boundaries ...

In scope Out of scope

Method descriptions (e.g. agile and iterative approaches)● For discovery, modeling, documentation,

development, deliver, QA, integration and implementation

● Formal method assessments (e.g. if Disciplined Agile Delivery is selected, how well is <<redacted>> doing?)

Tool positioning (for product and project management)● Process discovery (<<redacted>>)● Agile portfolio and product management

(<<redacted>>)● <<redacted>> development and deployment

platform (<<redacted>>)

● Formal Migration from SQL Server on Windows to DB2 on Unix is on a different scope of work (<<redacted>>)

● Potential future integrations (e.g. Source Code Management in <<redacted>>)

Teams involved● <<redacted>> Transformation and

Development● <<redacted>> IS/IT Development team● External CPM Project Leads and QA

(<<redacted>> onsite professional)● External BPM Developers (<<redacted>>

professionals)


Timeline and milestones (current version, subject to revision)

Schedule ...

8/30

9/6

9/13

9/20

9/27

10/11

10/ 18

10/25

11/1

Kickoff (Aug. 27) 1. Definition of the governing group2. Diagnosing (cycle 1)

3. Action Planning (cycle 1)

Briefing with IS/IT team (Sept. 10)

4. Action Taking (cycle 1)

5. Evaluating (cycle 1)

6. Specifying learning (cycle 1)

7. Diagnosing (cycle 2)

8. Action Planning (cycle 2)

9. Action Taking (cycle 2)

10. Evaluating (cycle 2)

11. Specifying learning (cycle 2)

Quality Assurance


Agenda








problem(s)






The proposed way forward changes the style for information systems development and organizational process at <<redacted>>

Methodological style ...

Traditional style Proposed style

Information Systems Development

Structured Methods →(Tailoring of) (Disciplined) Agile Delivery

Organizational Process

Hypothesis Driven Thinking → Action Research


Structured methods assume progressing with succeeding or preceding steps, now described as waterfall

The evolution of structured methods (page 1 of 6) ...

Figure 3. Hopefully, the iterative interaction between the various phases is confined to successive steps.

Source: Winston W. Royce, “Managing the Development of Large Software Projects”, IEEE Wescon 1970 (Figure 3)

Figure 3 portrays the iterative relationship between successive devlopment phases for this scheme. The ordering of the steps is based on the following concept: that as each step progresses and the design is furthered detailed, there is an iteration with the preceding and succceeding steps but rarely with the more remote steps in the sequence. The virtual of all of this is that as the design proceeds the change process is scoped down to manageable limits. At any point in the design process after the requirement analysis is completed there eixsts a firm and closeup, moving baseline to which to return in the event of unforeseen design difficulties. What we have is an effective fallback position that tends to maximize the extent of early work that is salvageable and preserved.


If testing fails, a major design is required, which could lead to necessary modifications in requirements


Figure 4. Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps


I believe in this conceopt, but the implementation described above is risky and invites failure. The problem is illustrated in figure 4. The testing phase at the end of the development cycle is first even for which timing, storage, input/outpot transfers, etc., are experience as distinguished from analyzed. These phenomena are not precisely analyzable. .... if the pheonmena fail to satisfy the various external constrains, then invariably a major design is required. ... The require design changes are likely to be so disruptive that the software requirements upon which the design is based on which provides the rationale for everthing is violated. Either the requirement must be modified, or a substantial change in the design is required. In effect, the development process has returned to the origin and one can expect up a 100-percent overrun in schedule and costs.


The recommended solution is a preliminary design before analysis and program design. [See details, next page]




To lower risk, more documentation and a complete program design is recommended before analysis and coding


Figure 10 summarizes the five steps I feel necessary to transform a risky development project into one that will provide the desired outcome. I would emphasize that each item costs some additional sum of money. If the relatively simpler process without the five complexities described here would work successfully, then of course the additional money is not well spent. In my experience, however, the simpler method has never worked on large development efforts and the costs to recover far exceeded those required to finance the five-step process listed.

1. Complete program design before analysis and coding begins

2. Documentation must be current and complete.

3. Do the job twice, if possible

4. Testing must be planned, controlled, and monitored

5. Involve the customer

Preliminary program design

Program design

Program design

Preliminary design

CodingCoding



Structured System Analysis and Design Method is a derived descendant promoted as an open standard


Source: SSADM Foundation, Office of Government Commerce (UK, 2000)

SSADM was initially introduced, in 1981, as a standard for development projects undertaken within government departments. It was soon adopted by private sector organisations and is currently the development standard in a significant number of public and private organisations both in the UK and worldwide.


We define agility as the ability to respond to risks rapidly; changing requirements or stakeholders needs, or other changes impacting the application we are building[1]

The evolution to Disciplined Agile Delivery [page 1 of 11]

Process Map

WaterfallFew risks, sequential

Late integration and testing

Low CeremonyLight documentation

Light process

High CeremonyWell documented

TraceabilityChange Control Boards

IterativeRisk-driven

Continuous integration and testing

Agility translates to being in the lower-left quadrant in our process map.

Iterative development provides us with the rapid and timely feedback we need to understand when and

what to change, and the low ceremony provides us with the

ability to execute changes rapidly.

[1] Per Kroll and Bruce MacIsaac. 2006. Agility and discipline made easy: practices from OpenUP and RUP. Addison-Wesley. p.6

-


Work is organized at personal, team and stakeholder levels of micro-increments in iteration lifecycles in project lifecycles


Source: Introduction to OpenUP (Open Unified Process), http://www.eclipse.org/epf/general/getting_started.php

http://www.eclipse.org/epf/general/getting_started.php


The values of the Agile Manifesto developed in 2001 by 18 signatories were reworked by Scott Ambler in 2010


Values of the Agile Manifesto (2001) Reworked Values Agile Manifesto (2010)

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

1. Individuals and interactions over processes and tools

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

2. Working solutions over comprehensive documentation

3. Customer collaboration over contract negotiation

3. Stakeholder collaboration over contract negotiation

4. Responding to change over following a plan

4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

http://agilemanifesto.org, signed by:

Kent Beck James Grenning Robert C. Martin

Mike Beedle Jim Highsmith Steve Mellor

Aire von Bennekum Andrew Hunt Ken Schwaber

Alistair Cockburn Ron Jeffires Jeff Sutherland

Ward Cunningham John Kern Dave Thomas

Martin Fowler Brian Marick

Source: Scott Ambler, “Reworking the Agile Manifesto”, Agility@Scale blog, Nov. 1, 2010 at https://www.ibm.com/developerworks/community/blogs/ambler/entry/reworking_the_agile_manifesto14?lang=en

http://agilemanifesto.org/

mailto:Agility@Scale


From twelve original principles, Ambler modified five, and added three


Principles of the Agile Manifesto (2001) Reworked Principles of the Agile Manifesto (2010)

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable solutions.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

2. Welcome changing requirements, even late in the solution delivery lifecycle. Agile processes harness change for the stakeholder’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

3. Deliver working solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

4. Stakeholders and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

6. The most efficient and effective method of conveying information to and within a delivery team is face-to-face conversation.

7. Working software is the primary measure of progress. 7. Quantified business value is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential. 10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

13. Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.

14. Visualize workflow to help achieve a smooth flow of delivery while keeping work in progress to a minimum.

15. The organizational ecosystem must evolve to reflect and enhance the efforts of agile teams, yet be sufficiently flexible to still support non-agile or hybrid teams.


The Agility Maturity Model sees a progression from core, to disciplined to agility at scale


Focus is on construction

Goal is to develop a high-quality system in an evolutionary, collaborative, and self-organizing manner

Value-driven lifecycle with regular production of working software

Extends agile development to address full system lifecycle

Risk and value-driven lifecycle

Self organization within an appropriate governance framework

Addresses one or more scaling factors:

● Team size● Geographical

distribution● Organizational

distribution ● Regulatory

compliance● Environmental

complexity● Enterprise

discipline

Reference: See http://www.ibm.com/developerworks/blogs/page/ambler?tag=APMM

1 Core Agile Development

DisciplinedAgile Delivery2

Agility at Scale

3


The basic agile version of DAD incorporates experiences with practices from inception through concept to transition


Time and again, whenever either one of us worked with a team that had adopted Scrum we found that they had tailored the Scrum lifecycle into something similar to Figure 1.3, which shows the lifecycle of a DAD project.1 This lifecycle has several critical features:● It’s a delivery lifecycle. The DAD lifecycle extends the Scrum

construction lifecycle to explicitly show the full delivery lifecycle from the beginning of a project to the release of the solution into production (or the marketplace).

● There are explicit phases. The DAD lifecycle is organized into three distinct, named phases, reflecting the agile coordinate-collaborate-conclude (3C) rhythm.

Figure 1.3 The Disciplined Agile Delivery (DAD) lifecycle

● The delivery lifecycle is shown in context. The DAD lifecycle recognizes that activities occur to identify and select projects long before their official start. It also recognizes that the solution produced by a DAD project team must be operated and supported once it is delivered into production ...

● There are explicit milestones. The milestones are an important governance and risk reduction strategy inherent in DAD.


The inception phase is tailored for planning activities to gain stakeholder consensus to proceed with the project


Figure 1.6 Inception phase overview

Traditional methods invest a large amount of effort and time planning their projects up front. Agile approaches suggest that too much detail up front is not worthwhile since little is known about what is truly required as well as achievable within the time and budget constraints. Mainstream agile methods suggest that very little effort be invested in upfront planning. [....]

In DAD, we recognize the need to point the ship in the right direction before going full-speed ahead—typically between a few days and a few weeks—to initiate the project. Figure 1.6 overviews the potential activities that occur during Inception, described in greater detail in Chapters 6 through 12. This phase ends when the team has developed a vision for the release that the stakeholders agree to and has obtained support for the rest of the project (or at least the next stage of it).


A construction iteration sets a timebox with user stories and tasks estimated and prioritized in a backlog of work items


Figure 1.7 Construction iteration overview

The Construction phase in DAD is the period of time during which the required functionality is built. The timeline is split up into a number of time-boxed iterations. These iterations, the poten tial activities of which are overviewed in Figure 1.7, should be the same duration for a particular project and typically do not overlap. Durations of an iteration for a certain project typically vary from one week to four weeks, with two and four weeks being the most common options. At the end of each iteration a demonstrable increment of a potentially consumable solution has been produced and regression tested. At this time we consider the strategy of how to move forward in the project. We could consider executing an additional iteration of construction, and whether to deploy the solution to the customer at this time.


The transition phase recognizes putting a release in production may involve additional testing and documentation


Figure 1.8 Transition phase overview

The Transition phase focuses on delivering the system into production .... Internal systems are generally simpler to deploy than external systems. High visibility systems may require extensive beta testing by small groups before release to the larger population. The release of a brand new system may entail hardware purchase and setup while updating an existing system may entail data conversions and extensive coordination with the user community. [....]

Some agilists will look at the potential activities listed in Figure 1.8 and ask why you couldn’t do these activities during construction iterations. The quick answer is yes, you should strive to do as much testing as possible throughout the lifecycle and you should strive to write and maintain required documentation throughout the lifecycle, and so on. You may even do some stakeholder training in later construction iterations and are more likely to do so once your solu tion has been released into production. The more of these things that you do during the Construction phase, the shorter the Transition phase will be, but the reality is that many organizations require end-of-lifecycle testing (even if it’s only one last run of your regression test suite), and there is often a need to tidy up supporting documentation.


DAD builds on a framework open-sourced as the Eclipse Process Framework, pledged by IBM


role

work product

activity

guidance tool mentor

task

responsible for

in outchecklisttemplate

deliverableartifact outcome

estimation consideration practice

roadmap term definition

white paper

reusable asset

is

has

work breakdown

is

performs

task description

process

phase

iterationmilestone

capability pattern

delivery process

role description

work product description

hashas

has

is

is

is

is

is

Work content

Work coordination

Reference: EPF Composer Architecture, http://www.eclipse.org/epf/composer_architecture/

http://www.eclipse.org/epf/composer_architecture/


Roles are central in the process frameworkThe evolution to Disciplined Agile Delivery [page 11 of 11]

Open Unified Process [1]

Core Agile Development[2] Business (Process)[3]

● Stakeholder● Analyst● Architect● Developer● Tester● Project manager● Any Role (for general

tasks)

● Stakeholders● Team lead/coach● Developers● Product owner● Independent tester● Technical expert● Domain experts

● BPM analyst● BPM developer● BPM integration developer● BPM project manager● BPM solution architect● Infrastructure specialist● Interface developer● Monitor specialist● Rule analyst

Agility@Scale[3] adds ..

● Architecture owner● Integrator

[1] Richard Balduino. 2007. Introduction to OpenUP (Open Unified Process). Eclipse Foundation. http://www.eclipse.org/epf/general/OpenUP.pdf .[2] IBM Software Group 2011. Introduction to Agile Delivery Workshop[3] Claus T. Jensen, Owen Cline, and Martin Owen. 2011. Combining Business Process Management and Enterprise Architecture for Better Business

Outcomes. IBM Redbooks. http://www.redbooks.ibm.com/abstracts/sg247947.html .

-

mailto:Agility@Scale

http://www.eclipse.org/epf/general/OpenUP.pdf

http://www.redbooks.ibm.com/abstracts/sg247947.html


The proposed way forward changes the style for information systems development and organizational process at <<redacted>>

Methodological style ...

Traditional style Proposed style

Information Systems Development

Structured Methods →(Tailoring of) (Disciplined) Agile Delivery

Organizational Process

Hypothesis Driven Thinking → Action Research


Strategic change typically involves defining a question, generating hypotheses, and collecting data to support findings

Hypothesis Driven Thinking [slide 1 of 3]

Source: Jeanne M. Liedtka, “Using Hypothesis-Driven Thinking in Strategy Consulting”, UVA-BP-0486, University of Virginia Darden School Foundation

Defining the Strategic Question

Generating the Hypothesis

Testing the Hypothesis

Presenting the Findings

Identifying Data Needs and Sources

Conducting Interviews

Selecting Analyses


Findings to bridge a gap rest on confirming data on the descriptive (current state) and prescriptive design (future state) hypotheses


Source: Jeanne M. Liedtka, “Using Hypothesis-Driven Thinking in Strategy Consulting”, UVA-BP-0486, University of Virginia Darden School Foundation

Defining the Strategic Question

Generating the Hypothesis

Testing the Hypothesis

Presenting the Findings

Identifying Data Needs and Sources

Conducting Interviews

Selecting Analyses

1. Define the problem / question.What is the big question or questions that need to be answered? Usually the strategic problem has to do with the existence of a gap between what the client wants ... and what the client has. Thus, our focus is utimately on making a recommendation (the design hypothesis) about the actions that the client should take to close that gap).2. If needed, gather preliminary data that allows construction of initial hypotheses about the causes of and answers

to the question.

3. Develop a set of competing descriptive hypotheses about the causes and their associated prescriptive hypotheses.

Example: The bank's profitability problems could be caused byDescriptive Hypothesis → Prescriptive (Design) HypothesisUnattractive industry structure → exit industryLack of appropriate strategic capabilities → develop appropriate onesSelection of less profitable target markets → select new ones

5. Identify the analysis that needs to be performed and design the study needed to collect the data.

4. Select the most promising descriptive hypothesis for testing.

6. Collect the data.

7. Using the data, test the hypothesis. Is it supported or rejected?8. Resolve any anomalies or disconfirming data by gathering additional data and reformulating

hypotheses, or by moving to an alternative hypothesis to begin new testing, as necessary.

9. Structure an argument that lays out the supporting logic for the design hypothesis.


BPR similarly is based on on process as the problem, with hypotheses on the descriptive (as-is) and prescriptive (to-be)


Source: Subramanian Muthu , Larry Whitman , S. Hossein Cheraghi, “Business Process Reengineering: A Consolidated Methodology”, 4 th Annual International Conference on Industrial Engineering Theory, Applications, and Practice, 1999

Figure 1: BPR: The surest way to the top!

Generally they make there choices based on three criteria: dysfunction: which processes are functioning the worst?;

importance: which are the most critical and influential in terms of customer satisfaction; feasibility: which are the processes that are most likely to be successfully reengineered.

Having identified and mapped the processes, deciding which ones need to be reengineered

and in what order is the million-dollar question. No company can take up the unenviable task of reengineering all the processes simultaneously.


Action research is a an action strategy where knowledge is to be produced in service of, and in the midst of, action

Action Research [slide 1 of 4]

Source: Joe Raelin, “Preface to Special Issue on The Action Dimension in Management: Diverse Approaches to Research, Teaching and Development”, Management Learning, v. 30, n2, pp. 115-125 June 1999, http://dx.doi.org/10.1177/1350507699302001

Criteria Action research

Philosophical basis Gestalt psychology, pragmatism, democracy

Purpose Social change through involvement and improvement

Time frame of change Both short- and long-term

Depth of change Intrapersonal through cultural, ranging from shallow to deep

Epistemology Knowing through doing; making and applying discoveries

Nature of discourse Collaborative discourse of action and problem-solving; use of data-based, actionable knowledge

Ideology Focusing on participation, involvement, and empowerment of organizational members affected by the problem; reeducative

Methodology Iterative cycles of problem defining, data collection, taking action or implementing a solution, followed by further testing

Facilitator role Primary functions as research/process guide

Level of inference Focusing on data encourages low levels of inference, but reeducation process encourages higher level testing

Personal risk Moderate risk, but ultimately depends upon organizational culture, consequences, visibility, and degree of sanction

Organizational risk Depends upon strategic importance of the problem chosen, may entail less risk than doing nothing

Assessment Validity based on appropriateness of method and on the extent to which the original problem is solved

Learning level Varies based on nature of project, skills, and risk-taking of participants

The six action strategies include: action research, participatory research, action learning, action science, developmental action inquiry, and cooperative inquiry. To explain each briefly:

action research, itself, constitutes a process wherein researchers participate in studies both as subjects and objects with the explicit intention of bringing about change through the research process.

Participatory research, sometimes also referred to as the ‘Southern School’, is concerned with knowledge andpower. It seeks collaboration between those from privileged groups who often control the production of knowledge and those among the economically disadvantaged who by questioning the dominant values within society can press for social change. Action learning is based on the straightforward pedagogical notion that people learn most effectively when working on real-time problems occurring in their own work setting. Action science is an intervention method based on the idea that people can improve their interpersonal and organizational effectiveness by exploring the hidden beliefs that drive their actions. Developmental action inquiry is the systematic attempt to enrich a person’s, group’s, organization’s, or society’sawareness of the interplay among transpersonal awareness, subjective interpretations and strategies, intersubjective practices and politics, and objective data and effects. Finally, in cooperative inquiry all those involved in the research are both coresearchers, generating ideas and designing and managing the project; and also co-subjects, participating in the activity that is being researched.


Kurt Lewin developed the action research model in the mid-1940s, to respond to the chasm between social action and social theory


Source: Linda Dickens and Karen Watkins, “Action Research: Rethinking Lewin”, Management Learning, v. 30, n2, pp. 127-140 June 1999, http://dx.doi.org/10.1177/1350507699302002; Max Elden and Rupert F. Chisholm, “Emerging Varieties of Action Research”, Human Relations 1993, v46, p121 http://dx.doi.org/10.1177/001872679304600201

Lewin conceived of action research as a cycling back and forth between ever deepening surveillance of the problem situation (within the persons, the organization, the system) and a series of research-informed action experiments. His original formulation of action research ‘consisted in analysis, fact-finding, conceptualisation,planning, execution, more fact-finding or evaluation; and then a repetition of this whole circle of activities; indeed a spiral of such circles’. Although Lewin first formulated the definition, he left scant work to describe and expand his early definitions.

The classical model of action research can be described or defined with five minimum characteristics:

1. Purposes and Value Choice Action research ... rejects the idea that science is completely value free. ... What is studied, how, who makes sense of data, and who learns are all imporant issues ...

2. Contextual focus Problem definition is not limited to the concepts, theories, and epistemology of a particular discipline, but rather is grounded in the participants' definition of context

3. Change Based Data and Sense Making

Since action research is change oriented, it requires data that help track the consequences of intended change. So, action research must have data collected systemically over time.

4. Participation in the Research Process

It requires those who experience or “own” the real world problem to be actively involved ... at least in selecting the problem and sanctioning the search for solutions.

5. Knowledge diffusion Diffusion ... occurs via new methods by which participants are directly involved in creating new knowledge which they then act on, involve others ...

Figure 1 Lewin’s action research model

http://dx.doi.org/10.1177/1350507699302002

http://dx.doi.org/10.1177/001872679304600201


The action research cycle has been refined into five phases encouraging both single-loop and double-loop learning


Source: Gerald I. Susman and Roger D. Evered. 1978. “An Assessment of the Scientific Merits of Action Research.” Administrative Science Quarterly 23 (4): 582–603. http://www.jstor.org/stable/10.2307/2392581.

ACTION PLANNINGConsidering alternative

courses of action for solving a problem

DIAGNOSINGIdentifying or

defining a problem

EVALUATINGStudying the

consequences of an action

ACTION TAKINGSelecting a course

of action

SPECIFYING LEARNING

Identifying general findings Development

of a client-system

infrastructure


Systematic collection of data at every phase enables interpreting and making sense of the consequences of intended change


ACTION PLANNINGConsidering alternative

courses of action for solving a problem

DIAGNOSINGIdentifying or

defining a problem

EVALUATINGStudying the

consequences of an action

ACTION TAKINGSelecting a course

of action

SPECIFYING LEARNING

Identifying general findings Development

of a client-system

infrastructure

0. Definition of the governing group, for regulation of the learning cycles:

● Expected scope of the intervention (possibly recorded in an evolving charter)

● Specification of individuals responsible, accountable, consulted and informed on progress

1. Diagnosis (for a cycle):● Articulation of the (evolving) problem

statement discussions and collective position● Identified gaps in outcomes or outputs to be

resolved or dissolved

2. Action Plans (for a cycle):

● Alternative plans and options considered, and the reasoning for the path selected

● Baseline, target and/or transitional criteria (in inputs, internal processes, externally-visible outputs, or stakeholder-perceived impacts) with benchmarks or references as available3. Action Taking Facilitation (for a cycle):

● Workshops and/or meetings to communicate, educate or encourage adoption of the action plans, as required

4. Evaluation (for a cycle):● Gathering and presentation of progress and

results, as compared with action plans and identified gaps

● Examination of conformance of findings with expectations / models / theory

5. Specified learning (into the next cycle):

● Document learning from from the evaluation step to suggest adjustments to system design or policies


Agenda








problem(s)






A situational analysis of an organization surfaces a problematique -- a system of problems -- also called a mess

Diagnosing [slide 1 of 2]

Source: Russell L. Ackoff, “A Brief Guide to Interactive Planning and Idealized Design”, 2001

Every organization is faced with a set of interacting threats and opportunities, a system of problems that we call a mess. The aim of this phase of planning is to determine how the organization would eventually destroy itself if it were to continue behaving as it is currently; that is, if it were to fail to adapt to a changing environment, even one that is perfectly predicted. Identification of this Achilles' heel -- the seeds of its self-destruction -provides a focus for the planning that follows by identifying what must be avoided at all costs.

Formulating the mess involves preparation of:● a. a systems analysis, a detailed description of how the system currently

operates;● b. an obstruction analysis, identification of those characteristics and properties of

the organization that obstruct its progress;● c. reference projections, projections of aspects of the organization's future

assuming (1) no change in its current plans, policies, programs, etc., and (2) the future environment that it currently expects; and

● d. a reference scenario, a description of how and why the organization would destroy itself if the assumptions made were true. [This scenario is a synthesis of what is learned in (a), (b), and (c).]


Scope (current version, subject to revision)

Boundaries ...

In scope Out of scope

Method descriptions (e.g. agile and iterative approaches)● For discovery, modeling, documentation,

development, deliver, QA, integration and implementation

● Formal method assessments (e.g. if Disciplined Agile Delivery is selected, how well is <<redacted>> doing?)

Tool positioning (for product and project management)● Process discovery (<<redacted>>)● Agile portfolio and product management

(<<redacted>>)● CPM development and deployment platform

(<<redacted>>)

● Formal Migration from SQL Server on Windows to DB2 on Unix is on a different scope of work (<<redacted>>)

● Potential future integrations (e.g. Source Code Management in <<redacted>>)

Teams involved● <<redacted>> Transformation and

Development● <<redacted>> IS/IT Development team● External CPM Project Leads and QA

(<<redacted>>)● External BPM Developers (<<redacted>>)


For the situational analysis, let's formulate our mess by responding to four questions

Diagnosing [slide 2 of 2]

Source: Russell L. Ackoff, “A Brief Guide to Interactive Planning and Idealized Design”, 2001

1. Systems analysis Within the scope defined in the charter, how is the system currently operating?

2. Obstruction analysis What are the characteristics or properties of the organization that are obstructing progress?

3. Reference projection(s) What is the organization's future, if we continue our current ways in the future

4. Reference scenario How and why would the organization destroy itself if the above assumptions made were true?


Agenda








problem(s)






Which plans of actions and options should we consider? Why? Why not? What criteria should we use to measure?

Action planning [slide 1 of 2]

For this next cycle, what plan of action or option should we consider?

Under which conditions is this a good plan of action?

Under which conditions is this not a good plan of action?

By which measures should we evaluate our success?

(Example plan 1): Adopt Test-Driven Development

●Completion criteria is unclear, so rework is frequent

●Automated testing tools support release cycles shorter than one month

●Solution to be developed is of low complexity

●Developers have world-class skills

●Speed of delivery●Quality (number of defects, declining)


For plans selected, what resources will be committed for action?

Action planning [slide 2 of 2]

Selected plans Tools / technologies

Roles / people Time

(Example plan 1): Pilot Test-Driven Development

●Automated testing tool

●Method exponent●Quality assurer●Lead developer●Developers

●Startup 2 days●First 2 weeks, 1 hour per day learning tool

●Subsequently, net zero additional time


Agenda








problem(s)






Action and review datesNext steps ...


Agenda








problem(s)






Agile portfolio and product managementAppendix ...

http://www.soberit.hut.fi/sprg/projects/atman/TowardsAgileProductandPortfolioManagement.pdf

● Chapter 1: Using Time Pacing to Manage Software Development

● Chapter 2: Agtile Product and Portfolio Management --Crucial for Competitiveness

● Chapter 7: Agile Product Management● Chapter 8: Portfolio Managemant and Agile

Software Development● Chapter 9: Agile Development Portfolio

Management● Chapter 10: The Agile Requirements

Refinery● Chapter 11: Scaling Up Release Planning● Chapte 12: Kanban for Software

Development● Chapter 13: Requirements for a Backlog

Support Tool for Agile Product and Portfolio Management


User stories (with behavior driven development)Appendix ...

Mike Cohn | User Stories (web video + MP4) | Norwegian Developers Conference | June 6, 2012, digest and links at http://daviding.wordpress.com/2013/07/27/mike-cohn-user-stories/Dan North, “Whats in a Story?”, http://dannorth.net/whats-in-a-story/

Front of card: story“As a [role], I want to [action/function], so that [value]”.

[Conversation]

Back of card: confirmation“Given [some initial context], when [an event occurs], then [ensure some outcomes]”.

http://daviding.wordpress.com/2013/07/27/mike-cohn-user-stories/

http://dannorth.net/whats-in-a-story/


Agile estimatingAppendix ...

Mike Cohn | Agile Estimating (web video + MP4) | June 6, 2012 | Norwegian Developers Conference digest and links at http://daviding.wordpress.com/2013/07/27/mike-cohn-agile-estimating/

● Project backlog ↔ iteration backlog

● Estimate size, derive duration

● Prefer story points (over ideal time)

● Estimate with Planning Poker?


Agile planningAppendix ...

Mike Cohn | Advanced Agile Planning (web video + MP4) | June 6, 2012 | Norwegian Developers Conference digest and links at http://daviding.wordpress.com/2013/07/27/mike-cohn-advanced-agile-planning/

● Velocity == amount of work completed per iteration

● Prefer fixed date plan over fixed scope plan?

● Partition backlog as iterations with (i) will have; (ii) may have; (iii) won't have

● Balance expectations with risk

http://daviding.wordpress.com/2013/07/27/mike-cohn-advanced-agile-planning/

Work Organization (Methodology) Definition ...€¦ · August 27, 2013 Work Organization Definition...

Documents

Transcript of Work Organization (Methodology) Definition ...€¦ · August 27, 2013 Work Organization Definition...