Agile Fundamentals

scrum

transparency, inspection and adaptations

generating learning example: learning matrix

Helps team members find what is significant in their data • Especially useful when time is pressing Team is presented with a flipchart • Prepared, divided into four quarters ◦ Containing a smiley face, a frowning face, a light bulb, and a bouquet Team members write on sticky notes and populate the quarters with them Team members use sticky dots to vote for highest priority for attention • Each attendee has a strip of 6 to 10 dots

Essence of agile

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software"

Agile methods

• Increasingly product-focused • Manage features delivered by the whole team • Create plans throughout the project on a JIT basis • Are always iterative and incremental • Are often self-managed by the Development Team

Unit test supports the programmer

1. A unit test is an automatedtest for a single code block a. For example, a method or function b. Or a class c. Or a module 2. Written by a programmer implementing some functionality •a. Written in the same language as the production code 3. Provides her with a safety net to surround her code a. Giving her confidence to make changes and refactor 4. Therefore, unit testing is not in a separate "phase" a. It is an essential part of design and implementation

Kanban - A change management approach

1. Kanban is Japanese for "signal card" • Popularized through its use in the TPS ◦ And, subsequently, in Lean manufacturing 2. Origins in practices in U.S. supermarkets • Just-in-time shelf-filling, observed by Taiichi Ohno in the U.S. in the 1940s 3. Developed as a change management practice in software development • By Dave Anderson in 2007 4. Kanban's techniques focus on achieving fast, flexible flow throughout a value chain

information radiator: burndown chart

1. Plots the estimated effort left to complete an iteration or release goal against the amount of time left 2. Helps the team understand whether it is on track to meet iteration targets a. Or whether the team needs to replan

Scrum vs Kanban: differences

1) In Scrum: Timeboxed iterations are prescribed In Kanban: Timeboxing is not required 2) Scrum: Product Backlogs must be ordered Kanban: Prioritization is optional 3) Scrum: Product Backlog Items (PBIs) must be decomposed to fit within a Sprint Kanban: No particular item sizes are demanded 4) Scrum: New items cannot normally be added to a Sprint Backlog once work has begun Kanban: New items can be added whenever capacity is available 5) Scrum: Three roles are prescribed Kanban:No roles are prescribed 6) Scrum: Cross-functional development teams are prescribed Kanban: Specialist ("component") teams are allowed 7) Scrum: No one tells the Development Team how to do its work Kanban: Who decides the work and how it is done is not prescribed 8) Scrum: Only the Development Team can estimate effort kanban: Estimation by teams is optional "Pull" is by batching PBIs in a Sprint "Pull" is by imposing WIP limits on each work-state 9) scrum: Key metric is velocity kanban: Key metric is cycle time

issues and impediments

1. "Your use of Scrum will expose every reason why your enterprise has trouble building products. Scrum willkeep exposing the problems until they are fixed. 2. Whenever they [Agilepractices, etc.] cause a conflict with existing practices, an impediment has been encountered and made visible. The enterprise has to choose whether to change to remove the impediment or to give up some of the benefits." * 3. Scrum and other Agile approaches systematically surface issues and dysfunctions 4. The Agile mindset treats each one as an opportunity for improvement 5. An organization that acts in this way exhibits a Kaizenculture a. Kaizen is Japanese for "good change"

Information Radiator Scrum board

1. A Scrum Board is a visualization of the Sprint Backlog 2. Shows progress of stories toward "done" a. Optionally shows which team members are working on which tasks 3. Helps team synchronize its efforts toward achieving iteration targets a. Daily stand-ups often held around the board

Getting to done

1. A constant theme in Agile development: "Stop starting, start finishing" •In traditional development, the desire to maximize resources often leads to many jobs being worked on in parallel ◦People working on multiple projects at the same time ◦Teams working on multiple features at the same time •Causing all of them to be finished later than necessary if at all 2. Value can only be generated by finished work •WIP needs to be limited to maximize the chances of getting stuff done 3. In general, pull systems facilitate the limiting of WIP better than push systems Getting to "Done" 4. In a pull system, the team pulls from a pool of potential work according to its capacity, as opposed to having work pushed on to it externally

gathering data example: timeline

1. A large poster is created in advance containing all the events and milestones of the period being reviewed 2. Each attendee is given a bundle of colored sticky notes a. Writes comments on each according to a predefined color code b. For example: i. Blue = sad, mad, bad ii. Yellow = cautious, confused iii. Pink = challenged, confused iv. Green = happy, satisfied, energized 3. Attendees place notes on the timeline 4. Activity is debriefed

kanban rules (in manufacturing)

