Lost in Translation
Enterprise Scrum - Tactics for Implementing Agile Practices
If you are implementing agile practices, methodologies and organisational changes within the company without full executive support, you are probably facing an uphill struggle.
I was watching a TV documentary on the space race the other day, and one of the interviewees stated that in today's world nobody takes any real risk... This is fundamentally the problem you face, agile is perceived as high risk and difficult to manage.
From a traditional management perspective, it is!
Agile is about recognising there is a limit to control, that all things are not predictable, and that although we have clear objectives and a general direction, the detail of functionality and architecture is unknown at the beginning of a project. Managers need to learn an empirical approach to work and ensure that feedback loops and frequent communication are embedded within the fabric of the organisation.
So with so much risk... cost, direction, control, design, architecture, functionality... why would any career executive want to take on agile?
One approach is to lose the agile message in translation... Or rather, put the agile philosophy into accepted company lore / language.
If your company has adopted Kaplan & Norton's Balanced Scorecard approach (http://www.bscol.com/), as a vehicle for strategic change programmes then use it for your agile implementations.
If Jones & Womack's lean approach is the driving force within the corporation, then use Mary Poppendieck's Lean Software Development philosophies (http://www.poppendieck.com/) to build lean projects.
I'm Head of Development at an SME where we use the Balanced ScoreCard for strategic implementations and have a "lean" initiative. Although the ideal use of these models could be questioned, I am translating the needs of the development team, into the terms, language and presentation formats that fit the culture, dominant logic, and decision-making processes of the company.
When considering your own corporate environment, what are the key business drivers?
I believe that the true success stories for corporates adopting sustainable, effective agile software development teams will depend on our ability to "manage" or "lead" organisational change.
Understanding and managing the levers of organisational structure, business processes, stakeholder management, decision hierarchies and communication are the key competencies required by people implementing scrum and agile at the enterprise level.
If you are implementing agile practices, methodologies and organisational changes within the company without full executive support, you are probably facing an uphill struggle.
I was watching a TV documentary on the space race the other day, and one of the interviewees stated that in today's world nobody takes any real risk... This is fundamentally the problem you face, agile is perceived as high risk and difficult to manage.
From a traditional management perspective, it is!
Agile is about recognising there is a limit to control, that all things are not predictable, and that although we have clear objectives and a general direction, the detail of functionality and architecture is unknown at the beginning of a project. Managers need to learn an empirical approach to work and ensure that feedback loops and frequent communication are embedded within the fabric of the organisation.
So with so much risk... cost, direction, control, design, architecture, functionality... why would any career executive want to take on agile?
One approach is to lose the agile message in translation... Or rather, put the agile philosophy into accepted company lore / language.
If your company has adopted Kaplan & Norton's Balanced Scorecard approach (http://www.bscol.com/), as a vehicle for strategic change programmes then use it for your agile implementations.
If Jones & Womack's lean approach is the driving force within the corporation, then use Mary Poppendieck's Lean Software Development philosophies (http://www.poppendieck.com/) to build lean projects.
I'm Head of Development at an SME where we use the Balanced ScoreCard for strategic implementations and have a "lean" initiative. Although the ideal use of these models could be questioned, I am translating the needs of the development team, into the terms, language and presentation formats that fit the culture, dominant logic, and decision-making processes of the company.
When considering your own corporate environment, what are the key business drivers?
- Cost cutting and risk reduction?
- Value Creation and Customer focus?
- Quality & Excellence?
I believe that the true success stories for corporates adopting sustainable, effective agile software development teams will depend on our ability to "manage" or "lead" organisational change.
Understanding and managing the levers of organisational structure, business processes, stakeholder management, decision hierarchies and communication are the key competencies required by people implementing scrum and agile at the enterprise level.
Comments
Great blog. It provides a real insight into your "agile" challenges.
One quick question - assuming that the project objectives and its framework are communicated and well understood in advance, it is obvious that an agile run project would provide all the benefits that come with a greater level of transparency and flexibility (for example, better focus on business value, significantly quicker identification of risk, ..etc..) than a more traditionally run project - does this not become its major selling point in any organisation and does this not support organisational "risk aversion"?
Sorry can't help you with your digiserve or automated download software queries... You might find help at blogs.conchango.com They're an IT consultancy with a very good blogging community.
Best Regards,
Steve
Reference your point on selling agile and its transparency and flexibility... I agree that one would expect it to be an easy sell. I think your first assumption is quite a big one, I have rarely seen a cohesive corporate decision making body, and rarely are the objectives of the project understood by all.
Your point is a good one though, agile practices do reduce risk and provide a true indicator of progress on a software development project.
Best Regards,
Steve