It can be difficult for data professionals to transition into an agile way of thinking and way of working.  A big part of the problem is that the Agile Manifesto doesn’t address the enterprise issues that data professionals deal with on a daily basis.

The Agile Data (AD) method extends the Agile Manifesto.  First, it puts the agile mindset into terms familiar to data professionals.  Second, it extends the manifesto with philosophies that address the key concerns surrounding enterprise data.  In this session Scott Ambler overviews how to bring agile ways of thinking to the data world.

The world moves at a rapid pace, and your organization must be able to respond to changing conditions.  Your DW/BI team is being asked to help end users answer new questions to gain new insights at an increasing pace.  They need to become agile, but are struggling to do so.

In this session Scott Ambler addresses a series of difficult questions that DW/BI must have answers to if they are to learn how to work in a work in an agile manner:

• How can we proceed without modeling everything up front?
• What can we do when our users can’t tell us what data they need?
• How can we easily respond to changing requirements?
• How do we implement “vertical slices” of value?
• It takes weeks to analyze a legacy data source, how does that fit into a two-week sprint?
• How can we realistically deal with the quality problems of all the data sources that we work with, and usually aren’t responsible for?
• Our end users want updates in hours or days, how do we do that in two-week sprints?
• Is it realistic to evolve production data sources?
• How can we deliver new changes quickly into production?
• And more.

Organizations around the world have successfully adopted agile and lean ways of working (WoW) on the DW/BI teams.  You can too.

Data, the way that we process it and store it, is one of many important aspects of software-based solutions. Data is the lifeblood of our organizations, supporting real-time business processes and decision making. It is crucial to the success of software development, and to our organization as a whole, that we apply agile and lean strategies to data-oriented activities. Yet for many organizations their data sources prove to be less than trustworthy and their data-oriented development efforts little more than productivity sinkholes. We can, and must, do better.

This presentation begins with a collection of agile principles for data professionals and of data principles for agile developers - the first step in collaborating more effectively is to understand and appreciate the priorities and strengths of the people that we work with. Our focus is on a collection of practices - the "agile database techniques stack" - that enable you to easily and safely evolve databases. These techniques are vertical slicing, clean architecture and design, agile data modelling, database refactoring, database regression testing, continuous database integration, and configuration management. We call them a technique stack because they build upon each other.

The primary cause of technical debt in your organization is very likely your project managers – not your programmers nor your architects. The management desire to be “on time and on budget” and often motivates deployment of poor-quality assets and rarely leaves room for investment in long-term quality.  Although technical professionals may readily realize this problem managers often do not, or if they do they don’t view technical debt as a priority.  It is time for a change.

In this keynote Scott Ambler explores the root causes of technical debt within organizations, many of which trace back to the project management (PM) mindset and the strategies that result from it. Just like the technical challenges of addressing technical debt must be addressed by technical solutions, the management challenges of technical debt must be addressed by management solutions. Scott works through how to make leadership aware of technical debt and its implications, how to evolve your management practices to avoid and address technical debt, and enterprise-level strategies to embed technical debt thinking and behaviors into your culture.  Results from industry research will be shared throughout.

Data technical debt refers to quality challenges associated with legacy data sources, including both mission-critical sources of record as well as “big data” sources of insight. Data technical debt impedes the ability of your organization to leverage information effectively for better decision making, increases operational costs, and impedes your ability to react to changes in your environment. Bad data is estimated to cost the United States $3 trillion annually alone, yet few organizations have a realistic strategy in place to address data technical debt.

This presentation defines data technical debt is and why it is often a greater issue than classic code-based technical debt. We describe the types of data technical debt, why each is important, and how to measure them.  Most importantly, this presentation works through

Disciplined Agile (DA) strategies for avoiding, removing, and accepting data technical debt. Data is the lifeblood of our organizations, we need to ensure that it is clean if we’re to remain healthy.

2021 marks the 20 anniversary of the Agile Manifesto. Yet many organizations are still struggling to clearly improve value delivery for their customers. In this talk Scott Ambler and Mark Lines explain why agile has struggled in the past and what we can do about it.  Go beyond agile rhetoric, agile methods and frameworks and learn how to optimize agility for your situation, not others. We can do better, and it is not difficult. Disciplined Agile can help. The journey starts with an investment in learning, optimizing for your situation, and then removing obstacles to accelerate delivery and delight your customers.

The Disciplined Agile (DA) toolkit provides straightforward guidance to help organizations choose their way of working (WoW) in a context-sensitive manner, providing a solid foundation for business agility.

DA builds on the existing proven practices from agile methods such as Scrum, Extreme Programming (XP), Lean software development, Unified Process, and Agile Modeling to include other aspects necessary for success in the enterprise. DA fills in the gaps left by mainstream methods by providing guidance on how to enable software development team to choose their WoW, how to address DevOps in an enterprise-class setting, how to apply agile and lean strategies to IT, and how to support business agility within your organization.

Our fundamental advice is to start where you are, do the best that you can given the situation that you face, and always try to get better.

