From BC$ MobileTV Wiki
(Redirected from Value Stream Mapping)
Jump to: navigation, search

Agile is a group of software development methodologies in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.

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:

  • 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."

[3] [4] [5] [6] [7]

12 Agile Principles


A list of the most prominent Agile Methodologies follows, but for any methodology the emphasis is on moving faster than business has done in the past, and the commonality is to where possible look to streamlining processes in order to ensure the most. The most prominently used methodology in Software Development has up until recently been Scrum, but now DevOps is rapidly taking over; meanwhile the most common in manufacturing has been Lean Six Sigma but Kanban and/or Lean Startup are taking over.

Often these Agile Methodologies are combined to some success, for example Lean Manufacturing of physical goods can borrow aspects of Scrum for brainstorming/ideation and even DevOps practices for running their production line's IT systems and/or managing factory automation, as is inevitably required for large-scale productions of goods. Another example from the software world is to use Lean Manufacturing processes to setup the Delivery Pipeline similar to a modular factory floor layout where incremental pieces of a larger product are put together in various stages (as in Microservices that work together but are developed separately by various teams), yet organizationally adhering to Kanban for Project Management tasks such as moving tasks between various statuses from assignment through to completion and doing Scrum Daily Standup and/or post-Sprint meetings or relying on its Burndown Charts for effort estimations and resource planning. With Agile, it is important to note that adherence to a single Agile Methodology is much less important than the end result, which should remain on target or corrected for along the way (early and often) as needed.



Lean methodologies are those which aim to maximize customer value while minimizing waste. This is accomplished in Lean by creating more value for customers with fewer resources (natural, human, operational and/or monetary). Key corporate processes are focused on, in order to continuously increase customer value. Lean thinking changes the focus of management from optimizing separate technologies, assets, and vertical departments to optimizing the flow of products and services through entire value-streams that flow horizontally across technologies, assets, and departments to customers. Eliminating waste along entire value-streams, instead of at isolated points, creates processes that need less human effort, less space, less capital, and less time to make products and services at far less costs and with much fewer defects, compared with traditional business systems. It also improves overall corporate responsiveness to changing customer desires. Businesses in all industries and services, including healthcare and governments, are using lean principles as the way they think and do.

Many of the "Lean" methodologies and practices emerged from the Total Quality Management (TQM)[8] movement in the 1980's to 1990's to increase competition with Japan and other international net exporters of the time, who were beating American companies on product quality and lower product defects in a substantial/measurable manner.

[9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22]

Demings' 14 Points

  1. Create constancy of purpose for improving products and services
  2. Adopt the new philosophy
  3. Cease dependence on inspection to achieve quality
  4. End the practice of awarding business on price alone; instead, minimize total cost by working with a single supplier
  5. Improve constantly and forever every process for planning, production, and service
  6. Institute training on the job
  7. Adopt and institute leadership
  8. Drive out fear
  9. Break down barriers between staff areas
  10. Eliminate slogans, exhortations, and targets for the workforce
  11. Eliminate numerical quotas for the workforce and numerical goals for management
  12. Remove barriers that rob people of pride of workmanship, and eliminate the annual rating or merit system
  13. Institute a vigorous program of education and self-improvement for everyone
  14. Put everybody in the company to work accomplishing the transformation

[23] [24] [25] [26]


The Toyota Production System (TPS) is a leading, frequently-studied "Lean" management approach pioneered by the Toyota Motor Corporation which intends to optimize flow (both effectiveness & efficiency) of the vehicle manufacturing process from ideation to design to the individual parts manufacturers' factory floors and Toyota's own production/assembly lines. It has been adapted and served as inspiration for a number of other manufacturing industries, followed by the software development and general IT industries as well.

  1. Smooth rough edges/spots (konnyaku stone)
  2. Mistake avoidance (poka yoke)
  3. Continuous Learning (hansei)
  4. Safety Signal (andon)
  5. Automation supported by human intellect (jidoka)
  6. Just-In-Time (chodo jikan)
  7. Production levelling (heijunka)
  8. Continuous Improvement (kaizen)
  9. Witness 1st-hand (genchi genjutsu)
  10. Consensus (nemawashi)
  11. Signpost/visualization (kanban)
  12. Waste (muda, muri, mura)
  13. Workplace (genba)

[27] [28]

[29] [30] [31] [32]

Six Sigma


Six Sigma is a form of opposing yet potentially compatible if not complimentary approach to efficiency & project agility than the core Agile methodologies (which are more focused on quick results & fixes than up-front perfection). It prioritizes reduction of defects overall before a given product or service goes into production, aiming to reduce defect rates down to the "high quality" threshold of 3.4 defects per 1000000 opportunities. An opportunity is a situation where a direct sale or key customer interaction potentially leading to a sale can be made; i.e. customer impression, transaction, event, signup, trial, etc.

It is said to be compatible with other Agile Methodologies (depending on corporate goals & brand positioning) because it aims to make customers happier and increase profits, which are commonly stated reasons for Agile adoption. Its premise is on saving money by avoiding defects since they cost alot of money to fix (especially in the case of lawsuits for major malfunctions or recalls in physical goods and products). An improvement system for existing processes or systems falling below specification to be incrementally improved is DMAIC:

  1. Define
  2. Measure
  3. Analyze
  4. Improve
  5. Control

[33] Define the problem, Measure the severity, Analyze opportunities for change, Improve processes & remove bottlenecks[34] and Control waste or non-value adding activities[35].

SixSigma DMADV.png

Similarly, the Six Sigma DMADV process is an improvement system used to develop new processes or products at Six Sigma quality levels. It can also be employed if a current process requires more than just incremental improvement.

  1. Define
  2. Measure
  3. Analyze
  4. Design
  5. Verify


Define the problem, Measure the severity, Analyze opportunities for change, Design a better solution (often a new product entirely or "greenfielding") and Verify that the new solution solves the problem better than any existing solution. [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62]

Lean Six Sigma
LeanSixSigma 8-wastes.png

Lean Six Sigma is a collaborative team effort to improve corporate performance by systematically removing waste, combining lean manufacturing & lean enterprise concepts with traditional and Six Sigma to eliminate the eight kinds of waste (Japanese term for which is muda). There are 7 main types of "muda" to be eliminated or reduced as much as possible, commonly abbreviated as TIMWOODS:

  1. Transportation
  2. Inventory
  3. Motion
  4. Waiting
  5. Over production
  6. Over processing
  7. Defects
  8. Skills


[69] [70] [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89]

Lean Startup


Lean Startup is a methodology for developing new businesses, enhancing existing ones & innovating upon product lines or creating revolutionary new products which disrupt their most similar markets' incumbents. Shorten product development cycles by adopting a combination of business-hypothesis-driven experimentation, iterative product releases, and validated learning. The central hypothesis of the lean startup methodology is that if startup companies invest their time into iteratively building products or services to meet the needs of early customers, they can reduce the market risks and sidestep the need for large amounts of initial project funding and expensive product launches and failures.

[91] [92] [93] [94] [95] [96] [97]

Value Stream Mapping

Value Stream Mapping is a "Lean Agile" technique used to highlight waste and bottlenecks in a given production system, from ideation to deployment of features, products and projects into customers' hands.

[98] [99] [100] [101] [102] [103] [104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156] [157] [158] [159] [160] [161] [162] [163]



Kanban is a methodology for managing knowledge work with an emphasis on just-in-time delivery while not overloading project team members. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see. Team members pull work from a queue of items to be done. Kanban in the context of software development can mean a visual process-management system that tells what to produce, when to produce it, and how much to produce - inspired by the Toyota Production System[164] and Lean manufacturing[165]. The name Kanban originates from Japanese[看板], and translates roughly as "signboard" or "billboard", representing the importance of visualization of work-in-progress and the workflow for completing individual work items. The primary goal of Kanban is to expose system operation (or process) problems and stimulate collaboration to continuously improve the system. Kanban is founded upon four basic principles:

  1. Start with existing process
  2. Agree to pursue incremental, evolutionary change
  3. Respect the current process, roles, responsibilities & titles
  4. Leadership at all levels

