After 6 months I'm still really enjoying my curent contract.
However, I can relate to
Siddharta Govindaraj 's
5 dangers when adopting Agile .
I'm contracted by a department in a large organisation and I'm
working on a project that is part of a much larger program of work.
Like any work, it has its ups and downs. The ups generally relate
to the project, the people I'm working with and not having to
compromise on our team's use of Extreme Programming, Scrum and Lean
thinking. The downs are moments of annoying frustration when we
encounter the wider program and its organisation, bureaucracy and
dysfunction.
The department wants the benefits of Agile, so I ask myself why
has the program been organised as the antithesis of Agile? It's
partly historical but also I think it's because they're
unfamiliar with Agile. Most people involved in the
program but not our project see the practices we employ, and they
understand some of them, but they're not
seeing the
value system that we've built nor
do they fully comprehend the
principles that guide our
actions.
For me, Agile is
all or nothing . Find the right
people. Live by the values. Be guided by the principles. Practice
all the practices. Gather feedback often and then adapt. And we
have that in our team. We're self-organising and empowered; we make
commitments and then deliver; we are colocated with our customers
encamped on the edge of our bullpen (they're not in it because we
do not have the room to expand the bullpen area). We've achieved
these things because we're operating in a vacuum and our work to
date has been ring-fenced without dependencies on the rest of the
program or the organisation. The program's adoption of Agile is
effectively an
incomplete implementation . We're an Agile development team
embedded within in a program office driven by
top-down thinking .
Our team's culture is founded on open and honest communication,
collaboration, visibility and accountability. We get work done. We
deliver value to our customer, frequently and regularly. The
corporate culture is about process. I see bureaucracy and a lot
waste. And often mediocre performance is the norm, even worse it's
accepted. Our team's situation is likely to change soon as the
focus of our work shifts and expands. I'm looking forward to this
happening because it'll take us out of our vacuum. But I worry
about two things. First, dependencies on other teams being
introduced. As my friend and co-worker
Gus
Power says,
the agility of a project is generally inversely proportional to
the number of people involved who are external to the team .
Second, the inevitable clash of the two cultures and working
styles. I'm hoping we will not be asked or forced to change our
value system and working practices. Why would you want to change
something that is clearly working so that it can work with
something that clearly isn't working? Can our agility bring about a
wider
culture change , at least in the program office? Maybe. It
depends on the willingness of people to move beyond the comfort
zone provided by a command and control environment.
Fortunately, the organisation doesn't see Agile as a
silver bullet . It recognises that there are other factors
that contribute to success. Looking to the future, I'd like to see
more people, especially executive management, actively learning
about Agile to attain a deeper understanding. I can't see the wider
organisation changing (for a long time) but I would like to see
visible and tangible steps taken to bring about organisational and
cultural change throughout the program office so that a full
implementation of Agile can be achieved. This would prevent any
schismogenesis between the Agile team and the
surrounding program office.
Friday, 15 September 2006
Relating to the dangers when adopting Agile
Posted by Simon Baker - Permalink