Thoughts on Agile: planning vs response

From	RS Wood <rsw@therandymon.com>
Newsgroups	comp.misc
Subject	Thoughts on Agile: planning vs response
Date	2014-03-30 14:37 +0000
Organization	solani.org
Message-ID	<lh9a77$ifp$1@solani.org> (permalink)

Show all headers | View raw

From the «way better than nimble and supple» department:
Title: Agile in the enterprise: To succeed, avoid the fundamentalists
Author: Márcio “Mars” Cyrillo, CI&#38;T
Date: Sat, 29 Mar 2014 18:03:45 -0400
Link: http://feedproxy.google.com/~r/Venturebeat/~3/E7hQEjpHc-0/
Podcast Download URL: http://feedproxy.google.com/~r/Venturebeat/~5/MVY8xz9jQCM/agile-project-management.jpg

[image 1]

Above: Agile development requires lots of flexibility -- and Post-It Notes.
Image Credit: VFS Digital Design[2]

I remember it as though it were just months ago, but it was early 2005 when a
heated discussion rippled across our company. A new way to develop software
had matured and had been growing fast since 2001: the agile software
development[3] approach. We knew that it would disrupt the very controlled
way CI&T had been developing custom software for big companies for over 6
years, and that was scary.

Until then, we were exclusively implementing a formal process called RUP
(rational unified process), a successful implementation of the ideas from the
unified process[4] framework. In our pitch we were purposely fighting the
waterfall method[5] that had been eroding the reputation of software houses
over time. Studies were consistently showing that more than 65 percent of big
software projects would fail.

Today, it comes without a single sign of pain to say that 100 percent of our
projects are carried out using agile[6], but during that time we were
uncertain about the future. That pristine CMMI[7] level 5 certification we
had conquered with so much effort over the years was, after all, going to be
irrelevant for the industry. Not to mention the detailed processes we had
built to align teams and clients in very well defined tasks and waves of
work, would all be compromised by a novelty we would need to learn how to use
from scratch.

But as clients were demanding us to use it, we found ourselves in a Matrix
-like situation where we had no option but to take the red pill.

And then in 2006, we delivered our first 100 percent agile project. It wasn’t
all peaches and cream. We struggled to let go of things RUP had taughted us
over the years. But nothing resists positive reinforcement, and soon after we
would have reinvented the way we build software to fully embrace the agile
manifesto[8].

Enterprises are a rough terrain for whatever new ideas may increase
uncertainty, even if in favor of better potential outcomes. We admit that at
the beginning we took the manifesto too literally. We had become some sort of
fundamentalists who wanted to rigidly follow and implement the philosophy by
pushing it down our clients’ throats.

But as we grew from hundreds of employees to half a thousand and later to
more than a thousand, and our projects were large scale software
implementations for Fortune 100 companies, reality started to wake us up. We
realized we were fooling ourselves to believe that we could follow the
manifesto so literally. We were more “fragile” than “agile” and we knew we
needed to carefully take into consideration the enterprise scale and
constraints. The challenge was how to make information and decision making
processes work in an environment where it is just impossible to have all
stakeholders in the daily meetings.

Let’s take a look at each of the contrasts made in the manifesto, which state
that “while there is value in the items on the right, we value the items on
the left more”:

1. Individuals and interactions over processes and tools

There’s an intrinsic beauty in allowing self-sufficient teams to get their
hands dirty to develop the user stories[9] by collaborating with a few key
stakeholders like a product owner. While this is great for small teams or
start-ups, inside enterprises, a lack of alignment in different levels often
generates more heat than results.

As a colleague of mine recently wrote[10], we have a more holistic view on
the “people over process” piece and extend the concept of teams to different
areas of the enterprise so that we can achieve a common ground before and
during a project. And there are very simple tools that don’t cost any money
that will help teams to communicate efficiently.

We also found out that user experience design as part of the development
process is a great way to align expectations with business areas.

2. Working software over comprehensive documentation

