When a CIO, development manager, or a team decides to ‘go agile’, what does this mean for other colleagues that work with this team? What does it mean to Product Managers that are responsible for developing business cases and delivering product requirements? What happens if there are technical teams that are on the periphery of the core software development group such as QA teams, operations, offshore teams, or shared services? What about enterprise architecture teams that set standards; how do you handle conflicts with the technology and process choices selected by your self organizing agile team? How does an agile delivery affect the strategic and product planning process?Small teams and startups in particular don’t have to address these questions. But larger organizations looking to move to agile delivery models have to consider some of these questions. I recall one ScrumMaster that initially frowned at me when I suggested we could follow agile methods for planning iterations, but eventually we would need to put a forecast on feature delivery for several months (and many iterations) into the future. “That’s not agile” was a response I got initially and it required some dialog to convince him that agile in the enterprise required this type of planning.

These questions don’t need to be answered all at once. In a true agile approach, leadership can look at these and other questions and prioritize based on needs. But larger organizations should consider developing a team and process that focuses on these questions.