Harnessing the complex with Agile - SNC-Lavalin/media/Files/S/SNC... · Agile approaches seek to...

16
Harnessing the complex with Agile Author Symon Cusack Agile Technical Director August 2018

Transcript of Harnessing the complex with Agile - SNC-Lavalin/media/Files/S/SNC... · Agile approaches seek to...

Harnessing the complex with AgileAuthorSymon CusackAgile Technical Director

August 2018

About usSNC-Lavalin’s Atkins business is one of the world’s most respected design, engineering and project management consultancies. Together, SNC-Lavalin, a global fully integrated professional services and project management company, and Atkins help our clients plan, design and enable major capital projects, and provide expert consultancy that covers the full lifecycle of projects.

3

www.atkinsglobal.com/MC

The Industrial Age introduced manufacturing techniques and approaches that enabled us to accurately predict and ‘productionise’ construction processes. We could plan complicated things in the physical world and accurately predict the outcome, even if the solution was intricate and complicated, because the pace of change did not outstrip the production lead-time. It therefore made sense to control and tightly manage any ‘off-specification’ items and adopt top-down management approaches based on philosophies such as Taylorism, which seeks to maximise efficiency and productivity.

The modern world is going through the next Industrial Revolution as it establishes the Digital Age and what is often termed ‘Industry 4.0’.

What do we mean by complex?

Symon Cusack, Agile Technical Director at SNC-Lavalin’s Atkins business, describes how he is helping clients adopt Agile approaches and meet the challenges of doing business in an ever more complex and volatile world where change is the norm.

This is a world where data is king and customers can be fickle. The validity of a product or solution could hinge on a favourable re-tweet or the competition getting to market quicker. The ‘bad guys’ are taking advantage of the pace of change, becoming faceless shadows that quickly adapt and re-organise – largely in cyberspace – and there is the ever-present threat of cyber-attack. We need approaches that deal with ambiguity and quickly reduce this ‘Cone of Uncertainty’.

Increasingly, we have to deal with at least some degree of uncertainty and unpredictability with both requirements and solution. At the extreme end of the spectrum, we have to test our hypotheses quickly and cheaply using techniques pioneered by people such as Eric Ries in The Lean Startup.

Introduction

Customer Feedback

Release

Value

Requirements

Development

Test

Harnessing the complex with Agile

4

www.atkinsglobal.com/MC

Organisations are rapidly seeing their projects shift from the ‘complicated’ to the ‘complex’ space and are finding the old ways of trying to predict plans and control change no longer work. This is because the pace at which requirements can change, or with which new requirements emerge, can often be greater

‘Waterfall’ approaches typically try to predict and fix scope within cost and time parameters and tend to have the following attributes:

› Big design upfront effort

› Change discouraged and tightly controlled

› Success largely measured by adherence to a plan and success evaluated at the end

› Quality parameters assessed around lifecyle gates

than the project’s change control mechanisms can cope with. In this brave new world anything that doesn’t deliver value to the customer within a month is in danger of failing, and we need very short cycles of the ‘Waterfalls’ that used to take months or years to deliver value that was out of date as soon as it’s released.

• Tend to simplify the question/area of research• Early and often feedback• Fail fast• Learning is key• Minimal process / formality• Novelty / innovation• Emergent requirements

• Responding to feedback• Iterative / incremental delivery• Some process / governance• Requirements understood at high level, fluid at the lower level

• Done before• Sense and categorise problem• Standard, repeatable solutions

• Done similar before• Tight governance and change control of resources and delivery• Able to analyse solution and plan with reasonable certainty based on largely understood requirements

Anarchy

Complex

Complicated

Far from agreement

Far from certainty

Close to agreement

Close to certainty

REQ

UIR

EMEN

TS

SOLUTION

Simple

Test

Deployment

Requirements

Design

Build

An interpretation of the Stacy Complexity Model.

5

www.atkinsglobal.com/MC

world. This is because speed and flexibility are vital. That is, responding to change over sticking to an upfront plan, getting the customer as close to the team as possible, and getting value from regular releases of products or services that customers can start to use as soon as possible. Above all, changing the paradigm by giving autonomy and choice to those doing the work and asking that leaders concentrate on how they can help and align priorities, rather than control and lock down the solution. This culture and mindset, the small ‘a’ agility, is something all organisations must strive to instil, regardless of the nature of their work.