Kanban Boards and Kanban Cards are two of the more prominent tools which can be used to implement the Kanban method of management for a project. Whereas Kanban (signal) Cards represent demand or capacity, a Kanban Board utilizes magnets, plastic chips, colored washers or sticky notes to represent work items. Each of these objects represents an item in a production process as it moves around the board. Its movement corresponds with a manufacturing process. At its simplest, the board is usually divided into three sections: "awaiting production", "work in progress" and "completed work" (or correspondingly "To Do", "Doing" & "Done").

[167] [168] [169] [170] [171] [172] [173] [174] [175] [176] [177] [178] [179] [180] [181] [182] [183] [184] [185] [186] [187] [188] [189] [190] [191] [192] [193] [194] [195] [196] [197] [198] [199] [200] [201] [202] [203] [204] [205] [206] [207] [208] [209] [210] [211] [212] [213] [214] [215] [216] [217] [218] [219] [220] [221] [222]


Visual representation of all the work to be done, improvements to be made, enhancements, defect/bug fixes, technical debt to be paid down, products to manufacture, etc.

[223] [224] [225] [226] [227] [228] [229] [230] [231] [232] [233]

WIP Limits

Work-In-Progress (WIP) limits set the capacity of each work center or individual team member within the system. These limits can be applied at many levels including

  • individual
  • team
  • department
  • company

For instance a WIP limit of 3 at the individual level in the Sotware Development industry would mean that a Developer can only take on or look into at most 3 items at once. Typically a lower WIP limit (i.e. WIP limit=1) is more desirable, as the degree of focus, reduction of context switching and emphasis on completion of an item at a time is almost always the most efficient approach.

Single-piece Flow

Reducing deliveries to just what is needed, reducing large batch sizes down to ideally just the individual items that are needed, as they are needed (fits together ideally with JIT deliveries).

[234] [235]


Continuous Improvement (commonly referred to by its Japanese term Kaizen which literally translated means "change for the better") is the concept that all members of a team/department/company constantly collaborate towards bettering all aspects of the operation of the company and delivery flow of its products/services.

The Five S's, from the 5 Japanese words in Kaizen that summarize the approach:

  1. Sort (seiri)
  2. Set in order (seiton - Straighten)
  3. Shine (seiso)
  4. Standardize (seiketsu)
  5. Sustain (shitsuke)

[236] [237] [238] [239] [240] [241]

Continuous Learning

Another, aspect of Kaizen that is not always recognized but which some advocates argue to be more or at least "as important" as the Continuous Improvement process is the "Continuous Learning" process.

[242] [243] [244] [245]

Cumulative Flow Diagrams

Cumulative Flow Diagrams (commonly abbreviated CFD).

[246] [247] [248] [249] [250] [251] [252]

Extreme Programming

eXtreme Programming (commonly abbreviated as "XP") is a Software development methodology and team mindset which intends to improve software quality and responsiveness to changing customer requirements. It advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

  1. Planning Game - Business & Development cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same: Business comes up with a list of desired features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes in broad strokes what is required. User stories are typically written on 4x6 cards. Development estimates - how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration). Busines' then decides which stories to implement in what order, as well as when and how often to produce a production releases of the system.
  2. Small Releases - Start with the smallest useful feature set. Release early and often, adding a few features each time.
  3. System Metaphor - Each project has an organizing metaphor, which provides an easy to remember naming convention.
  4. Simple Design - Always use the simplest possible design that gets the job done. The requirements will change tomorrow, so only do what's needed to meet today's requirements.
  5. Continuous Testing - Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Tests in XP come in two basic flavors. Unit Tests are automated tests written by the developers to test functionality as they write it. Each unit test typically tests only a single class, or a small cluster of classes. Unit tests are typically written using a unit testing framework, such as JUnit. Acceptance Tests (also known as Functional Tests) are specified by the customer to test that the overall system is functioning as specified. Acceptance tests typically test the entire system, or some large chunk of it. When all the acceptance tests pass for a given user story, that story is considered complete. At the very least, an acceptance test could consist of a script of user interface actions and expected results that a human can run. Ideally acceptance tests should be automated, either using the unit testing framework, or a separate acceptance testing framework.
  6. Refactoring - Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn't break anything because you have the tests.
  7. Pair Programming - All production code is written by two programmers sitting at one machine. Essentially, all code is reviewed as it is written.
  8. Collective Code Ownership - No single person "owns" a module. Any developer is expect to be able to work on any part of the codebase at any time.
  9. Continuous Integration - All changes are integrated into the codebase at least daily. The tests have to run 100% both before and after integration.
  10. 40-Hour Work Week - Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.
  11. On-site Customer - Development team has continuous access to a real live customer, that is, someone who will actually be using the system. For commercial software with lots of customers, a customer proxy (usually the "Product Manager" or "Product Owner") is used instead.
  12. Coding Standards - Everyone codes to the same standards. Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code.

User Story

One core part of Scrum requiring a detailed breakdown is the User Story, which is Scrum's primary (in the opinion of many, the only necessary) design artifact.

User Stories typically explain the functionality not in traditional "The system must do function X" Requirements format, but rather users a more flexible and flowing yet concise template:

As a ________ I want __________ so that ___________.

The first blank is filled with the role or archetype of the User of the system, application, product or service. The second blank is filled with the goals, capabilities, or enabling activities from the User's point of view. The third blank is filled with the justification or benefits, also from the User's point of view.

An important distinction between User Stories and Requirements is that the former are always describing "features" from an end-user perspective, while the latter tends to describe functionality or non-functional characteristics from the Business' perspective (often in an attempt to commoditize the end-user rather than provide them a service).

[254] [255] [256] [257]

[259] [260] [261] [262] [263] [264] [265] [266] [267] [268] [269] [270] [271] [272] [273] [274] [275] [276]

Business Value

[277] [278] [279] [280] [281] [282] [283] [284] [285] [286] [287] [288]

Story Points

Generate a list of all the required enhancements called the "Must Haves" to support current customers (users) or maintain profitability/operations, then list all necessary features to be added for growth as identified by the executives or business team and put in the "Nice To Haves" and relegate all non-essential functionality updates to a third "Wish List" category; this complete list is the Backlog which needs to be identified into a manageable number of releases over the course of a single year (i.e. release every quarter, release every month, when scrum is working well release all the way to production at the end of every Sprint). Depending on the frequency of releases, there may be a dependency on more involved upfront setup/configuration by the Technical team to put CI/CD (Continuous Integration/Deployment/Testing) and other DevOps tools/processes in place, but on large projects the amount of time/effort savings can be exponentional. The period of time in which an agreed upon amount of work must be completed and fully functional at end of such period is called a single Sprint; each Sprint should be arranged to take place over a consistent period of time, typically 2-weeks (10 business days, 14 days total) but could be anywhere from 2 to 30 days, depending on frequency of release cycle. Estimate the time it will take for each task (card). Estimates are best done in Story Points which are an intangible yet very clearly differentiated (and incremental) sizing metric that doesn't relate directly to time; good examples of this are T-Shirt sizes (XS, S, M, L, XL) or more commonly the Fibonacci sequence (0, 1/2, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, ???, ☕) the argument being that many things in nature such as shells & flowers grow according to this scale; although even this scale has been modified to simplify the numbers and further differentiate the sizing in a "Fibonnaci-inspired" series (0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ???, ☕). However, often when adopting Agile/Scrum management will not easily give up completely time-centric metrics and as such you could also make use of eight time-blocks (where total amount of time for a task must be less than two weeks, using a non-flexible scale where jobs take one of 1h, 2h, 4h, 8h, 2d, 4d, 6d, 8d (and jobs that take somewhere in between get slotted in the time-allocation above; i.e. a 3-hour job gets slotted as "4h" and a 3-day job gets slotted as "4d"). Anything larger than 8 days needs to be broken up into several smaller and more manageable sub-tasks. If it is 16d+ it is really its own Project, and should be budgeted/capitalized as such.

[289] [290] [291] [292] [293] [294] [295] [296] [297] [298] [299] [300] [301] [302] [303]


wikipedia: Return On Investment

[304] [305] [306] [307] [308] [309]

Story Maps

[310] [311] [312] [313] [314] [315] [316] [317]

Story Writing Workshop

[318] [319] [320] [321] [322] [323] [324] [325] [326] [327] [328] [329] [330] [331] [332] [333] [334] [335]


