what makes Agile agile?
Scott Bellware has presented an excellent talk at AgileAustin user group this past Tuesday, talking about combining Lean and Agile methodology on software projects.
Scott takes pride in being an Agile believer and practitioner, with over 10 years of Agile experience.
He also advocates Lean software production methods, and his presentation talked about combining Lean and Agile features in managing software projects.
However, some ideas offered in the presentation appear to contradict Agile philosophy and values.
Scott recommended command-and-control method of management, with strict punishment (although not dismissal) for dissent.
The command-and-control in a software development organization should come from a Chief Engineer - a role that requires expertise in three major areas:
knowing what the client wants, knowing how to design and architect the product, and being able to manage people and other resources involved in the project.
These ideas strike me as anti-Agile for a few reasons.
Agile manifesto talks about valuing individuals and interactions over processes. Command-and-control management style does not value individuals - the only individual valued is the person in command.
Agile methodology is centered on the assumption that everybody on the team wants to do good work - deliver valuable products in the most efficient way possible.
As soon as this assumption is gone, forceful management practices have to be introduced, but the resulting system is no longer Agile.
Agile philosophy has evolved as a response to failures of projects managed using the Waterfall model, where requirements are gathered up front, then design is created, and then the project is implemented as defined. A big part of the reason why many projects were failing is that requirements change, available resources change, design needs to evolve to accommodate changes in the product and resources, and implementation has to be able to change in response. The Waterfall model is not equipped to handle the changing and imperfect world, because the requirements and design are committed to early in the game, and there is no room to allow for updates.
The idea that for a successful project there has to be a God-like figure of Chief Engineer available is anti-Agile because it imposes an impossible requirement.
Agile software development methodologies attempt to deal with the real world as it is - clients change their minds about requirements, architects make mistakes in design, and engineers produce code that is less than perfect. Agile methodology expects changes and mistakes, and provides for a way to discover and correct them, rather than require an ideally qualified person in command of the process.
- Jane Prusakova's blog
- Login or register to post comments
Comments
Jane, > Scott recommended
Jane,
> Scott recommended command-and-control method of management,
> with strict punishment (although not dismissal) for dissent
Very specifically and precisely, for the sake of clarity: I stated - not recommended - that effective organizations are both flat and hierarchical.
I asserted that command and control is necessary, and specifically stated that dissent is also necessary as a counter-force. I also stated that dissent doesn't come for free, and that hen dissent goes badly, that the dissenter should expect repercussions for not fulfilling expectations in favor of following his or her own heart.
> Agile manifesto talks about valuing individuals and interactions over
> processes. Command-and-control management style does not value
> individuals - the only individual valued is the person in command
Command and control neither values nor de-values individuals. Whether an individual is valued or not depends on whether the people in play are capable of valuing others. It has absolutely nothing to do with the inherent value of people.
Specific to the manifesto, it states that the signatories value individuals and interactions over processes and tools. That means that processes and tools should not obstruct individuals and interactions; that we should not differ to processes and tools what we can get directly from individuals and interactions.
The manifesto says absolutely nothing about organizational structure and the interpretation of the manifesto to support an idea of a perfectly flat organization is precisely the self-determination and entitlement anti-pattern that I called out in my talk.
> Agile methodology is centered on the assumption that everybody on the
> team wants to do good work - deliver valuable products in the most
> efficient way possible.
> As soon as this assumption is gone, forceful management practices
> have to be introduced, but the resulting system is no longer Agile.
Just to be clear, here: the representation of command and control as "forceful" is your own embellishment. Command and control is neither forceful nor forceless. It just is. Any time there is a set expectation in business there is command and control. Command and control is the environment within which agile teams already exists. Even at organizations like Google.
Again, "Self-Organizing" is not meant to mean "Self-Determining". It never was meant to mean that no matter how divergent agile adopters' understandings of the principles go as agile goes deeper into the mainstream.
The ultimate issue here is that just because everyone on the team *wants* to do good work, it's not assured that they can do good work, where good work is defined by the best people or person on the team. This is why I said that not everyone on an agile team is equal, and therefore we should be very careful of perpetuating the nascent notion of technical and executive egalitarianism on agile teams. It will lead to people who feel entitled neither to learn nor to be managed.
It's the responsibility of everyone on a team to ultimately become as good as the best person or people on the team at the guidance of the best people on the team. This has always been an assumption of agile software development. And by agile software development, I don't mean Scrum, which is specifically concerned with agile project management rather than learning forces and engineering forces.
> Agile software development methodologies attempt to deal with the real
> world as it is - clients change their minds about requirements, architects
> make mistakes in design, and engineers produce code that is less than
> perfect. Agile methodology expects changes and mistakes, and provides for
> a way to discover and correct them, rather than require an ideally qualified
> person in command of the process.
Just because we can make changes, doesn't mean that we should cause the need for them. Just because we now have better ways of dealing with rework should under no circumstances be interpreted to mean that we should voluntarily take on rework as a side effect of a methodological orthodoxy. Rework is still cost and waste. It is minimized through deep design instincts which are not going to be available to all members of a team, and therefore the responsibility for design expectations and guidance are vested in the best software design people on the team.
The presence of a deeply experienced chief on an agile software team doesn't preclude adaptability - it permits even greater adaptability and minimizes the need for rework, which enables yet further adaptability. The chief role and adaptability and reversibility are complimentary and enabling forces in agile engineering, rather than counter forces.
Inevitably, when I talk about a Chief Engineer, I'm speaking about someone like myself with nigh on a decade of agile and software design experience, backed up by many years of pre-agile experience. If you put a traditional waterfall "architect" in the chief position, you should expect to get nothing more than the same old failure modes. The only person who is qualified to be in a Chief Engineer role on an agile team is a Chief Engineer who is qualified to be in a Chief Engineer role on an agile team. This is not your average agilist. In fact, this person in this role is necessarily very much of an above average agilist - hopefully one that knows not only why and how waterfall fails, but how agile does as well.
Scott, thank you for your
Scott, thank you for your clarifications.
>> Any time there is a set expectation in business there is command
>> and control.
This is a frivolous usage of terminology. If somebody tells somebody else what to do, it is not necessarily command and control. That is simply management.
There is always a set of expectations in any organization. However, command and control is a specific way of management, and not the only one available to an organization. Plenty of highly hierarchical organizations are not command-and-control - most start-ups do not start as command-and-control, including Google.
>> The manifesto says absolutely nothing about organizational structure and
>> the interpretation of the manifesto to support an idea of a perfectly flat
>> organization is precisely the self-determination and entitlement
>> anti-pattern that I called out in my talk.
Just to be clear, nowhere did I argue for a perfectly flat organization, or against a hierarchical organization. Hierarchical organizations are good, and helpful, and the only ones that work.
>> Just to be clear, here: the representation of command and control as
>> "forceful" is your own embellishment.
There maybe a difference in definitions. I understand command and control as
"Primarily, the idea is that people do what you tell them to do, and if they don’t, you yell at them until they do, ..." [and other bad things happen to them], as discussed in Joel Spolsky's blog back in 2006. That falls under the definition of forceful management.
>> The presence of a deeply experienced chief on an agile software team
>> doesn't preclude adaptability - it permits even greater adaptability and
>> minimizes the need for rework, which enables yet further adaptability.
No doubt that having a highly qualified leader is immensely helpful to a project. It was my understanding of your presentation that having a Chief Engineer is absolutely essential for success of an agile project.
However, to say that such a leader is absolutely necessary for success would be to limit the adaptability of an organization. Plenty of success is achieved by leaders and teams who do not possess all qualifications required for a Chief Engineer.
>> The only person who is qualified to be in a Chief Engineer role on an
>> agile team is a Chief Engineer who is qualified to be in a Chief Engineer
>> role on an agile team.
I absolutely agree with you here. However, this statement does not help in any way to figure out who is qualified to lead a successful project and where to get such a person.
Jane Prusakova
Software Architect & Developer
My blog
Bravo Scott! William W.
Bravo Scott!
William W. (Woody) Williams
Senior Project Manager
Software Development, PMO, IT Governance
My door64 Blog
enweave