In essence, if you can deliver a project in incremental steps then you should do so because the customer can start using it, or at least keep giving you invaluable feedback.

What is Agile? The dictionary defines agility as ‘the ability to move quickly and easily’. No organisation or business would say they don’t want this attribute. Agile with a capital ‘A’ is often associated with the process frameworks that have come out of the software industry, for example ‘Scrum’. ‘Lean’ manufacturing techniques, born out of the rapid growth of the post-war Japanese car industry, underpins Agile and helps to achieve the optimum flow of work from scarce resources.

The software industry published the Agile Manifesto and principles in 2001 when its leaders met to try to understand why so many software projects were failing. These texts have not altered much, if at all, since then. Apart from changing ‘software’ to ‘solution’ they hold true for any type of delivery in this new, ‘complex’

Agile approaches seek to deliver on time, based on known and stable costs, allowing scope to flex. This does not mean that the amount of scope that can be delivered in a given period is not predictable just that its nature may change. The Agile approach can be summarized as follows:

› Enough design up front to get going › Embraces change › Success measured by working solutions

and customer satisfaction › Quality is good enough to meet

customer expectations › Continuous review of viability

and direction › Focuses on team empowerment

and enablementPrioritised

Backing

LEARN

Build& Test

Design

Plan

Deploy LEARN

Build& Test

Design

Plan

Deploy LEARN

Build& Test

Design

Plan

Deploy LEARN

1

2

3

4

5

6

7

8

...

Harnessing the complex with Agile

Is Agile the new norm? The small ‘a’ mindset of being able to respond to change through empowered teams working closely with their customers to deliver early and often should now be at the forefront of most organisations’ strategy, and permeating their culture. Many commentators, including the main project management professional bodies, admit that almost all delivery portfolios already contain a significant proportion of work that is, or should be, delivered using Agile approaches and a failure to adopt the right approach is impacting successful outcomes.

Effectively, all delivery is on a Waterfall cycle that is, to some extent, dictated by the nature of what is being delivered. The trick, however, is to reduce the delivery cycles down to the minimum possible, and using lean principles, ideally a batch size of one, that is available to the customer as and when it has been produced. Anyone who has played the ‘coin game’ simulation* will understand the overhead that batching work adds to

any production process. Where delivery components are working on different cycles the trick is to choreograph the integration points as often as possible, all the time reducing the elapsed time of the ‘Plan, Do, Study, Act’ cycle, based on a clear and mature understanding of what ‘done’ means across the production and delivery process or ‘Value Stream’.

With larger deliveries there is added complexity when the different capabilities are adopting varied delivery methodology (across the spectrum of obvious, complicated, complex and anarchic). This adds to the complexity as we have to establish a coherent approach to coordinate delivery dependencies, along with deciding what capital ‘A’ Agile processes and frameworks we should use for the Agile element. In summary we should be seeking very short Waterfall cycles – a cycle based on a solution that can be delivered incrementally and easily integrated into the whole.

Harnessing the complex with Agile

�Learn Identify

EnvisionChange is Embed

DesignDeliver

As an enhanced version of the PDSA cycle, the IEDDEL wheel, developed by Atkins EY, ensures there is a vision or visualisation upfront and the embedded change.

6

www.atkinsglobal.com/MC

*https://www.youtube.com/watch?v=fh4nkQnWL6I

7

www.atkinsglobal.com/MC

For example, it still seems to make sense that physical construction of the built environment is planned sequentially. For instance, you need to rivet the right components of a ship in the right order. However, if the planned role of the ship changes during the process, and its systems are being developed in different cycles, the basic platform can be adapted to meet the changing requirements during construction. So even in the built environment, we can adopt Agile approaches to design using visualisation systems such as

Atkins was recently involved in a successful construction project applying a Lean and Agile approach to Bergen Art and Design School in Norway.https://www.youtube.com/watch?v=GyL11KJDB2k

Inception

Waterfall (>1 month release cycle)

Agile sprint based with initial backlog identifies in inception

Kanban based pull model

Continuous Integration and release

Lean Startup

Inception

Design

Design Build Test Design Build Test Design Build Test

Construct

Construct

Test Release

Inception Release

Inception

Available to release

Available to release

Technical Feasibility

Construct

Released

Release

Build

Measure

Actionable metrics

MVPHypotheses to be validated