1. A later process tells an earlier process when new items are required 2. The earlier process produces what the later process needs 3. No items can be made or moved without a Kanban 4. Defects are not passed on to the next stage 5. The number of Kanbans is reduced carefully to lower inventories and to reveal problems

relative sizing

1. A popular approach is to estimate the size of stories relative to each other using story points 2. A team is estimating the relative effort of the entire team in delivering the wholestory a. Rather than estimating how long it would take an individual to complete a task 3. Values reflect uncertainty a. A scale loosely based on the Fibonacci series is typical b. 1, 2, 3, 5, 8, 13, 20, 40, 100 3. Consensus is achieved through techniques like Planning Poker

incremental delivery, iterative development

1. Agile methods promote incremental delivery •Allows value to be generated at the earliest opportunity ◦Even while the full product is still under development •Integrates feedback from users of the delivered product ◦Mitigating the risk of building a product that has no real value in the marketplace 2. Regular releases of quality-assured pieces of functionality requires iterative development •Engineering tasks such as analysis, design, and testing are repeated continuously ◦Reworking previously delivered product slices, where

Classes of service

1. Agile teams typically must support features they have released even while adding new ones to a product or service • As well as developing infrastructure, etc. 2. Kanban boards often reflect this with different classes of service • a. Expedite - Work items that need immediate attention. Often fatal defects that escaped into a previous release b. Fixed-Date - Work items that will incur a significant penalty if delayed beyond a specific date c. Standard - Priority-driven work d. Intangible - Business As Usual (BAU), maintenance upgrades, etc. ◦ Items of long-term value, difficult to quantify 2. Represented with horizontal swim lanes and/or color-coded tokens; Can also be used on Scrum boards (if required)

user stories

1. Agile techniques drive collaborative behaviors 2. User stories are a common technique for representing requirements a. Originated in XP, now widely used in Agile methods i. For example, as Product Backlog Items (PBIs) in Scrum 3. Stories are brief statements of user needs a. Designed to trigger just-in-time conversations about system requirements b. Between developers and customers i. System requirements documentation is the outcome of these conversations

roi

1. All product development is a cost •Until the product is released to customers, and value generated •In software development, almost all the cost is that of labor ◦In wider product development hardware, firmware and other costs have more weight 2. The single biggest risk is that insufficient value is generated to justify the cost

Scrum board (aka Task Board)

1. Although not mandated, most Scrum and XP teams use task boards • Either wall posters with cards and sticky notes • Or digital variations ◦ Generated by Team Foundation Server, JIRA, VersionOne, etc. Or even Excel • Or both in combination 2. Effectively, visualizations of the Sprint Backlog • Updated at least daily, preferably in real time 3. Daily stand-up meetings are often held in front of the board • Allowing the team to synchronize its efforts ◦ And "spin" (if necessary), adjusting its plan in the face of changes to deliver the expected value

visibility

1. An inherent problem with software development is that it is largely invisible a. Software is "thought stuff," essentially intangible - Unlike physical products 2. Cross-functional collaboration requires visibility a. Collaboration within the Development Team b. Collaboration between developers, customers, and other stakeholders 3. Making the development process open and transparent is a key characteristic of Agile development a. Often using information radiators* to lower communication costs

facilitating communication

1. Any project's rate of progress is linked to how long it takes to communicate ideas from one person to another a. Especially true of Agile teams 2. Communication costs include the time it takes to a. Find out who has relevant information b. Make an information request and get an answer

designing a scrum board

1. As with Kanban boards, tokens are moved across the Scrum board • As development progresses ◦ Cards and sticky notes tend to be used on wall posters 2. Columns on the board are simpler and fewer • Engineering tasks are either "not started," "in progress," or "done" • Additional columns are usually added for PBIs and their completion Designing a Scrum Board

reflection

1. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly (princple 12) 2. The purpose of reflection is for the team to take action to become more effective a. So that the next iteration is more productive and more enjoyable 3. Best done through facilitated workshops 4. People, relationships, processes, and tools are inspected a. By asking the questions: 1. "What went well during the last iteration?" 2. "What could have been better if done differently?" 5. The outcome should be actionable items for the next iteration put back in the backlog

Scrum and Kanban compared: similarities

1. Both are Lean and Agile 2. Both use pull mechanisms to limit work in progress 3. Both demand visibility of the development process -So that it can be improved 4. Both require breaking work into smaller pieces 5. Both optimize the release plan continuously • Based on empirical data

ongoing customer collaboration

1. Collaborative approaches can be used at many levels a. Establishing the product vision i. Product, or project, chartering b. Release planning c. Iteration planning and feedback d. Daily planning 2. Typically, but not exclusively, through cross-functional workshops

information convection currents

1. Cost-effective collaboration relies on exploitation of "information convection currents"* a. Within and around the team b. Analogy is with movement of heat and gas 2. Alistair Cockburn* uses this metaphor to stress a. Osmotic communication b. Information drafts c. Information radiators