The one-day workshop is not technical and is suitable for all team members. Many group exercises reinforce the principles learned. The workshop is also valuable for management tasked with moving from traditional approaches to agile.

A fundamental philosophy from the early days of Agile, and particularly of XP, is that teams should own their process. Today we would say that they should be allowed, and better yet, enabled, to choose their own way of working (WoW).

This was a powerful vision, but it was quickly abandoned to make way for the Agile certification gold rush. Why do the hard work of learning your craft, of improving your WoW via experimentation and learning, when you can instead become a certified master of an agile method in two days or a program consultant of a scaling framework in four? It sounds great, and certainly is great for anyone collecting the money, but 18 years after the signing of the Agile Manifesto as an industry we’re nowhere near reaching Agile’s promise. Nowhere near it.

We had it right in the very beginning, and the lean community had it right all along – teams need to own their process, they must be enabled to choose their WoW. To do this we need to stop looking for easy answers, we must reject the simplistic solutions that the agile industrial complex wants to sell us, and most importantly recognize that we need #NoFrameworks.

Every organization is struggling with the issue of how to reconcile project management and agility. This is a serious challenge for the project management community who often doesn't understand what agility is, particularly within the context of an established organization. This can also be a serious challenge for agile practitioners who may not appreciate the potential value of management. We need to work together.

Project managers have a lot of important skills and knowledge to bring to an agile team if we help them to do so. At the same time they also have some mindset and cultural issues to overcome, something that they may also need help with. In this workshop we will identify the real value that an existing PM can bring to an agile team and explore how they can move into new agile roles to do so.

A fundamental philosophy from the early days of Agile, and particularly of XP, is that teams should own their process. Today we would say that they should be allowed, and better yet, enabled, to choose their own way of working (WoW).

This was a powerful vision, but it was quickly abandoned to make way for the Agile certification gold rush. Why do the hard work of learning your craft, of improving your WoW via experimentation and learning, when you can instead become a certified master of an agile method in two days or a program consultant of a scaling framework in four? It sounds great, and certainly is great for anyone collecting the money, but 18 years after the signing of the Agile Manifesto as an industry we’re nowhere near reaching Agile’s promise. Nowhere near it.

We had it right in the very beginning, and the lean community had it right all along – teams need to own their process, they must be enabled to choose their WoW. To do this we need to stop looking for easy answers, we must reject the simplistic solutions that the agile industrial complex wants to sell us, and most importantly recognize that we need #NoFrameworks.

Are the majority of agile transformations failing? Succeeding? Just sort of stumbling along? It’s really hard to tell. You hear a lot of promises and platitudes from consulting firms specializing in transformations, you read case studies that focus on the good and downplay the bad, and there’s a plethora of agile trainers who will certify that you’re a master, a professional, or an agile coach in just a few short days. Who do you trust to share with you what’s really happening in organizations making these transformations? What’s really working? What isn’t?

We like to say that agile teams own their own process by choosing their way of working, their “WoW.” This of course is easier said than done because there are several aspects to WoW. First, our team needs to know how to choose the appropriate lifecycle for the situation that we face. Should we take a Scrum-based approach, a lean/Kanban-based approach, a continuous delivery approach, or an exploratory/lean startup approach? Second, what practices should the team adopt? How do they fit together? When should we apply them? Third, what artifacts should the team create? When should they be created? To what level of detail? Finally, how do we evolve our WoW as we experiment and learn?

There are several strategies that we could choose to follow when we tailor and evolve our WoW. One approach is to bootstrap our WoW, to figure it out on our own. This works, but it is a very slow and expensive strategy in practice. Another approach is to hire an agile coach, but sadly in practice the majority of coaches seem to be like professors who are only a chapter or two ahead of their students. Or we could take a more disciplined, streamlined approach and leverage the experiences of the thousands of teams who have already struggled through the very issues that our team currently faces. In this talk you’ll discover how to develop your WoW without starting from scratch and without having to rely on the limited experience and knowledge of “agile coaches.”

We like to say that agile teams own their own process by choosing their way of working, their “WoW.” This of course is easier said than done because there are several aspects to WoW. First, our team needs to know how to choose the appropriate lifecycle for the situation that we face. Should we take a Scrum-based approach, a lean/Kanban-based approach, a continuous delivery approach, or an exploratory/lean startup approach? Second, what practices should the team adopt? How do they fit together? When should we apply them? Third, what artifacts should the team create? When should they be created? To what level of detail? Finally, how do we evolve our WoW as we experiment and learn?

There are several strategies that we could choose to follow when we tailor and evolve our WoW. One approach is to bootstrap our WoW, to figure it out on our own. This works, but it is a very slow and expensive strategy in practice. Another approach is to hire an agile coach, but sadly in practice the majority of coaches seem to be like professors who are only a chapter or two ahead of their students. Or we could take a more disciplined, streamlined approach and leverage the experiences of the thousands of teams who have already struggled through the very issues that our team currently faces. In this talk you’ll discover how to develop your WoW without starting from scratch and without having to rely on the limited experience and knowledge of “agile coaches.”

