ATTENTION DEVELOPERS: If you’re being told how to do your job, then you are not Agile.
I recently read a post by a developer in India – Ravi Mohan – titled Let the Agile Fad Flow By. It sounds as if Ravi has run into a manager or consultant that was trying to tell him how to be a developer. Here’s one select quote with my response:
Here is the secret. Nobody who is really good at programming/product design/marketing/business (or anything) will demean himself by trying to make money telling other people how to do what they are good at.
I agree with this, to an extent. When I work with teams to help them implement Agile, I don’t tell the developers how to be better developers. I work with PHP, .NET, and Rails teams. Frankly, I haven’t written a serious application in over a year and a half, and it’s been more than 5 years since I touched PHP or .NET. Far be it from me to tell any developer how to write better code. So, I don’t.
At the heart of what I do is helping rebuild the trust that has been broken between IT and business. I don’t have enough fingers and toes to count the number of business people that tell me they hate their IT people. Hate them! And why? Nine times out of ten it’s because a history of non-delivery, for a variety of reasons, has created a mutual animosity between these two that continues to fester. Any guesses how that impacts a business? Does anyone like working with people that don’t like them? That’s just the tip of the iceberg.
So what I do is to help these two typically separated parts of the business understand each other, and work together toward a common goal. The way I do this just so happens to be using Agile principles and development methods.
Self-Organization Requires Trust
An Agile team is a self-organizing team. How I define this is that what is to be done (features, requirements) is determined by the business, or in Scrum a Product Owner. The details are defined in the acceptance criteria. Now enter self-organization. Once the team agrees to design and develop a certain list of features, the team decides how best to go about it. The Product Owner and ScrumMaster do not tell the Team how to code the features. They provide the requirements, and the Team determines how best to implement.
A lack of trust between business and the Team does not allow for self-organization. This trust, missing in many organizations for a variety of reasons, must be rebuilt for the full benefits of Agile to be seen.
It takes effort on both sides to seek understanding of the other, and to begin the rebuilding.
But What Do I Know?
What do you think? That’s what I really want to know.
Other Posts That Might Interest You
