At Daugherty, we probably hear about Agile Development more than any other topic. Common detailed questions such as: How do I get started? Should I use scrum? Can my PM be the scrum master? Then, there’s also the other big picture questions about the nature of migrating from a waterfall or an iterative approach to full agile.
Daugherty believes that there is no one answer that fits perfectly into every environment. The truth that everyone must understand is:
- Agile is not a magic bullet that is going to solve all of your IT dysfunctions
- Agile is not a set of ceremonies and artifacts, but is a cultural discipline that demands a change in thinking as well as process
Let me start off this conversation with the question we should be getting asked. Why Agile?
Agile Construction provides key benefits that will align IT closer to the business outcomes it provides, reduce rework, and provide tangible value quicker to the business. No matter how you design your Agile program, it must have:
- Rapid Feedback from all parties that leads to less rework, highest value construction, and better definition of the deliverables
- Embedded Q/A and continuous testing (we are going to be ruthlessly refactoring; we need to make sure we aren’t breaking the things that used to work)
- Tight, well-defined relationship between the business and IT, dedicated product owner(s) that is willing to guide the teams through all decision and feedback stages
- Empowered teams that are allowed to self-select, self-drive, and self-commit to the work being done (along with empowerment comes responsibility and accountability)
- Faster release cycles, getting the high value, completed items in the users hand as quickly as is feasible
- Prioritized risk evaluation, making sure that architectural or technical risk is addressed before functionality is fully developed
An Agile program can leverage Scrum, XP, Adaptive Software Development, or any of the other Agile frameworks, as long as first and foremost you keep the above disciplines in place.
So to address the bigger question… Should you go Agile?
Let’s look at what it takes to truly make agile work. First and foremost, you need a committed business and IT alignment, where value, funding, and outcomes are all in sync. If you do not have this, your first step should be to invest in a Business Alignment workshop, otherwise you may have Agile construction, but you will never have an Agile Enterprise.
Second, you have to understand your current staff. You wouldn’t ask a Java shop to start coding in .NET without training, continuous education, and a coaching plan. Nor should you expect your business and IT resources to be able to pick up the rigor and discipline of Agile without the same level of training and support. In addition, the way you allocate resources, to product instead of by project, may mean an organizational change is warranted, which again can be culturally difficult to accomplish.
And lastly, follow the money. Is your organization willing to make decisions without full knowledge of cost and delivery date (many would argue that we never had this and that we were just kidding ourselves in Waterfall)? Daugherty believes that some upfront work is necessary, that a level of scoping and overarching requirements should be rapidly gathered and allow for the final feedback driven scope to emerge. Emergent architecture and emergent standards should be avoided where possible. Agile works best when Architecture and Security are provided as up front guidance, followed by just-enough governance, to business and construction teams.
We, ourselves, run an agile shop in our Dev Centers and have several scrum masters and certified SAFe experts across our team. We’re helping clients through agile workshops and coaching, Rapid Process Mapping techniques (the quickest, most accurate method of getting 80% requirements), bringing Agile programs to scale, and even Bi-Modal IT and Application Pace Layering. Let us know when you’re ready to talk agile. Team Daugherty is ready to help you.