Actively engaging stakeholders increases the likelihood of

1. Product not veering off track due to unresolved stakeholder issues 2. Enhancing the ability of people to operate synergistically 3. Limiting disruptions

customers

1. Customers are the most salient group of stakeholders from an Agile perspective a. The most powerful and the most appropriately relevant b. Require the most immediate attention 2. The customer is a. the individual or group that uses the created product to generate business value or, in the case of retail product the person who uses the product. Customers define value and are the judges of user experience 3. Other stakeholders include a. Internal managers who are not direct customers, architects, domain experts b. External participants (vendors, regulatory bodies, etc.) 4. Broadly, these other stakeholders contribute oversight and constraints 5. While customers (who are also stakeholders) provide requirements

Daily Plan

1. Daily stand-up meetings are typical of Agile teams a. Called Daily Scrums in the Scrum framework 2. Aim is for Development Team members to update each other on progress a. So that they can synchronize on their plan for the iteration b. And replan, if necessary

What is continuous integration?

1. Each increment of functionality is fully integrated with previous ones a. Implicitly part of any definition of "Done" 2. Infinitely easier if CI is in use a. CI becomes even more important for large projects b. With multiple teams 3. "Continuous Integration is a software development practice where membersof a team integrate their work frequently, usually each person integrates atleast daily—leading to multiple integrations per day. Each integration is verified by an automatic build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly." *

Classes of customer

1. Effective customer engagement also requires understanding different kinds of customers 2. Commissioning User a. Customer who ultimately is paying for the development b. Views the product or service as a commodity i. Primarily interested in value for money ii. Less interested in detailed requirements 3. Customer Sponsor a.May also be a kind of commissioning user b. Often a senior manager in the business and person most likely to benefit c. For example, the Sales Director may sponsor a new CRM system d. And/or someone who liaises with a real customer i. For example, acting as their "agent" within Product Management 4. End user a. Someone who uses the product or service directly i. In their job, or (for retail products) as a consumer

CI is not a tools issue

1. Efficient CI requires automation a. Includes automation of testing b. Requires changes in human behavior by theDevelopment Team 2. The precondition for successful CI is that developers have the discipline to a. Integrate regularly and maintain their integration environment b. Grow an always-working, stable system c. Work in small batches d. Integrate on the "mainline" or "trunk" 3. TDD enables integrating code every 10-20 minutes in a mature Development Team

Estimation Effort

1. Effort estimation is a necessary part of planning 2. Who does the estimation differs across Agile methods a. In Scrum, only the Development Team is allowed to estimate effort b. In Kanban, the team is not required to do so - Often left to management 3. General rule is: size the features first, then derive the schedule a. Irrespective of who is doing the estimation 4. Estimation should be accurate enough to deliver some level of predictability about how much functionality can be delivered and when a. But does not have to be precise 5. In general, this is best done by breaking the items into small enough pieces a. Much more important than the use of any particular metric

seven principles of lean

1. Eliminate waste- Identifying wastes and removing them from the process adds value 2. Amplify learning - Facilitate communication and feedback; embed what is learned 3. Decide as late as possible - "The last responsible moment" is the point at which any option times out by default 4. Deliver as fast as possible - To maximize ROI, gain rapid feedback, and get the best solution through rapid evolution 5. Empower the team- They are the development experts, best positioned to make the best choices Build integrity in - Apply quality assurance throughout design and development. Do not shoehorn quality in at the end 7. See the whole -The system is more than the sum of its parts; Local optimizations may be harmful to the overall delivery of value

information radiator: cumulative flow diagram (cfd)

1. Essentially displays the history of a Kanban Board by reporting the number of tickets in each stage over time 2. Team can use the CFD to measure lead time and cycle time, and to identify bottlenecks in the workflow a. To which resources can be moved to smooth it

Product envisioning outputs

1. For - Target customer 2. Who- Statement of need or opportunity 3.The - Product name- is a- Product category 4. That - Key benefit, compelling reason to buy 5. Unlike - Primary competitive alternative 6. Our product - Statement of primary differentiation

forward planning example: circle of questions

1. Helps develop plans for action in the next iteration 2. Team sits in a circle a. With no table in the middle b. With a flipchart nearby to record outcomes 3. Facilitator turns to member on the left and asks a question a. For example, "What is the most important thing for us to try in the next Sprint?" 4. The team member answers the question to the best of its ability 5. Respondent then asks a question of the person to the left a. Perhaps expanding the previous discussion b. Or starting a new one 6. The process is repeated until a.Topic is exhausted b. Consensus as to action is retrieved (and recorded) 7. Optionally, further topics can be considered in the same way

