Agile Value Streams: What , Why and How.
Value Streams, an organizing principle within Lean Software Engineering and SAFetm, help executive leadership understand the concept to cash flow of value available from a properly scaled Agile implementation. In the simplest cases, Value Streams are obvious and easy to cluster agile teams around but in the real world things are not always so simple.
This presentation presents a value stream definition accessible to any agile practitioner followed by an in-depth discussion to the fundamentals behind value streams. The session concludes with a class exercise on identifying and selecting one or more value streams and introduces the concept of a Release Trains.
Outline/Structure of the Talk
The session will begin with a definition and discussion around value streams and their use in visualizing concept to cash activity flow. The importance of taking an economic view and the cost of delay assist in highlighting the importance of business value over engineering embellishment.
Using agile teams to organize value streams around seems obvious but the reality is much more complex as converging business priorities (features vs subsystems vs architecture) complicate stream construction, especially when scaled to larger implementations. By the end of this section, the fundamentals behind What and Why are covered.
The last part of the session introduces the concept of Release Trains and their importance in subdividing a value stream along logical and functional criteria. The class exercise reinforces these principles as participants go through a simulation of merging two systems into one as a result of a merger between two large corporations who need to release a new version of their combined product asap.
Attendees will learn the importance of leaning out waste in the development process and how to identify value streams within a development planning effort prioritizing around business value. Also they will visualize how release trains running within a value stream focus and synchronize development energies.
This session will help anyone challenged with planning releases that can deliver business value.
schedule Submitted 5 years ago
People who liked this proposal, also liked:
Michael Harris - What if you need to scale agile but don't fit the models? A case study.Michael HarrisPresident & CEODavid Consulting Group
schedule 5 years agoSold Out!
Agile scaling models tend to be based on scenarios where 5 - 10 agile teams are working on the same project/program/product/value stream. The scaling models provide some good ways of organizing the work that needs to be done to plan, synchronize and demonstrate the outputs of the teams. This case study describes the path of a development group that has 10-12 teams working on about 50 different software "products and services" within a reasonably narrow-focused energy company. The case study describes how they went about paring down the SAFe model to meet their needs and then prioritizing the scaled-back scaling transformation using group inputs to a weighted shortest job first exercise.
Thomas M Cagley Jr - Budgeting, Estimation, Planning, #NoEstimates and the Agile Planning Onion - They ALL make sense!Thomas M Cagley JrAgile Practice ManagerDavid Consulting Group
schedule 4 years agoSold Out!
There are many levels of estimation, including budgeting, high-level estimation and task planning (detailed estimation). We can link a more classic view of estimation to the Agile planning onion popularized by Mike Cohn. In the Agile planning onion, strategic planning is on the outside of the onion and the planning that occurs in the daily sprint meetings is at the core of the onion. Each layer closer to the core relates more to the day-to-day activity of a team. The #NoEstimates movement eschew developing story- or task-level estimates and sometimes higher levels of estimation. As you get closer to the core of the planning onion the case for the#NoEstimates becomes more compelling and dare I say useful.
This presentation focuses on challenging the attendee to consider estimation as a form of planning. Planning is a considered an important competency in most business environments. Planning activities abound whether planning the corporate picnic to planning the acquisition and implementation of a new customer relationship management system. Most planning activities center on answering a few very basic questions. When will “it” be done? How much will “it” cost? What is “it” that I will actually get? As an organization or team progresses through the planning onion, the need for effort and cost estimation lessens in most cases. #NoEstimation does not remove the need for all types of estimates. Most organizations will always need to estimate in order to budget. Organizations that have stable teams, adopt the Agile mindset and have a well-groomed backlog will be able to use predictable flow to forecast rather than effort and cost estimation. At a sprint or day-to-day level Agile teams that predictably deliver value can embrace the idea of #NoEstimate while answering the basic questions based what, when and how much based on performance.
Jessica Soroky - Gaming Team Forming, Norming, and StormingJessica SorokyAgile CoachAEP (American Electric Power)
schedule 5 years agoSold Out!
You’ve read all the books, you’ve gotten your certifications and now you have a team staring at you waiting for you to take the lead. There is no hesitation about how to perform the basics -- determining roles and scheduling meetings -- but how do you kick off an effective, high performing team?
Whether you have a brand new team or you’re the new guy on an existing team, the tools and techniques you will learn in this session have proven to be effective from state government to private sector insurance.
As an accredited Leadership Gift Coach Jessica focuses on vocabulary, shared responsibility, and team agreements. You will leave the session able to facilitate more than one Innovation Games and utilize them during your kick offs to set the stage for a powerful and effective team no matter what methodology they use.