Agile - Scrum Primer

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

1. Customer Satisfaction
2. Welcome Changing Requirements
3. Deliver working software/product frequently
4. Business people and developers (team and customers) work together daily
5. Build Products around motivated individuals
   
6. Most efficient and effective method of conveying information is face2face
   
7. Working SW or product is the primary measure of progress, based on delivering value to customer
   
8. Agile processes promote sustainable dev
   
9. Continuous attention to technical excellence and good design enhances Agility, accomplished
   
10. Simplicity - the art of maximizing the amount of work not done, via
    
11. Best architectures, requirements, and designs arise from self-organizing teams
12. At regular intervals the team reflects on how to become more effective, then tunes and adjusts behavior accordingly

With agile software development the requirements for the project do not have to be codified upfront, instead they are prioritized and scheduled for each iteration.

There are many Agile frameworks that have been created and evolved over the years.  A non-exhaustive list could be considered to be:

1. Kanban
2. Scrum
   
3. Lean
4. XP - Extreme Programming
5. AUP - Agile Unified Process
6. DAD - Disciplined Agile Delivery
   
7. TDD - Test Driven Development
8. RAD - Rapid Application Development
9. Crystal, made up of several agile processes, including Clear, Crystal Yellow, Crystal Orange, and other uniquely characterized methods.
   
10. DSDM - Dynamic Systems Development Method
11. FDD - Feature Drive Development
12. SAFe - Scaled Agile Framework

(Note:  Much of the following detail was pulled directly from Wikipedia and other online sources.  As this is a private document, not for publication, effort has not gone into completely sourcing the arguments.)

1. Kanban
•  In earlier days of software development, many teams relied on Scrum, a method that uses timeboxing, rules, and strict role assignments, to help them deliver batches of work on schedule. But as flexibility and adaptability have become increasingly important elements of the development process, teams have been searching for a workflow management method that allows for both the structure to keep progress moving and the flexibility to adapt to market changes.   The driving concepts of Kanban were first developed on the shop floor of Toyota, right after World War II. The Japanese manufacturer was desperate to compete with Western companies in the midst of an economic downturn. In order to reduce operating costs, they began experimenting with a system that processed small amounts of raw inventory quickly, a system that came to be known as just in time manufacturing. A disciplined emphasis on small batch sizes, continuous flow, and eliminating waste helped Toyota outperform its competitors and establish a sustained advantage for decades to come. The practices and principles Toyota used came to be known as the Toyota Production System, a system that was used by Western manufacturers, and later, companies from all industries, to reduce waste and improve sustainability and profitability. Kanban shares many common concepts with TPS, such as:
  
• An emphasis on eliminating waste in processes and practices
  
• A deliberate practice of limiting work in process (WIP)
  
•  An emphasis on optimizing flow A disciplined approach to teamwork, collaboration, and leadership
  
• The use of a clearly defined process with distinct steps
• Basics of Kanban Software Development:
1. Visualize Work
   
• Creating a Kanban board is the first step towards visualizing your software development process. By creating a visual model of your work and workflow, you can observe the flow of work moving through your Kanban system. The first step towards visualizing your work is to understand the distinct steps your work goes through as it moves from “To Do” to “Done.” These will become the lanes on your Kanban board. Most software development teams follow some version of the following process: Gather Requirements > Design > Implementation > QA > Deploy > Maintain. We recommend undergoing a value stream mapping exercise to identify your team’s unique process steps. Visualizing work in Kanban means not only visualizing the process, but visualizing each piece of work (represented by a Kanban card) as it moves through that process. Teams find that making the work visible, along with blockers, bottlenecks and queues, instantly leads to increased communication and collaboration. Visualizing all work across the team also helps establish accountability and transparency across the team. This is invaluable, especially for software development teams, which require coordinated efforts to get their work done efficiently.
2.  Limit Work in Process
   
• Software development teams can easily get overwhelmed with their long list of to-dos; between new features, bug fixes, maintenance work, and other project work, teams often struggle to prioritize work in a disciplined, methodical way. An important concept in the Kanban software development process, then, is limiting work in process, or WIP. By limiting how much-unfinished work is in process, you can reduce the time it takes an item to travel through the Kanban system. You can also avoid problems caused by task switching and reduce the need to constantly re-prioritize items. Limiting WIP at both the personal and team levels can help software development teams move faster, reduce error, and collaborate more effectively.
  