iteration planning

1. In Kanban, iteration planning can be as simple as a request for a (specific) number of items for development a.For example, "What top three items should we work on in the next 30 days?"* b. Planning cadence and development cadence can be decoupled-And planning can be done by management, outside the team 2. Scrum and XP's timeboxed inspect-and-adapt cycles require planning and development to have the same rhythm a. For example, every Sprint in Scrum starts with a Sprint Planning meeting 3. Updated roadmaps and release plans are typical inputs to iteration planning meetings 4. Outputs will include a. An iteration goal or sprint goal - The value anticipated to be achieved by the end of the iteration b. Set of stories the Development Team forecasts it can implement c. Construction and development plan for the iteration - The Sprint Backlog in Scrum

Prioritizing the back log

1. In Scrum, the Product Owner owns the Product Backlog and orders the work items within it •Business value is the main driver ◦Others are risk (including technical risks), dependencies, constraints, etc. 2. Assumes responsibility for ROI and TCO through decisions about the Backlog 3. Agrees a Sprint Goal with the Development Team at the Sprint Planning meeting •And the list of Product Backlog Items (PBIs) that they will deliver to implement the Sprint Goal •The Development Team then constructs its Sprint Backlog ◦Its plan to meet the goal

Minimal Releasable Features

1. In all cases, the aim will be to ensure a delivery of a set of Minimal Releasable Features (MRFs) a. Contain enough accumulated value to be usable by the customers 2. Implies that those features are prioritized more highly than others a. Minimizing the risk of them not being developed in time b. Especially true if there is a fixed release date constraint - Other features delivered at the same time are an added value bonus 3. MRFs should be delivered as soon as possible a. In the absence of fixed release dates

Engaging Customers and Stakeholders

1. In master-planned development, customers and stakeholders are mostly engaged at the beginning and at the end a. At the beginning, prior to signing off a requirements specification b. At the end, from User Acceptance Testing (UAT) onwards 2. Risk is that a. The signed-off requirements do not reflect the required value at the endof development i. Changes in business and/or technology not fully taken into account b. Defects are only made visible when the cost of change is highest 3. Contracts are drawn up to deal with the risk a. Fixed price contracts push most of the risk onto the developer b. Time and materials push most of the risk onto the consumer 4. Agile approach is to treat customer and developer as peers a. XP refers to the whole team i. All stakeholders are on the same side b. Maintain engagement throughout product development

Information Drafts

1. Information drafts are unwanted information a Noise in an open-plan office b. Or where the separating walls are too thin c. Cause high distraction rates 2. Drafts can also occur within colocated teams a. Some individuals require some solitude to concentrate on their work b. People need privacy to deal with e-mails, have private conversations, etc. 3. Therefore, the needs is to balance forces a. Increase information flow b. Eliminate "draftiness" 4. XP recommends a "Caves and Common" office base for colocated teams a. Presupposes a single-project team b. Strong team dynamics c. Provision for both private and common project space

problems with traditional approach

1. It is nearly impossible to define all requirements before development begins •On average, 35 percent of requirements will change* 2. Encourages the impression that all requirements are "must haves" •And therefore disengagement of stakeholders after they are signed off 3. Value tends to be a moving target •When expressed in terms of requirements ◦Business-and technology-driven changes impact the product even as it is being delivere

stakeholder analysis

1. Stakeholder analysis is the classification of stakeholders a. Typically by power/interest, power/influence, influence/impact, and relevance

Kanban as a pull system

1. Kanban systems are the archetypal pull systems The VSM is mapped on to a Kanban Board •A column is created for each value-adding state (or stage), and for each queue where a work item might be in a wait state •Explicit WIP limits are set for each stage ◦The maximum number of items that can enter the stage at any one time •No upstream stage passes on work unless it has been requested by the next downstream stage •Tokens representing the work items cross the board as they pass through each stage 2. The process begins by the team asking which two (say) items should be prioritized over the next work period

Extreme Programming (XP)

1. Kent Beck's work on the Chrysler Comprehensive Compensation (C3) system which he joined in 1996 2. borrows much from Scrum 3. Main significance is in its engineering practices 4. standard practices in Agile a. Pair programming b. User stories c. Test-driven development

Development Cadence in Kanban

1. Lean and Kanban tend to decouple planning from development and delivery cycles •Development iterations do not have to be timeboxed 2. Rapid ROI through speedy delivery is achieved by focusing on the flow of work •Described as a system of queues and control loops that has to be managed •Eliminating or streamlining non-value adding activity •Removing bottlenecks 3. Value stream maps can be used to visualize the sequence of value-adding stages the product must go through •The aim is then to reduce the cycle time to delivery to its minimum ◦Lead time* is the total time "from soup to nuts" From concept to cash, or from request to delivery •Increased process efficiency = increased ROI

