Agile

On Feb 24 & 25, I received training in Scaled Agile Framework for enterprise (SAFe®) – a framework that combines elements of Agile software development, Lean process improvement, and Extreme Programming (XP) . The project I’m working on is looking to incorporate elements of this and part of that involves getting us all trained. Here are my notes of highlights (which I wrote up as a way to prepare for the test which I then took to get “certified” in SAFe®, as well as to process some thoughts on how I can apply what I’ve learned to my work).

• Core Values of the framework:
  • code quality – built in upfront
  • program execution – produce something that provides value
  • alignment – helps you make decisions in context, promotes decentralized decision-making
  • transparency – everyone at all levels needs to have the same information; transparency is needed to built trust
• The framework is modular – you can use just the pieces of it you need, but the elements are synergistic, so the more you use, the more “benefit” you get
• They also noted that “projects” create “deliverables” and “outputs”, whereas “programs” provide “outcomes” and “benefits”. This resonated for me as I’ve worked with the “project” to focus on ultimate goals (i.e., clinical transformation) rather than shorter-term outputs (such as “creating an IT system”. We want an IT system because it will help us reach our clinical goals, not just because we want an IT system).
• They don’t like to think in terms of “projects”, which are defined by a start and end, as Agile is more about ongoing development (rather than just creating a complete/perfect product that you roll out and then disband the project team). Instead, they think of things are “programs”. This has some implications for the “project” I’m working, which has been defined as a “project” that will essentially produce a product, roll it out to the organizations, and then transition it over to operations at the orgs. This way of thinking provides more of a blurring the project into the organizations (rather than being separate from it), which actually mirrors a shift the project has been undergoing anyway (from an IT-focused, vendor-led project to a clinically-focused, IT-enabled, health organization-led, “project” team-supported program)
• This whole thing is a paradigm shift from what we are used to – it requires a change in mindset and culture – both of which are difficult things to do.
• Team decides “how” it gets done (neither product owner nor leadership is allowed to interfere with the “how” it gets done.
• Product owner decides “what” gets done (giving the customer what it decides is important)
• Agile teams are:
  • self-organizing
  • empowered (because they get to make decisions and be accountable and regularly produce something of value – this is motivating to people)
  • cross-functional
  • 4-9 people
  • includes:
    • developers/testers – creates/refines user stories & acceptance criteria (that the P.O. will make the decision on whether to accept); builds/tests/delivers stories
    • product owner – represents the interests of the customer; prioritizes the backlog
    • demo master – mentors the team, removes barriers that are getting in the team’s way, attends scrum of scrum meetibng
• Scaled Agile involves scaling to the Program and to the Portfolio
• Scaled to the Program:
  • self-organizing self-managing team of Agile teams
  • a common mission
  • a single backlog of items to be done (which they can all draw on)
• Program Increment (PI)
  • a specific amount of time in which they plan/implement/measure
  • provides a cadence which all the teams align to
  • not  the same as the product release cadence (product releases are “on demand” – release the stuff that’s been built out to the world when it makes sense).
• Scaled to the Portfolio:
  • a Portfolio vision to provide an aim for the whole system
  • Lean approaches to strategy, finance, program management, and governance are all needed to support the Agile program and Agile teams
  • strategy is centralized, but execution is decentralized
• Backlog:
  • a list of things to do
    • if something is on there, it may get done
    • if something is not on there, it definitely will not get started
    • don’t need details (which require a lot of time to define and might change by the time the items gets from the backlog to actually being worked on – so details are defined just-in-time)
    • product owner should keep it prioritized (look at it every day) – e.g., if a team finds themselves with extra capacity, they may take an item from the top of the backlog to do
    • includes:
      • user stories – a thin slice of functionality – must be something of value
      • refactors – an improvement to the code base (e.g., improving performance, maintainability, scalability) that does not change any observable system behaviour; making your code “beautiful”
      • spikes – research activities (e.g., to understand a functional need, to reduce a risk, increase estimate reliability, define a technical approach; to build a prototype in order to learn stuff)
        • technical spike: researching a technical approach or unknown
        • functional spike: researching how a user might use/interact with the system
  • Portfolio Backlog contains Epics
  • Program Backlog contains Features
  • Team Backlog contains Stories

• Lean is a process improvement method that focuses on eliminating waste and doing things that provide value
• The House of Lean:
  

  value
  respect for people and culture		flow		innovation		relentless improvement
  leadership

• focused on providing value
• people do the work – respect and trust them
• the customer = whoever “consumes” your work – respect them too
• to change culture, you need to change the organization
• Remember the Peter Drucker quotation: “Culture eats strategy for breakfast”
• want to optimize flow, avoid start-stop-start delays, make informed decision by using fast feedback
  • reducing batch size:
    • helps reduce variability, which improves flow
    • results in a quicker cycle time, so you get feedback faster
    • limiting Work in Progress (WIP) also helps improve flow
      • put limits on amount of WIP that is allowed
      • having a short cycle helps reduce WIP (focus on getting small things done and thus out the “WIP” stage)
      • when WIP is too high, purge the lower value items
      • make the WIP visible – when you can see it, it is easier to see when it is building up
• need time and space to innovate; try getting out of the office (go to the Gemba – Gemba = “the real place; the place where the work is actually done)
• focus on relentless improvement – applying Lean tools to identify and address root causes of issues; reflect at key milestones
• leadership supports the team by leading the change, developing people
• “People are already doing their best; the problems are with the system. Only management can change the system” – W. Edwards Deming

• Kanban = visual board
• have it up in the team’s work area – look at it every day – serves as an early warming indicator
  • the earlier you identify an issue, the more options you have to fix it

• Decisions: to centralize or decentralize?
  • centralize: infrequent, long-lasting, significant economies of scale
  • decentralize: frequent, time critical, don’t have significant economies of scale
  • local decision making has the benefit of better local information
  • framework for making the decision about where decisions should be made (where 0-3 = centralize, 4-6 = decentralize):

• Traditional Waterfall vs. Agile:

• sprint: short iterations with a regular cadence (usually 2 weeks long) in which you produce a thing of value
  • plan, develop/build/test/integrate, and demo for the product owner
  • retrospective the end to reflect on what you learned, what you can do better next time
• Sprint planning: 4 hours
  • product owner presents sprint goals (which align team to a common purpose) & stories
  • determine team velocity
  • team clarifies and estimate stories (elaborates acceptance criteria)
  • P.O. and team negotiate and finalize (load = stories you taken on for the sprint – must be less than or equal to the velocity)
  • everyone commits to the sprint
• put all the stories and their acceptance criteria on the kanban

• Scrum
  • daily, 15-minute stand up meetings
  • share info on progress, coordinate activities, raise issues that are blocking you (scrum master’s job is to get rid of those blocks for you)
  • ask 3 questions:
    • what stories did you work on yesterday?
    • what stories can you complete today?
    • what’s blocking you?
  • don’t get into problem solving – can od that in a “Meet After”
• Mid-Sprint Review
  • determine if you are on course and if you need to adjust
  • if you aren’t on track to meet your sprint goal, you can:
    • negotiate story scope to “good enough”
    • reprioritizee stories
    • reassign resources
    • defer or delete stories
• Backlog Refinement Session
  • done to prepare for next sprint
  • can invite subject matter experts (SMEs) or other team’s members if needed
  • process
    • P.O. present potential stories for next sprint
    • discuss this list (e.g., add or remove stories, split stories, ask questions, discuss acceptance criteria)
    • determine if anything needs to be done on these before the next sprint
• Demo
  • demonstrate what you created for each story
• Sprint Retrospective Meeting
  • reflect on results
  • learn from reflection
  • adapt process to produce better results
  • pick one thing you can do differently next time

• Since you are delivering something the provides value every two weeks, if the program gets cancelled, you’ve provides something useful that is out there in the world. When a traditional project gets cancelled, you’ve spent millions with nothing to show for it but a bunch of documents – nothing of value has been produced

• Agile Manifesto (quoted verbatim – source):

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

• This struck me as having similarities to Developmental Evaluation – with the focus on responding to changes and collaborating with your client. And instead of “working software” over documentation, I’d say “evaluation findings put to use” over documentation of evaluation findings.

• timelines and budget are fixed – what can change is the scope
• it’s better to have a high quality product of a smaller scope than a poor quality product that covers a bigger scope (especially since you know that you are going to continue to add to the scope over time)

• Extreme Programming (XP)
  • testing-driven development (and automated testing)
  • pair programming
  • simple design
  • coding standards
  • continuous integration
  • collective ownership
  • user stories
  • refactoring

• System Team
  • builds infrastructure
  • manages environments
  • provides/supports full system integration
  • end-to-end system and performance testing
  • stages and supports the System Sprint Demo

• Estimating backlog items
  • don’t use hours – use “story points”, which is a single number that represents:
    • volume – how much?
    • complexity – how hard?
    • knowledge – what do we know?
    • uncertainty – what do we not know?
  • story points are relative to other stories (e.g., a 2 pt story takes half as long as a 4 pt story), but not in a specific unit of measure
  • then we use this size to estimate a duration
  • estimation is a team activity – applies all perspectives, develops shared understanding & commitment (everyone participates in the estimation session, but the product owner does not estimate)
  • uses a modification of the Fibonacci sequence: 1, 2, 3, 5, 8, 20, 40, 100, ?
  • process:
    • product owner reads the backlog item
    • everyone discusses
    • estimators select a story point value (have cards with all the numbers of the modified Fibonacci sequence)
    • everyone show their cards
    • discuss highest and lowest values (and why they are at extremes)
    • re-estimate (continue until values converge)
  • velocity = amount of capacity the team has during a sprint, expressed in story points
  • process for determining team velocity:
    • 8 points per full-time developer or tester (pro-rate for part-timers)
    • -1 point for every holiday or vacation day
  • quick way to start estimating – find a story that will take ~1/2 day to code + ~1/2 to test/validate and call that 1 point – estimate everything else relative to that
  • this method is quick, easy, and just as accurate as complicated mathematical estimate models – it also gets the group talking about how to solve the problem

• User Stories:

As a <role>
I can <activity>
So that <business value>

• a good user story should be small and add value
  • INVEST – Independent, Negotiable, Valuable, Estimable, Small, Testable
• if the user story is too big:
  • if it’s a complex problem, break it down into technical and/or functional spikes (to reduce the complexity)
  • if it’s a compound problem, split it into smaller stories
  • can split stories by:
    • workflow steps – make each step a story
    • business rule variations – make each variation a story (e.g., “sort  by demographics” can be split into “sort by postal code”, “sort by home demographics”, etc.)
    • major effort – start with the one requiring most effort and add more functionality later
    • simple/complex – what’s the simplest version that can work?
    • variations in data – e.g., send messages in English, in French, in Spanish, etc.
    • data methods – e.g., bar chart of your household’s data, then bar chart that compares your data  with other households’ data
    • deferring system qualities – start with simple and later more it faster, or more precise or more scaleable
    • operations – split each operation into its own story – e.g., Create Read Update Delete (CRUD)
    • use case scenarios – if use cases represent complex interaction, split into individual scenarios
• roles:
  • can be people, devices, or systems
  • 1st degree – people that use the product (meet their needs first)
  • 2nd degree – people that work with results from those who use the product
  • 3rd degree – people that sell, install, support, or make money from the product
• sequence stories based on:
  • priorities, events (e.g., milestones, release dates), dependencies with other teams, local priorities, capacity allocations for defects/maintenance/refactors
• allocate some time for refactors and maintenance, along with user stories
• non-functional requirements (NFRs) – system qualities (the “-ities”  – reliability, usability, scalability, maintainability, etc.)

• Acceptance Criteria
  • how you will known you have achieved the intent of the story
  • starting point for story acceptance tests
  • include both system behaviour and NFRs
  • defined during sprint planning (but can also come up during backlog refinement (i.e., before spring planning) or during design/build/test (i.e., after sprint planning))
• Acceptance tests are written to test that the system is working as intended; they will be used repeatedly because you need to make sure that they system keeps working as intended when you change things

• Definition of Done (DoD) – owned by the whole team
• an example of a DoD:
  • acceptance criteria met
  • unit test passed, included on kanban
  • coding standards followed
  • code peer reviewed
  • code checked in
  • story acceptance test passed
  • no must-fix defects
  • NFRs met
  • story accepted by product owner

• Agile Release Train (ART)
  • a virtual org of  5-12 teams (50-125 people) (a team of agile teams)
  • self-organizing, self-managing
  • plans/commits/executes together
  • common mission
  • common cadence
  • synchronized – system is sprinting together
  • normalized story point estimating
  • single program backlog
  • produces valuable Program Increments every 8-12 weeks
  • all “cargo” (cod, docs, supplemental) goes on the train
  • the system always  runs
  • but since it’s so frequent, if you don’t get on this train, you can just get on the next one

• Scrum of Scrums
  • meeting of all the scrum masters + the Release Train Engineer
  • twice per week
  • like a scrum, it’s focused on team progress and program impediments (and can be supplemented with a Meeting After for problem solving)

• Release Planning
  • two day session held every Program Increment (8-12 weeks)
  • everyone attends
  • develop a common set of program objectives for the next PI

Image credit:

• Kanban board – posted by Kanban Tool on Flickr with a Creative Commons license