Archive for the ‘The Agile Movement’ Category
Balancing Agile – Guest Post by Alan Shalloway
A fascinating difference exists between Agile and Business Service Management (BSM). Agile emphasizes continuous flow of value to the customer. In contrast, BSM focuses on the business – it aligns the deliverables of IT to the enterprise’s business goals. Subtle that the difference might be, the two methods evolved along quite different lines in spite of the common denominator – dealing with software.
In this guest post, Alan Shalloway – Founder and CEO of NetObjectives – discusses the implications of focusing on the business as distinct from focusing on the customer. His discussion is part of a few thought-provoking threads he weaves around the Agile Manifesto. Alan perceives the Manifesto a product of the times. He thinks aloud whether today’s circumstances require a revised manifesto.
Alan is a man of passion. While I do not always agree with him, I have a lot of respect for his quest to find the deeper truths. Furthermore, I always learn from him. Whether you agree or disagree with the opinion Alan articulates in this post, “listening” to his thoughts is well worth your time.
Here is Alan:
The Agile Manifesto was a watershed event that has forever changed the landscape of software development. So profound a positive impact of it has had, that few challenge whether it was actually correct. Manifestos are often a statement in reaction to something prevalent that needs changing. This makes them very topical and temporal – and the exact intention needs to be restated when the landscape against which it was drawn has changed. The Agile Manifesto[1] states:
“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on
the right, we value the items on the left more.”At the time of its edict, this was profound and well stated. Too many software teams were:
- Following a process dictated to them from outside their team
- Managing according to an extensive set of artifacts that recorded where they supposedly were well before software existed
- Were given a set of requirements to meet with little opportunity to discuss real needs (note, points 3 and 4 in the manifesto address this point in two ways – first recognizing that customer collaboration is necessary to discover their true needs and second that it is essential to take advantage of newly discovered information)
The manifesto represented a new paradigm from which to work – one in which the team would have better control over its destiny and where it was recognized that one had to make incremental, iterative movement towards one’s goals – both in discovering the true goal and in implementing it.
Unfortunately, the perspective from which the manifesto was created, or at least the methods which first followed the manifesto, have been extremely team centric. Not a surprise, given the paradigm at the time gave development teams too little say in their own methods. The impact of this has been, not surprisingly, success at the teams and difficult beyond the team. It is almost axiomatic now that companies will have successful team pilots only to bog down in their enterprise agile adoption efforts or even revert back to earlier methods.
I say “not surprisingly” because several things have been left out of the agile manifesto. These are:
- The role of management
- The role of process
- The role of planning
- And indirectly, the role of guiding principles
It could also be said that the driver for agile development is misplaced. I do not believe “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” This makes software groups customer driven, not business driven.
There is a subtle, but important difference. Basically, conscious or not, the Agile Manifesto is driven with a team-centric view of satisfying customers – business and management play mostly secondary roles. Unfortunately, there is a significant difference between customer driven and business driven (see the figure entitled Alignment with Vision of Business to the right). This is not apparent at the team level (the team is supposed to satisfy the customer). But definitely at the business level. Not surprising, however, since the manifesto is a team perspective it states things in terms of customer value.
Ironically, it is the over-focus on the team, however, that is robbing teams of one of their greatest tools. Clearly any method must have respecting people and providing those doing the work the ability to choose how they do their work. But this does not mean that process isn’t essential or that attending to certain laws of software development is optional. Rather it means that process can’t be imposed on teams since to do so would both rob them of respect and almost certainly be the wrong way to do things – who knows more about how to get work done than the people doing the work themselves?
But “Individuals over process” as the first line has come to be called, makes it sound like people are it. I do not think so – and I think this mindset has caused a lot of damage in many ways.
There is great evidence that the best approach is not merely get smart people onto a team and have them figure out how to solve their problems. They must be properly equipped to do so. Just being smart doesn’t mean you can solve the challenges facing you. This should be readily apparent, but in many ways, the Agile community has mostly ignored it. Actually, there is not really an Agile community any more – there are factions that have significantly different beliefs. For example, XP has long recognized the need for technical practices in Agile while the Scrum community is only just starting to get into what these are.
However, except for the Lean/Kanban community, few Agilists seem to espouse discovering and following the laws of product development flow (or even recognize their existence). This, in my mind, has led to the low rate of success in scaling Scrum to the enterprise*[2]. Ironically, it is the over-focus on people that leads many in the Scrum community to assert this lack of success is a lack willingness to take the effort to improve. This is not surprising – if it’s up to the team to succeed, then when they don’t it must be something wrong with the team or their management when they fail. I think not. I think it is the lack of understanding of the principles of software development flow.
These laws are not new. Don Reinertsen, in his iconic book Managing the Design Factory lays out much of the rules of product development. His more recent book The Principles of Product Development Flow: Second Generation Lean Product Development he lays out 175 of these principles.
To me, true respect for people means that one must equip them with what they need to get their job done. Our thinking in the Agile community should change from “People over process” to one of “People times process.[3]” This phrase emphasizes that if either are low, you get a low productivity. Process does not ensure success. But a poor process requires heroes to succeed. We’d like good, motivated, well-intentioned people to be able to succeed.
Our new agile perspective needs to include an understanding of what teams need to know to do their work. This opens up a role for managers to actively help teams get their job done and to coach them when they have challenges or lose their way. While I will always be thankful for the Agile Manifesto, I am looking for a Business Agile Manifesto that will expand the focus from the team to the entire enterprise.
Footnotes:
[1] http://www.agilemanifesto.org
[2] Ken Schwaber, iconic leader of the Scrum community has said that “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.”
[3] I first heard this from Don Reinertsen. Before that I used to say “People plus process.”
The Agile Regime Change – Guest Post by Tom Grant
Forrester’s Tom Grant shares with us his observations from the recent Agile Success Tour in Santa Clara, thoughts where the Agile movement is and lessons from history we all should pay attention to. His post is characterized by breadth of vision and depth of knowledge.
Tom is a Senior Analyst at Forrester Research, specializing in the technology industry’s challenges in product development and adoption. He has recently published research on the effects of Agile within technology companies, the use of social media as a new source of product requirements, and the roles of product management and product marketing. Before joining Forrester in 2008, Tom ran product management teams at big companies, such as Oracle, and small companies, such as Xythos.
Here is Tom’s post:
By all appearances, the Agile revolutions is entering a new phase, by moving along the same path that many revolutions follow. We’re now at the point where revolutionary movements succeed or fail, based on their ability to be pragmatic and inclusive.
Revolution and pragmatism
In the 18th and 19th centuries, political thinkers and practitioners in the Old and New Worlds pondered the differences between the American and French Revolutions. How did the leaders of the American Revolution replace a distant monarchy with a benign republic, with violence limited to a traditional war among field armies? Why, in contrast, did the French revolutionaries eventually exchange their king for an emperor? And why did the Revolution turn its violent wrath on civilians?
Many pointed to the enlightened pragmatism of Jefferson, Washington, Madison, and other American revolutionaries. The leaders of the American Revolution made profound political changes that took human nature into account, without trying to change it. Madison, for example, argued in the Federalist papers for a form of government that took into account the “propensity of mankind to fall into mutual animosities,” instead of trying to cure people of these nasty tendencies.
In contrast, the radicals who eventually gained the upper hand in the French Revolution had a more ambitious agenda. For example, the Jacobins sought to “cure” citizens of their attachment to religion. Unfortunately, they didn’t replace one deeply personal source of inspiration and solace, the Church, with anything comparable. Not surprisingly, when the revolution regime fell under internal and external attack, the Jacobin leaders were unable to mobilize the support they needed, and the revolution collapsed.
The historian Charles Caleb Colton made this point succinctly: “Thus the American Revolution, from which little was expected, produced much; but the French Revolution, from which much was expected, produced little.”
Agile and pragmatism
Last week, both Israel Gat and I attended Rally’s “Agile Success Story Tour” (he as a presenter and moderator, me as an audience member). The success stories themselves had a clear, obvious common thread: Agile success depends on adapting methods to fit the organization, which encompasses a lot more than just the development team. For example, George Morris of Roche stressed how important it was to manage the “impedance mismatch” between Agile and non-Agile teams. Doug Miller of Thermo Fisher Scientific argued that, to accommodate concerns like FDA regulations, his team needed to treat Agile and Waterfall as a continuum, not a binary choice.
These narratives of Agile success did not involve comparisons between the virtues of Scrum over XP, analyses of the right build environment for Agile development teams, or many of the other familiar topics from the last several years of Agile discussions.
Just a new constitution re-defines how politicians and civil servants should behave, Agile introduces new practices, such as continuous integration, daily Scrum meetings, and test-driven development, that prescribe new behaviors for development teams. However, as shown in these success stories, the Agile revolution depends on more than just a new constitution. For any new regime to succeed, it must bring the rest of the country, or the organization, along with it.
From the particular to the general
Of course, you may wonder if any single success story, no matter how compelling it sounds, is really representative. That question has more than just academic interest, if you’re trying to repeat the same experiment successfully.
Fortunately, the broader data support the success stories presented at the Agile Success Story Tour. For a recent Forrester study about Agile in the technology industry, “From Agile Development To Agile Engagement,” we surveyed a broad range of tech industry professionals—some in development, others not. Among other results, we found that the vast majority of implementations mix Agile with other techniques, and don’t treat Agile as a strict orthodoxy.
Since we spoke to more than just the members of the development team, we also had a chance to spot how Agile changes the relationships between Development and other groups. The “impedance mismatch” that Roche’s George Morris reported is by no means a unique experience. Without a deliberate effort, the relationship between Development and other groups does improve to some degree. The amount of improvement depends on how close to the development process the other group is. On average, the relationship between Development and PM, for example, improves more than the relationship between Development and Sales.
In other words, Agile in its original form, new techniques for product teams to follow, is a mixed blessing. Improvements happen, but not necessarily everywhere they need to. As the technology industry has matured, vendors have gradually learned that, for innovation to succeed, the customer-facing groups, such as Sales, Professional Services, and Support (not to mention partners), have to work in closer sync with the Development team. Throwing code over the wall is a formula for failure. Throwing code over the wall faster is not a formula for success.
The people who move the Agile revolution forward from this critical juncture should ponder what Edmund Burke said about the English political system, in contrast to the French Revolutionary regime: “Our patience will achieve more than our force.”
The Agile Executive 