Persevere, Pivot or Stop

Ideas

Learn

Delivery ‘patterns’ – effectively

different cadences of design, build,

test, deploy.

‘Building Information Management’, to prototype early and design just enough upfront. The build itself is largely sequential but the construction industry increasingly leaves the planning of detailed interiors as late as possible because the customer could change their mind and usage patterns will emerge once the space can be experienced. Atkins was recently involved in a successful construction project applying a Lean and Agile approach to Bergen Art and Design School in Norway.

Rarely can we divorce the digital aspects from the built elements. The SpaceX rocket programme used Agile approaches in developing both systems and hardware, and in four years went from prototype to landing a reusable launch vehicle. Incremental funding was provided based on results and it built many prototypes that scaled up the solution, learning each time from failures and successes. Technologies such as 3D printing enabled the company to quickly evolve and build new components.

Harnessing the complex with AgileHarnessing the complex with Agile

“Organisations are rapidly seeing their projects shift from the ‘complicated’ to the ‘complex’ space and are finding the old ways of trying to predict plans and control change are no longer fit for purpose.”

8

www.atkinsglobal.com/MC

9

www.atkinsglobal.com/MC

The new emphasis is on teams and unlocking the potential of human resources. Peter Drucker points out that ‘knowledge workers are individuals who know more about the work that they perform than their bosses’. In this context, ‘how can any manager seriously attempt to oversee or even coordinate the technical activities of people who are infinitely more capable than they are of defining the tasks necessary to accomplish their mission?’. Daniel Pink’s social experiments show that given an acceptable level of wages and reward, what really unlocks workers’ potential is to have a clear purpose and understand how they contribute to the bigger picture. Secondly, be able to pursue mastery of their chosen profession in the same way the Gothic stonemasons did in the past. And finally, to be given the necessary empowerment and autonomy to come up with solutions based on clearly defined outcomes.

The Taylorism legacy is at odds with this concept as it assumes leaders are the thinkers and creators of ideas for the workers to implement. In some cases, it has contributed to a culture of HiPPOs – Highest Paid Person’s Opinion counts. However, many organisations now seek to recognise and reward key workers to the same level as some executives, and no longer do talented and valuable people get promoted away from ‘doing’ in favour of being a manager in order to progress up the pay scale.

Studies show that team dynamics break down when we include more than eight people, who need to work closely together. We also benefit from taking work to established teams rather than assemble teams around the work. These teams should contain all the skills necessary to deliver working solutions as often as possible without outside dependencies and handoffs. This approach is not without its challenges. For instance, how do we manage scarce specialists; how do we scale and coordinate across a team-of-teams on a larger project and ensure we don’t isolate specialists? Increasingly, we are now looking for ‘T’ or even ‘E’ shaped people. These people have one or more deep specialism but can also help the team out if they are short in other areas. An example could be a software developer

who is also prepared to do testing work or architectural design. SpaceX has taken this concept further and many of the company’s teams contain physical engineers who can also do software engineering to design and produce electrotechnical components in a short time. This has been a significant factor in being able to enter and undercut the satellite relaunch market in less than four years.

Increasingly, organisations are identifying the value and transparency that the Product Owner model, advocated by Agile methodologies, can bring in terms of clear prioritisation and voice of the customer. The rise of the ‘scrum master’ has also been exponential as organisations seek ‘servant leaders’ who can help facilitate teams and instil Agile and Scrum values.

Agile ways of working challenge traditional project management methodologies and roles. Agile seeks bottom-up enablement and empowerment, with decisions being made at the lowest applicable level based on clearly defined objectives on which everyone is aligned, but not seeking to identify and drive solutions top-down. Moving away from an autocratic top down “command and control” culture can prove challenging for established project management professionals as it calls for servant leaders who can support and enable teams to be successful in a culture of openness, transparency and learning.

The rise of the knowledge worker

Harnessing the complex with Agile

10

www.atkinsglobal.com/MC

Spoiled for Choice There is an ever-growing body of methodologies, approaches and tools in the Agile space. These new approaches are often based on similar themes and principles but selecting the right approach adds to complexity, and the team, programme and organisation need to decide whether to mix and match best practice across methods or choose to align their approach to a single framework. Another challenge is how to manage and govern mixed or hybrid delivery containing both Agile and more traditional approaches.

