As agile coaches helping organizations transition to a different way of doing things, are we doing a disservice to our clients by accepting a mandate that we know deep down will most certainly fail? Are we failing to recognize the fact that any attempt for a particular client to adopt an agile approach to software development is simply too far out of their reach?
A not so far-fetched example
Let’s just imagine that we walk into DoMoreTech Inc. and we are confronted with 40 developers, 4 QAs, a few ivory tower architects and control hungry project managers. Not to mention a management team that believes taylorism is still the best way to create software.
The Java developers are totally separated from the back-end C developers. A test means starting up the Tomcat server and clicking away. If you mention unit or automated tests, they look at you like a bunch of deers caught in the headlights. For the past 20 years or so, C developers have been masters of their domain and are very comfortable working within the three and half carpeted walls of their cubicles. One of them even installed a makeshift cardboard roof to cut down on noise! Oh, yes! And everyone is working on at least 5 projects in parallel.
The QAs are on a mission: Embarrassing the developers during the weekly “team” meeting. To ensure that they reach their bug finding quotas, they withhold information that might help developers today.
Developers tremble when he appears at the elevator doors. Even the paying client with clearly define business needs folds under the pressure of the all mighty Architect. The Architect has positioned BDUF as a critical process that must be respected for any and all projects to be successful. This well defined process is flawless and the Architect’s design is always perfect and final. If there’s a problem, it’s obviously due to the developer’s lack of maturity and experience.
Project managers and management are really happy that this “Agile thing” will help them do more with less. Since they are not part of the problem, only the technical teams need to improve the way they work. Now that they have “purchased” Scrum, they have ADDITIONAL tracking tools to better control the situation and make better decisions for the teams.
Ok. Now what?
After a few days, when all these non-winning conditions are confirmed – What do you do as an Agile Coach? Jump in and hope for the best? Run away and never look back? Or maybe do away with the detailed diagnostic and simply leave a Hallmark card on the manager’s desk saying: “Sorry, but this ain’t gonna work”
Personally, I’ve seen watered down variations of the example above in different organizations and I’ve never turned down a client. But to even hope for agile transition to succeed, the client does need to comply with two simple requirements:
Requirement 1
A pilot project (unless “Big Bang” implementation is considered). Neither a small and meaningless “test tube” project nor a do or die project. How about something just in the middle that involves external dependencies and creates value?
Requirement 2
We need a team. To quote a good friend of mine: “We don’t coach projects, we coach teams!” And this team needs to be committed to one project. This Scrum team will be composed of a ScrumMaster, Product Owner and qualified individuals to create the solution.
Whether or not these requirements are met, a Mandate Charter is created in collaboration with the client to clearly define, among other things, the conditions of success (COS) of our initiative. Taking time with the client to establish the conditions of success is a great collaborative activity and allows us to have those hard conversations and setting some facts straight.
If the basic requirements are met, the COS can be far reaching and beautiful things can happen! If not, the COS might be superficial or even cosmetic in nature. At this point, decisions need to be made. Is the client willing to pay for cosmetic changes to his or her organization? Does the client see value in these changes and is he or she able to sell ME on it?
It’s all about managing expectations. A client can’t expect an agile coach to turn water in wine. But allow a coach to work with some quality basic ingredients and we just might end up with an award winning Cabernet Sauvignon.
Party on!