Organizations struggle to adopt Agile practices because their cultures do not encourage or support Agile ways of working. Examining the beliefs of leaders and professionals in organizations can reveal insights about the organization's readiness for change. The five beliefs discussed in this presentation help organizations to have an honest, and often revealing, conversation about why they want to become Agile, and how far they are willing to go to adopt Agile principles, practices, and mindsets. By helping organizations understand what they really value, discussions about beliefs can reveal potential barriers to adopting Agile practices and mindsets. Understanding these barriers is essential to overcoming them and achieving the benefits of Agility.

Philips - SW transformation program is involved in the deployment of (Scaled) Agile framework to enable TTM and Quality in Business from the year 2014. We started with Pilots and then followed with Mass deployments. We have:

1. 44 Agile Release Trains launched since Aug 2014 and 220 + PI planning sessions completed.
2. Currently, focusing on System Business with multiple ART’s launched in Systems Business, including 1^st ART launch in Philips –China.
3. 3700+ people engaged in (Scaled) Agile way of working globally and part of ART's and 1300+ are formally certified in Agile and SAFe

We have learned that when engaging, deploying, an important and not-to-be-forgotten first step is to brief Executives and leadership about the approach, changes .This typically takes 4-8 hours, which sounds like a huge investment, but almost always is seen as paying off. Involving Leadership along has been a key element of our Success in our deployment

Throw a purpose in a middle of a crowd, it will start to self-organize. Many self-organised entities like ... villages or cities have an "embedded purpose", not voluntarily shared out-loud or displayed in common places. Villages and cities have growth aligned to their embedded purpose. Acting in a purpose driven way is less obvious for organisations. More a company grows, more dissolved into the Process the original business purpose becomes. This talk presents the 3 stages of Agile Experience Awareness I've seen unfolded and reveals how aligning to a clear shared purpose triggers growth, Agile culture propagation, and scaling becomes a side effect. 

Agile coaching is a booming industry -- but what do companies hope to get out of coaching, and what tangible impact does coaching actually have on a team? What happens when you take an agile coach and force them to "eat their own dog food"? This is what happened to me. Join me in my personal journey of transitioning from an enterprise agile coach to a programmer on a team, and what I learned about agile, coaching, and myself in the process. 

The magic behind the Agile manifesto is in the question they asked. The 17 people assembling in Snowbird spend their time figuring out how they were similar, not what way of working was best. And in the course of those two days, they discovered the deeper truths in what worked.

So what happens when we look what the different Agile Scaling frameworks have in common? A move away from projects towards product development and teams as the fundamental building blocks?

In this talk, we will be exploring how these two shifts impact the way we scale Agile. Looking back on all the Agile Transformations I have done all of them have succeeded (or failed) when we have (not) focussed on these two things.

Don Reinertsen says that if you only quantify one thing, quantify the Cost of Delay. As we’ve talked about before, quantifying Cost of Delay not only helps improve prioritisation, it also help with making trade-off decisions, creates a sense of urgency, and changes the focus of the conversation. Maybe this has got you interested in experimenting with it, but you’re not sure how to get started? If so, this workshop is specifically for you!

When people hear about Cost of Delay they sometimes doubt whether their organisation is ready for it. They say things like, “We don’t have the maturity for it”, or “We couldn’t do that because our stakeholders wouldn’t support it”. We’ve heard people say this too. And yet, in hindsight, people find it much easier than they thought! We will show you how to get started with using Cost of Delay, despite these doubts.

Building blocks

The first essential building block is to understand the value. To help structure the conversation we will use a simple economic framework to surface the assumptions and drive to the economic impacts. The second essential building block is to understand the urgency. For this, we will look at different urgency curves to help us understand how value is likely to decay over time. Combining these two gives us the Cost of Delay helping us to question and better understand what our gut tells us about value and urgency.

Practice makes perfect!

To get going, we will start by looking at some simplified scenarios that help you put what you’ve learned about Cost of Delay into practice. You’ll work at your own pace through some simple exercises that test different aspects of your understanding. To really embed it, once you’re done you’ll get a chance to help others around you – you become the teacher. We will then quickly reflect on what we’ve learned so far.

Then, we’re all going to work on quickly estimating the Cost of Delay for a real life example for a real company. You’ll do this in pairs making assumptions you need to get to a cost of delay for the feature in dollars per week. To help us learn about what the key assumptions were we will compare results across the group to help us understand what the value might be and the areas of greatest uncertainty.

To wrap up we’re going to ask you to do a mini-retrospective about what you’ve learned and what your puzzles are. If we have any time left, we’re happy to help you have a go with a feature or project you are working with.

“If you only quantify one thing, quantify the Cost of Delay” – Don Reinertsen

Everyone seems to talk about Cost of Delay, but few are actually quantifying it. And yet doing so helps us to better manage stakeholders, improve prioritisation and change the focus of the conversation away from cost and dates onto delivering value quickly.

In this talk you will hear about how quantifying Cost of Delay of our ideas helps with:

– Improving prioritisation

– Managing multiple customers

– Trade off decisions across the whole portfolio

This is not a theoretical session, we’ve actually done this in lots of organisations: public and private sector, in large, medium and small organisations as well as using Cost of Delay across a $100m portfolio at a Fortune 500 company.

When people hear about Cost of Delay they sometimes doubt whether their organisation is ready for it. They say things like, “We don’t have the maturity for it”, or “We couldn’t do that because our stakeholders wouldn’t support it”. We’ve heard people say this too. And yet, in hindsight, people find it much easier than they thought!

From this session you will walk away with all the necessary knowledge and practical tips to get started with Cost of Delay and you will have seen lots of actual examples of Cost of Delay calculations from other organisations who have done this. You’ll also hear some interesting before and after results that might help you to make the case in your organisation. In our experience, quantifying Cost of Delay really helps to discover, nurture and speed up the delivery of value.

“#1 trend: HR embraces agile" | HR Trend Institute

"HR drives the agile organization" | HRO Today

---

Agile HR is a hot topic. But what does it really mean: Is it about implementing Scrum in your HR teams? Is it about eliminating annual employee appraisals? Or is it more than that?

Bringing your HR into the 21^st Century with Lean | Agile values, principles, and practices starts by understanding the various aspects of Agile HR.

DevOps practices remove barriers that prevent Agile teams from achieving higher velocity, delivering higher quality products, and reducing technical debt. Not everyone views it this way: some see DevOps supplanting Agile. Yet DevOps needs Agile just as much as Agile needs DevOps: DevOps provides practices that support delivering higher quality products as faster cycles, while Agile practices provide the business engagement model and the teaming model that fosters collaboration and helps organizations "build the right thing", not just "build the thing right".

This is a case study on How we managed our dependencies in SAFe.