Talks about partial successes with Agile implementations. We have become iterative for sure and there is a definite sense of cadence. But concept to cash lead times are still quite high. A sense of dogma has crept in the rituals, they happen, but there is little soul.Team members are still quite stressed out; We have avoided the famous waterfall death march for sure but it is still a very tiring and painful long march. Organisations doesn't feel that they have reaped all the benefits which were promised. There is just a handful of companies who seem to be living the values and are really nimble in the market place. What went wrong?

1. Text
Becoming Agile
Get back to first principles first
Presentation Outline Only - NOT the actual content

2. Outline structure of the session
What went
wrong?
What about
people?
What about
value?
What about
flow?
What about
quality?
Becoming Agile

3. What went
wrong?

4. Talks about partial successes with Agile implementations. We have become iterative for sure and
there is a definite sense of cadence. But concept to cash lead times are still quite high. A sense
of dogma has crept in the rituals, they happen, but there is little soul.Team members are still quite
stressed out; We have avoided the famous waterfall death march for sure but it is still a very tiring
and painful long march. Organisations doesn't feel that they have reaped all the benefits which
were promised. There is just a handful of companies who seem to be living the values and are
really nimble in the market place. What went wrong?
Our focus on people, value, flow and quality instead of process,tools, cost, schedule and scope,
got the attention but did not get internalised by all. So while we are adopting “Agile” methods we
have not become “agile” yet.
There is a need to get back to first principals. There is a need to explain knowledge workers on
the ground “Why” the principals work. Leaders need to do more than just support the change,
they need to know, behave and do the right things. Lastly people do need to learn and love their
craft. Yes, it is about money but is it also about autonomy, mastery and purpose.
The session takes through key concepts around people, business value, product development
flow and quality via fast feedback, and invokes people to understand and let their team
understand the basic principals first to lay a strong foundation, before building an Agile
enterprise on top of it. It is only then the “real transformation” happens and the products get in
front of the end users faster.

5. What about
people?
Teams
Motivation
Leadership
Communication,
Collaboration &
Communication

6. Teams
Building a high performance team
Hundreds of books have been written on team-working; team-building
courses are perennially popular, and every CV insists the applicant is a
'team player'. Team is obviously an important concept for modern
business, but most individuals will have experienced the frustrations of
non-working teams as well as the special magic of teams that work as
more than the sum of their parts.

7. Motivation
Doing more, and having more fun doing it
A motivated team or company is not only fun to work in, it increases
growth, profitability and reduces staff turnover costs. Yet despite
maintaining expensive motivation programmes, most companies
motivate their staff in ways that are inefficient or have unintended
consequences. Challenging a system engrained in corporate culture
can prove difficult, but this session provides a compelling argument,
supported by meticulous research, to reconsider the way we motivate
our teams and our people

8. Communication, Collaboration &
Coordination
A project is more likely to fail because of problems with communication
than through technical difficulty. A failure to collaborate can destroy
employee motivation and erode the competitive edge, while
coordination errors result in staggering levels of waste. In short, these
three fundamentals of human interaction are more essential than any
other skill to the success of your project and organisation. As
philosophies, Agile and Lean have placed enormous emphasis upon all
three. Yet few companies make any formal or sustained attempt to
improve them as part of their end-to-end innovation and delivery
processes.

9. What about
value?
Understanding your
customer
Prioritisation
Delivering value early & often
Trade-offs

10. Understanding your customer
Create lasting value - focus on customers
The Agile manifesto opens with the statement, 'our
highest priority is to satisfy the customer'. Everyone
knows that the customer is important, right? And yet
there are many organisations that have failed because
they have lost sight of the customer's needs. It's not
always easy, but knowing how to give your customers
what they want when they may not even know
themselves is what successful innovation is all about.

11. Prioritisation
The problem isn't having good ideas - it's deciding which ones to do
Wherever resource is constrained - time, money, people - choices have
to be made about which project, feature or requirement we will focus
on first, or whether to do them at all. How we make that choice is not
always simple because value can mean different things to different
people. Is the decision based on revenue, time-sensitivity, risk, cost or
a combination of them all? Investing your resource in the right projects
and even ordering what you deliver within those projects can have a
radical impact on profitability. Indeed, it can mean the difference
between success and failure.

