Dean Leffingwell shares a new CALMR approach
April 18, 2017
11:00 AM -12:00 PM EDT / 17:00-18:00 CET
DevOps and Continuous Delivery is all the rage these days. And why wouldn’t it be? What good does it do to be agile right up to the point where we can’t actually release the software?
Join Dean Leffingwell, co-founder and chief methodologist at Scaled Agile, Inc., as he describes how a CALMR approach — Culture, Automation, Lean-Flow, Measurement, and Recovery — to scaling DevOps and Continuous Delivery creates the foundation teams need to release value on demand. Hear how the practices and mechanisms of continuous exploration, continuous integration, and continuous deployment work in concert to build an efficient Continuous Delivery Pipeline.
Dean will review existing SAFe DevOps content and preview new content making its way into SAFe Guidance, and likely future versions of the Scaled Agile Framework®.
Can’t attend the webinar? No problem. Everyone who registers will get a link to the recording.
Get an overview of Agile approaches starting with eXtreme Programming (XP) & Scrum and then hear about Lean-Agile and its team oriented Kanban for software process.
Early Agile methods have been overly-team centric and have eschewed management. While 2nd generation Agile methods build on a decades old history of Lean thinking and have extended agility in three ways that are not only required for an enterprise engagement but also for creating synergies that improve Agile at the team level:
- Extending the Team to across the Enterprise
- Extending Individual skill sets to Systemic Thinking
- Extending the Worker to include Management
Part A: USING KANBAN TO IMPROVE SCRUM
Session 1: Key Kanban Practices – Explicit Policies, Managing Work in Progress and Visibility
Session 2: Using Theories of Flow to Manage Work involving Multiple Teams
Session 3: Using Service Level Agreements to Manage New Work
Part C: ADVANCED SCRUM AND KANBAN
Session 7: Transitioning to Kanban from Scrum
Session 8: Creating A Kanban Board from a Value Stream Map
Session 9: Comparing Scrum and Kanban
Organizations can’t limit themselves to operational excellence without expecting disruption.
They have two options: disrupt or be disrupted.
Yet innovation is not what most people think — it isn’t about “inventing the next new thing” or R&D. It’s about continuous experimentation. Today even older, large organizations are learning how act like start-ups. Agile and Lean are key ingredients in making this happen in the short, medium, and long term.
PRESENTER: Joel Semeniuk is a founder and chief innovation officer/incubation director at Imaginet Resources Corp., a Canada-based Microsoft Gold Partner and the number-one small- to medium-sized employer in Canada. Joel also served as the executive vice president of Innovation and Agile Project Management at Telerik. Joel has a degree in computer science and is also a corporate Microsoft regional director. Previously he was a Microsoft Most Valued Professional in the area of Application Lifecycle Management and Software Architecture.
Some theorists talk about universal theories of disruption. Others tell one-off stories about the disruption of individual firms. What is more helpful, said global thought leader John Hagel, is understanding the patterns of disruption that will hit more than one market, but not all markets. This can help you understand two important things: What are the characteristics of a market that would make it vulnerable to a particular type of disruption? And how do you defend against it?
Drawing on new research from Deloitte’s Center for the Edge, Hagel explained that executives tend to be overwhelmed when they think about disruption. They are worried that disruption could come from anywhere and it could be anything. As a result, they don’t know what to do. Hagel said, “Without excluding other possibilities, here are two or three possible patterns of disruption that your market is particularly vulnerable to. So you can figure out how to deal with that, rather than simply waiting for whatever happens.”
Most efforts to change an organizational culture fail. Efforts to create an innovative organizational culture are typically even less successful. Yet some succeed. One extraordinary example is SRI International (SRI), the creator of Siri, the iPhone virtual assistant.
In 1998, SRI was practically bankrupt, with a toxic, distrustful culture. Over the next 16 years, SRI turned into a highly profitable, collaborative serial innovator with a string of multimillion dollar innovations, including Siri. In this webinar, Curt Carlson, who was the CEO of SRI during this period, explained how the company did it.
Organizations today face a crisis. The crisis is of long standing and its signs are widespread. Productivity is one-quarter of 1965 levels. Innovation continues to decline. Workers are disgruntled. Customers are frustrated. Brands are unraveling. Executive turnover is accelerating. In the last 25 years, startups created 40 million jobs in the US, while established firms created almost none. Traditional management is broken.
The principles described in this webinar show how Agile thinking can respond to the crisis and be applied to the overall management of any organization so as to inspire high productivity, continuous innovation, deep job satisfaction and client delight.
Radical management is an approach to management that is fundamentally different from traditional management. It comprises seven inter-locking principles of continuous innovation: focusing the entire organization on delighting clients; working in self-organizing teams; operating in client-driven iterations; delivering value to clients with each iteration; fostering radical transparency; nurturing continuous self-improvement and communicating interactively. In sum, the principles comprise a new mental model of management.
Everyone I know working to help organizations to become Agile agree that…
Becoming Agile is a Process
I know teams that have been maturing for 3+ years and they will tell you they still have room for growth. That tells me from first hand experience as well as talking to organizations that have committed to this journey so they can be more responsive to their customers and business, that not only do you have to be committed to being patient with the growth process – you can help the process by creating a Kaizen Culture.
Kaizen is a Japanese word for “improvement”, or “change for the better”. It refers to philosophy or practices that focus upon continuous improvement of processes.
Kaizen is a daily process, the purpose of which goes beyond simple productivity improvement. It is also a process that, that can humanize the workplace, helps people work smarter, not harder; and teaches people how to spot and eliminate waste in their own work and business processes. It covers five main areas: Read more
Agile was implemented company-wide at Geonetric after experiencing early success with Agile adoption in their software teams.
“We saw software releases hitting targets,” Eric said, “meeting both scope and deadline requirements. Our software development was accelerating with each sprint, almost doubling in speed over the course of a year.” Eric felt challenged by the boundaries of traditional management thinking. “As a team, we recognized the traditional management model was broken.”
After a lot of soul-searching, Geonetric took the huge leap — and capital investment — to rethink everything and apply Agile across the entire organization to the furthest extent they could imagine.
In this presentation, Eric will demonstrate how to:
- Flatten the org chart
- Ditch traditional departments
- Open up in radical transparency
- Create a peer-accountable culture
Use cases and user stories are both excellent techniques for understanding what a user needs from a product. While both have a similar purpose, use cases and user stories are not meant to be used interchangeably. That is why it’s important for a business analyst to understand the difference.
The older of the two techniques is the use case, which captures usage scenarios. In other words, a use case documents how an individual uses a product to accomplish something of value. This technique works well for projects where functional requirements and usage scenarios must be – and can be – specified upfront. However, what if you can’t know the requirements upfront?
In a user story, the user and what they need the product to accomplish is also specified, but in contrast to use cases, at a much higher level.
Recognizing which technique is best suited to your situation is the key.