In Dean Leffingwell’s recent webinar on scaling Lean|Agile development, he introduced the Scaled Agile Framework (SAFe) <click here for Dean’s recording>. SAFe is a public-facing set of practices which have been used to successfully scale Lean|Agile development to hundreds — and even thousands — of practitioners at companies like BMC Corporation and John Deere.
You will gain these valuable insights as we cover the following topics…
- What are best practices for writing team-based User Stories and non-functional Agile requirements?
- How do these scale to the program and portfolio levels?
- How can you work more strategically with upper management to achieve the highest business value for your company and customers?
by Dean Leffingwell
Are you tired of the myth that Scrum, XP and Kanban do not scale to the needs of the larger software enterprise? Are you tired of the ideologies that prevent your enterprise from even trying to apply them? If the answer to either of the above is yes, this presentation is for you.
In this presentation, Dean Leffingwell will finally dispel these myths and ideologies by describing the Scaled Agile Framework™, a public-facing set of practices which have been used to successfully scale Lean|Agile development to hundreds—and even thousands—of practitioners at companies like BMC Corporation, John Deere and others.
He’ll describe five key scaling mechanisms:
• SCALING VALUE: Not everything is a User Story
• SCALING DESIGN: Complex systems require intentional architecture.
• SCALING TEAM AND TIMEBOX: Aligning teams to a common mission with the Agile Release Train
• SCALING PORTFOLIO MANAGEMENT: Addressing legacy mindsets
• SCALING LEADERSHIP: Your enterprise can be no leaner than your executives thinking.
The Scrum Field Guide (by Mitch Lacey) is meant to help you fine-tune your own implementation, navigate some of the unfamiliar terrain, and more easily scale the hurdles we all encounter along the way.
Who Should Read This Book
If you are thinking about getting starting with Scrum or agile, are at the beginning of your journey, or if you have been at it a year or so but feel like you’ve gotten lost along the way, this book is for you. I’m officially targeting companies that are within six months of starting a project to those that are a year into their implementation, an 18-month window.
This is a book for people who are pragmatic. If you want theory and esoteric discussions, grab another of the many excellent books on Scrum and agile. If, on the other hand, you want practical advice and real data based on my experience running projects both at Microsoft and while coaching teams and consulting at large Fortune 100 companies, this book fits the bill.
Games are a great way to learn…especially as a team. Here is one simple but powerful exercise that can be used to demonstrate several aspects of flow, value and teamwork: The Dice Game, by Lithespeed.
You can have several teams – each representing a different method of delivery: Watherfall, Continuous Flow/Kanban, Scrum. And compare results afterwards.
Key Learning Points:
- Value is delivered more rapidly in small batches
- Steady delivery of features mitigates the risk of non-delivery
- Small batches reduce the impact of customer changes
- Teamwork is more prevalent when activities are shared and there is frequent interaction
- New skills can be built over time by frequent interaction between those performing neighboring activities, leading to more polyskilled team members and hence more fruitful collaboration
- Work in small batches is less complex
- Optimal release strategies can maximize the flow of value, hence the necessity of the Product Owner role
Agile software development has been gaining momentum and mind share in software development circles for well over a decade. Its emphasis on incrementally delivering business value by teams that are both cross-functional and self-organized has resulted in getting innovative products to market faster. However, most large enterprises have failed to embrace the Agile movement even though they have earnestly tried by sending scores of their people through Certified Scrum Master and similar Agile training programs. What has been lacking is an Agile framework that addresses the needs beyond the Team. In order to succeed, the Program and Portfolio levels of an organization must be fully engaged in building an Agile Enterprise.
This webinar will discuss “proven” advances in enterprise scale Agility and present a framework that has been proven to scale to meet the needs of large product development organizations such as BMC, SalesForce.com, Google, John Deere and Nokia.
All new recording…in HD just released !
Learn Scrum in under 10 minutes. This video is an introduction to the Scrum software development methodology. By the end of this fast-paced video, you’ll practically be a scrum master. You’ll know about the follosing and will be ready to start implementing Scrum in your own team.
- burn-down charts,
- team roles,
- product backlogs,
- daily scrums
- and more…
Our mission is to enable organizations and project teams to be as Lean-Agile as possible — by helping them determine HOW, WHEN and WHERE to utilize Lean-Agile practices along side their Traditional Waterfall methods to “Deliver Results Quickly”
We often have questions about relating traditional PM practices to Agile practices. This is especially true in the area of risk. In this one hour webinar, Greg Smith (Author of Becoming Agile) and Donna Reed (The Agilista PM) will cover traditional risk management techniques and contrast them to the Agile risk management practices.
You will learn how to use traditional risk management in harmony with an Agile lifecycle and how to perform risk management at a level that minimizes waste and over-planning.
- BURP (Big Upfront Risk Planning),
- daily risk management,
- and Team involvement in risk identification.
This FREE eBOOK DOWNLOAD by Henrik Kniberg and Mattias Skarin is excellent ! It clears up the fog, so you can figure out how Kanban and Scrum might be useful in your own environment. Thanks to InfoQ for posting it.
There isn’t a single “best” way to do things; you have to think for yourself and figure it out – based on your situation !
- the difference between Scrum and Kanban.
- their strengths and limitations,
- when to use each
- how and when to improve upon Scrum, or any other tool you may happen to be using.
- how to apply them in real life situations
- and more….
Mary Poppendieck writes:
Henrik Kniberg is one of those rare people who can extract the essence of a complicated situation, sort out the core ideas from the incidental distractions, and provide a crystal clear explanation that is incredibly easy to understand. He makes it clear that these are just tools, and what you really want to do is have a full toolkit, understand the strengths and limitations of each tool and how to use them all. The important thing is not the tool you start with, but the way you constantly improve your use of that tool and expand your toolset over time.
David Anderson, the founder of Kanban, writes,
Kanban is proving useful to teams doing Agile software development but equally it is gaining traction with teams taking a more traditional approach. Kanban is being introduced as part of a Lean initiative to morph the culture of organizations and encourage continuous improvement.
Scrum is not a hard concept to understand. But there are a lot of parts ot making it successful. I found a great article that explains how to implement Scrum in just 10 easy steps from getting your backlog in order to tracking progress through burn charts, and more… Thanks goes out to Kelly Waters, from All About Agile, who writes:
When I first encountered agile development, I found it hard to understand. Okay, I might not be the brightest person you’ve ever met! But I’m not stupid either, I think 🙂
There’s a myriad of different approaches, principles, methods and terms, all of which are characterised as ‘Agile’. And from my perspective, all this ‘noise’ makes agile software development sound far harder, far more scientific, and far more confusing than it really needs to be.