lean software development

1. Lean software development is largely a translation of the thinking of Lean manufacture and Lean IT 2. Popularized initially by Mary and Tom Poppendieck* 3. The main objective is to eliminate waste and maximize the flow of value a. Reducing queues b. Stripping out non-value adding practices c. Removing bottlenecks 4. Ideally, Lean practices are applied across an entire value stream (from beginning to end) a. The sequence of value-adding stages in a production process 5. Not a method in itself - Has given rise to Kanban, Scrumban and other approaches

information radiator: kanban board

1. Maps, potentially, an entire value stream 2. Shows the progress of tickets as they are pulled through the value-adding stages a. Each stage controlled by an explicit WIP limit 3. Enables the team to manage the flow of work over the lifetime of a product or service

Building Agile Capability for Organizations

1. Organizations building their Agile capability need 2. Knowledgeable Agilists at every level a. In all disciplines 3. Experienced Agile professionals a. Who have applied their learning in different contexts 4. Validation of deep-learning and competency a. Through industry-recognized certification bodies i. Scrum Alliance ii. ICAgile iii. Lean Kanban University iv. Scaled Agile v. PMI vi. APMG

osmotic communication

1. Osmotic communication occurs when information is "overheard" a. Information is radiated outwards from person-to-person conversations 2. Lowers the general cost of communication a. Reduces the number of conversations needed 3. Lowers the cost of communication delay a. No need to search for the information b. Questions don't have to be asked directly- Or answers waited for 4. Reduces "lost-opportunity" costs a. When information sources are difficult to find, the search may be abandoned 1. Assumptions will be substituted, including many false ones - Causing errors to be designed and coded 5. Maximum benefit occurs when people work side by side a. Colocation

the 12 principles behind the agile manifesto

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity—the art of maximizing the amount of work not done—is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

XP Team Member

1. Programmers, designer, architects - How to design and develop the product 2. Product Manager (Owner) and On site owner - Importance of the product 3. Domain experts - Rules the product should follow 4. Interaction Designers - How the product should behave 5. Graphic Designers - How the product should look 6. Testers - Where defects are likely to hide 7. Project managers - How to interact with the rest of the company 8. coach - where to improve work habits

quality from day one

1. Quality cannot (easily) be shoe-horned in at the end of an iteration a. For example, no time to fix bugs found in testing b. Too heavy a burden for the tester 2. Quality Assurance must be every team member's responsibility a. And should be exercised every day of development 3. For this reason, Agile teams should include testers as well as programmers a. As the minimumstep toward cross-functionality 4. It is a good idea to pair programmers and testers early a. So they learn from each other about what it takes to deliver quality

Scrum and XP as Pull Systems

1. Scrum and XP teams also use a pull system to limit WIP •And balance the demand for work with capacity 2. The approach is a time-boxed one with small batches •Based on Sprints 3. Based on the Development Team's understanding of its capacity and velocity •Capacity = the total number of person-hours available in the Sprint for working on this product •Velocity = the team's history of delivery in previous Sprints 4. The team pulls work items from the Product Backlog into its development plan for the current Sprint •At the Sprint Planning meeting

Development and delivery cadence in scrum and xp

1. Scrum and XP work on a tightly coupled planning and development cycle •A constant iteration length of two weeks is typical ◦One month is the maximum timebox for a Sprint in Scrum 2. Both emphasize the importance of regular builds that meet the standards of releasability •Scrum requires that a working product be demonstrated to stakeholders at the end of every Sprint ◦A "potentially shippable increment of functionality" ◦The increment must meet the Scrum team's definition of "Done"* to be considered potentially shippable 3. Actual release to the customer depends on a judgment call •Whether or not enough usefulvalue has accumulated to generate value •In Scrum, the Product Owner makes the call on behalf of the customer The release cycle does not have to be as regular as the development

Driving characteristics of agile product development

1. Self-organizing teams -Empowered to make decisions about the product 2. Rigorous inspect-and-adapt cycles - Which may or may not be timeboxed 3. Obstinate focus on customer value - Refusal to be distracted by secondary concerns 4. Incremental delivery and iterative development - Reworking, when necessary, for effectiveness 5. Continuous improvement - Always innovating to get better

Basic Structure of Retrospectives

1. Set the stage a. Simple welcome, agenda b. Reminder of values, working agreements 2. Gather data a. Hard data: burndown charts, task boards, events, milestones b. Activities to gather feedback from attendees 3. Generate insights a.Activities to help attendees b.Identify repeatable patterns of success c.Analyze breakdowns and deficiencies 4. Decide what to do a. Activities to help the team b. Identify the top issues for improvement and/or experimentation for the next Sprint, release, or project 5. Close the retrospective a. Activities to document the retrospective b. Plan for follow-up c. Retrospect the retrospective

