| Description |
1 online resource (149 pages) |
| Contents |
Intro -- Contents -- About the Author -- Part I: The Accident -- Chapter 1: Clear Ownership -- Daily Standup Day 1: Who's on first? -- Shared Lists -- Ownership -- Untangling -- Chapter 2: Small, Independent Units of Work -- Daily Standup Day 2: Merge conflicts! -- Daily Standup Day 3: Need a reviewer! -- Daily Standup Day 4: I broke some stuff. I think. -- Daily Standup Day 5: Turns out I need this other thing. -- Chapter 3: Sized -- Daily Standup Day 6: Five hours or five weeks ... -- Chapter 4: Sequenced -- Daily Standup Day 7: ... or five hours over five weeks? |
|
Chapter 5: Inputs, Transition Criteria, Outputs -- Daily Standup Day 8: Did you say something? -- Chapter 6: Stakeholder Approval -- Daily Standup Day 9: Oops. I forgot to tell you. Or ask you. -- Part II: The Agile Codex Theory -- Chapter 7: The Problem -- Plan for the Imperfect Plan -- Optimize for Adaptability -- Don't Surrender to Dependencies -- Chapter 8: The Codex -- The Principles of the Agile Codex -- Small Units of Work -- Sized -- Sequenceable -- Acyclic Dependency Tree -- Single Owner -- Application -- Chapter 9: The Agile -- Clear Ownership of Work at All Times in Each Stage |
|
Clear Inputs -- Clear Transition Criteria -- Clear Outputs -- Stakeholder Approval -- Chapter 10: Benefits -- Low Overhead -- Detailed Auditing -- Quick and Safe Deliveries -- Many Quality Gates -- Chapter 11: From Invention to Assembly Line -- The Importance of Dependencies -- Building the Assembly Line -- In Review -- Chapter 12: Team Functions -- User Experience (UX) -- Product Management (PM) -- Engineering Management (EM) -- Development (DEV) -- Quality Engineering (QE) -- Documentation (DOC) -- Operations (OPS) -- Customer Support Group (CSG) -- Chapter 13: Software Development Life Cycle |
|
Phases -- Planning -- Execution -- Releasing -- Choosing a Cadence -- How SDLC Length Affects Practices -- Constructing the Codex -- Chapter 14: Risk Management -- Categories of Risk -- Product Risk: How Clearly and Comprehensively the Product Can Be Defined -- Technical Risk: How Clearly and Comprehensively It Is Understood How to Build It -- Market Risk: Any Demand-Side Shift Which Creates an Arbitrage Opportunity for a Quick Feature Pivot -- Business Risk: Any Supply-Side Shift Which Creates an Arbitrage Opportunity for a Quick Feature Pivot -- Today and Tomorrow Risk |
|
Positive Interactions with Risk -- Risk Quadrants and Risk over Time -- Planning for Resilience -- Conclusion -- Part III: The Agile Codex Practice -- Chapter 15: Building Blocks -- Planned Release -- Epic -- User Story -- Acceptance Criteria -- Tasks -- Dependencies -- Adjacent Teams -- Story Points -- Bug -- All Together -- Chapter 16: Workflow -- Planning -- Release Planning -- Epic Grooming -- User Story Grooming -- Epic Commitment -- Execution -- Setting Up the Tree -- The Board -- Needs Sign-Off -- Signed Off -- In Progress -- Fix Needed -- QE -- PM / UX -- Closed -- External Dependencies |
| Note |
The Sprint or the Kanban. |
| Summary |
Apply the industrial engineering science of invention and assembly to how software is described, planned, and built, allowing you to be free to flex your practices according to your needs, putting principle over habit and rules. Reading about Agile practices is like reading diet advice. Everything sounds unique and good; everything starts with good intentions. Then reality sets in. Organizations adapt their practices, but lose sight of grounding principles. A bias toward ceremonies, metrics, and recipes comes at the expense of efficiently getting the real work done. Managers and developers are incentivized to game the system. Organizational metrics become detached from the reality of what is being delivered and how. The Agile Codex shows you how to describe a software project as an acyclic dependency tree of sized work items, scoped to be operated on by one software engineer each and completed within a week. It provides Open Source tooling to help you visualize, sequence and assign these work items to account for risk and increase predictability in your delivery times. You'll see the value of doing this as it applies to efficiently planning and adjusting software projects in the face of learning and change. Finally, the book covers the collaborative agile principles required to bring this skill set and practice to a software team. Throughout the book you'll be reminded that software engineering is not a rote task - it is primarily a skilled, creative act. As such, you'll see that we need to account for the space needed to research, plan, create, and adjust. The Agile practices serving the codex deal with this intersection between the engineering problem of software delivery flow, and the human reality of how work is described, owned, executed, and transitioned from one state to another. Everything an agile team does must serve the codex. The creation and the care and feeding of this structured tree of work sets the frame in which all other team actions take place and against which all successes or failures can be evaluated. |
| Note |
Includes index. |
| Subject |
Agile software development.
|
|
Méthodes agiles (Développement de logiciels) |
|
Agile software development |
| Other Form: |
Print version: McCormick, Michael. Agile Codex. Berkeley, CA : Apress L.P., ©2021 9781484272794 |
| ISBN |
9781484272800 (electronic bk.) |
|
1484272803 (electronic bk.) |
| Standard No. |
10.1007/978-1-4842-7280-0 doi |
|
More Resources