Scrum is a framework for resolution of complex adaptive problems (i.e. "new product" development, research & design, etc). It is a subset of the Agile methodology whereby a team of talented cross-discipline individuals (almost always under 10, but ideally 3-5) collaborate closely with daily interaction. Because of the constantly-changing nature of the Software industry, it is perhaps most commonly used there, but has become popular in all technology-related industries, and even in more traditional or non-technical industries as their once "well-defined" requirements become "constantly changing" requirements to keep pace with competitors, maintain market share and/or solve their real-world business/operational problems.

All features delivered through Scrum are typically written from the perspective of an end-user (and thus called "User Stories"), a concept borrowed from XP. However, the Scrum Guide does not actually mandate this, it has merely become a common practice because it lends itself well to the Backlog grooming and prioritization that is prescribed by Scrum.

[338] [339] [340] [341] [342] [343] [344]


In summary, Scrum is:

  1. ROLES: Executives, Product Owner, Scrum Master (or at least PM with right mindset), Developers, Testers, Customers (Users)
  2. Daily short status/challenges (< 15 min) in Scrum Standup Meeting (standing/telephone/videoconf)
  3. Features + Requirements + Defects discovered + Wish list = Backlog
  4. Feature + Requirement + Defect subset + Wish subset (to develop this release cycle) = Release Backlog
  5. Defects created as side-effect (often resolved by a separate Ops team, so Dev team can keep sprinting/releasing) = Defect Backlog
  6. (Contractual) Severity-ranked & (Business) Priority-sorted & (Technical) Time/Difficulty-estimated subset of Release Backlog = Sprint (usually 2-weeks, but could be 1-4wk cycle)
  7. Each Sprint consists of Tasks (visually represented as Cards), and should be color-coded to denote aforementioned Priority and/or Time/Difficulty Estimate
  8. A graph/chart monitoring progress of a given Sprint = Burndown Chart (should trend towards 0 or else problems)
  9. Today's Date + Work Remaining(in days) / Rate(tasks completed per day) = Completion Date (of project)
  10. Have a 30-45 minute Retrospective after each Sprint to discuss possible new efficiencies, improvements or innovations to help work faster (often called a Post-Mortem although care must be taken to avoid the slightly negative tones that term can carry[345][346][347][348][349], and Impediments should be raised if features got missed or defect rate exceeded threshold, which the Scrum Master should actively work to resolve[350])

[351] [352] [353]


There are specifically only four meetings prescribed by the Scrum Guide.

  1. Sprint Planning
  2. Daily Standup
  3. Review
  4. Retrospective


Sprint Planning
Daily Standup

[355] [356]


Product Owner

Responsible for the product being delivered and acting as a liaison between the interests of the business, delivery team, and customer; Agile/Scrum purists would say the Product Owner (PO) must always put the needs/wants of the customer above those of the organization or themselves.

However, of course this role exists for a reason and some intelligent decision-making will be required as often the customer may not know exactly what they want/need (or how to describe it, and the continuity of the organization must factor into product lifecycle decisions (i.e. if 100 customers still want/need a legacy product that formerly had 10k customers, it might be more beneficial to figure out how to migrate those customers to an adequate replacement and retire the legacy product).

From the perspective of the delivery team, the belief is that "should the proper decisions have been made with regards to Technical Debt, such retirements/decommissioning/migration would never be required, as our systems would constantly evolve and never be considered legacy, out-dated or needing of replacement". This is certainly a lofty ideal but may not be possible in practice, many (most) organizations have been guilty of letting products/services run their course, making insufficient TechDebt paydowns, then making "big bang" investments every few years to upgrade, switch or reimagine them. Ability to pay down TechDebt may be limited by PO willingness and/or prohibitive factors sucha as company budgets or disjointed decision-making at the executive or business stakeholder level above the PO or team's decision-making capacity.

[357] [358] [359] [360] [361] [362] [363]

Scrum Master

Coach of the team on following Scrum, constantly improving through Retrospectives, and unblocking the team by actively removing impediments.

[364] [365] [366]


Front-end, Back-end and/or Full-stack programmers whom implement the product.

Optional roles
Actual User

In the most "hyper-Agile" of teams, Actual Users are invited in directly to work with the delivery teams to various extents. There is no greater form of feeback than direct communication between those who build and those who use the built products/services on a regular basis. However, this can also lead to problems if not structured properly (with room to grow/adapt).

It is often best used in B2B situations (i.e. vendor deliveries, supplier arrangements, etc), where a product/service provider integrates to the team(s) of their customer(s) (i.e. a software vendor allows their paid developers to sit with their client(s) teams all or part of the time, or at least join in their Daily Scrums), although can be pulled off for B2C as well with aforementioned rigor around whom is chosen from the customer base, whether and how often that representation changes and the parameters for engagement of discussion/feedback between provider and consumer of the product/service being built.

Business Users

When properly done, the Product Owner is able to fill this role acting as the business' sole representative for the end-user, but for various reasons (sometimes out of the team's control) the Business User(s) could be another individual or group (commitee) made up of Subject Matter Experts (SMEs), Product Managers, Authors, etc from around the organization.

Security Specialist

[367] [368] [369] [370] [371] [372] [373] [374] [375] [376] [377] [378] [379] [380] [381] [382] [383] [384] [385] [386] [387] [388] [389] [390] [391] [392] [393] [394] [395] [396] [397] [398] [399] [400] [401] [402] [403] [404] [405] [406] [407] [408] [409] [410] [411] [412] [413] [414] [415] [416] [417] [418] [419] [420] [421] [422] [423] [424] [425] [426] [427] [428] [429] [430] [431] [432] [433] [434] [435] [436] [437] [438] [439] [440] [441] [442] [443] [444] [445] [446] [447] [448] [449] [450] [451] [452] [453] [454] [455] [456] [457] [458] [459] [460] [461] [462] [463] [464] [465] [466] [467]


ScrumBan as its name suggests is a "best-of-both-worlds" approach that combines Scrum and Kanban. Scrum would typically be used for enhancements (i.e. new feature requests encapsulated as Epics/User-Stories/Use-Cases), while Kanban would typically be used for defects (i.e. fixing bugs, completing partially implemented features already delivered, etc); however there may be cases where they can be used interchangeably, or, where one could be used for both at different stages of the project or life of the team.

[468] [469] [470] [471] [472] [473] [474] [475] [476] [477] [478] [479] [480] [481] [482] [483] [484] [485] [486] [487] [488] [489] [490] [491] [492] [493] [494] [495] [496]


[497] [498] [499] [500] [501] [502] [503]


[504] [505] [506] [507] [508] [509] [510] [511] [512] [513] [514] [515] [516] [517] [518] [519] [520]


DevOps started out as a push for closer collaboration between Development & Operations teams within traditional and/or Agile IT organizations, and has since rapidly expanded into an IT industry practice and corporate culture revolution movement.

For more info, see the DevOps dedicated page.

Scaling Approaches

[521] [522] [523] [524] [525] [526] [527]


[528] [529] [530] [531] [532] [533] [534] [535] [536]


Scaled Agile Framework for Enterprises (SAFe) is an approach to rolling out ScrumBan (joint Scrum/dev and Kanban/ops teams) in a holistic Portfolio & Roadmap based corporate view.

Scaled Agile Framework (SAFe): [537] [538] [539]

[540] [541] [542] [543] [544] [545] [546] [547] [548] [549] [550] [551] [552] [553] [554] [555] [556] [557]



[558] [559]


[560] [561]


Tribes & Guilds

[563] [564] [565] [566] [567] [568] [569] [570] [571] [572] [573]





[597] [598] [599] [600] [601] [602] [603] [604] [605] [606] [607] [608] [609]

[610] [611] [612] [613] [614] [615] [616] [617] [618] [619]