XP Process

1. Teams range in size from 5 to 20 (Scrum 3 to 9) 2. typically 12 - 6 programmers, 1 on-site customer, 4 testers and a PM 3. 1 programmer would act as coach 4. User Stories -> release planning ->Release plan -> iteration planning -> Iteration plan -> pair programming -> product increment -> customer approval -> small release

mounting technical debt

1. Technical deb trefers to product that is not fully fit-for-purpose in some way a. May have defects or otherwise falls short of quality standards 2. Metaphor based on personal debt a. Interest grows as long as the capital is not paid off 3. Can be a particular problem if causes are not addressed for Agile a. Incremental delivery may mean escaped defects having to be dealt with b. Impacting the planned-for development of new value 4. The "Whack-a-Mole" pattern is favored a. To minimize debt, fix the problem as soon as it reveals itself b. May require a change in engineering practices

test driven development

1. Test-driven developmentkeeps teams on topic a. Ensures that programmers are always working to specification - Even as requirements evolve 2. TDD uses small tests to drive each increment of code a. Developer imagines a small behavior required by the code - Typically occupying as little as five lines of code when implemented b. Then writes the test for the existence of the behavior 3. No production code is written unless there is a failing test in existence a. The test is run with the entire suite of previous tests and fails b. Then the simplest code possible is written to pass the test 4. Refactor for design quality a. Once all the tests are passing, the code can be reworked for design quality and conceptual integrity b. And be retested

how programmers and testers work together

1. Testers can help programmers understand how quality is validated a. Helping programmers create Test Ideas Catalogs (TICs)-Checklists for testing in various domains b. Paving the way for unit-testing, test-driven development, etc. 2. Programmers can help testers understand what it takes to pass their tests a. And pass on simple programming skills i. That testers can use when not actually testing

agile value driven triangle

1. The Agile Model focuses on (business) value •And on quality 2.Constraints are managed to deliver maximum value •Including cost and time

the agile fluency model

1. The Agile fluency model is a useful guide for determining where teams and organizations should invest in Agile 2. A four-level model to help teams and organizations decide which level to shoot for a. Based on measuring benefits against required investment 3. Notice that higher levels involve wider organization change a. Implies training roles outside of software development

definition of stakeholders

1. The PMBOK Guide*definition of a stakeholder: 2. Actively engaging stakeholders increases the likelihood of a. Product not veering off track due to unresolved stakeholder issues b. Enhancing the ability of people to operate synergistically c. Limiting disruptions 3. The PMBOK Guidetalks of "managing" stakeholders a. Agile talks of engaging stakeholders a. Involves managing methods and styles of communication

The customer - team interface in scrum

1. The Product Owner role in Scrum acts in part as a customer proxy a. Responsible for the ROI and TCO of the product 2. Ensures domain knowledge and understanding of business value is brought into the Development Team a. Maintains the product vision b. Sets release and iteration goals c. Orders the items in the Product Backlog i. Primarily by customer-perceived value

How to avoid breaking the build

1. The major risk in CI is that any new codeintegration might break the build 2. This risk can be mitigated by a number of tactics a. Splitting large changes into smaller ones while keeping existing functionality working b. The more skillful developers become at splitting, the easier integration is c. Reducing non-value added work to speed integration such as reducing or eliminating sign-offs and approvals d. Increasing the speed of the safety-net feedback cycle e. If unit testing is slow, developers may only be able to run a subset leaving the rest to the CI system f. Speeding the feedback cycle decreases the chances of a broken build by increasing the ability to check in more frequently

documentation

1. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation 2. An issue with the up-front, signed-off requirements specification is that it discourages further communication between customer and developer a. Interim artifacts become the main method of communication 3. It is during development that most new information is discovered a. And when collaboration is most valuable i. Among members of the Development Team/organization 11. Between the Development Team as a whole and customers 4. Valuable documentation should be created and maintained a. As efficiently and cheaply as possible i. Autogenerated where feasible 5. Documentation that substitutes for collaboration is frowned upon

threats to throughput of value

1. The rules of the various Agile methods mitigate against WIP 2. But it is still possible to generate excess WIP while seemingly following them 3. If the WIP limits on a Kanban board are set by management rather than by the teams themselves a. Managers may try to raise the WIP limit in the mistaken belief they could improve throughput i. In which case, the Kanban Board would act as a push rather than a pull system 4. If Scrum or XP teams work on multiple PBIs in parallel a. Generally better for teams to "swarm" to get one item to "done" at a time Threats to the Throughput of Value

agile release plans

