Tuesday, 21 May 2013 04:05

Frayed Agile Pools - The Ultimate Methodology At Last

Written by

Ferrer May21 ArticleVision-Schmision is Taking a Break

To bring you this breaking news!

V-S vill be bock!

A new paradigm has emerged, and just as some (the fools!), were starting to think that Agile might be a fad after all, fading just like April showers of the recent past. As team after team has struggled with the productivity gain potential (stress!) of more teamwork and less messing around, many have found Agile wanting.

Scrum is often used as a scapegoat, as in statements such as: “They used Scrum rituals but did not practice agile” and “They are Pond Scrum.” Scrum is a simple set of rules and calculations that anyone could follow, and they do. Scrum is easy.

Concerned Agilists* protest that true implementation of Agile is hard, and that Scrum is not Agile. Some say that agile teams that fail must not have practiced Agile at all, since Agile cannot fail by definition. Enlightened management sees this as a critical error. As Edward Deming said: ***

When you think of all the underuse, abuse, and misuse of the people of this country (US), this may be the world’s most underdeveloped nation.”

It seems that blaming people**** is not the way to “fix” Agile. If, as Deming claimed, it is the “system” in which we work that accounts for most behavior. If Agile is our “system”,  Then Agile itself must be at fault! *****

The good news is that the Agile Control Group******* has done a root cause analysis, and has just done a press release******** announcing the solution to any Agile “blues”. They have figured out that it is possible to create multiple Agile teams capable of handling ANY project in ANY timeframe, however short.

For example, one of the Agile principles is:

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

Root cause analysis shows that employees are underperforming against management’s expectations almost everywhere these days. Many employees will , and will pad their task estimates so they can web surf and tweet on employer time. The “constant pace” principle is SO tempting that employees will set a pace lower than a boss has a right to expect, especially if the employees are experts (IT) and the boss is not (Product Owner). Frayed Agile Pools can address this issue in the following ways:

By splitting a large project into smaller (fractal) pieces (fraying). This allows a boss to make ANY deadline with no whining. Let’s say that your worst Agile team can produce 100 lines of code a day. If success is achieved by producing 1000 lines of code a day Then the boss can succeed by creating 9 more Agile teams (the “pools”) and merging their code every day. This has the advantage of increasing the number of “product owners”, each with the correct expertise to support each team in the pool.

This “fraying” fractal process eliminates all excuses, is “free” in the sense that the cost per line of code need not rise (bring in or outsource contractors), and cannot fail to produce more code. If productivity suddenly drops below 1000 lines per day, the boss will KNOW whom to motivate. Knowing whom to motivate is a management “key success factor”.

Because of the brilliance of self-commitment, the coders must achieve their own “estimates”; else they will look weak to the team. In this kind of “self-organizing” productivity environment, management can slowly increase pressure, by insisting on increased code production as Agile succeeds where the team could not succeed before. If the team protests, remind them that Agile says:

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

This may “fray” some nerves, but you can tell the teams that it is more fun to be busy, and that stress is what coffee and donuts are for. Forgetting donuts is one mistake where it is OK to blame management.

Another Agile principle is:

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

Root cause analysis for this principle is, of course, trivial. No businessperson has time to work on projects, and most are too old or overweight to sprint. They are too busy fixing what is failing, even though what is failing is also the driver for the project you are asking them about. They are too busy sawing to sharpen their saws. They have meetings to plan how to plan other meetings. They installed Quicken on their home PC, and can’t understand why you can’t get SAP (or Oracle, or PeopleSoft) up and running without infuriating other business people. They can’t take their fingers out of the dam just to talk with a hydrological engineer – the dam could collapse, and besides, fixing the dam is not the business’ problem. 

Frayed Agile Pools offer some ways to fix this “broken Agile” problem.

Reassure the business people by letting them know that the dam WILL collapse, but not to worry as there are MANY pools of developers to absorb the flow, and no businessperson will need to be washed away.

Reassure the developers by pointing out that every pool will have access to whatever time is available from business people, so that all pools are on a level playing field. By spreading stakeholder time across multiple pools the business’ knowledge goes further.

Encourage the multiple product owners to ask for more complicated solutions, since they have so little time to spend with the developers. Since we are able to produce as much code as needed without increasing the cost per line of code, this will maximize our delivery of working software.

One could go on an analyze root cause issues with other Agile principles, but we end by mentioning one principle that is honored by every Agile team I have witnessed: 

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

The simplest teams are always the best – with practice, and judicious application of inhibitors; a top-notch simple Agile team might not ever break anything, ever again :)

For other BA Times articles on Agile and how it affects project outcomes, try these links:


Pursuit of this breakthrough might even lead to the holy grail of project management, the plan they shoot for (aim, ready :-) many times:

Requirements For Nothing and Tests For Free.

Have fun, and don’t forget to peer review with your comments!

* What else takes a 3 day class to get certified for a $115K** job?
** Prices set by the state of Virginia unemployment job service :)

*** Deming finishes with: “It’s about time for American management to wake up.”
**** Management are not people, Deming believed most were short sighted.
***** Logically, IF the first part is false  THEN the whole statement is true. ******

****** This is different from the truth of the second statement – fun lookup! :)

******* They are coming to get you, woooooo…. :)

******** If the press release still exists :) Then you will find it here.

Read 10889 times
Marcos Ferrer

Marcos Ferrer, CBAP has over 20 years experience in the practice of business analysis and the application of Information Technology for process improvement. Following graduation in 1983 from the University of Chicago, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in diverse industries. His recent projects include working requirements for the Veteran's Administration, introducing BA practices at the Washington Suburban Sanitary Commission, and creating bowling industry models for NRG Bowl LLC. In November 2006, Marcos Ferrer is one of the first CBAPs certified by the IIBA. He has served as an elected member of the DC-Metro chapter of the IIBA, most recently as President, and assisted in the writing of the BOK 2.0 test.

© BA Times.com 2019

macgregor logo white web