

Honey, I Introduced Agile In My Company - budchrislee
http://proghammer.blogspot.com/2012/03/honey-i-introduced-agile-in-my-company.html

======
lucisferre
I'm pretty turned of anything to do with Scrum these days. It's such a cargo
cult of process (remember the "people before process" part of agile?) and
focuses solely on the development process to the exclusion of almost
everything else about the organization.

I've seen too many organizations and teams try to use agile to "fix" things
while completely ignoring issues like product development, customer
development and even culture.

Any gains from applying agile will still be barely incremental when compared
to addressing the real issue of product development and doing so holistically.
I think lean and even lean startup make some significant strides past agile in
doing this, but even that is starting to show it's cargo cult side (a/b test
all the things anyone?).

~~~
quattrofan
Well if I told at least 3 clients have introduced "agile" in an attempt to
solve perceived process problems and "speed things up" but have in effect made
things worse, what would you say?

Agile is bollocks and just another excuse for consultants to fleece money from
companies.

~~~
wpietri
I think "Agile" can be used as an excuse for consultants to fleece money from
companies. Indeed, I'm on record as saying that's mainly what's getting sold
these days:

[http://agilefocus.com/2011/02/21/agiles-second-chasm-and-
how...](http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-
in/)

But acknowledging that, I'd like to add two things:

First, as a developer, adopting Agile methods (in particular, Extreme
Programming) made my life a lot better, and probably kept me from quitting the
industry in frustration. And when I started a company, we gradually put
together a custom Agile approach we liked a lot.

Second, any useful Agile method works mainly by surfacing hidden problems so
that people can fix them. So if you are doing an Agile adoption right, things
always appear to get worse before they get better. The test for me is whether
people treat the adoption as a process and relentlessly fix problems as they
appear.

------
ceekays
at my previous employement, we were using agile (scrum, to be specific). We
used to pair-program. Always, the head of the team made sure that you have a
new workmate for a every new project. As such, you got used to know and
leverage the different talents of the co-workers. We used to have fun through
freestyle coding (once a month) and pseudo-random brownbags where we were
learning new techniques in the indurstry. Being in Africa, brownbags were
great and everyone of us was always making sure to keep track of what was
happening in software world.

But when I changed jobs in July last year, I met a different team. I call it a
dead team. There is no collaborative development, no source code versioning
and tracking. (I am comfortable with git and mercurial). No brownbags, no
codefests, no freestyle. Everyone works like a cowboy. I tried introduce
agile, the team was just rigid because of the head.

Now the head of the team is quitting early September. There are high chances
that I may acting as the head of the team after he is gone. But even if I may
not be acting, I think I will try again to bring back the culture I used to
love. I am guessing it was the head who was refusing to change. Two months ago
I tried to introduce git to some workmate, he liked it only that he could not
do more with it since the team doesn't use versioning.

I have learnt something: some people refuse change.

~~~
quattrofan
Hate to tell you but version control has zero to do with being agile nor does
"collaborative development".

~~~
ericHosick
That is not true. None of the practices applied by Agile actually originated
within Agile. Agile is simply a collection of best known practices. CI, Pair,
Estimation, etc. are all aspects of Agile.

------
MrKurtHaeusler
Good post. For me the first 3 tips, about having management backing, the right
culture and the right people made me smile a bit. An analogy would be like
"Here are 3 tips for being successful in business: Have a lot of capital, have
a great idea, and execute it perfectly".

Normally getting management backing, developing the right culture, and having
the right people are huge, difficult topics in themselves that are much larger
and more fundamental than how a team decides to develop software.

If anything it goes the other way around. In order to get management support
the team should first start doing agile and proving that it works. Having the
right culture is a long term thing. Agile software development is a mere step
in that direction as far as developing software goes. If anything agile
software development helps the right culture emerge rather than the right
culture being a prerequisite for agile software development.

And if you truly have the right people you don't need to to worry about agile,
you are already doing so well that agile will only slow you down. Agile is
probably ideal for larger organisations who unfortunately don't have the
"right" people and need a framework or something to help them along. Once
people get competent enough, "agile" just starts to feel dogmatic and
restrictive. I mean they will still do the practices that make sense, but they
aren't going to appreciate other aspects of buying into a whole "agile"
approach.

I would also caution against "passing the change baton to higher ups". I have
seen all the hard work undone when a fairly agile software development
department decided to combine with the product department and include them in
the change management process. The idea was to spread agility outwards, but
because the product department had mostly more extroverted, managerial types
they took control of the decision making (I was surprised how easily the
software developers ceded control and retreated into a yes boss mentality) and
their command and control culture swamped over any agility we had in the dev
department.

~~~
adrianhoward
_And if you truly have the right people you don't need to to worry about
agile, you are already doing so well that agile will only slow you down. Agile
is probably ideal for larger organisations who unfortunately don't have the
"right" people and need a framework or something to help them along. Once
people get competent enough, "agile" just starts to feel dogmatic and
restrictive. I mean they will still do the practices that make sense, but they
aren't going to appreciate other aspects of buying into a whole "agile"
approach._

When you say "[Aa]gile" here are you talking about a particular process
(Scrum? XP?) or something else? I can't really understand the intent -
especially since in my experience agile works better with smaller
organisations than large ones.

------
vampirechicken
I highly recommend the book "Priciples of Software Engineering Magement by Tom
Gilb.

It lays out a superset of the techniques and principles of what eventually
came to be called "Agile," in the wee early years of the eighties, and
provides the rational for the principles, grounded in experience, and
featuring data.

Despite having been through Scrummaster training, I still believe in the power
of creating a "destination" and iterating analysis-design-build util the
destination is reached. Using short iterations allows for course corrections,
and destination shifts. The abilty to correct sooner rater than later is the
key aspect I appreciate in "agile."

I've also found that while interations are good for short term planning and
for scheduling sprint retrospectives (to borrow from scrum), I find that a
kanban/funnel approach works better than strict iteration boundaries.

------
Zarathust
I'm working to do stuff that we aren't sure whether it is possible to do or
not. Sometimes showing a working demo is more than 2-3 weeks, especially when
I have to integrate into 3rd party components and such. I'm no sure how to
work with "sprints"

~~~
adrianhoward
_Sometimes showing a working demo is more than 2-3 weeks, especially when I
have to integrate into 3rd party components and such. I'm no sure how to work
with "sprints"_

If you can talk a bit more about what you're trying to deliver and how I might
be able to give some pointers. I've never worked with any client where we
couldn't get to delivering something useful every week or two.

(Very deliberately ignoring the whole sprint vs flow debate :-)

