Agile project management has become a standard for modern software consulting, but many Agile consulting projects still struggle to understand it.
To deliver your next Agile consulting project successfully, I sat down with Nate Hughes. Nate is certified as a Project Management Professional, Agile Certified Practitioner, and Salesforce.com Developer with Etherios, a Platinum Partner of Salesforce. Equally important, he’s managed many real-world projects over his 22 year career for a diverse base of clients.
Q: What do you see as the key differences that make Agile clients and their projects successful?
Agile consulting clients prefer early and often views of the work in progress by using short iterations. These iterations proceed until either their project completes, funding runs out, or the ROI for the next iteration doesn’t make it feasible to continue. Many Agile consulting companies realize this approach can either save them money on their project or, in the event they realize the ROI to complete the next iteration exceeds the cost of the iteration, increase their profit. Agile projects need a client that is truly an Agile proponent and not just a proponent of the buzz word.
Q: Agile buzz words have certainly become part of the mainstream business vocabulary; which concepts do clients actually find valuable?
New agile consulting clients typically only want a daily scrum and short iterations of 2 weeks, with demos at the end of each. For a client that is more experienced with Agile, it’s our job as consultants to find out what methodologies the client feels is most valuable to them. For those clients I like to add one or two new tools that they don’t currently use to get them additional exposure, for instance Kanban boards.
Q: Those really capture the core transparency and communication of Agile; what aspects of Agile just add overhead in a client’s view?
Clients that haven’t fully adopted Agile typically don’t want to have someone available to test in each iteration. Many also don’t see the value in prioritizing their requirements and doing story point estimation. I find that’s because they are of the mindset that every requirement which was identified early on in the process is mandatory. Whereas an Agile client understands that correctly prioritizing and not stating that every requirement is mandatory early on allows them more flexibility later when they’ve realized some new functionality they would prefer to have.
Q: You mentioned ROI drives project spending – how does Agile help clients understand the business value of software?
Quite simply when I’m working with a client that prioritizes their requirements using the MoSCoW method (Must, Should, Could, Won’t), I can quickly understand and ensure focus on what a client feels are the most important functions. Having multiple iterations, and more importantly demos at the end of those iterations, allows me to drive business value for the client’s current goals, not their goals from six months ago when they were determining their requirements.
Q: We’ve talked about Agile as a broad set of concepts and cultural changes; what’s your parting advice to clients starting a new Agile project?
A couple of quick and easy tips:
- Get training at all levels
- Ensure buy-in at all levels
- For a first project, pick a few concepts you think might help and try those, then add more in the next project. Many companies try to go overboard on their first attempt, and if it doesn’t work out for them, they blame Agile and don’t try it again. There are a lot of different methodologies to try, feel free to experiment.
Thanks, Nate – that’s a comprehensive view on how to use elements of agile itself to adopt agile on projects. Modern software consulting projects move fast, but by slowly adding agile consulting concepts, you’ll gain additional insight into their business value to deliver projects successfully.
How will you use these lessons in your agile consulting project?