Some people don’t realize how profound this mindset change has been to
software development. While start-ups do it intuitively, since they have to
minimize their costs to get products and services to the market, inside
established enterprises a mold of irrational attachment to documentation had
to be broken.

There are, however, cases where comprehensive documentation might be
necessary — like in highly regulated financial services. If taken too
literally, a radical agilist might despise any documentation, which might
make the use and proliferation of APIs, to give a simple example, impossible.

3. Customer collaboration over contract negotiation

Individuals in big enterprises attuned to the new pace of technology are on
board with different contract models where they (and their organizations) can
accommodate changes in scope.

Enterprises, however, cannot afford to have zero visibility about deadlines
and the productivity of agile teams.

Some agile extremists fiercely fight to disprove any attempt to measure
performance of agile teams. But how can one improve on what’s not being
measured? And most importantly, how is it possible to adapt to the fast
changing pace of technology without adapting processes?

4. Responding to change over following a plan

Companies small and big see a lot of value in having a software development
team quickly responding to change without hours of deep discussions. Changes,
after all, have become more common and more decisive to project success.

It’s clear, however, that big companies need a plan to accommodate changes,
otherwise they will quite often run out of budget. Value engineering has
proved to be of tremendously effective tool to help with this.

If you ever heard one or more of the following phrases from agile developers,
ask yourself if you aren’t dealing with an agile fundamentalist:

* “Software development is a form of art and thus can’t be measured.”
* “The feature will be ready when it’s ready. Projections from management
won’t help, we are working on adding value as quickly as possible.”
* “Productivity measurements and metrics are things of the past, from the
mass production processes. Artifacts used by managers to squeeze life out
of developers.”
* “The measurement of productivity is a risk because the teams will find a
way to artificially prove that they are productive.”
* “We can’t do a fixed price project because we won’t be able to
accommodate changes.”

Those are all myths that can be proven wrong.

Metrics can be used to measure processes, not people, and productivity should
be collected and monitored by the teams themselves. A team that is not
capable of measuring its own performance and understanding what’s affecting
it will never be able to promote continuous improvement.

As we found out when we grew to over 1,200 people (we are now at 1,700), the
lean principles[11] offer the best set of philosophical baselines and tools
for the best implementation of agile, be it with SCRUM, Kanban or anything
else.

“Lean” was the key for us to overcome the agile manifesto pitfalls and to be
able to scale that approach inside big companies like Johnson & Johnson,
Pfizer, and Coca-Cola, to name a few.

We are now a smart collection of “lean agile enterprise” evangelists, as
opposed to agile fundamentalists, and our clients are happy with that,
reporting quality and throughput performances never before seen.

Our organization isn’t the only one who’s noticed this phenomenon. Dave
Thomas, one of the founders of the Agile Manifesto, recently wrote a blog
post[12] to suggest the term “agile” should be dropped.

In my opinion, we just need to discern between evangelists and
fundamentalists.
----------------------------------------------------------------------------

Márcio “Mars” Cyrillo is executive director at CI&T[13], creator of smart
applications that add a layer of intelligence to business. He is currently
responsible for global marketing operations, the global partnership with
Google and CI&T’s strategic early involvement with the emergent market of
smart applications (CI&T Digital Brain). With CI&T since 1999, Mars holds a
PhD in applied physics from Universidade Estadual de Campinas and two MBAs in
sales management and entrepreneurship from Fundacao Getulio Vargas and Babson
College. Mars is driven by constant improvement in: technology, his running,
and the best lens to capture the NYC skyline.

 

Related articles

* [image 15][14]It’s an agile world – the sooner you get used to it, the
better[14]
* [image 17][16]An idiot’s guide to DevOps[16]
* [image 19][18]Continuous delivery is a killer advantage for companies
that want to move fast without breaking things[18]
* [image 21][20]Why companies are not startups[20]

