How to get agility anywhere, not only in software development sprints ...

How to get agility anywhere, not only in software development sprints ...

Whatever work we do in organisations (be it "business as usual" or "transformation" or "project portfolio management"), we should always try to get autonomy ("Flow") and cooperation ("Group Flow") in both the thinking (strategy, design, ...) and the doing (implementation, execution)

The problem however is that all our "classical instruments" (like: structures, accountabilities, overall KPIs, reporting formats, ....) WORK AGAINST autonomy and cooperation: they fuel our tendency to always "Work Apart Together" instead of really cooperating.

There are 3 simple rules that govern Flow and Group Flow (ref. Mihaly Csiksentmihaly):

  • You need clear and shared goals for all actions
  • You need to capture immediate feedback from how the work progresses
  • Your actions need to be not too difficult (avoid frustration) nor too easy for you (avoid boredom)

When these 3 conditions are met, people become highly focused on what they do and how they do it, with a strong desire to optimise collective progress (i.e. cooperation) continuously and effectively.

Agile software development is an example of how an approach can trigger Group Flow:

  • In a sprint, you set clear goals for all actions (e.g. a specific functionality to implement, test and rework)
  • In a sprint, there is more feedback as people are more closely working together, making them more focused on cooperating for progress
  • In and across sprints, there is a dynamic of trying and re-trying things to a point where everyone gradually becomes fully effective, the point where his/ her actions are optimally fitting the balance between skills and difficulty. It can take a while and some re-iterations (usual in a sprint) before getting to that point ...

So, Agile works particularly well because, and only because, it triggers Flow so effectively!

 

And it does so for a very specific reason: because "software development" allows to make progress very transparent and continuous: any new functionality develops very visually, continuously, and feedback on every step can immediately be used to re-adjust and continue.

 (By the way, can you develop the same rationale why also "Lean" triggers Flow effectively ?)

Now, wouldn't it be great if we could trigger Flow as easily, in any type of work we do, and not only in agile software development sprints ?

This would take agility / cooperation / ... to places far beyond "only" development of software. It would allow innovation, sales lead management, transformation design and implementation, ... also to benefit from this better way of workng. It could even span the entire organisation, triggering Flow in almost all the work people do, across and through many layers and departments.

We at Pactify have developed a process (similar to "sprints") and software platform to actually do so.

Our process is managed by "PMO+" people that drive the interaction between

people focused on making progress on problems, projects, goals, ... Our software supports this PMO+ process.

Both process and platform are designed to trigger the 3 conditions for Flow around the work that is being managed on the platform and for which you want more autonomy (Flow) and cooperation (Group Flow).

Here are some screenshots illustrating the 3 conditions for Flow:

1) Clear and shared goals for all actions

In the platform there is a transparent, clear "Flow" between the high level goals on the one hand, all the way down to the single contributions (actions) on the other hand. All actions need a clear milestone, milestones need a project objective, and project objectives need to connect to higher level objectives.

2) Capture immediate feedback on how you progress

The progress tab (screenshot above) already makes progress very transparent and real-time, this is feedback that teams use to stay focused and improve on progress. 

But we go bit further in making feedback really "immediate" and effective for cooperation: we developed a specific KPI (the "Pact Value") for the team on a project. The KPI changes automatically when the progress tab is updated and it reflects the "cumulative cooperation performance" of the team. The more progress, the higher the Pact Value, the more cooperation, the higher the Pact Value - but also vice versa ! This KPI unites the team around the focus of how to optimally make progress in cooperation and really changes the dynamic significantly ( 1 KPI and everyone contributes, in real-time ... it works! Because: who's going to be the one to let the team down? Or isn't this more valuable feedback than once every 3 months in a steering committee that doesn't really know what you did ?)

Additionally we also make real cooperation transparent, which is not always the case: we tend to look too much at the end result without knowing and appreciating all the contribtions it took to get there! The below "network" respresents how people really help each other: how people support others in their responsibilities or how they jointly progress. This networks is drawn from all the progress input from all the teams: so this is not a fuzzy, philosophical picture, it's the real-live tangible cooperation AT WORK what you see here!

3) Actions are not too difficult (frustrating) nor too easy (boring)

Finally, for all actions/ contributions in the progress of projects, our platform and process allows to map them on the "Flow" chart you see below. It allows teams to understand the real reasons why progress is stalling or blocking and, more importantly, to re-configure the work (smaller steps first, more help from others, re-shifting workloads, ...) in other to allow progress again.

 

 

 

 

 

Contact us at [email protected] to learn how we can trigger more autonomy and cooperation around the work you do !

Cheers

Bart

@pactifysoftware

Alain Vereecke

Agile ICT Analyst - Teal Explorer

8 年

"Group Flow" is an interesting concept and indeed quite "agile", txs for this post. The different personalities and/or "personal flows" of every teammates is also a dimension to add on the problem. Have you a view on some solutions or approaches for this dimension ?

I would tend to believe that product development is of a more defined focus. Software development contains shorter time between iterations versus hard products. Process and organizational development is complicated by fiefdoms and requires participation of varying capabilities driving inefficiencies throughout the process.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了