Throughout the last year my team has been trying out a smattering of Agile approaches to software development. We’re largely self-taught and as a result, we’ve had mixed success with the framework (although that’s by no means an indictment against it). It’s fair to say that our successes (or occasionally our lack thereof) are usually in direct relation to our efforts.
We’ve lately become more disciplined about our approach, as a result of a push from our recently hired manager. She is a proponent of Agile development and has encouraged us to not only adopt, but to really own such methods and tools as the daily stand-up, test driven development, pair programming, and weekly sprints, amongst others.
The Problem
There’s always a problem, right? We’ve often been applying these techniques without appropriate buy in from our business users. We’ve also experienced some unexpected (and sometimes unsolicited) involvement from our stakeholders, which makes me wonder if our efforts can be considered Agile at all? Is this all or nothing? Or can we continue to develop without full buy in from management and our product owners?
My concerns were a popular topic of conversation at a two day Deploying Enterprise Agile training that our team completed today. The consensus was that it would be difficult to sell Agile to the entire organization, although we certainly should try. We’ll invariably have our share of resistance, but there’d be easy converts to the cause as well.
A Solution?
We’ll need to explain the benefits of using Agile, the steps we’ll take to implement it, and manage the expectations of both our stakeholders and business owners all the while. We’ll then need to do work and prove the worth of the framework by successfully completing projects in a satisfactory manner to all who are involved.
I look forward to the progress that we’re going to make in using Agile techniques for our development. Time to get to work!