3. Focus on Flow
   
• A deliberate emphasis on optimizing for flow is a critical element of any Kanban software development process. Flow describes the way work moves through your Kanban system. Good flow means that work moves in a fairly linear path, from one step to another with little delay between them. Bad flow happens when work stops and starts abruptly, spends lots of time in wait states, or moves between different steps without making significant progress. Using WIP limits is great first step towards optimizing for flow. By limiting WIP, you limit one of the biggest obstacles to good flow: an excess of active work. But this is not all; you must, as a team, work to keep each piece of work moving forward. Many teams discuss ways to improve flow at a daily standup, where they ask questions such as: What can we do to move existing cards off the board? Is there anything we can help to finish before we pull next work? Has anything been waiting in the same place for more than a day? What can we do to get it moving again? You can also use process policies to maintain consistently good flow, by creating rules that all cards (and therefore, all team members) must follow. These might include: WIP limits on each lane, to prevent bottlenecks A policy on how to handle blockers A policy that dictates conditions that must be met before a new card can be pulled into an active lane A policy for “stale” work – work that has been sitting for a period that is longer than usual Focusing on optimizing for flow can help software development teams stay productive, efficient, and ever-evolving on their path of continuous improvement.
  
4. Continuous Improvement
   
• Kanban is a system of evolution, not revolution; it is not meant to force your team to completely change everything it does. A Kanban system is most effective when it reflects reality, which is why we always recommend that teams start by designing a board that accurately reflects their existing process. From there, you can thoughtfully, carefully practice continuous improvement, a perpetual process of making small, meaningful changes that help your team perform more efficiently and effectively. As you use your Kanban board, you’ll notice opportunities for practicing continuous improvement. Implement these changes one at a time, and measure their impact so you can maximize your learning. Follow these four basic elements of the Kanban software development process consistently, and you’ll find the balance between discipline and flexibility that your team needs to succeed.
  