Choosing the right delivery approach should not be based on the latest trend or because there are problems with the existing approach. Instead, it should involve an objective analysis of the inherent nature of each capability that is being delivered. We need to ask some key questions around the predictability of the requirements and solution, along with the likely complexity.

What the Agile community does agree on is the use of ‘scrum’ and ‘kanban’ at the team level, and all frameworks subscribe to the Agile manifesto and principles, or an interpretation of them. When it comes to scaling Agile, preserving these principles comes under strain, in particular:

› Which scaling approach(s) to adopt › Incorporating hybrid delivery models › Poor or inconsistent understanding

and adoption of Agile at a team level › Legacy enterprise governance and

funding processes › Cultural change associated with

incremental delivery › Supplier contract models › Senior leadership awareness and support › Delivery management community

feeling threatened › Adoption of Agile tools

Portfolio

Programme

Project

Team

Good Delivery Practices mainly derived from IT industry

Managementof Portfolios

(MOP)Large Scale

Scrum (LeSS) Huge

Large Scale Scrum (LeSS)

Disciplined Agile

Delivery (DAD)

DSDM Agile

PF

Non Agile(just for

comparison)

ManagingSuccessful

Programmes(MSP)

PRINCE 2

Scrum Ban

Crys

tal m

etho

dolo

gies

Scal

ed A

gile

Fra

mew

ork

(SAF

e)

Scru

m N

exus

Agile

BA

Agile

Dig

ital

Serv

ices

(GD

S)

Kanb

an Scru

m @

Scal

e

PRINCE 2 Agile

Agile PgM

Agile PM

Scrum

e.g. Test Driven Development, Behaviour Driven Development, Continuous Integration, DevOps, Lean Manufacturing

Lean

Sta

rtup

Leading delivery methodologies at all levels of the organisation.

11

www.atkinsglobal.com/MC

Critically, all methodologies agree on the need to support successful Agile delivery with the associated cultural change. There are two main aspects to business change associated with Agile. Firstly, there is the cultural change needed to adopt and accept Agile delivery models, for instance working with partially completed emergent solutions, embracing the concept of failing fast to harvest the lessons and knowledge that can be gained. Secondly, there is the benefit of feeding a new solution into the user community in manageable instalments and ensuring early benefit realisation. We do, however, need to watch out for the new phenomenon of change fatigue, which regular delivery can inflict on the user.

Business change professionals will need to adapt their tool kits and approaches with bodies such as Prosci leading the way, and we now need to incorporate business change into our definition of ‘ready to start’ work on and really completed or ‘done done’ in Agile parlance.

Product vs project The Agile body of knowledge contains elements of the ‘systems thinking’ movement, in particular it asks us to understand how the solution we are developing works within the organisations end-to-end value stream, and also understand the value stream used to develop and deploy the solution. Many of the methodologies don’t recognise the concept of a project as we know it, and favour the concept of an organisation having semi-perpetual value streams into which we drop requirements for new features alongside the work needed to keep the solution up and running. As such, there is no clear beginning and end and we don’t need to assemble teams around a solution but invest in stable teams that know and support the semi-perpetual value stream.

The new features that we introduce into these streams are mini projects in their own right, based on mini business cases. They can be traded based on changing business need and continually assessed to see if we are receiving enough value to stop developing them further.

In this world of value streams the concept of annual budget rounds, based on agreed milestone deliveries, is breaking down. It’s now a question of can we afford to increase the dedicated resource pool so they can pull more work through their value stream.

This thinking gives rise to the role of the Product Owner, who appears to be similar, for instance, to the PRINCE2 Senior User. In actuality, this role is not the temporary construct of a project team and exists to see the solution from inception through to sunset (even if it’s not the same person over time). This person provides a single voice to the delivery teams taking away all noise, politics and ambiguity. We often struggle to find this superhero who knows the market, the technical solution and can be a business analyst, systems engineer etc. all in one. In reality, we need people who can make balanced business decisions based on good, but not always complete information, working with other professionals to capture and prioritise requirements.So, what of the Project Manager in this new

11

www.atkinsglobal.com/MC

Harnessing the complex with Agile

12

www.atkinsglobal.com/MC

So, what of the Project Manager in this new world? Scrum, in particular, talks about needing only three roles:1. The Product Owner who owns the money

and the solution and who is empowered to prioritise and sign off the work

2. The empowered and trusted team members who produce the solution

