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.
- 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.
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.