Implementing Agile - top-down or bottom-up

If you are considering implementing agile approaches in a company or large department one of the first considerations is whether to adopt a top-down or bottom-up approach.

Agile practices are about self-organisation, self-learning and shared responsibility across a team. Using scrum and XP practices, teams are given the freedom to innovate within a highly disciplined development environment.

Freedom and discipline seem like opposing forces... they're not.

A top-down approach is incongruous to agile philosophy, it implies a directive authority setting the approach. This approach is in line with Transactional Leadership (http://businessagile.blogspot.com/2005/02/agile-transformational-leadership.html)

The advantages of this approach are that as a manager you can move through a change programme in a relatively structured, reportable manner.

However, it is my belief that to truly gain the benefits of agile practices then a bottom-up (transformational) approach is required. Bottom-up is about letting people find out for themselves how effective agile approaches are. This will take alot longer than implementing a change programme, but I believe the effect of the change will be much greater.

By allowing people to find out themselves, try approaches themselves, and providing an environment where innovation is given space to breathe, advocates of agile practices will have a much more profound effect.

I have been trying to move the department towards agile practices through encouragement, education, and providing opportunities and an environment that enables innovation. It is pain-staking, frustrating and very time-consuming. But each small success is that more rewarding.

However, I have reached the point where as a manager, I feel I have a responsibility to ensure the adoption of agile development practices as a minimum. Yes.. I've gone over to the dark side...

I have created a Career Development Framework of 17 competencies that will be implemented as part of the appraisal and promotion process. These 17 competencies reflect what I believe to be key competencies needed for agile development and include the basics such as design, coding, and testing, as well as the more softer and more difficult competencies of collaboration, communication, and self-organisation.

As I was creating the framework I pulled on my own experience of working with guys like Howard van Rooijen, James Simmonds and Ian Shimmings, as well as the book by Coplien and Harrison on Organisational Patterns of Agile Software Development.

I also spent time at the last Scrum Gathering talking to Esther Derby (http://www.estherderby.com/), who has some excellent insights into supporting agile teams.

The initial reaction to the framework has been positive, although some developers do not see collaboration, communication and testing as part of a developer's role. The framework has gone through discussion,workshop review and amendment and will be implemented over the coming weeks.

There a four key areas of capability within which the 17 competencies sit:
Leadership & Management
  • Organisation & Planning
  • Mentoring & Coaching
  • Motivational
  • Technical Strategy
Technical Skills & Knowledge
  • Shaping & Estimating
  • Design & Architecting
  • Coding
  • Testing
  • Documenting
  • Technology Breadth
Personal Skills & Attributes
  • Effort & Attitude
  • Communication
  • Collaboration
  • Influence
Commercial & Business Knowledge
  • Financial Understanding
  • Business Domain Knowledge
  • Industry Awareness

Popular posts from this blog

Breaking the Iron Triangle: Project Manager v Scrum Master

Starting Out

Lost in Translation