2. Scrum, or SCRUM, is a framework for project management[1] with an initial emphasis on software development
• Scrum has been used in other fields including research, sales, marketing and advanced technologies. It is designed for teams of ten or fewer members who break their work into goals that can be completed within time-boxed iterations, called sprints, no longer than one month and most commonly two weeks. The scrum team assesses progress in time-boxed daily meetings of 15 minutes or fewer, called daily scrums (a form of stand-up meeting). At the end of the sprint, the team holds two further meetings: one sprint review which demonstrates the work done for stakeholders to elicit feedback and one sprint retrospective which enables the team to reflect and improve.
  The term scrum is borrowed from rugby, where it is a formation of players. The term scrum was chosen by the paper's authors because it implies teamwork. The software development term scrum was first used in a 1986 paper titled "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka. The paper was published in the Jan 1986 issue of Harvard Business Review. Scrum is occasionally seen written in all-capitals, as SCRUM. While the word itself is not an acronym, its capitalized styling likely comes from an early paper by Ken Schwaber that capitalized SCRUM in its title. While the trademark on the term scrum itself has been allowed to lapse, it is now deemed as a generic trademark owned by the wider community rather than an individual.
  KEY IDEAS:
  SCRUM is a lightweight, iterative, and incremental framework for developing, delivering, and sustaining complex products.  The framework challenges assumptions of the traditional, sequential approach to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved. A key principle of scrum is the dual recognition that customers will change the scope of what is wanted (often called requirements volatility) and that there will be unpredictable challenges—for which a predictive or planned approach is not suited. These changes come from a variety of sources, but according to scrum, understanding why is irrelevant, and change should simply be accepted, embraced, and analyzed for benefits.
  HISTORY:
  Hirotaka Takeuchi and Ikujiro Nonaka introduced the term scrum in the context of product development in their 1986 Harvard Business Review article, 'The New New Product Development Game'. Takeuchi and Nonaka later argued in The Knowledge Creating Company that it is a form of "organizational knowledge creation, [...] especially good at bringing about innovation continuously, incrementally and spirally". The authors described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, photocopier, and printer industries.  They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, in which the team "tries to go the distance as a unit, passing the ball back and forth". (In rugby football, a scrum is used to restart play, as the forwards of each team interlock with their heads down and attempt to gain possession of the ball. The scrum framework was based on research by Schwaber with Babatunde Ogunnaike at DuPont Research Station and University of Delaware. Ogunnaike advised that attempts to develop complex products, such as software, that weren't based in empiricism were doomed to higher risks and rates of failure as the initial conditions and assumptions change. Empiricism, using frequent inspection and adaptation, with flexibility and transparency is the most suitable approach.
  
3. Lean
• Lean software development is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System,[1] it is emerging with the support of a pro-lean subculture within the agile community. Lean offers a solid conceptual framework, values and principles, as well as good practices, derived from experience, that support agile organizations. The term lean software development originated in a book by the same name, written by Mary Poppendieck and Tom Poppendieck in 2003.The book restates traditional lean principles, as well as a set of 22 tools and compares the tools to corresponding agile practices. The Poppendiecks' involvement in the agile software development community, including talks at several Agile conferences has resulted in such concepts being more widely accepted within the agile community.
  
4. XP - (Extreme Programming)
• A software development methodology intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles, intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.
  
5. AUP - Agile Unified Process
• A simplified version of the Rational Unified Process (RUP) developed by Scott Ambler. It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques including test-driven development (TDD), agile modeling (AM), agile change management, and database refactoring to improve productivity. In 2011 the AUP accounted for one percent of all the agile methodologies used. In 2012 the AUP was superseded by disciplined agile delivery (DAD). Since then work has ceased on evolving AUP.
  
6. DAD - Disciplined Agile Delivery
• Disciplined agile delivery (DAD) is the software development portion of the Disciplined Agile Toolkit. DAD enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of agile software development, including scrum, agile modeling, lean software development, and others. The primary reference for disciplined agile delivery is the book Choose Your WoW!, written by Scott Ambler and Mark Lines. In particular, DAD has been identified as a means of moving beyond scrum. According to Cutter Senior Consultant Bhuvan Unhelkar, "DAD provides a carefully constructed mechanism that not only streamlines IT work, but more importantly, enables scaling. Paul Gorans and Philippe Kruchten call for more discipline in implementation of agile approaches and indicate that DAD, as an example framework, is "a hybrid agile approach to enterprise IT solution delivery that provides a solid foundation from which to scale."
  
7. TDD - Test Driven Development
• Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later. Software engineer Kent Beck, who is credited with having developed or "rediscovered" the technique, stated in 2003 that TDD encourages simple designs and inspires confidence. Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right. Programmers also apply the concept to improving and debugging legacy code developed with older techniques.
  
8. RAD - Rapid Application Development
• Rapid application development was a response to plan-driven waterfall processes, developed in the 1970s and 1980s, such as the Structured Systems Analysis and Design Method (SSADM). One of the problems with these methods is that they were based on a traditional engineering model used to design and build things like bridges and buildings. Software is an inherently different kind of artifact. Software can radically change the entire process used to solve a problem. As a result, knowledge gained from the development process itself can feed back to the requirements and design of the solution. Plan-driven approaches attempt to rigidly define the requirements, the solution, and the plan to implement it, and have a process that discourages changes. RAD approaches, on the other hand, recognize that software development is a knowledge intensive process and provide flexible processes that help take advantage of knowledge gained during the project to improve or adapt the solution. Rapid application development (RAD), also called rapid application building (RAB), is both a general term for adaptive software development approaches, and the name for James Martin's method of rapid development. In general, RAD approaches to software development put less emphasis on planning and more emphasis on an adaptive process. Prototypes are often used in addition to or sometimes even instead of design specifications. RAD is especially well suited for (although not limited to) developing software that is driven by user interface requirements. Graphical user interface builders are often called rapid application development tools. Other approaches to rapid development include the adaptive, agile, spiral, and unified models.
  
9. Crystal, made up of several agile processes, including Clear, Crystal Yellow, Crystal Orange, and other uniquely characterized methods.
• Crystal (1992) was the starting point of the evolution of software development methodologies which ultimately resulted in what we know as Agile movement. The honor of creating Crystal goes to Alistair Cockburn. Cockburn developed the “light-weight” methodology called Crystal for IBM in 1991. Cockburn interviewed & researched numerous people who did not follow the traditional/ formal approach but still delivered practical, successful projects. Therefore, he realized that different team size & dynamics lead to varying procedures to carry on the projects. The methodology was named “Crystal” only in 1997. Crystal can be applied to teams of up to 6 or 8 co-located developers working on systems that are not life-critical. You can see the seeds of Agile manifesto in Crystal because it focuses on – (1) Frequent delivery of usable code to users, (2) Reflective improvement and (3) Osmotic communication preferably by being co-located.
  
10. DSDM - Dynamic Systems Development Method
• Dynamic systems development method (DSDM) is an agile project delivery framework, initially used as a software development method. First released in 1994, DSDM originally sought to provide some discipline to the rapid application development (RAD) method. In later versions the DSDM Agile Project Framework was revised and became a generic approach to project management and solution delivery rather than being focused specifically on software development and code creation[clarification needed][citation needed] and could be used for non-IT projects. The DSDM Agile Project Framework covers a wide range of activities across the whole project lifecycle and includes strong foundations and governance, which set it apart from some other Agile methods. The DSDM Agile Project Framework is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement. DSDM fixes cost, quality and time at the outset and uses the MoSCoW prioritisation of scope into musts, shoulds, coulds and will not haves to adjust the project deliverable to meet the stated time constraint. DSDM is one of a number of agile methods for developing software and non-IT solutions, and it forms a part of the Agile Alliance.
  
11. FDD - Feature Drive Development
• Related to Scrum, but in FDD, features are the foundational piece. Features are to FDD what stories are to scrum. In addition, during FDD, a feature may be delivered every 2-10 days. In scrum sprints typically last 2 weeks, but may be up to four. What are the stages of FDD? There are 5 basic stages during an FDD lifecycle:
  
1. Develop an overall model
   
2. Build a feature list
   
3. Plan your features
   
4. Design your features
   
5.  Build by feature
   
12. SAFe - Scaled Agile Framework
• The scaled agile framework (SAFe) is a set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices. Along with large-scale Scrum (LeSS), disciplined agile delivery (DAD), and Nexus, SAFe is one of a growing number of frameworks that seek to address the problems encountered when scaling beyond a single team.  SAFe promotes alignment, collaboration, and delivery across large numbers of agile teams. It was developed by and for practitioners, by leveraging three primary bodies of knowledge: agile software development, lean product development, and systems thinking.  The primary reference for the scaled agile framework was originally the development of a big picture view of how work flowed from product management (or other stakeholders), through governance, program, and development teams, out to customers.  With the collaboration of others in the agile community, this was progressively refined and then first formally described in a 2007 book.[8] The framework continues to be developed and shared publicly; with an academy and an accreditation scheme supporting those who seek to implement, support, or train others in the adoption of SAFe. Starting at its first release in 2011, five major versions have been released[9] while the latest edition, version 5.1, was released in February 2021.[10] While SAFe continues to be recognised as the most common approach to scaling agile practices (at 30 percent and growing), it also has received criticism for being too hierarchical and inflexible.
  

A great deal of time and talent has been spent developing these methodologies. Each has specific features that may make that particular framework best suited for a particular situation. However, these different agile software development methodologies adhere to the same basic four principles.

Much of the present focus is on Scrum, but that is not mandatory.  It could be that one of the other Agile methodologies may be more effective for a particular dev environment.

Agile Scrum
Activities and Responsibilities within Agile Scrum are discussed in terms of:

• Principles (Qty 6)
• Aspects (Qty 5)
• Phases (Qty 5)
• Processes (Qty 19)

1. Product Owner
2. Scrum Master
3. Scrum Team

Scrum Aspects (5)

1. Organization
   
2. Business justification
3. Quality
4. Change
5. Risk

1. Initiate Phase (6)
   
2. Plan and Estimate Phase (6)
3. Implement Phase (3)
4. Review and Retrospect Phase (2)
5. Release Phase (2)

Scrum Processes (19)

1. Create Project Vision
2. Identify Scrum-Master and Stakeholders
3. Form Scrum Team
4. Develop Epics process
5. Create Prioritized Product Backlog process
6. Conduct Release Planning Process
7. Create User Stories
8. Estimate User Stories
9. Commit User Stories
10. Identify Tasks
11. Estimate Tasks
12. Create Sprint Backlog
13. Create Deliverables (Scrum Team works on tasks in the Sprint Backlog to create Sprint Deliverables)
    
14. Conduct Daily Stand-up
15. Groom Prioritized PRODUCT backlog
16. Demonstrate and Validate Sprint Process
17. Retrospect Sprint
18. Ship Deliverables
19. Retrospect the Project