Text

Becoming AgileGet back to first principles first

Presentation Outline Only - NOT the actual content

Outline structure of the sessionWhat went

wrong?

What about people?

What about value?

What about flow?

What about quality?

Becoming Agile

What went wrong?

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.

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

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.

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

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.

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

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.

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.

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.

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.

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

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.

Optimising FlowOptimising 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.

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.

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.

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.

What about quality?Feedback

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.

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.