An agile enterprise increases value through effective execution and delivery in a timely and reactive manner. Such organizations do this by streamlining the flow of information, ideas, decision making, and work throughout the overall business process all the while improving the quality of the process and business outcomes. This talk describes, step-by-step, how to evolve from today’s vision of agile software development to a truly disciplined agile enterprise. It briefly examines the state of mainstream agile software development and argues for the need for a more disciplined approach to agile delivery that provides a solid foundation from which to scale. We then explore what it means to scale disciplined agile strategies tactically at the project/product level. We then work through what it means to strategically scale across your IT organization as a whole and discover what a Disciplined DevOps strategy looks like in practice. Your Disciplined Agile IT strategy, along with a lean business strategy, are key enablers of a full-fledged disciplined agile enterprise. The talk ends with advice for how to make this challenging organizational transition.

An agile enterprise increases value through effective execution and delivery in a timely and reactive manner. Such organizations do this by streamlining the flow of information, ideas, decision making, and work throughout the overall business process all the while improving the quality of the process and business outcomes.   This talk describes, step-by-step, how to evolve from today’s vision of agile software development to a truly disciplined agile enterprise. It briefly examines the state of mainstream agile software development and argues for the need for a more disciplined approach to agile delivery that provides a solid foundation from which to scale. We then explore what it means to scale disciplined agile strategies tactically at the project/product level. We then work through what it means to strategically scale across your IT organization as a whole and discover what a Disciplined DevOps strategy looks like in practice. Your Disciplined Agile IT strategy, along with a lean business strategy, are key enablers of a full-fledged disciplined agile enterprise. The talk ends with advice for how to make this challenging organizational transition.

Data, the way that we process it and store it, is one of many important aspects of IT. Data is the lifeblood of our organizations, supporting real-time business processes and decision-making. For our DevOps strategy to be truly effective we must be able to safely and quickly evolve production databases, just as we safely and quickly evolve production code. Yet for many organizations their data sources prove to be less than trustworthy and their data-oriented development efforts little more than productivity sinkholes. We can, and must, do better.  

If database evolution isn’t an explicit part of your DevOps strategy then you’re not really doing DevOps yet, are you?

Over the last few years, as agile has gained traction inside the enterprises, we've seen many scaling frameworks have sprung up. These scaling frameworks claim to retain the core agile values & principles and aim to provide a simple yet comprehensive way to scale agility across the organisation. There have been several success case-studies that have been published. We also hear and see many horror stories of failed scaling attempts. 

In this panel, let's have a critical view of the entire scaling framework eco-system.

An agile enterprise increases value through effective execution and delivery in a timely and reactive manner. Such organizations do this by streamlining the flow of information, ideas, decision making, and work throughout the overall business process all the while improving the quality of the process and business outcomes.   This talk describes, step-by-step, how to evolve from today’s vision of agile software development to a truly disciplined agile enterprise. It argues for the need for a more disciplined approach to agile delivery that provides a solid foundation from which to scale. It then explores what it means to scale disciplined agile strategies tactically at the project/product level and strategically across your IT organization as a whole. Your disciplined agile IT strategy, along with a lean business strategy, are key enablers of a full-fledged disciplined agile enterprise. 

Disciplined Agile (DA) is an IT process decision framework for delivering sophisticated agile solutions in the enterprise. It builds on the existing proven practices from agile methods such as Scrum, Extreme Programming (XP), Lean software development, Unified Process, and Agile Modeling to include other aspects necessary for success in the enterprise. DA fills in the gaps left by mainstream methods by providing guidance on how to effectively plan and kickstart complex projects as well as how to apply a full lifecycle approach, with lightweight milestones, effective metrics, and agile governance.

The one-day workshop is not technical and is suitable for all team members. Many group exercises reinforce the principles learned. The workshop is also valuable for management tasked with moving from traditional approaches to agile.

Many agile methods and strategies are geared towards small teams working in reasonably straightforward situations. That’s great work if you can get it. Most organizations that are adopting agile today have been in operations for decades and sometimes centuries. They are typically dealing with significant investments in legacy systems and processes that won’t go away any time soon. They have an existing culture that is usually not-as-agile as it could be and an organization structure that puts up many roadblocks to collaboration. Their staff members are often overly specialized and many people do not have skills in agile software development techniques, and there are many thoughts as to what needs to be done to improve things, the adoption of agile being one of many. This is certainly not the startup company environment that we keep hearing about.

In this keynote presentation Scott Ambler reviews the challenges faced by established enterprises when transforming to agile and what enterprise agile means in practice. He then overviews the Disciplined Agile (DA) framework, a pragmatic and context-sensitive approach to enterprise agile, working through how it addresses the realities faced by modern organizations. Scott then works through advice for transforming your enterprise to become more agile, including the people-process-tools triad and the skills and experience required of enterprise agile team coaches and executive agile coaches. He ends with an overview of proven strategies for adopting agile in less-than-ideal environments