[image 23][22][image 24]
----------------------------------------------------------------------------
VentureBeat is studying mobile monetization. If you're a mobile developer or
publisher, fill out our quick survey[25], and we'll share the resulting data
with you.[image 26]
[image 28][27] [image 30][29] [image 32][31] [image 34][33] [image 36][35]
[image 38][37][image 40][39][image 42][41][image 44][43][image 45][image 47][46][image 49][48][image 51][50][image 53][52][image 55][54][image 56]

Links:
[1]: http://venturebeat.files.wordpress.com/2014/03/agile-project-management.jpg?w=578&h=9999&crop=0 (image)
[2]: https://www.flickr.com/photos/58816914@N05/5396691102/ (link)
[3]: http://en.wikipedia.org/wiki/Agile_software_development (link)
[4]: http://en.wikipedia.org/wiki/Unified_Process (link)
[5]: http://en.wikipedia.org/wiki/Waterfall_model (link)
[6]: http://ciandt.com/agile (link)
[7]: http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration (link)
[8]: http://agilemanifesto.org/ (link)
[9]: http://en.wikipedia.org/wiki/User_story (link)
[10]: http://www.ciandt.com/us-en/card/the-agile-manifesto-where-the-enterprise-got-it-wrong (link)
[11]: http://www.lean.org/whatslean/principles.cfm (link)
[12]: http://pragdave.me/blog/2014/03/04/time-to-kill-agile/ (link)
[13]: http://www.ciandt.com/ (link)
[14]: http://venturebeat.com/2013/11/27/its-an-agile-world-the-sooner-you-get-used-to-it-the-better/ (link)
[15]: http://i.zemanta.com/224941350_80_80.jpg (image)
[16]: http://venturebeat.com/2013/09/30/an-idiots-guide-to-devops/ (link)
[17]: http://i.zemanta.com/206962242_80_80.jpg (image)
[18]: http://venturebeat.com/2014/03/10/continuous-delivery/ (link)
[19]: http://i.zemanta.com/255274494_80_80.jpg (image)
[20]: http://venturebeat.com/2014/03/08/why-companies-are-not-startups/ (link)
[21]: http://i.zemanta.com/254689929_80_80.jpg (image)
[22]: http://reblog.zemanta.com/zemified/56af0c0d-6f77-4452-8622-e7d4fcfdc1f3/ (link)
[23]: http://img.zemanta.com/reblog_e.png?x-id=56af0c0d-6f77-4452-8622-e7d4fcfdc1f3 (image)
[24]: http://stats.wordpress.com/b.gif?host=venturebeat.com&blog=342986&post=1221110&subd=venturebeat&ref=&feed=1 (image)
[25]: http://intel.venturebeat.com/surveys/game-monetization.html (link)
[26]: http://venturebeat.feedsportal.com/c/34021/f/617399/s/38c4343b/sc/4/mf.gif (image)
[27]: http://share.feedsportal.com/share/twitter/?u=http%3A%2F%2Fventurebeat.com%2F2014%2F03%2F29%2Fagile-in-the-enterprise-to-succeed-avoid-the-fundamentalists%2Ft=Agile+in+the+enterprise%3A+To+succeed%2C+avoid+the+fundamentalists (link)
[28]: http://res3.feedsportal.com/social/twitter.png (image)
[29]: http://share.feedsportal.com/share/facebook/?u=http%3A%2F%2Fventurebeat.com%2F2014%2F03%2F29%2Fagile-in-the-enterprise-to-succeed-avoid-the-fundamentalists%2Ft=Agile+in+the+enterprise%3A+To+succeed%2C+avoid+the+fundamentalists (link)
[30]: http://res3.feedsportal.com/social/facebook.png (image)
[31]: http://share.feedsportal.com/share/linkedin/?u=http%3A%2F%2Fventurebeat.com%2F2014%2F03%2F29%2Fagile-in-the-enterprise-to-succeed-avoid-the-fundamentalists%2Ft=Agile+in+the+enterprise%3A+To+succeed%2C+avoid+the+fundamentalists (link)
[32]: http://res3.feedsportal.com/social/linkedin.png (image)
[33]: http://share.feedsportal.com/share/gplus/?u=http%3A%2F%2Fventurebeat.com%2F2014%2F03%2F29%2Fagile-in-the-enterprise-to-succeed-avoid-the-fundamentalists%2Ft=Agile+in+the+enterprise%3A+To+succeed%2C+avoid+the+fundamentalists (link)
[34]: http://res3.feedsportal.com/social/googleplus.png (image)
[35]: http://share.feedsportal.com/share/email/?u=http%3A%2F%2Fventurebeat.com%2F2014%2F03%2F29%2Fagile-in-the-enterprise-to-succeed-avoid-the-fundamentalists%2Ft=Agile+in+the+enterprise%3A+To+succeed%2C+avoid+the+fundamentalists (link)
[36]: http://res3.feedsportal.com/social/email.png (image)
[37]: http://da.feedsportal.com/r/193359848007/u/49/f/617399/c/34021/s/38c4343b/sc/4/rc/1/rc.htm (link)
[38]: http://da.feedsportal.com/r/193359848007/u/49/f/617399/c/34021/s/38c4343b/sc/4/rc/1/rc.img (image)
[39]: http://da.feedsportal.com/r/193359848007/u/49/f/617399/c/34021/s/38c4343b/sc/4/rc/2/rc.htm (link)
[40]: http://da.feedsportal.com/r/193359848007/u/49/f/617399/c/34021/s/38c4343b/sc/4/rc/2/rc.img (image)
[41]: http://da.feedsportal.com/r/193359848007/u/49/f/617399/c/34021/s/38c4343b/sc/4/rc/3/rc.htm (link)
[42]: http://da.feedsportal.com/r/193359848007/u/49/f/617399/c/34021/s/38c4343b/sc/4/rc/3/rc.img (image)
[43]: http://da.feedsportal.com/r/193359848007/u/49/f/617399/c/34021/s/38c4343b/sc/4/a2.htm (link)
[44]: http://da.feedsportal.com/r/193359848007/u/49/f/617399/c/34021/s/38c4343b/sc/4/a2.img (image)
[45]: http://pi.feedsportal.com/r/193359848007/u/49/f/617399/c/34021/s/38c4343b/sc/4/a2t.img (image)
[46]: http://feeds.feedburner.com/~ff/Venturebeat?a=E7hQEjpHc-0:zfW-ynZMn98:yIl2AUoC8zA (link)
[47]: http://feeds.feedburner.com/~ff/Venturebeat?d=yIl2AUoC8zA (image)
[48]: http://feeds.feedburner.com/~ff/Venturebeat?a=E7hQEjpHc-0:zfW-ynZMn98:qj6IDK7rITs (link)
[49]: http://feeds.feedburner.com/~ff/Venturebeat?d=qj6IDK7rITs (image)
[50]: http://feeds.feedburner.com/~ff/Venturebeat?a=E7hQEjpHc-0:zfW-ynZMn98:V_sGLiPBpWU (link)
[51]: http://feeds.feedburner.com/~ff/Venturebeat?i=E7hQEjpHc-0:zfW-ynZMn98:V_sGLiPBpWU (image)
[52]: http://feeds.feedburner.com/~ff/Venturebeat?a=E7hQEjpHc-0:zfW-ynZMn98:I9og5sOYxJI (link)
[53]: http://feeds.feedburner.com/~ff/Venturebeat?d=I9og5sOYxJI (image)
[54]: http://feeds.feedburner.com/~ff/Venturebeat?a=E7hQEjpHc-0:zfW-ynZMn98:D7DqB2pKExk (link)
[55]: http://feeds.feedburner.com/~ff/Venturebeat?i=E7hQEjpHc-0:zfW-ynZMn98:D7DqB2pKExk (image)
[56]: http://feeds.feedburner.com/~r/Venturebeat/~4/E7hQEjpHc-0 (image)

Back to comp.misc | Previous | Next | Find similar | Unroll thread

Thread

Thoughts on Agile: planning vs response RS Wood  <rsw@therandymon.com> - 2014-03-30 14:37 +0000

csiph-web