3. The Scrum Master who helps the team adhere to scrum principles and get better at doing Agile

This is all very well if you have an environment that is fully applying Agile principles and practice along with a solution that suits this way of working. In reality, we often have a combination of hybrid approaches, different levels of Agile maturity, challenging sponsors and demanding funding bodies, all coupled with significant risks and issues outside those which Agile seeks to mitigate. If we have a Project Manager however, we now need them to move from a top-down “Command and Control” mindset to that of an enabler and facilitator: the ‘Servant Leader’.

A number of the Agile approaches lack detail on how you get started, including getting the right roles and team structure in place, an initial backlog of requirements. Even if you are putting a smallish change into an existing value stream there is a place for a risk- based lifecycle such as that advocated by the Agile Business Consortium, which incidentally, can dovetail into approaches such as the Government Digital Services (GDS) standard.

It’s all an excuse to bypass sound controls!Poor or lazy adoption of agile has caused some leaders to question its ability to deliver the heralded benefits. Like anything worth doing, it’s often easy to understand and start but hard to master. It does, however, give jaded and downtrodden delivery teams a temporary place to hide from what can often be a world of stifling change control, vanity metrics and fortune-telling delivery plans.

‘Governance’ in this complex environment needs a new perspective. The right questions to ask include: › Are we doing the right thing? › Are we doing things right? › Can we prove it?

Governance approaches should be mindful of: › Not slowing down delivery › Ensuring decisions are made when needed

at the right level › Including the right people (open, honest,

capable, focused) › Going and seeing for yourself rather than

waiting for an out of date and diluted report › Only doing it if it adds value › Trust and verify – checking little and often

We want to promote a culture of openness and transparency, where we collectively identify and solve problems. We need information and metrics that support and promote learning that leads to improvement in delivery, based on real-time information. We also want to enhance the ability to change, reducing any bureaucracy and delay associated with decision making and change control. The days of the monthly Project Board meeting are numbered.

The only real value in reporting the past is to learn and get better. We need to accept reality warts-and-all in a no-blame culture. The assumption must be that everyone is doing their best, given the tools and information available to them, so we need to be open and supportive of issues, and roll up our sleeves to help solve problems. Most importantly, we need to recognise and celebrate success.

It’s a fallacy that we don’t plan in Agile. Good Agile teams do as much, if not more planning, than Waterfall teams. We do, however, need to remain true to lean principles by not wasting effort planning something in detail too far into the future. We need to put the right amount of effort into each horizon, such that the next sprint is a detailed commitment, the next planning increment broadly understood and the longer term is an indicative view. The practice of estimating and subsequently re-baselining missed milestones in a world of incremental delivery is counterintuitive.

13

www.atkinsglobal.com/MC

The concept of the regular heartbeat that sprinting instils can also apply to planning horizons. Regular planning events for a batch of sprints can get teams of teams, both Agile and hybrid, aligned and synchronised at the right level but still leave flexibility to plan in detail and adjust at individual team level.

Delivering incremental solutions in slices means we don’t want to hang our hat on a binary delivery milestone, instead we want to understand the current scope of a feature and how fast we are burning through work to estimate when it might be ‘minimum viable’ and, therefore, tradable against a new feature.

“The types of metrics that we value also change in this Agile world. We focus on the health and morale of our most valuable asset – those delivering the solution. We want to understand and help teams deliver more often and gauge satisfaction levels from the customer. ”

What, Who, Why When,Constraints, Assumptions

Interaction, Team Capacity, Stories, Priority, Size, Estimates, Definition of Done

Stories – Definition of Done, Level-of-Effort, Commitment

1. What did I do yesterday?2. What will I do today?3. What is blocking me?

Release – Date, Theme/Feature Set, Objective Development Approach

Product Vision

Product Roadmap

Release Planning

Iteration Planning

Daily Planning

The five levels of planning in Agile.

The market for Agile work management tools is competitive and broadly differentiated by legacy tools that have been developed to encompass Agile and those that are purpose built. The holy grail is finding a tool that effectively supports the range of delivery approaches. Data integrity is key and the only real-time way of ensuring that is by embedding tooling into everyone’s everyday process. Updating an actual work item in the backlog is much better than filling in a time sheet.

Delivery Manager View

ReleasesCapabilities

Features

Customer View

Team Health

Product Ownership

Team Morale

