Partially Done Work (the “inventory” of a development process) Relearning (easy to find in documentation-centric development)Extra Features (develop only what customers want right now)Task Switching (everyone should do one thing at a time)Delays (for instructions, for information) Handoffs (tons of tacit knowledge gets lost) Defects (at least defects that are not quickly caught by a test)
Respect – teammates must respect each other, developers must respect QA, product management, etc.Commitment – team decides for itself what to take on, but the trade-off for that is commitmentFocus – Minimize task switching; minimize hand-offsOpenness – Requires team to be willing to share true status of thingsCourage – Courage to demand respect; courage to commit; courage to be open; courage to allow a team to focus
Promise for a conversationDifferent from traditional requirements documentation which seeks to ensure all details are present to form a “contract”
Delivering the highest quality, best customer service.. Every transaction, every time.
Scrum and the Agile Development Process
Agenda Introduction Empirical vs. Defined Process Agile Development Scrum 101 Scrum Overview Roles and responsibilities New Operations Team
Defined Process Requires every piece of work be well understood. Given a well-defined set of inputs, the same outputs are generated every time. Yummy Donuts! Donut Mix
“Traditional” Waterfall Job Function E Job Function D Job Function C Job Function B Job Function A Requirements Gathering Design Development Documentation, Signoffs, Handoff Documentation, Signoffs, Handoff Documentation, Signoffs, Handoff Documentation, Signoffs, Handoff Testing Launch & Maintain Advantage: Highly Logical Disadvantage: Human Beings are involved
Empirical Process Provides and exercises control through frequent inspection and adaptation Processes are imperfectly defined Generate unpredictable and unrepeatable outputs. Yummy Donuts! Is it soup yet? Yummy Soup! Soup Fixin’s
Agile Software Development Feedback Feedback Feedback v 1.0 v 1.1 v 1.2 Short Iterations Incremental Releases
Agile Software Development Feedback Feedback Feedback
Empirical Processes “It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.” Process Dynamics, Modeling, and Control, Ogunnaike and Ray, Oxford University Press, 1992 Translation into English: Inspect and Adapt
What are some other examples of processes suited to an empirical approach? ???
Product Manager Product visionary Maximizes business value Prioritizes and clarifies requirements
Product Manager Does Provide clear product direction Work with the team closely to clarify requirements Actively manages the product backlog Represents the business and customer needs
Product Manager Does not Assign work to the team members Give fixed date fixed scope projects without team consent Change priorities during a Sprint
Scrum Team Cross-functional Possesses all the skills necessary to produce an increment of potentially shippable product Team takes on tasks based on skills, not just official “role” Self-organizing Team manages itself to achieve the Sprint commitment
Scrum Master Similar to a Project Manager… yet different A facilitator Removes impediments
Scrum Master The Scrum Master does everything in their power to help the team achieve success Serving the team Protecting the team Guiding the team’s use of Scrum
Tracking Progress Uses inspection and subsequent adaptation to optimize realization of goals. Transparency is required for inspection and adaptation Transparency requires courage and change in reward system
Focus My report doesn’t print right. DPR wants to change the Red Zone criteria I didn’t get my scheduled report. I want to keep track of my old comments. Can’t I add contractors during an inspection?
New Operations Team Respond to small/moderate customer requests quickly Can focus on support issues when required Can focus on operations issues when required Keeps the other team focused on the release