Embedding agile in a large global organization
However, it soon became apparent that adopting agile approaches could benefit projects across the organization – not just IT projects. However, due to lack of defined governance, Scrum in isolation did not satisfy their needs.
Working with agileKRC, Mars Inc. adopted a more holistic approach to agile project management, to benefit numerous projects across the organisation. The following presentation discuss the key learnings during the agile journey in Mars Inc. and the intentions for the future.
In this video, Keith Richards, the Founder of agileKRC and Dave Watson, Methodology Expert Centre Leader, Mars Global Services – Service Excellence, discuss the agile transformation taking place at Mars Inc.
In this presentation we cover:
- Agile at Mars: The story so far
- The Agile journey
- What Agile@Mars is
- Agile behaviours
- Agile approaches
- Agile tools & techniques
- Governance & management
- Why agile?
To see a PDF version of the presentation used in this video, click the download button below.
Several questions were left unanswered after the webinar. These are below. Keith’ answers are labelled KR. Dave’s answers are labelled DW
Registration Question results:
How far has your organization gone in its agile transformation?
|Have gone a very long way||10%|
|Have gone quite a long way||26%|
|Have not yet started||19%|
Poll question result:
In your opinion which of these four is the most important?
|Inspect, adapt and learn||18%|
I found this to be known as WaterScrumFall. A common term for this approach of phased delivery trying to embed agile philosophies. What is your view on this?
(KR) I have seen and read a lot about WaterScrumFall and my advice to everyone is to avoid it. Agile is not something you do in the middle – it is something you do throughout.
(DW) I would disagree that this is what we are implementing at Mars. We are allowing Project Managers to make a choice between Waterfall or Agile project delivery approaches. Regardless of which approach they choose, we are also encouraging a steering/governance team (led by a single sponsor) to regularly ask “Is the project currently still on track to deliver the expected benefits?”
Lean has 2 variants – Lean 6-Sigma for production, and Lean development, which Toyota and Honda developed for creating new vehicle designs. Could Mars not use that for the design of new factories & production lines?
(KR) good point I agree with your distinction and I think you would be surprised and amazed at how advanced Mars are at their production side.
(DW) Honestly, in my role I have limited visibility to the factory teams (although I know lean concepts are indeed central to how they operate). Most of the teams I work with are implementing business change to global processes/operations (i.e. Information Technology, Finance, Human Resources, Procurement, Supply, Sales, and Marketing).
Do you have a definition for Scope?
(KR) there are many definitions of scope but my definition and the KRC definition which is predominantly used in the agile context is to refer to requirements, functions and features.
(DW) I would add to Keith’s comments by suggesting that there may be ‘high-level requirements’ (perhaps we call these objectives?), ‘medium-level requirements’, and ‘detailed requirements’ on a single project. Perhaps (and this is only a suggestion), a steering team should approve changes to ‘high-level requirements’, whilst the project team has the autonomy to make changes to ‘medium-level’ and ‘low-level’ requirements.
How did Mars retrospectives happen? What were the meetings like?
(DW) I previously implemented the ‘retrospectives’ technique with an IT development team based in India. This took the form of a virtual meeting (video call). We discussed what went well, potential improvements, and updated our ways-of-working accordingly.
How about remote teams and daily stand ups. If so, did this work well?
(DW) I previously implemented the ‘daily stand-up’ technique with the same (see above) offshore IT development team based in India. We made this ‘work’ by keeping the meeting limited to the offshore team only (i.e. I didn’t ‘dial in’). They shared with each other; what they had worked on yesterday, what they planned to do today, and what risks/issues/blockers they had encountered. Risks/issues/blockers that could not be resolved offshore were escalated to myself (the project manager)
Does this AgilePM approach work for Lean Kanban approaches for continuous change? A continuous improvement approach to improving an existing service or system? How are such long-term change needs governed and managed? I can see how the behaviours, approaches and tools work, but not the governance and management.
(KR) this is a really good question and very current for the present time. The two main observations I would give regarding this question is that firstly you can bring in Lean and Kanban concepts to the delivery layer of a project and it can be extremely beneficial. My second observation would be to assess if the work you are doing is actually a project or not, because many of the Lean/Kanban and continuous change concepts are applicable outside of a project context. Either way, both projects and business-as-usual (BAU) activities need the appropriate governance and management. The golden rule is to run complex pieces of work as projects and the more routine and simple pieces of work as BAU.
(DW) I agree. You certainly don’t need the same type of governance and management for continuous improvement activities as you would for a project (remember a project is unique, complex, and most importantly temporary)
I was wondering about a high-level release plan which contains a number of sprints. Did you have one of these? Or was it ‘here’s our next release let’s start planning’? I think this is important for visibility.
(DW) I have certainly seen projects which utilised development sprints, the outcome of several sprints then forming a release… which continues throughout the fixed timebox of the project. In such a situation, it is of course important to maintain visibility of what is expected to be delivered in the next release (based on current priorities). I wouldn’t call it a ‘fixed-plan’ though.
Have you been able to reduce management costs (Less project managers and delivery managers)?
(DW) Not as far as I am aware. We are encouraging adoption of Agile ways-of-working in order to more often deliver the ‘right thing’ in the ‘right way’ at the ‘right time’. In other words, improve project outcomes. We did not set out with an objective to reduce management costs.
Do you have operations team members embedded in the delivery teams to speed ease delivery of releases into production?
(DW) This is certainly encouraged (we strongly promote the behaviour of not operating in silos)
What process do you see in agile – Scrum, Lean, Kanban etc?
(KR) when I arrived at Mars agile was seen as Scrum and Scrum was seen as agile, but the team in the Expert Centre knew that there was a ‘bigger fish to fry’. To achieve a more powerful use of agile required a more holistic and embracing view of agile. Therefore, it would need to incorporate other concepts such as Lean and Kanban
(DW) We encourage teams to use whatever Agile tools/techniques (i.e. user stories, stand-up meetings) are appropriate for the team in question. We also promote full ‘methods’ such as Scrum and Kanban… although we always try to make it clear that being Agile is about the behaviours (communication, collaboration, inspect/adapt/learn, autonomy) and approaches (being change-friendly, fixing time/cost/quality, working iteratively/incrementally) – not about following a specific ‘method’.
What is your view of DSDM?
(KR) I think it’s great! A lot of what Mars have done is to incorporate good project management practices and blend it with agile…which is what DSDM does. Mars have taken this a step further though.
(DW) I think that if I worked in a software house, I might have been tempted to pick DSDM ‘off the shelf’. We didn’t due to the DSDM language being too IT focused.
If you’re implementing Agile into an organisation that is operating quality gates that push you towards waterfall for governance – what should you do?
(KR) tread very carefully. It is very important for you to realise that quality gates and agile are not mutually exclusive, in fact they are perfect partners. As Dave alluded to during the webinar you just need to check what needs to be checked and quite often it is the same as with a waterfall project – but the secret to success here is knowing what the differences are when you need to apply governance to an agile project.
(DW) The true purpose of ‘stage gates’ is to keep asking questions like: “is the project currently still on track to deliver the expected benefits?”, “is the project delivering to the desired quality?”. I do think it gets tough though when an organisation aligns a ‘stage gate’ process to waterfall phase names. Stage gates should simply be regular (timeboxed?) opportunities to ask the questions that matter.
Is lean agile used for software development projects?
(KR) Yes it is. But I would not restrict this to just software development. Lean can be applied to anything. Ironically, Scrum has come from Lean and as Scrum has evolved it could be said that a lot of the agile movement is now going back to Lean fundamentals.