Technical Health

Ability to release

Backlog

21

To Do

6

In Progress

5

Done

1

6 12 7

Ready In Progress Released

1. 2. 3. 4.

Mission Impacts

omer View

Releases

Delivery Manager View

Capabilities

Features Team Health

Custo

Revolution vs Evolution Most of the Agile methodologies advocate an organisational reset of some sort. Ideally, the business needs to stop, re-train, reorganise and get going on the new footing. This obviously plays into the hands of new start-ups but for the established organisation presents a dilemma that usually results in experimental implementation in some business functions. This can lead to sub-optimisation impacting on interfacing business functions.

It can start through sponsorship from senior leaders who are open to new ways of working to meet ever-ambitious corporate goals and objectives, along with delivery teams organically ‘giving it a go’. But members of the “middle” delivery layer are quickly out of their comfort zone and either dig in or leave. To be effective, we need to nurture and support the whole vertical segment of the organisation involved in adopting the new way of working, all the way from – potentially – a separate Agile portfolio, through adaptive roles in the delivery management layer, down to effective teaming strategies for delivery.

Customer collaboration over contract negotiation The third item in the Agile manifesto applies to the relationship between the customer of the people providing the solution, and seeks to build in flexibility in both working agreements and underlying contracts to effectively deal with ambiguity and change.

The idea of an external supplier being defined in a ‘them and us’ way breaks down as we need to extend the same openness, trust and collaboration to everyone who is producing the solution. The type and nature of Agile contracts is evolving rapidly, and contrary to common belief, we can establish a fixed-price based on buying delivery capacity (or velocity) and based on broad outcomes. We can also introduce innovation pots to reward greater output and innovation.

Example Agile Dashboard

14

www.atkinsglobal.com/MC

Harnessing the complex with Agile

15

www.atkinsglobal.com/MC

There is no one template or blueprint for adopting Agile (although the Discipled Agile (DA 2.0) Framework provides a good checklist). Every situation and organisation is different. Some Agile practitioners advocate letting it happen organically through a process of trial and learning but we should perhaps give it a helping hand.

“Essentially, it’s about recalibrating our priorities and placing empowerment and decision making at the lowest possible level, with those who have the most accurate and up to date understanding of their customers’ needs.”

In return, we want those who are trusted to be open and transparent about how and what they’re doing, and what they need to get better. We want to base decisions on empirical and not subjective information.

There are three pillars of empiricism according to Scrum, which when adopted at all levels of the organisation takes us a quantum step forward:

• Transparency – presents the facts as they are (no veneer or smoke-and-mirrors). Have a culture of trust that supports the delivery of bad news as well as good.

• Inspection – ability to look at what is being delivered and how it is being delivered. Teams openly display what they have achieved and are open and flexible in accepting challenge and change

• Adaption – an ability to regularly review, learn and put in place improvements to make things better. A culture where the status quo is never accepted as the norm.

Adopting these values provides a fertile soil for the adoption of agile ways of working and offers a more rewarding, vibrant and energetic culture in which to work.

Agile principles and an open mindset must always apply to some degree if the organisation is to survive in the complex world. Capital ‘A’ Agile frameworks and processes may not always be applicable but in the complex world we need to challenge anything that takes more than a month to deliver value, even if that is giving us valuable feedback that will inform the solution.

The complex world has resulted from advances in technology coupled with a thirst for faster information in greater quantities, which often reduces human interaction. Paradoxically, we need to focus on the human aspects of unlocking knowledge workers’ potential as individuals and collaborating teams to harness this complexity. New Agile delivery processes help but as the Agile manifesto says, ‘Individuals and interactions over tools and processes’.

So, what’s the secret sauce?

About the authorSymon CusackAgile Technical Director

Symon Cusack has been our Agile Technical Director for a number of years now, and has worked with many of our clients across a number of sectors to help them understand and embrace Agile ways of working. He was first involved in Agile some 15 years’ ago working for a large global organisation and, having a background in more established project and programme delivery approaches, can appreciate first-hand the cultural challenges associated with adoption, especially in medium and large organisations including Government. He believes he has the best job in Atkins, especially when attendees of the workshops and coaching sessions he runs suddenly switch on to the potential Agile has for making things so much better.

© Atkins Limited except where stated otherwise.

Harnessing the complex with Agile.www.atkinsglobal.com/MC