12. Delivering value early & often
The compelling case for early delivery of value
Delivering early and often has major financial benefits by
releasing value early. It also helps with marketing,
incorporating customer feedback earlier to improve
flexibility and with engineering, because lowering technical
complexity is often a requirement of incremental delivery
and short launch cycles help advance quality. There is also
a real and measurable affect on team motivation, joint
learning and performance, as teams focus on seeing their
work go live.

13. Trade-offs
If you can't have everything, what do you need
Trade-offs are essential within any project or organisation - cost,
speed, risk and flexibility among others. Yet decreasing cycle time
actually helps with most of these, by shortening the feedback cycle.
Previous sessions provide an in-depth exploration of the tools which
help to decrease cycle time. This highly-practical session examines the
combinations in which the tools should be used to optimise flow
depending upon the trade-offs that best suit your organisation. It also
explores concurrent engineering, overlapping activities so as to reduce
cycle time, discussing the benefits and risks and how to manage the
team's external dependencies.

14. What about flow?
Requirements
Optimising flow
Attacking your queues
Batch size matters
Work in progress

15. Are requirements the problem?
When projects fail, poor requirements are cited as the problem a third
of the time. No wonder writing and managing requirements is such a
hot topic in delivering projects. But, are the requirements really the
problem? Ultimately the requirements are a way of communicating
ideas and coming up with a shared understanding of ways to meet
customer needs and wants, but they so often become an immovable
contract that leads to many unhappy parties. Agile methods have
introduced the idea of much shorter feedback loops and the ability to
change based on evidence and learning from interacting with users
much more frequently. So, we now need to look harder at how we
express and communicate customer needs and develop the most
valuable solutions we can.

16. Optimising Flow
Optimising flow – finding the best way for your organisation to deliver
The fable of the tortoise and the hare is a story of slow and steady versus
fast but flaky. It’s a story with parallels to software development. Moving
fast means more time in market and more awareness, while an
organisation’s agility or nimbleness makes it easier to respond to
opportunities or threats. Speed and first-to-market also have associated
costs and risks. Deciding how to travel depends on the organisation’s
goal, but in general most organisations want to move faster. Despite
striving towards this, few organisations deliver software and IT projects as
fast as they, or as their customers, would like. Instead they are wedded
to a measure called ‘on time’ delivery, which has unintended results -
often making them slower and less flexible.

17. Attacking your queues
Battling the enemy of flow to reduce cycle time
Most work - whether a task or a vast project - spends most time not in
activity, but sitting waiting for someone to do it - in a queue. Because
work in software development is normally intangible information, it is
easy not to manage these queues and instead to let them build up.
This session examines the nature of queues - the reason they form,
why long queues get longer and why they cause so much damage.
Especially revealing is the link between capacity utilisation and cycle
time.

18. Batch size matters
For better flow, batch size matters
A batch is a quantity of work for or from a single operation, and since
the rise of industrialism, we have trained ourselves to work with large
batches because of perceived efficiencies. Waterfall development, big-
bang launches, project approval gates ! these are all examples of
processes that lead to large batches. This session considers the high
price we pay for these supposed efficiencies - increased risk, value
tied-up and lengthy cycle times.

19. Work in progress
Do less to do more, the beautiful paradox of WIP
Work-in-progress constraints are the heart of the Kanban methodology
gaining popularity in some organisations. Understanding why WIP
constraints work and their effects on work flow, queues and delivery
are essential for anyone considering adopting 'pull' practices. The
session explains the principles of visualising work, signalling, self-
management and matching work to capacity. As well as advising of
differing ways of limiting WIP, the session examines potential problems
and the likely pitfalls and errors - signs that system is not working for
your organisation.

20. What about
quality?
Feedback

21. Feedback
The route to learning
Customers don't know what they want, developers don't know how to
build it, and things change! Painful as those problems may be, they are
common, in fact, inevitable. Feedback is the only solution. It is not a
perfect solution, and interpreting feedback may not always be simple,
but it is essential - the only way that we can adapt and learn.

22. Becoming Agile
When it comes to Agile
implementations, at one extreme you
find people who want a checklist of
rules; at the other, people adopt the
label ‘Agile’ without changing anything
at all. Both attitudes are liable to end
up in the same place – frustration. One
of the approaches that work:
Get back to first principles
Right application of Lean & Agile -
Scrum, Kanban, XP etc.
Scale across the enterprise using SAFe
etc.