This post originated from an RSS feed registered with Agile Buzz
by Simon Baker.
Original Post: Relating to the dangers when adopting Agile
Feed Title: Agile In Action
Feed URL: http://feeds.feedburner.com/AgileInAction
Feed Description: Energized Work's blog.
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.
Previous Topic