1. There is no prescribed format for Agile release plans 2. Many teams will start with a. A product vision - Output, perhaps, from a collaborative envisioning workshop b. A set of high-level PBIs that reflect the vision- First-cut business epics that "seed" the initial Product Backlog b. A road map- Aligning epics with target release dates- And, perhaps, with the iterations in which they might be delivered 2. This release plan is owned by the Product Owner in the case of Scrum and XP* a. Who brings it for refinement to subsequent release-planning activities b. For example: 1. Release-planning meetings 2. Iteration-planning meetings 3. Requirements workshops

stories: an example

1. There is no standard format for writing stories 2. The example below is typical a. As a <role>, I want <feature> so that <goal> b.Known as the Connextra format 3. The back of the card describes the acceptance criteria for the story

Test Driven Design

1. Traditionally, testing has been defined as the process of executing a program with the intent of finding errors 2. TDD is more fundamentally a design technique a. The programmer is always writing to specification 3. ...but one that also drives out errors a. Almost as a side-effect b. With the additional benefit that bugs can be found and fixed immediately 4. "Test-first coding is not a testing technique" —Ward Cunningham, XP thought leader* *Quoted

principles of kanban (in software)

1. Visualize workflow • Knowledge work is often invisible • Visualizing it allows us to spot bottlenecks and recurring quality problems 2. Limit Work-In-Progress (WIP) • Balance demand and capability • Limiting WIP allows teams to work with sustainable pace 3. Manage flow • Manage constraints and measure flow ◦ Most common measurements are flow throughput and cycle time 4. Make policies explicit (e.g., a definition of "done") 5. Implement feedback loops • Helps you learn whether you are getting it right during product development 6. Improve collaboratively; evolve experimentally • Evolve using problem solving, experiments, and scientific methods

agile fluency

1. What we are trying to create is Agile fluency 2. Fluency is achieved through the building of new "muscle memory" a. Training ourselves, our teams, and our organizations in new behaviors 3. "[Agile] fluency is how a team develops software when it's under pressure. Anyone can follow a set of practices when given time in a classroom; true fluency is a skillful, routine practice that persists when your mind is distracted with other things." —Diana Larsen and James Shore*

XP Core Practices

1. Whole team •All contributors to a project sit together in the same location, as members of the same team 2. Planning game •Negotiation between customer and developer for Release Planning and Iteration Planning 3. Small releases •Frequent, small releases to test environments are encouraged ◦For measuring progress and for feedback from the customer 4. Customer tests •Customer describes acceptance tests to help define functionality 5. Collective code ownership •Any (pair of) programmers can amend the code base―it belongs to the whole team 6. Code standards •All programmers follow a consistent code standard 7. Sustainable pace •Highest level of productivity is achieved by a team operating at a sustainable pace 8. Metaphor •Metaphors and similes are used to create a shared technical vision 9. Continuous integration •Automatic integration every time code is checked in by a developer •Surfaces broken builds and other issues so they can be fixed early 10. Test-Driven Development (TDD) •Programmers code automated tests prior to developing the production code that must pass it 11. Refactoring •Changing code structure―to improve quality―without changing its function •Focuses on removing duplicated code, lowering code coupling, increasing cohesion 12. Simple design •Keeping the design simple, but adequate, to avoid "gold plating" and unnecessary complexity that is difficult to change 13. Pair programming •Production code written by two developers at a single workstation •Provides real-time code reviews •Facilitates the spread of learning through the team

The customer team interface in XP

1. XP has the notion of on-site customer a. Defines the software the team builds b. May be a real customer c. Or the role may be played by any one of i. Product manager, domain expert, interaction designer, business analyst, etc. 2. Most important activity is release planning a. Evangelizes the project vision b. Identifies and groups user stories and features i. Usually writes the stories 3. Must supply requirements details on request a. Acts as living requirements document 4. Considered to be part of the whole team a.Sits with the development team in a shared space

mounting debt principle

1. debt accumulation is so high that you can only pay the interest and not pay the principal 2. that is you can only work on the bug fixes and not on the new sprints

Seven wastes

1. in process inventory - partially done work 2. over production - gold plating 3. extra processing - unused documentation, unnecessary sign off 4. transportation - hand off 5. motion - task switching 6. waiting - delas defects - requirements defects, bugs

XP Circle

1. outer - whole team, customer tests, small releases, planning game 2. mid - code standard, continuous integraiton, collective ownership, metaphor, sustainable pace 3. inner - test driven development, simple design, pair programming

quality is not tradeable

1. principle - continuous attention to technical excellence and good design enhances agility 2. In the Agile model, quality is never traded for speed of delivery a. Quality standards are enshrined in the definition of "Done", or its equivalent 3. Means, minimally, that an item must be fully tested and integrated a. And has passed all its tests, including integration and regression tests

