Organisations want to be Agile; they need to innovate, delight customers and exploit opportunities. Agile is a strategic response to the many risks of developing software as well as the competing needs of diverse stakeholders such as compliance, accountability, usability and finance.
Agile is a Framework not a Fix
However, the uncomfortable reality for many large and medium-sized organisations is that their management and operational practices frustrate the adoption of Agile. The obstacles most-often encountered include:
- Traditional reporting measures and tight controls prevent self-organisation
- Silo culture stands in the way of trust and respect
- Communication remains poor
- Everyone feels ‘they just throw stuff over the wall at us’
- There are sabotage attempts
- Technical and architectural expertise is missing
- Changes and features are taking too long to appear
- People are frustrated and good staff are leaving
Agile Done Well
Agile adoption can be very successful and straight-forward as Transport for London proved when they expanded their TfL Oyster Card onto National Rail in just 9 months. For that project, a small, co-located team, 100% dedicated to making the project work, had the active support of management and stakeholders.
Following the success of that first project, TfL’s Director of Customer Experience, Shashi Verma embarked on a highly ambitious Contactless payment system. Although costing £75m and facing innumerable stakeholder challenges, the project’s technical and methodological risks were addressed in a matter of just a few weeks. TfL’s Contactless payment card system went live in London in September 2014 and is expected to save taxpayer’s £20m per year. TfL Agile adoptions compared.
Small Steps, Big Changes
Agile projects are characterised by:
- Early and frequent delivery of valuable output
- Working to clear customer-led objectives
- Developing joined-up teams
- Personal development
- Continuously improving the process itself
Agile is Fragile
Success stories such as TfL’s may suggest that Agile itself solves problems, but that’s not the case. If anything, Agile will bring problems and failures very quickly to the surface. (Agilists argue that this is a good thing as it allows sponsors to end failing projects sooner.)
Whilst the small, dedicated and co-located team of the Oyster Expansion project above was able and willing to ‘do whatever it takes’ to succeed, the same was not true of the Contactless project, which had many detractors and opponents. Contactless owes much of its success to enlightened leadership by senior management who built on successes, gaining trust and respect with every milestone reached.
The Transition to Agile Must be Agile
Agile methods depend on team values such as trust, honesty, courage and respect. These emerge over time and not on-demand. Unless people genuinely feel that it’s OK to make a mistake or to learn through failure, then no amount of labels or ceremonies will make that team Agile.
Organisational agility is rare outside of IT development and it can be very challenging for agile team members to interact with their non-agile colleagues and vice-versa. This is where management guidance is needed, but who guides the managers? Certainly not the Agile methodologies themselves, which espouse self-organisation (within the team and assume stakeholders are aligned and available to support the project externally).
Agile managers need to develop leadership and management competencies that help move the organisation towards Agility by appropriately supporting the business.
Understanding Agile, Scrum and Lean and then actually getting the team started on their first sprint usually takes no more than a week. Unless your organisation is able to ‘pivot’ (and if more than 10 people are involved it can’t) then Agile adoption is going to be more like a journey than a magical conversion.
Storm Delivers Value in Three Competency Areas
Success depends on improving three areas so each competency supports its project role:
We work with your team to develop their expertise in each of these competencies. That’s what we did for TfL and it worked for them.
An Assisted Journey
People who have been working in a ‘command and control’ hierarchy tell us that they don’t feel comfortable when told to be ‘open and honest’. They recognise that trust is vital in agile and so they lose confidence in the change process. Talking helps of course, as does getting used to the idea and process of change itself.
We coach, do, train, explain, support, fill-in the blanks and ensure your project succeeds – no matter what it takes.
You expect your football team to have a coach, so get a coach for your professional team too.
Agile, Scrum, XP and Lean – What’s the Difference?
Agile refers to the Agile Manifesto of 2001 in which 17 developers set out the 4 values and 12 principles of software development. Many Agile practices support the manifesto, including Jeff Sutherland and Ken Schwaber who formalised Scrum, and Kent Beck whose classic XP book provides the source reference for the terms values, principles and practices.
Agile’s roots are intertwined with Lean manufacturing practices such as Just In Time and Total Quality Management developed by Taiichi Ohno and his colleagues at Toyota. Read the original article here.