Solution Focused Agility in Projects and Management

Replies to This Discussion

Permalink Reply by Josef Scherer on June 18, 2008 at 14:02

Hi Hans-Peter,

as a Scrum Coach I'm certainly not an expert in the field of agile QM as such, but probably only on the sofware development (SD) part.

To put agile QM into two sentences:
A cross-functional team tries to produce the right thing (product) the right way (process) and they do this in an iterative, evolutionary fashion.

So one thing, which IMHO is at the heart of agile QM would be the definition of quality as customer value, as expressed e.g. in the first principle of the agile manifesto:

http://agilemanifesto.org/principles.html

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

In agile software development you try to deliver the highest customer value as early as possible and that on a regular basis, say every month. In this way we can get timely feedback from our customer about the perceived quality of the product and this feedback is included in the next monthly iteration.

This ideas are covered by the next two priciples:

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

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

The second thing is, that the development team gets involved in the improvement of the process:

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

This is also done on a regular basis at the end of an iteration and is also known as agile retrospective. Learnings from the retrospective are also included as improvement tasks in the next iteration.

Needless to say, that customer and developers have to work together closely, to deliver the right product in the most effective and efficient way.

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

So the third cornerstone of agile QM is probably working together in complete, cross-functional teams, for instance of customers, business analysts, users, developers and testers, because this is essential in achieving 'complete' results, which cover all aspects of the requirements.

Permalink Reply by Hans-Peter Korn on June 18, 2008 at 18:11

Yes, Josef, this "agile principles" can serve as good helpers for a "SF-QM"

And SF principles also can enhace some agile practices, e.g. scrum:

Scrum (and other agile practices like Cockburn's cristal-family) are methods for software development. And SW-systems "alone" (without any human interactions) are "predictabe & analyzabel" systems, that means: Not "general complex systems". And such "not general complex systems" can be treated in a "mechanistic" way: Analyzing problems and finding the causes are very useful and effective. This is done e.g. in the scrum retrospective meetings when "technical stuff" is discussed. But analyzing problems and finding the causes is not the golden bullet to find solutions in complex systems like SW-systems including human interactions or the "social system of the project stakeholders".

So: To enhance quality in such complex systems we have to pay attention that we do not extend the "mechanistic" way which was successfull for SW-systems "alone".

What SF can offer the agile people are some ideas how to deal with quality aspects in complex systems.

I have a presentation from Jenny Clarke shown at the SOL 2008 in Colongne about "Quality management with SF inside"" - it is on the "SOL08-USB-stick". This presentation shows such ideas.

Jenny, as the author of this presentation, are you willing to upload it here?

Thanks!
Hans-Peter

Permalink Reply by Josef Scherer on June 19, 2008 at 8:00

Hi Hans-Peter,

I think your talk of complex and hybrid systems can be very helpful in preparing a retrospective, where you make a choice of tools, which best fit the line of process improvement the team is most likely to take.

The reality of the retrospectives I facilitate is that not only technical stuff is discussed there, but usually its about things like communication, collabortion, feedback etc. Even if most of the stuff discussed were technical practices and tools, because agile software development follows the idea that "Individuals and interactions" are more important than "processes and tools" , those tools are usually meant to accelerate interaction, communication and feedback.

So my impression is, that retrospectives are already designed in a quite SF way, e.g. when you compare it with the SolutionCircle for team coaching or special variants of retrospective using AI:

Retrospective using Appreciative Inquiry

Permalink Reply by Hans-Peter Korn on June 20, 2008 at 16:15

Hi Josef,
btw:
==> HERE you find a Comparison of Appreciative Inquiry and Solutions Focus by Kendy Rossi, Tricia Lustig & Mark McKergow.
This overview presents key aspects of Solutions Focus and Appreciative Inquiry side by side. The similarities and differences are clearly visible, and the authors' collective experience of both fields makes this as definitive a document as could be desired. To read comments on the differences from an SF perspective by Jenny Clarke pless open also ==> THIS PAPER

Permalink Reply by Hans-Peter Korn on June 20, 2008 at 16:31

There is an interesting seminar about „Hypnosystemische Konzepte und Interventionen für Gruppen und Teams“ on
03. – 04. Juli 2008 in Vienna mit Gunther Schmidt
==> DETAILS HERE