communication barriers

1.A typical target of continuous improvement efforts is communication barriers 2. Barriers between senior management and others in the organizational hierarchy a. Causes lack of alignment on business goals, objectives 3. Barriers between the business side and the development side c. Confusion as to the real value proposition 4. Barriers between end-users and developers a. Leading to barely usable products 5. Barriers between members of the Development Team a. Divergence of effort and creation of waste through WIP

project roadmap

Agile Product Roadmaps focus on priorities, not timelines • Are typically revisited at every iteration Planning Meeting the roadmap is used to build the product backlog

Agile Methods

Best characterized by reference to 1. The Agile Manifesto for Software Development, 2001 2. The 12 principles of Agile development

Designing a Kanban board

Burrows* suggests a top-down approach to designing a Kanban board 1.Identify the commitment points •The point at which the team(s) commit to start building or servicing something •The point at which it is delivered, deployed, or otherwise completed 2.Give category names to states or activities between commitment points •Typical examples include ◦Backlog (the list of potential work items) ◦Engineering ◦Implementation ◦"Done" 3.Decompose as necessary •For example, engineering could be broken into Development and Test 4.Identify the queues where work exists between active states •Usually found at hand-over boundaries

kanban board vs scrum board

Despite superficial similarities, Kanban boards and Scrum boards play different roles Kanban boards last as long as the product • They map the entire flow of value • Provide visualizations that help the team understand how to smooth the workflow ◦ Improve process efficiency, reduce cycle time • Tokens are coarse-grained ◦ Typically, features • May reflect the work of many teams working on different stages Scrum Boards are reset every Sprint • They represent the development and construction plan for the currentSprint only • Are owned, and organized, by a single Scrum (or XP) Development Team • Are fine-grained ◦ Show tasks for PBIs as well as the PBIs themselves Kanban Board vs. Scrum Board1

Traditional iron triangle of management

Requirements fixed early "Success" is implied if other constraints are controlled •And full scope delivered Goldent triangle - budget, scope and time

The planning onion

The Planning Onion Effective planning requires setting and planning goals that we can see • Accuracy decreases as the planning horizon recedes Agile planning is just-in-time, but operates on at least four levels • Product vision, Release, Iteration, and Day

Effectiveness vs. Efficiency

The paradigm shift involves recognizing that our old methodsdon't work 1. They are the wrong tools for the types of problems we face 2. shifting from a primary focus on "efficiency"; 3. to a focus on effectiveness - Co 4. In short, Agile product development is about responsiveness - "faster, better, cheaper"

product envisioning (aka product chartering)

Traditionally, project envisioning involves long lead times • Gaining consensus on resources • Sign-offs at multiple levels of management hierarchies Agile favors light-touch, "barely sufficient" techniques • To gain consensus on the big picture ◦ Between stakeholders and developers Typically half-day, collaborative workshops; outputs include • A product vision "box" or cover story vision • An elevator statement • Optionally, a product roadmap ◦ Birds-eye view of potential release goals through the product timeline

Traditional development methods

Typically project-focused 1. Manage activities performed by specialist roles 2. Create up-front master plans 3. May be waterfall or iterative and incremental 4. Tend to be managed top-down

agile manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: a. Individuals and interactions over processes and tools b. Working software over comprehensive documentation c. Customer collaboration over contract negotiation Responding to change over following a plan

What is agile development

a. Promotes development through iterations, open collaboration, and process adaptability throughout the life cycle of the project b. Chooses to do things in small increments with just-in-time planning of work episodes rather than front-end master plans c. There is also an emphasis on stakeholder involvement and rapid feedback cycles throughout the product life cycle

development team

accountable, first and foremost, to the Development Team itself. In turn, the Development Team as a whole is accountable for the work of every individual member. There is no rank in the Development Team. The team is not allowed to accept work other than that listed in the Product Backlog (owned by the Product Owner), and no one is allowed to tell the team how to do its work.

timeboxing

all mandatory events of scrum are timeboxed to maximum lengths - dont want to get caught in analysis paralysis

value stream map

boxes are working on, triangles are queues of work items or inventory in the language of lean

TPS (Toyota Production System)

described as a management system designed to absolutely eliminate waste

empirical process theory

empiricism - theoretical foundation of scrum its rules, roles, events and artifacts are mandatory

scrum master

is accountable for Scrum itself. Coaches the Scrum team in agility, and acts as a change agent in the wider organisation. As a servant-leader has no formal authority whatsoever.

product owner

is accountable for the business value of the product—the only person with any individual, formal authority in the Scrum team.

mini waterfalls do not work

many new agile teams try and meet scrum's quality requirements by applying waterfall at the iteration level this does not work