Agile development methodologies put forth a set of guidelines for helping to navigate the complex world of software development. For agile to be truly effective, it needs to be supported throughout the organization, and encourages reaching out to the customers. In working with the agile projects at different companies, I found challenges in getting agile accepted and properly implemented. If you’re thinking about embracing agile in your organization, keep these points in mind to help make it a less bumpy road.
Executive/Management Buy-in.
- Can you commit to exactly what features will be delivered in 6 or 9 months?
- How can we design as we go? Shouldn’t all architecture details be worked out up front?
- How can you not know exactly how long things take?
At the end of the day, I can see the executives’ viewpoint regarding wanting to know because of the need for predictability and also for meeting the commitments to customers. Here are some suggestions to address the concerns:
- Point to historical results:
- Does the current process yield predictability?
- Does the process easily support changes needed by the business?
- Explain the key concept and value propositions of agile:
- Keep customers (customer representatives) closed by to ensure that the features are built as expected
- Keep teams focused by protecting resource during the iteration
- Short iterations to allow adjustment to adapt to changing business environment.
- Greater communication among team members, reducing chances for errors and misunderstanding
- Experimental approach: predicting future delivery based on past experience
- Explain potential drawbacks and pain points:
- It does take time to train the team and to get people to adapt to the new process.
- Adjustment will be made as part of the process
Product Team Buy-in
- Agile processes tend to rely on independent, self-motivated team members to come up with the tasks and the solutions.
- Agile processes tend to suggest that developers become generalists (any one can do any task), rather than specialists.
To address these concerns, I suggest the following solutions:
- Beside the scrum master who facilitates the process, there must also be senior engineers to provide mentoring and technical leadership to those who are willing, but not quite able to take on the more challenging tasks. All these people would play the role of the “servant leader” to help each and everyone reach their potential.
- The manager/team leader would work with each team member to identify their current areas of expertise and desired areas of expertise, both in the short term and the long term. With a skills roadmap identified for each person, people would be more motivated to contributed where it’s needed while still staying focus on their career goals for their specialized skills.
Customer Buy-in
Will the customer accept a “maybe” answer for a given feature? Usually not. Sharing a feature list of must and may have items (with respect to that customer) can help the customer put things in perspective. Getting the customer engaged early and frequently throughout the development process can usually get the product manager/sales representative enough browny points to go back and change a feature specification or even remove the feature all together. The key to doing this is to really understand from the customer’s viewpoint as to how the feature is actually used and how important is that particular feature to the customer. Often, I find that the customer doesn’t care as much for a particular feature as to that fact that you keep your word on the delivery. Many times a feature that gets delivered doesn’t really get used, but certainly helped to get the contract signed.
I love this post. Many people are “afraid” of agile because they have tried to implement it and fail. What most people do not understand is you need to set up some basic (infra)struture to make it work. It is by no a magio bullet. To Josh’s point, introducing change slowly allows several things –
– allows you prove its worth
– allows you to convert people who are set in their ways
– allows you to learn from mistakes.
Wow, Loyal and I are thinking on the same wavelength because I was going to comment that the last paragraph was key too.
Many proponents of this or that methodology are ruthlessly black-and-white about the implementation of it. In many cases, it’s all or nothing. I think that is one big reason why so many implementations fail.
Instead, a gradual transition plan over the course of years is probably the way to go. It is true that the entire organization needs to embrace a process as a part of the culture for optimal results….and that shift only happens over a period of time unless you are building the organization from scratch.
I like your last suggestion:
“Pick some set of practices and adopt them as you go, leaving others out for a later time.”
This sounds like being ‘Agile’ with Agile 😉
I wonder what the future will be for software development. I have been in engineering long enough to have lived through the earliest software life cycles that were force-fit into the then proven hardware processes, with the now predictable failures. From there they morphed into to the spiral and other more ‘agile-like’ techniques.
So, what’s after Agile? Perhaps suppliers will sell development platforms for the product directly to the customer and let the customer add the features they want. In fact, you need look no further than the blog engine running this website: WordPress. Hundreds of high-quality extensions allow us ‘customers’ to tailor the product to just what we want, when we want it. What’s next?