External Links



  1. Half-arsed Agile Manifesto (HUMOR): (jokes about the hypocrisy & gotchas of trying to be Agile in an Enterprise)
  2. Manifesto for Half-Arsed Agile Software Development discussion:
  3. Manifesto for Agile Software Development: (by Kent Beck, Martin Fowler et al.)
  4. Waterfall .vs. Agile: (phased project with whole system functionality delivered at end of project .vs. incremental MVP functionality delivery on a daily-to-weekly basis, production readiness of that functionality at end of shorter iterative cycles)
  5. The Agile Fluency Model:
  6. Comprehensive Guide to the Agile Manifesto:
  7. Choosing to Start Small or Go All In when Adopting Agile:
  8. [[wikipedia: Total quality management] (TQM)
  9. wikipedia: Lean manufacturing
  10. Principles of Lean:
  11. What is Lean?:
  12. Learning the lingo ("Lean" edition):
  13. Lean Thinking (book review):
  14. BPM & Lean -- a powerful combination for process improvement:
  15. Roman Pichler -- Product Management tools:
  16. 10 Tips for Creating an Agile Product Roadmap:
  17. What's in the Metrics?:
  18. Let’s Lean on "Lean" (What's in the Metrics -- Part 2):
  19. 7 Lean Development Principles:
  20. How Lean Thinking Helps Hospitals:
  21. How to Change a Culture - Lessons From NUMMI:
  22. The Five Orders of Ignorance:
  23. If Japan Can, Why Can't We?: (NBC "White Paper" series; June 24, 1980... commonly credited with beginning the "Quality Revolution" in North America)
  24. wikipedia: If Japan Can... Why Can't We?
  25. wikipedia: W. Edwards Deming (especially see section "14 Key Principles")
  26. The Red Bead Experiment with Dr. W. Edwards Deming:
  27. 13 pillars of the Toyota Production System:
  28. Need to Ensure the Quality of a Product or Process? Know the Core Concepts (13 pillars) of TPS and Lean Manufacturing:
  29. JIT, Kanban, Kaizen, Muda in TPS (Toyota Production System) :
  30. Gemba Walk - Where the Real Work Happens:
  31. Andon Cords at the Toyota Takaota Plant – It Doesn’t Come Naturally?:
  32. Nemawashi – Decisions by consensus without compromise - Thinking for a Change:
  33. wikipedia: DMAIC
  34. wikipedia: Theory of constraints (TOC)
  35. wikipedia: Total productive maintenance (TPM)
  36. wikipedia: DMADV
  37. wikipedia: Hoshin Kanri
  38. Hoshin Kanri: (transparent goal setting & roadmapping, with clear metrics & KPIs)
  39. Hoshin Planning -- Making the Strategic Plan Work:
  40. The 7 Steps of Hoshin Kanri Planning:
  41. The 5 Principles of Hoshin Kanri:
  42. More explanation on Hoshin Kanri:
  43. "Hoshin Kanri" Matrix Template:
  44. The Seven Steps of Hoshin Planning:
  45. The Seven Steps of Hoshin Planning:
  46. Strategic Planning Using Hoshin Kanri:
  47. Hoshin Kanri -- "Visual Strategic Planning":
  48. A few words about Hoshin Kanri:
  49. Project vs. Product:
  50. Product vs Project Development -- 5 factors that can completely alter your approach:
  51. Difference Between Product and Project — with examples:
  52. Project management vs. product management (by Steve Kelman):
  53. Project .vs. Product, and, Product Owner .vs. Project Manager (from "#noprojects" perspective):
  54. Project Manager vs Product Manager:
  55. Product Manager vs Project Manager – What’s the Difference?:
  56. Product Management vs. Project Management - What’s the Difference?:
  57. The Difference Between Product and Project Management:
  58. What is Six Sigma and why is it important?:
  59. Non Value Adding, Value Adding Activity, 7 Wastes:
  60. Drum Buffer Rope approach:
  61. The Goal -- Theory of Constraints (MOVIE): ("Drum-Buffer-Rope" scene)
  62. You liked the book "The Goal" by Eliyahu Goldratt? It's time to implement it!:
  63. wikipedia: Lean Six Sigma
  64. wikipedia: Six Sigma
  65. wikipedia: Fishbone diagram (aka. Ishikawa diagram)
  66. wikipedia: Root cause analysis (RCA)
  67. wikipedia: Five Ws
  68. wikipedia: 5 Whys
  69. Six Sigma Methodology: (Lean SixSigma .vs. DMAIC .vs. DMADV)
  70. SixSigma -- DMAIC vs. DMADV – What Are The Differences? (INFOGRAPHIC):
  71. Learning to Think Lean - Six Steps with Review Points:
  72. 8 Wastes of Lean:
  73. Who is TIM WOODS and why is he killing your business?:
  74. DMAIC vs. DMADV – What Are The Differences?:
  75. Jidoka: (Autonomation or AI/machines + human intelligence)
  76. wikipedia: Monodzukuri (Japanese sense of pride in craftsmanship and dedication to quality by striving for perfection)
  77. Monozukuri – Japanese Work Ethics:
  79. Agile – DevOps – Organizational Change Management:
  80. wikipedia: Kaizen
  81. Kaizen institute explains meaning of the Kanji & Japanese word/concept:
  82. KAIZEN overview:
  83. Intro to Kaizen (SLIDES):
  84. Shipping More Safely by Encouraging Ownership of Deployments :
  85. Kaizen & The Toyota Production System (SERIES):
  86. Management by Stress (in the Auto Industry):
  87. Single Piece Flow, Continuous Flow & Standardized Work:
  88. Why Process Improvement Matters For Your Team (And How To Implement It):
  89. ShuHaRi: (SHU=learning from a single "master"/expert, HA=branching out to learn from others, RI=self-guided learning and improvement)
  90. wikipedia:
  91. Lean Startup principles:
  92. Lean UX. Is it *really* about start-ups or something more profound?:
  93. Announcing a New Lean Innovation Series:
  94. The Lean Startup Cheat Sheet - v1.0:
  95. Falling in Love with the Problem:
  96. Good enough never is (or is it?):
  97. Lean Startups aren’t Cheap Startups:’t-cheap-startups/
  98. The Forrester New Wave™: Value Stream Management Tools, Q3 2018:
  99. Forrester report -- Where's The "Value" In Your Value Stream?:
  100. SixSigma -- Value Stream Mapping:
  101. What is Value Stream Mapping:
  102. DevOps & Value Stream Mapping:
  103. DevOps and Value Stream Mapping -- Why you need metrics:
  104. How value stream mapping delivered on DevOps' promise for Hearst Business Media:
  105. How value stream mapping, Kanban, queue management rival automation:
  106. Value Stream Mapping vs. Metrics-Based:
  107. Value Stream Mapping & Metrics Based Process Mapping (MBPM):
  108. 10 Tips for Getting the Most Value from Value Stream Mapping:
  109. Value Stream Mapping -- How to Visualize Work and Align Leadership for Organizational Transformation; by Mike Osterling, Karen Martin (BOOK):
  110. Drive Alignment -- 5 Strategies for Burning Down Silos and Building Bridges:
  111. 2019 is the year of the Value Stream:
  112. Flow Framework:
  113. Project to Product -- Value Stream Architecture:
  114. Project to Product -- What Flows through a Software Value Stream?:
  115. Value Stream Mapping (VSM) and metrics-based process mapping (SLIDES):
  116. Value Stream Mapping -- How to Visualize Work & Align Leadership for Organizational Transformation (SLIDES):
  117. Value Stream Mapping -- Case Studies (SLIDES):
  118. Learning To See -- Making Value Flow…From End to End, v1 (BOOK):
  119. Learning To See -- Making Value Flow…From End to End, v2 (BOOK):
  120. Learning To See -- Making Value Flow…From End to End, 2012 state of VSM (SLIDES):
  121. Value Stream Mapping Math -- Rolled throughput Yield:
  122. Value Stream Segmentation and New Product Development:
  123. Lean institute -- Total Value Stream - What is Value-Stream Mapping:
  124. Value Stream Mapping - The Concept (SLIDES):
  125. Does Value Stream Mapping Work for Software Development?:
  126. Value Stream Diagram:
  127. The Customer Value Problem: Ditch the Value Stream!:
  128. [wikipedia: Value stream mapping software]]
  129. Best software package for value stream mapping:
  130. Value Stream Mapping for Software Development:
  131. Creately - VSM guide:
  132. ConceptDraw -- Value Stream Mapping Software:
  133. MS Office -- VISIO - Create a "Value Stream Map":
  134. eVSM tool -- VSM examples:
  135. Mapping Your Value Stream:
  136. Looking at Your Work From a Value Stream Perspective:
  137. What's wrong with your value stream mapping:
  138. How to defrag your DevOps value stream:
  139. 6 steps to optimize software delivery with value stream mapping:
  140. 10 steps to successful value stream mapping:
  141. Learn the 10 Key Steps to Value Stream Mapping (VSM) for Software Delivery:
  142. Flow Metrics -- An MRI of your Product Value Streams: | SLIDES
  143. Driving Digital Transformation Insights with Value Stream Management (WEBINAR): SLIDES
  144. Identify bottlenecks with Value Stream Mapping (VSM):
  145. What do you need to be successful at Value Stream Management, and how can you help?:
  146. Value Stream Management will be a driving force behind successful businesses in 2021:
  147. 5 reasons why CI/CD is vital to your organization's value stream:
  148. VSM DevCon 2021:
  149. Challenging the way we organize around value:
  150. Why "Value Stream" matters to DevOps and the business:
  151. A BizOps Manifesto aims to close gap between business, IT:
  152. Maximizing the ROI of your Agile transformations:
  153. Improve operational efficiency with value calculators:
  154. The Forrester Wave™ - Value Stream Management Solutions, Q3 2020:
  155. How to improve DevOps security with value stream management:
  156. Why You Need a Value Stream Delivery Platform:
  157. Building DevSecOps with Value Stream Management:
  158. 6 steps for defining Product Value:
  159. Tracking Value Delivery - A Case Study:
  160. Sequence Your Value Delivery with Impact Mapping:
  161. "Continuous Improvement" throughout the value stream:
  162. Value Stream Management and Organizing Around Value:
  163. Remote Value Stream Mapping (VSM) Workshop:
  164. wikipedia: Toyota Production System
  165. wikipedia: Lean manufacturing
  166. wikipedia: Kaizen
  167. Kanban the game: (learn about Kanban by practicing)
  168. Evolving the Kanban Board: (in this case to help tackle the "Honey Do" home maintenance list, and figure out which jobs would be better served by external consultants/service-providers)
  169. What is Kanban?:
  170. Kanban Thinking:
  171. Personal Kanban (BOOK):
  172. Making Work Visible -- Exposing Time Theft to Optimize Work & Flow (BOOK):
  173. The Five Time Thieves:
  174. Scaled Agile Framework -- Team Kanban:
  175. Kanban boards -- step by step:
  176. 7 Obstacles to Enterprise Agility:
  177. Beginner’s Guide to Kanban for Agile Marketing:
  178. Kanplan -- where your backlog meets Kanban:
  179. Kanban vs. Iterative Development:
  180. Scrum .vs. Kanban (CHEAT SHEET):
  181. Don't Push. Pull Work Items for Better Results:
  182. JIRA -- Using your Kanban backlog:
  183. JIRA -- Monitoring work in a Kanban project (using a BOARD):
  184. Intro to Kanban (SLIDES): (also has many article & terminology links)
  185. Benefits of Kanban (when done right):
  186. Ditching Scrum for Kanban  —  The best decision we’ve made as a team:
  187. Kanban vs Scrum -- Which One Is the Better Approach to Use in 2019?:
  188. Agile vs. Waterfall vs. Kanban vs. Scrum: What’s the Difference?:
  189. What is Kanban System & kanban Board ? (scrum vs kanban):
  190. ScrumBan overview:
  191. The Kanban Guide for Scrum Teams: Kanban Guide.pdf
  192. Embracing Uncertainty:
  193. Kanban Metrics to Track Performance (Throughput) and Responsiveness (Cycle Time):
  194. Cycle time vs Lead time – what is the difference?:
  195. To estimate (or not) in Kanban? Leveraging lean thinking to eliminate waste.:
  196. Forecasting and Simulating Software Development Projects -- Effective Modeling of Kanban & Scrum Projects using Monte-carlo Simulation:
  197. #NoEstimates Part 2 – Contract Negotiation and the Old Banger:
  198. The perils of estimation:
  199. All Estimation is Waste – Rubbish!:
  200. Estimating defects in Agile is an anti-pattern:
  201. Is There Any Value in Estimating if You're Using Kanban?:
  202. Cynefin for Devs:
  203. How to release with Kanban?:
  204. Visualizing Agile Projects using Kanban Boards:
  205. 7 Steps to Build a Kanban Board for a Scrum Team’s Impediments:
  206. How One Piece Flow Can Reduce Your Operations Time by 96% :
  207. Scrum Is Dead. All Hail Kanban, the New King:
  208. How to structure your teams when you scale Kanban:
  209. 3 signals to watch out for when scaling your teams:
  210. Can You Scale Kanban?:
  211. Large Scale Kanban with Klaus Leopold:
  212. Going Beyond WIP Limits for Ever-Higher Organizational Performance:
  213. Balanced Flowchart Exercise: (finding where your time goes over a daily, then weekly, then monthly, then quarterly basis)
  214. Hiding in plain sight -- the everyday concept that can turbocharge your Kanban - Kanban Maturity Model:
  215. How to Use the Dependency Management Poster?:
  216. 7 lessons about Dependency Management:
  217. An intro to Jiko Kanri:
  218. "Jiko Kanri" literally means "self-managing" in Japanese:
  219. Kanban Maturity Model -- Cost of Delay:
  220. Kanban - A Powerful Enabler For Remote Work Teams:
  221. How to Revitalize your Kanban Implementation:
  222. Why Kanban is more than a visualization board:
  223. AgileAlliance -- Glossary of Agile Terms - Backlog:
  224. Crowded backlog? A product is more than the sum of its features:
  225. A Definitive Guide To Product Backlog – How To Build and Maintain It?:
  226. Product Backlog Building Canvas:
  227. Product backlog prioritization quadrants:
  228. How to Prioritise Your Product Backlog: (1.Impact effort matrix, 2.Stack Ranking, 3.MoSCoW method, 4.Weighted Shortest Job First, 5.Data-driven prioritization)
  229. Why Impact/Effort Prioritization Doesn’t Work And why you should keep using it:
  230. Scaled Agile, inc. -- Weighted Shortest Job First:
  231. wikipedia: MoSCoW method
  232. DSDM Agile Framework -- Ch.10 - MOSCOW PRIORITISATION:
  233. What is MoSCoW Prioritization?:
  234. Cycle Time Goes Visual:
  235. Work in small batches:
  236. wikipedia: 5S (methodology)
  237. Kaizen Institute - About the 5S approach:
  238. Using 5S Lean Methodology to Create an Agile Workplace:
  239. Making a Case for Continuous Improvement:
  240. What Does "Kvetch" Mean?: (an interesting companion to "Kaizen" perhaps?)
  241. Enduring Ideas - The three horizons of growth:
  242. The Google Way of Building A Strong Learning Culture:
  243. Creating a Culture of Learning in 6 Steps:
  244. Creating a Learning Culture in 6 Steps — and Why You Should:
  245. 20 Tips for Creating a Learning Culture in the Workplace:
  246. Cumulative Flow Diagram explained:
  247. Cumulative Flow Diagram - You Still Do Not Use It?:
  248. How to use the Cumulative Flow Diagram to visualize your project workflow:
  249. Cumulative Flow Diagram:
  250. What your CFD is telling you?:
  251. Cumulative Flow Diagram benefits:
  252. Introducing the Time In State InSITe Visualization:
  253. User Stories - An Agile Introduction:
  254. wikipedia: User story
  255. wikipedia: Planning poker
  256. wikipedia: Anchoring
  257. Better Together — XP and Scrum:
  258. User Stories overview:
  259. SPIDR – five simple techniques for a perfectly split User Story:
  260. My Slicing Heuristic Concept Explained:
  261. The essence of story slicing in agile development:
  262. Slicing, Estimation, Trimming:
  263. Quick Reference Guide for Splitting User Stories:
  264. How to Work with Complex User Stories That Cannot Be Split:
  265. Getting Small Stories:
  266. Epics, stories, versions, and sprints:
  267. Agile User Stories -- The Building Blocks for Software Project Development Success:
  268. Writing User Stories, Examples and Templates In Agile Methodologies:
  269. Myth -- In Scrum, the Product Backlog has to consist of solely User Stories:
  270. 5 Common Mistakes We Make Writing User Stories:
  271. 10 Tips for Writing Good User Stories:
  272. Write a Great User Story:
  273. User Stories are Not Enough for a Great User Experience:
  274. User Stories -- Ready, Set, GO!:
  275. Want to write better user stories? Stop using “can”:
  276. 12 Signs You’re Working in a Feature Factory - 3 Years Later:
  277. Exclusive Excerpt from "The Value Flywheel Effect":
  278. What is this thing called (Business) Value?:
  279. Business Value cheatsheet:
  280. What is Business Value Engineering?:
  281. What Is The Value of Perspective?: (investing and decision making based on not just the value to us personally, or our companies' bottom lines, but also the value to society and the environments in which we operate)
  282. Business Value matrix to prioritize the Backlog: (consistency is key)
  283. Better (business) Value Sooner Safer Happier (BVSSH) principles: (includes poster summarizing each principle)
  284. Business Marketing - Understand What Customers Value:
  285. Value-focused versus value-washing: The agency role in a sustainable future: (Prof. Philip Sugai):
  286. Value Washing: (Prof. Philip Sugai)
  287. Rebooting Accelerate, part 1 -- Looking beyond the hype:
  288. Rebooting Accelerate, part 2 -- How to deliver value faster:
  289. Story Points or Hours?:
  290. What is a story point?:
  291. The secrets behind story points and agile estimation:
  292. The Main Benefit of Story Points:
  293. Estimating Agile Story Points Using Fibonacci:
  294. What Is The Fibonacci Sequence? And How It Applies To Agile Development:
  295. Why is the Fibonacci series used in agile planning poker?:
  296. Why Progressive Estimation Scale Is So Efficient For Teams:
  297. Fibonacci -- The Math of Agile:
  298. Agile Estimating Tool – Planning Poker using Fibonacci Sequence:
  299. Story Points vs. Development Hours:
  300. Story Points -- Estimate delivery "Effort" (not just) "Complexity":
  301. Story Points Are Still About Effort:
  302. SWAGing -- A Rapid User Story Estimation Exercise for Distributed Teams:
  303. Swimlane Sizing – Complete & Fast Backlog Estimation:
  305. Extreme Programming FAQ:
  306. The 3 laws of TDD:
  307. wikipedia: Class-responsibility-collaboration card (CRC cards)
  308. "Team" room:
  309. Central Desk .vs. U-Pod seating arrangement:
  310. User Story Mapping (BOOK):
  311. The New User Story Backlog is a Map:
  312. Essentials of Agile User Story Mapping at Twitter - Atlassian Summit 2016:
  313. Story Mapping:
  314. User Story essentials (quick reference guide):
  315. DDD-Domain Driven Design (DDD) or Deadline Driven Design (DeadDD)?: (how to salvage the bad DDD with the good DDD)
  316. It’s all in how you slice it -- Design your project in working layers to avoid half-baked incremental releases (by Jeff Patton):
  317. Story Mapping:
  318. Can a Traditional SRS Be Converted into User Stories?:
  319. Use cases vs user stories in Agile development:
  320. Developing Effective Agile Requirements Relies On Both User Stories And Use Cases:
  321. User Stories to Functional Requirements in IT:
  322. The Fallacy of Converting Requirements into User Stories:
  323. User Stories – the Bridge Between Requirements and IT Project Implementation:
  324. How Programmers and Testers (and Others) Should Collaborate on User Stories:
  325. 5 Must-Haves For Great Story Writing:
  326. Walking Through a "Definition of Done":
  327. Should Documentation be in the "Definition of Done"?
  328. Improvement Stories - a simple alternative to User Stories:
  329. User Story Mapping and probabilistic forecasting:
  330. Agile Progress and Quality Reporting:
  331. Why Agile Teams Put So Much Emphasis on Being Done Each Iteration:
  332. Swarming -- One-Piece Continuous Flow:
  333. Swarming - How To Instantly Boost Your Scrum Team’s Productivity:
  334. Process Efficiency in Scrum – Why it Matters and How to Measure it:
  335. Making Your User Stories "Ready" to Get to "Done": SLIDES | VIDEO
  336. The Evolution of the Scrum Guide— ‘10 to ‘19:
  337. A list of Scrum Articles, Guides and books that have defined Scrum:
  338. Agile "(Story) Point" System vs. Hours System:
  339. Why do we use Story Points for Estimating (in Scrum)?:
  340. Who Writes User Stories in Agile with Scrum?:
  341. Scrum - stop marginalizing the Dev manager:
  342. Scrum – are you Serious?: (a series to address the malpractices of Scrum)
  343. Top 10 Scrum and Agile (INFOGRAPHICS):
  344. Scrum Project Life Cycle (SPLC): (how to "ease into" Scrum when stuck in a Waterfall organization by introducing SPLC as alternative to SDLC)
  345. Post Mortems Vs. Agile Retrospectives:
  346. Make the most of mistakes -- Best practices for agile retrospectives, postmortems:
  347. The Definitive Guide to Agile Retrospectives and Post-Mortem Meetings:
  348. Scrum And DevOps: (how they can work together)
  349. Same or Different? Retrospectives and Post-Mortems:
  350. Agile Retrospectives:
  351. The Relationship Between Team Reflection and Planning:
  352. Who is the Project Manager in Scrum?:
  353. “Scrum doesn’t have Project Managers, so we ignore them in our organisation”:
  354. Scrum and best practices (@ Microsoft):
  355. Timing for Sprint Reviews & Retrospectives:
  356. How To Install Apps On Older Devices Running Older Versions Of iOS:
  357. 6 diagrams I use to explain "Product Management" concepts:
  358. 12 Signs You’re Working in a Feature Factory:
  359. A 12-Step Program for Recovering Product Managers: | VIDEO
  360. The Four Big Risks (to both projects & products):
  361. Behold, the Product Management Prioritization Menagerie:
  362. Serious Scrum - Will the real Product Owner please stand up?:
  363. Marty Cagan - What is Product Ownership?:
  364. What is an "Agile Coach"? A valuable role for organizational change:
  365. Serious Scrum - "Sorry Scrum, the Game Might Be Over for You!":
  366. How Do You Identify a Successful Scrum Master?:
  367. wikipedia: Scrum Sprint
  368. Agile Scrum overview:
  369. 5 Key Patterns from "A Scrum Book" (and
  370. CSM-Moncton November 2017:
  371. University of California - CS course in Agile: (lots of books/whitepapers/material)
  372. When did Scrum stop being a methodology?: (re-dubbed a "Framework" instead)
  373. 2017 Scrum Guide Revision Webinar:
  374. Agile Product Management with Scrum (BOOK):
  375. Scrum Essentials Cards:
  376. The Beginner’s Guide To Scrum And Agile Project Management:
  377. Business Analysts in Scrum:
  378. What is an AGILE Business Analyst?:
  379. The Role of the Analyst in Agile Projects:
  380. What does a business analyst do in a scrum team?:
  381. Agile Testing -- The Role Of The Agile Tester:
  382. Role of Testers in Agile?:
  383. Role of Testers in Agile Teams:
  384. The Tester’s Role in Agile Is More than “Just Testing”:
  385. Why the Whole Team Should Participate When Estimating:
  386. The Role of an Architect on a Scrum Team:
  387. Programmers vs. Developers vs. Architects:
  388. Essential Scrum -- Chapter 6 - Product Backlog:
  389. Product Backlog Item (PBI) vs User Story:
  390. The Art of Product Backlog Refinement:
  391. Sprint Planning for Agile Teams That Have Lots of Interruptions:
  392. Does Scrum really work?:
  393. Scrum and Team Effectiveness - Theory and Practice:
  394. Agile Project Development at Intel -- A Scrum Odyssey:
  395. A Case Study on the Applicability and Effectiveness of Scrum Software Development in Mission-Critical and Large-Scale Projects:
  396. Are there any studies on the Efficiency/Effectiveness of Agile vs Waterfall:
  397. Introduction to Scrum (PRESENTATION):
  398. Reusable Scrum Presentation:
  399. Solve Scrum Problems Today -- 5 Free Preview Lessons From The Scrum Repair Guide:
  400. An Iterative Waterfall Isn’t Agile:
  401. Scrum Training series -- Module 4 - Daily Scrum Meeting (aka. 15-minute Standup):
  402. The 3-5-3 of Scrum:
  403. The Daily Scrum:
  404. Suggestions for a better Daily Scrum:
  405. Do Scrum Teams Meet Too Much?: (check your calendar "N" months back before adopting and really getting the groove of Scrum, which actually has more meetings?)
  406. Stop Calling Your Sprint Review a Demo WORDS MATTER!:
  407. Sprint Review Meeting:
  408. Microsoft - Sprint Review Meeting:
  409. Agile Management for Dummies - Sprint Review:
  410. Sprint Review:
  411. Scrum Training series -- Module 5 - Sprint Review Meeting:
  412. How to facilitate an awesome Sprint Review in “Bazaar mode”:
  413. Retrospective Plans: (different games/playbooks for running effective & engaging Sprint Retros)
  414. Sprint Retrospective:
  415. The Four Questions of a Retrospective and Why They Work :“-4-questions”-retrospective
  416. 3 Simple Steps to Effective Retrospectives: (1-Collect Data, 2-Look for Patterns, 3-Determine Actions)
  417. Sprint Retrospective:
  418. Sprint Retrospective summary:
  419. Sprint Retrospective overview:
  420. What is a Sprint Retrospective?:
  421. Key Elements of the Sprint Retrospective: (what: went well, went wrong,
  422. The Upward Spiral -- Sprint Retrospective Techniques:
  423. Agile Management for Dummies - Sprint Retrospective:
  424. Scrum Training series -- Module 6 - Sprint Retrospective Meeting:
  425. Applied Macro-measurements to Ensure On-Time Delivery, an Agile Approach to “Metrics”:
  426. Do Scrum sprints mean to work at the fastest pace possible?:
  427. What is the difference between Sprint and Iteration in Scrum and length of each Sprint?:
  428. What is Pig and Chicken in Scrum?:
  429. Commitment-Driven Sprint Planning:
  430. Commitment vs. Forecast -- A Subtle But Important Change to Scrum:
  431. How to measure the accuracy of forecasts:
  432. ScrumMaster and Product Owner Sprint "Commitments":
  433. Must a Scrum team stick with the Sprint commitment or is it just a Forecast?:
  434. What is a scrum master?:
  435. Why Scrum needs Product Leadership:
  436. 9 Questions Scrum Masters and Product Owners Should Be Asking: | PDF
  437. 3 Mistakes Scrum Masters Make and How to Correct Them:
  438. Spikes and the Effort-to-Grief Ratio:
  439. Spikes:
  440. PlanningPoker:
  441. JIRA plugin - PlanningPoker: SRC
  442. Planning Poker deck (and walkthrough):
  443. How to play planning poker… Badass Mode! :
  444. The Case for Poker Cards in Sprint Planning:
  445. Agile Estimating and Planning:
  446. Process Efficiency in Scrum – Why it Matters and How to Measure it:
  447. Velocity - How is it useful?:
  448. Velocity - Some preliminaries:
  450. WHAT DOES A "PO" DO?:
  451. Requirements for Product Owner -- Common Pitfalls:
  452. Keep Scrum retros positive with “Appreciative Inquiry”:
  453. The only thing that matters when planning a Sprint:
  454. Why I Hate Scrum:
  455. So, what is ‘Water-SCRUM-fall’?:
  456. The Comprehensive Guide to Making Agile and Waterfall Methodologies Get Along (And Avoid Drama and Delays along the Way):
  457. What is Water-Scrum-Fall (and is it inevitable)?:
  458. Analyst Watch -- Water-Scrum-fall is the reality of agile:
  459. Waterscrumfall -- the new hype in software development?:
  460. Water-Scrum-Fall — is it a Myth or Reality?:
  461. Water-Scrum-Fall Tons of upfront planning. Iterate. Tons of post code testing & Deployment steps:
  462. Water-Scrum-Fall Model in Life Sciences:
  463. Leveraging DevOps in a 'water-SCRUM-fall' world:
  464. What Does QA Do on the First Day of a Sprint?:
  465. Avoiding Squirrel Burgers By Insisting on Quality:
  466. The Trouble with Sprint Burndowns:
  467. Scrum by Example – Overtime on a Scrum Team is an Unhealthy Sign:
  468. wikipedia: Scrumban
  469. Lean/Kanban – The Perils of Partial Adoption:
  470. Advantages and Disadvantages of Kanban:
  471. The Perils of Project Parallelization:
  472. Why is Agile/Scrum compared to Rugby?:
  473. Let's Stop "Adopting" Agile and Start Becoming Agile:’s-stop-adopting”-agile-and-start-becoming-agil
  474. When Not to Use Scrum:
  475. Scrum Will Die:
  476. How scrum can stop you being agile?:
  477. Challenging Why (not if) Scrum Fails:
  478. 24 Common Scrum Pitfalls Summarized:
  479. What to do when Scrum doesn’t work:
  480. An Introduction to Scrumban for Agile Marketing:
  481. Scrumban -- A different way to be Agile:
  482. What is Scrumban?:
  483. What is a Bottleneck and How to Deal With It?:
  484. Breaking Agile’s QA Bottlenecks:
  485. Clearing the Software Testing Bottleneck:
  486. Scrum & Kanban - Battle Royale or Save the World?:
  487. MercuryApp - poll/index tracking tool:
  488. Tracking Project Emotions Using MercuryApp:
  489. How to Track the Team’s Mood with a Niko-niko Calendar:
  490. Why having a Niko-Niko chart is just as important as having a Burndown Chart:
  491. Niko-niko Calendar:
  492. Attention! Niko-Niko Calendar, it’s important to any Agile teams:
  493. Information Radiators:'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'information*20radiators))~searchTerm~'~sort~false~sortDirection~'asc~page~1)
  494. Why a Niko-Niko Calendar Kills Workplace Morale:
  495. SMILE, Dammit -- Some Companies Are Using An App To Track Your Moods At Work:
  496. The Hot Potato Process:
  497. No Projects - Beyond Projects:
  498. NoProjects -- SAMPLE CHAPTER - An introduciton to a new way of thinking about work:
  499. Using the NoProjects Paradigm:
  500. #noprojects -- Outcomes - The Value of Change :
  501. #NoProjects - Teams over Projects:
  502. The agile guide to winning at team development:
  503. #NoProjects everywhere:
  504. The #NoEstimates Movement:
  505. The Estimates in #NoEstimates:
  506. Ryan Ripley on #NoEstimates movement: | SLIDES
  507. #NoEstimates -- 6 Software Experts Give Their View on the Movement:
  508. The Throw Down -- "Agile Estimation" .vs. #NoEstimates:
  509. The NoEstimates book (overview from the author, Vasco Duarte):
  510. Planning with #NoEstimates:
  511. (Agile) Forecasting for Beginners:
  512. The logic of #NoEstimates -- #NoEstimates follows in the footsteps of Agile and Scrum:
  513. #NoEstimates and why Estimates are almost always wrong (by Allen Holub):
  514. Time Tracking is Essential to Agile Development?:
  515. Time Tracking on an Agile Team:
  516. Strategies for Tracking Time on Agile Teams:
  517. Time Tracking and Agile Methodology:
  518. Six Reasons for Time Tracking in Agile Projects:
  519. Lean Accounting -- Does IT Need a Time Out on Time Tracking?: (answer: NO, measure Business Value/ROI, Cycle Time & Throughput instead)
  520. To estimate or not to estimate, that is the question:
  521. Why Agile (by itself, often) Doesn't Work for Large Projects:
  522. Scaling for End-to-End Agility:
  523. Don’t Organize Around Projects! Choose a Better Unit of Focus to Eliminate Waste & Increase Agility:
  524. Agile at scale -- Movin' on up: scaling agile in large organizations:
  525. SCALING Agile: PART 1 | PART 2
  526. Scaling GitHub's Employees:
  527. Why it’s difficult to build teams in high growth organisations:
  528. Scrum of Scrums (DEFINITION):'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'scrum*20of*20scrums))~searchTerm~'~sort~false~sortDirection~'asc~page~1)
  529. Scrum of Scrums overview:
  530. Scrum of Scrums -- implementation example:
  531. All About the Scrum of Scrums:
  532. Scrum Team & Scrum of Scrums:
  533. What is Scrum of Scrums?:
  534. Scrum in practice -- the Scrum of Scrums meeting:
  535. What is a Scrum of Scrums?:
  536. Using Scrum of Scrums with Agile Teams to Coordinate and Collaborate:
  537. SAFe or Scrum at Scale – Which Framework is Best for You?:
  538. SAFE or Scrum@Scale which is best for you?:
  539. Scaling Agile Scaling Agile -- LeSS vs. SAFe:
  540. wikipedia: Scaled Agile Framework
  541. Introducing the scaled agile framework:
  542. dzone -- Pattern of the Month - Increment:
  543. What is an Increment in Scrum?:
  544. Scaled Agile Framework (SAfe) -- Program Increment (PI):
  545. Scaled Agile Framework (SAfe) -- Features and Capabilities:
  546. Scaled Agile Framework (SAfe) -- Milestones:
  547. Scaled Agile Framework (SAfe) -- PI Planning:
  548. Scaled Agile Framework (SAfe) -- Innovation and Planning Iteration:
  549. Scaled Agile Framework (SAfe) -- Portfolio Level:
  550. Scaled Agile Framework (SAfe) -- Value Streams:
  551. Scaled Agile Framework (SAfe) -- Agile Release Train (ART):
  552. Scaled Agile Framework (SAfe) -- Release Train Engineer and Solution Train Engineer:
  553. Scaled Agile Framework (SAfe) -- Release "on Demand":
  554. Scaled Agile Framework (SAfe) -- Business Owners:
  555. Drive Innovation in Software Development -- How to Choose Between Incremental and Fundamental Change:
  556. What is SAFe?:
  557. SAFe® 5.0 -- How to Avoid This Big Mistake - Tasktop Blog:
  558. SoS vs LeSS vs SAFe – Which One Is Right For You?:
  559. Atlassian summary - The Large-Scale Scrum (LeSS) framework:
  560. Scrum@Scale -- The Path to Agile - 30 Years of Large-Scale Agile Transitions @ Agile Amsterdam 2017 - Tobacco Theatre:
  561. Scaling Scrum – What People Are Not Talking About!:
  562. An Introduction to the Nexus Framework:
  563. Spotify Engineering Culture: Part 1 | Part 2
  564. Scaling Agile at Spotify:
  565. Scaling Agile at Spotify (presentation):
  566. Case Study -- When emulating Scaling Agile at Spotify went awry at Refinery29:
  568. Thoughts on emulating Spotify’s matrix organization in other companies:
  569. Failed #SquadGoals Spotify doesn’t use “the Spotify model” and neither should you:
  570. Spotify Doesn't Use the Spotify Model:
  571. Why Copying Spotify’s Squads and Tribes Model Probably Won’t Work for You:
  572. Atlassian -- Team Playbooks - Discover the Spotify model:
  573. Agile Team Organisation: Squads, Chapters, Tribes and Guilds -- why reogranize?:
  574. Set-Based Concurrent Engineering: Toyota's Principles of Set-Based Concurrent Engineering (SBCE):
  575. Toyota production system (SLIDES):
  576. Agile Topics card deck:
  577. Card Decks for Agile Transitions:
  578. 10 Best Free Scrum Tools:
  579. JIRA + HipChat = real-time communication for agile teams:
  580. The complete guide to using HipChat as an agile team:
  581. HipChat vs. Yammer and Office 365:
  582. 5 open source alternatives to Trello:
  583. Definition of Ready:
  584. Product Backlog Item (PBI):
  586. Servant Leadership, by Robert K. Greenleaf (BOOK):
  587. The Power of Servant Leadership, by Robert K. Greenleaf (BOOK):
  588. 5 Agile Metrics you won't hate:
  589. How to do Scrum with JIRA: (Steps 1-11)
  590. Learn advanced scrum practices with JIRA Software: (Steps 12-15)
  591. Agile by Design:
  592. Creating a lean, mean product requirements machine:
  593. Agile Roadmaps - build, share, use, evolve: (going agile doesn't mean not knowing where you're going. It means being flexible about the path you take)
  594. The Product Backlog -- your ultimate to-do list:
  595. Escaping the black hole of technical debt:
  596. How to build a kick-ass agile team:
  597. Customer Development Labs -- How to Interview your Customers:
  598. Customer Development Labs -- The Customers you Should be Interviewing:
  599. Customer Development Labs -- You’ve Interviewed Customers. Now what?:
  600. The FOCUS framework:
  601. UserTesting -- Discovery Interviews:
  602. Discovery interviews -- a deeper kind of networking:
  603. 10 Tips To Conduct Customer Discovery Interviews and Questions:
  604. 3 Goals for Blueprinting Discovery Interviews:
  605. What Customer Discovery Questions To Ask To Validate Pain Points:
  606. Never Ask What They Want  —  3 Better Questions to Ask in User Interviews:
  607. A 5-Step Process For Conducting User Research:
  608. Get better data from user studies - 16 interviewing tips:
  609. How to Test Prototypes with Customers -- The Five-Act Interview:
  610. AgileAlliance -- glossary of terms - Personas:
  611. Yes, Personas Focus on Demographics (And How to Fix That):
  612. Story-centered design -- hacking your brain to think like a user:
  613. Atlassian - User Stories with Examples and Template:
  614. Atlassian - Persona template:
  615. 10 Tips for Creating Agile Personas:
  616. "Choose your Wow!" codifying your User Archetypes as Personas:
  617. Customer Personas: How to Write Them and Why You Need Them In Agile Software Development:
  618. Scaled Agile -- Design Thinking: (overview of Personas, Empathy Maps, Customer Journey Maps, and how they tie into User Stories and the design/dev cycle)
  619. 4 Characteristics Of A Personable And Useful Customer/User Persona:
  620. What is an Information Radiator?:
  621. Do you have the Ultimate Wallboard? (CONTEST):
  622. Agile Software Development -- Forming Teams that Communicate and Cooperate:
  623. Agile Alliance -- GLOSSARY - Information Radiator:
  624. Information radiator:
  625. Agile Technique Guideline - Information Radiators:
  626. Minimum Viable Product (MVP) overview:
  627. 15 ways to test your Minimum Viable Product (MVP):
  628. Choosing the MVP:
  629. Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable:
  630. Estimation? It’s Complicated...:
  631. PERT Chart example:
  632. PERT overview:
  633. PERT for Project Planning and Scheduling:
  634. Critical Path Analysis and PERT Charts - Planning and Scheduling More Complex Projects:
  635. Tools for Systems Thinkers -- The 6 Fundamental Concepts of Systems Thinking:
  636. Reigniting Creativity in Business:
  637. FeatureToggle:
  638. Feature Toggles (aka Feature Flags):
  639. Use Canary Deployments to Test in Production:
  640. Canary release strategy vs. Blue/Green:
  641. Deployment Strategies Defined:
  642. Using Blue-Green Deployment to Reduce Downtime and Risk:
  643. The DOs and DON'Ts of Blue/Green Deployment:
  644. Blue-green Deployments, A/B Testing, and Canary Releases compared:
  645. On the importance of a Team Manifesto: ("ways of working", "team etiquette", etc)
  646. The "Command and Control" Military Gets Agile :
  647. Agile Metrics -- Progress Monitoring of Agile Contractors - by Will Hayes, Suzanne Miller, Mary Ann Lapham, Eileen Wrubel, Timothy A. Chick (WHITEPAPER):
  648. The Defense Innovation Board wants to help the military recognize ‘agile BS’:
  649. The U.S. Department of Defense on How to Detect ‘Agile BS’:
  650. The Importance of Product Management in Government:
  651. Risk Management – How to Stop Risks from Screwing Up Your Projects (with ROAM)!: | ARCHIVE (ROAM = Reduce, Owned, Accepted, Mitigated)
  652. wikipedia: Risk management
  653. ISACA Journal Volume 2, 2016 -- Risk Management in Agile Projects :
  654. Agile Risk Management:
  655. Working Product and the DOD:
  656. Why isn't Agile working - the best comment from the Reddit discussion:
  657. Robert C. Martin - The Land that Scrum Forgot:
  658. wikipedia: Technology roadmap
  659. How to Prioritize Product Features and Improvements:
  660. Agile roadmaps -- build, share, use, evolve :
  661. Aha! vs JIRA Portfolio:
  662. Agile roadmap planning done right with Jira Software and Portfolio for Jira:
  663. Creating and Managing a Product Roadmap in JIRA:
  664. 2015 Chaos Report - (overview) Q&A with Jennifer Lynch:

See Also

Product | Dashboard | Testing | SCM | CI/CD | QA | PM | Business | DevOps | Logging | BigData | Analytics | Optimization | Waterfall