How to explain Agile, Scrum, and Lean in DoD terms to turn Military Decision Maker skeptics into Agile Change Agents.
Have you ever been part of a team working to win over a DoD organization to Agile and were blocked with skeptics that assert that Agile is “just the next new fad.” This session will give you the hard facts and skills to win over these skeptics by showing that Scrum, Agile, and Lean are in fact Military war fighting methods that are battle tested, quite literally. This presentation will walk the audience through how the Agile and Military iterative problem solving methods map to one another. The desired objective in doing this is to provide examples and narratives that can be put into your agile tool box for when they are needed.
This presentation has been given via several venues over the last year to include: The AFEI Agile in Government Summit, The DoD CIO Software Assurance COP, Southern Fried Agile 2014, and several Agile meet-up groups.
About me: https://www.linkedin.com/in/thomasfriend
Thanks for taking the time to consider my proposal.
Tom Friend / Agile Consultant / LtCol USAF (Ret)
CSP, ACP, AHF, FLEX, CSM, PSM, ATP
Talk: (980) 939-3477
Outline/structure of the Session
Introduction 5 Min
OODA = SCRUM 10 Min
AGILE = MDMP 10 Min
LEAN = Maneuverer Warfare 10 Min
Questions and Answers 10 Min
Learning Objective - Provide Federal DOD Agilests ways communicate to Military decision makers that Scrum, Agile, Lean are in fact Military War Fighting methods they know just by different terms. The iterative problem solving methods are nothing new just being applied differently using a new vocabulary of terms.
Outcome - Present the similarities of Scrum, Agile, Lean vs traditional proven Military Decision Making Processes.
Outcome - Provide bridge of understanding between Scrum, Agile, Lean and military methods for Military and DOD contractors that are unfamiliar with Agile methodologies.
Outcome - Present talk tracks and narratives that demonstrate how the Agile Methodology complements Military War Theory.
Agile Practitioners working with Federal DoD projects that are using or will be using Agile methods.
schedule Submitted 3 years ago
People who liked this proposal, also liked:
Steve Ropa - DevOps is a Technical Problem AND a People ProblemSteve RopaThe Software Craftsman in ActionVersionOne
schedule 3 years agoSold Out!
Gerry Weinberg once said of consulting “There is always a problem, and it’s always a people problem.” The world of DevOps is emerging rapidly, and just like the early days of Agile, is still working on refining exactly what DevOps means. So often, the focus is either on the technical aspects of the various tool, or on the people problem of “bringing Ops into the room”. But what is the problem that DevOps addresses, and is that problem more of a technical problem, or a people problem? We will explore this, and look at the possible intersection between the two “problems” and how a DevOps approach can help overcome them.
Sally Elatta - Enterprise Agility Starts with Healthy Teams, How Healthy is YOUR Agile Team?Sally ElattaPresident and Enterprise Agile CoachAgile Transformation Inc.
schedule 2 years agoSold Out!
Have you been adopting Agile methods across several teams but wondering if there is a consistent way to measure their health and progress? What does it even mean to be a "healthy" Agile team? Take a deeper dive with our dynamic Agile Expert, Sally Elatta, as she walks you through the top 5 metrics you need to be looking at to measure the health and performance of your Agile teams and how you can create a continuous growth process where teams, programs and portfolios are getting better quarter after quarter.
- How do you really measure TeamHealth and what metrics should you look for?
- Why it's important to look at both Qualitative and Quantitative measures and not just focus on 'hard metrics'.
- How to create a continuous quarterly growth process that is predictable and measurable.
- Go through a TeamHealth retrospective simulation!
This will be an engaging and hands on session where attendees get to color a blank TeamHealth radar using crayons and have a tangible output they can share with their teams.
Satish Thatte - Failing to Plan is Planning to Fail: Succeed with Your Agile Planning PlaybookSatish ThatteAgile/Lean Coach and Product ConsultantVersionOne
schedule 2 years agoSold Out!
Although many people know that agile planning is different from big, up-front detailed planning done for traditional or waterfall projects, there are many misconceptions, or vague or partial understandings. Some people equate agile planning with minimal planning or just-in-time planning or “fluid” or “adaptive” planning. “Winging” an agile plan is expensive and doesn’t work well. If you don’t plan or plan poorly, no amount of execution effort would adequately compensate for poor agile planning. Agile planning is disciplined and rigorous, and the planning process itself is agile.
I will present a customizable Agile Planning Framework based on a core set of agile planning principles and practices, common to all organizations. The framework consists of four well-aligned agile planning levels, each driven by four steps, covering 16 agile planning practices (hence called “4x4 Agile Planning Framework”). Each agile planning level guides the next lower level of planning, which elaborates the planning done at the higher level but with a shorter time horizon. Planning retains its agility with periodic adjustments based on the feedback from the plan execution and changes in environment (market conditions, customer feedback, competitive responses, etc.).
- Product Vision and Strategy planning, with planning horizon of one to three years, and business initiatives or strategic themes serving as the planning unit taking several months to complete. This is the top level of planning.
- Release planning, with planning horizon of 2 to 6 months, and features that fit in a release cycle serving as the planning unit.
- Sprint planning, with planning horizon of 2 to 4 weeks, and stories that fit in a sprint serving as the planning unit
- Daily planning and Daily Scrums, with planning horizon of one work day, with tasks that fit a single work day as the planning unit. This is the bottom level of planning
At each planning level the following four steps are required:
- Select the planning method appropriate to your needs.
- Obtain required inputs appropriate for the selected planning method, and do necessary preparation ahead of the planning sessions.
- Apply the selected planning method and develop the necessary planning artifacts to drive the execution at that level, and guide the planning at the next lower level.
- Re-plan periodically to improve agility.
I will explain how to use Red Ocean and Blue Ocean Strategy frameworks, and how to harness the Lean Startup Strategy framework at Level 1 Agile Planning (Product Vision and Strategy).
VersionOne’s 9th Annual State of Agile Survey has indicated that the consistent process and practices is the top tip for success in agile. No two organizations are alike. No cookie-cutter approach to agile planning will work in a vast variety of situations. Context matters greatly. I will explain how Agile Champions can use the 4x4 Agile Planning Framework to develop customized Agile Planning Playbook appropriate to their organization, and how the resulting Playbook facilitates agile planning done by Agile Planners and plan execution by Agile Team Members in a standard and consistent way across an enterprise or at least across a set of projects or teams in a program or a portfolio.
Steve Ropa - Building Software CraftsmenSteve RopaThe Software Craftsman in ActionVersionOne
schedule 3 years agoSold Out!
There has been a lot of talk lately about Software Craftsmanship. Most of this talk has been centered around how to take existing, skilled programmers and turn them into Craftsmen. What about those who are just entering the field? In this talk, we will explore a new approach to fulfilling the entire journey from Apprentice to Master, both from a personal and organizational level. We will also look at how to get such a program started, and how to bring the existing team along.