Agile

From BC$ MobileTV Wiki
Revision as of 07:05, 18 June 2022 by Bcmoney (Talk | contribs) (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


Methodologies

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

Lean.jpg

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]

TPS

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

SixSigma.jpg

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

[36]

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

[63]

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


Lean Startup

LeanStartup.jpg

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]

Kanban

Kanban.jpg

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[163] and Lean manufacturing[164]. 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").

[166] [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]


Backlog

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.

[219] [220] [221] [222] [223] [224] [225] [226] [227] [228] [229]

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).

[230]

Kaizen

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)

[231] [232] [233] [234] [235] [236]

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.

[237] [238] [239] [240]

Cumulative Flow Diagrams

Cumulative Flow Diagrams (commonly abbreviated CFD).

[241] [242] [243] [244] [245] [246] [247]

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).

[249] [250] [251] [252]

[254] [255] [256] [257] [258] [259] [260] [261] [262] [263] [264] [265] [266] [267] [268] [269] [270] [271]

Business Value

[272] [273] [274] [275] [276] [277] [278] [279] [280] [281]

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.

[282] [283] [284] [285] [286] [287] [288] [289] [290] [291] [292] [293] [294] [295] [296]

ROI

wikipedia: Return On Investment


[297] [298] [299] [300] [301] [302]

Story Maps

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

Story Writing Workshop

[311] [312] [313] [314] [315] [316] [317] [318] [319] [320] [321] [322] [323] [324] [325] [326] [327] [328]


Scrum

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.

[331] [332] [333] [334] [335] [336] [337]

Scrum.jpg

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[338][339][340][341][342], and Impediments should be raised if features got missed or defect rate exceeded threshold, which the Scrum Master should actively work to resolve[343])

[344] [345] [346]

Meetings

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

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

[347]

Sprint Planning
Daily Standup
Review
Retrospective

[348] [349]

Roles

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.

[350] [351] [352] [353] [354] [355] [356]

Scrum Master

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

[357] [358] [359]

Developer

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

Tester
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.

Designer
Analyst
Architect
Operations
Security Specialist

[360] [361] [362] [363] [364] [365] [366] [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]

ScrumBan

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.

[461] [462] [463] [464] [465] [466] [467] [468] [469] [470] [471] [472] [473] [474] [475] [476] [477] [478] [479] [480] [481] [482] [483] [484] [485] [486] [487] [488] [489]


NoProjects

[490] [491] [492] [493] [494] [495] [496]

NoEstimates

[497] [498] [499] [500] [501] [502] [503] [504] [505] [506] [507] [508] [509] [510] [511] [512] [513]

DevOps

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

[514] [515] [516] [517] [518] [519] [520]


SoS

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


SAFe

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): https://www.scaledagileframework.com/ [530] [531] [532]

[533] [534] [535] [536] [537] [538] [539] [540] [541] [542] [543] [544] [545] [546] [547] [548] [549] [550]

ROAM

LESS

[551] [552]

S@S

[553] [554]

Nexus


Tribes & Guilds

[556] [557] [558] [559] [560] [561] [562] [563] [564] [565] [566]

ACME


Other


Tools

Resources

[590] [591] [592] [593] [594] [595] [596] [597] [598] [599] [600] [601] [602]

[603] [604] [605] [606] [607] [608] [609] [610] [611] [612]


Tutorials


External Links


[638]


References

  1. Half-arsed Agile Manifesto (HUMOR): http://www.halfarsedagilemanifesto.org/ (jokes about the hypocrisy & gotchas of trying to be Agile in an Enterprise)
  2. Manifesto for Half-Arsed Agile Software Development discussion: https://www.reddit.com/r/programming/comments/afthlr/manifesto_for_halfarsed_agile_software_development/
  3. Manifesto for Agile Software Development: http://agilemanifesto.org/ (by Kent Beck, Martin Fowler et al.)
  4. Waterfall .vs. Agile: http://www.developmentthatpays.com/files/DevelopmentThatPays-WaterfallVsAgile-CheatSheet-1-5.pdf (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: https://martinfowler.com/articles/agileFluency.html
  6. Comprehensive Guide to the Agile Manifesto: https://www.smartsheet.com/comprehensive-guide-values-principles-agile-manifesto
  7. Choosing to Start Small or Go All In when Adopting Agile: https://www.mountaingoatsoftware.com/articles/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: http://www.lean.org/WhatsLean/Principles.cfm
  11. What is Lean?: http://www.lean.org/whatslean/
  12. Learning the lingo ("Lean" edition): https://www.jackvinson.com/blog/2011/03/01/learning-the-lingo-lean-edition
  13. Lean Thinking (book review): https://www.jackvinson.com/blog/2011/03/02/lean-thinking-book-review
  14. BPM & Lean -- a powerful combination for process improvement: http://www.ibm.com/developerworks/bpm/bpmjournal/1308_col_schume/1308_schume.html
  15. Roman Pichler -- Product Management tools: https://www.romanpichler.com/tools/
  16. 10 Tips for Creating an Agile Product Roadmap: http://www.romanpichler.com/blog/10-tips-creating-agile-product-roadmap/
  17. What's in the Metrics?: https://dzone.com/articles/whats-in-the-metrics
  18. Let’s Lean on "Lean" (What's in the Metrics -- Part 2): https://dzone.com/articles/lets-lean-on-lean-whats-in-the-metrics-part-2
  19. 7 Lean Development Principles: https://leankit.com/learn/lean/principles-of-lean-development/
  20. How Lean Thinking Helps Hospitals: https://www.infoq.com/presentations/lean-hospitals/
  21. How to Change a Culture - Lessons From NUMMI: https://www.lean.org/Search/Documents/35.pdf
  22. The Five Orders of Ignorance: https://cacm.acm.org/magazines/2000/10/7556-the-five-orders-of-ignorance/fulltext
  23. If Japan Can, Why Can't We?: https://www.youtube.com/watch?v=vcG_Pmt_Ny4 (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: https://deming.org/deming-red-bead-experiment/
  27. 13 pillars of the Toyota Production System: https://mag.toyota.co.uk/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: https://badermartin.com/need-ensure-quality-product-process-know-core-concepts-tps-lean-manufacturing/
  29. JIT, Kanban, Kaizen, Muda in TPS (Toyota Production System) : https://www.slideshare.net/AbdulQadirMaster/jit-in-toyota
  30. Gemba Walk - Where the Real Work Happens: https://kanbanize.com/lean-management/improvement/gemba-walk/
  31. Andon Cords at the Toyota Takaota Plant – It Doesn’t Come Naturally?: https://www.leanblog.org/2012/11/andon-cords-at-the-toyota-takaota-plant-it-doesnt-come-naturally/
  32. Nemawashi – Decisions by consensus without compromise - Thinking for a Change: https://blog.nayima.be/2009/06/19/nemawashi-decisions-by-consensus-without-compromise/
  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: https://www.leanproduction.com/hoshin-kanri.html (transparent goal setting & roadmapping, with clear metrics & KPIs)
  39. Hoshin Planning -- Making the Strategic Plan Work: https://www.isixsigma.com/methodology/hoshin-kanri/hoshin-planning-making-strategic-plan-work/
  40. The 7 Steps of Hoshin Kanri Planning: https://blog.kainexus.com/improvement-disciplines/hoshin-kanria/the-7-steps-of-hoshin-kanri-planning
  41. The 5 Principles of Hoshin Kanri: https://blog.kainexus.com/improvement-disciplines/hoshin-kanri/the-5-principles-of-hoshin-kanri
  42. More explanation on Hoshin Kanri: http://www.hoshinkanripro.com/hoshin_kanri_explained.html
  43. "Hoshin Kanri" Matrix Template: https://www.clearpointstrategy.com/hoshin-kanri-matrix-template/
  44. The Seven Steps of Hoshin Planning: https://www.leanmethods.com/resources/articles/seven-steps-hoshin-planning/
  45. The Seven Steps of Hoshin Planning: https://www.bmgi.com/za/resources/articles/seven-steps-hoshin-planning
  46. Strategic Planning Using Hoshin Kanri: https://goalqpc.com/cms/docs/whitepapers/GOALQPCHoshinWhitepaper.pdf
  47. Hoshin Kanri -- "Visual Strategic Planning": https://www.learnfirm.com/#/user/course/08117118-A87C-4303-BCCF282FB4654917
  48. A few words about Hoshin Kanri: http://www.johnstark.com/fwhsh.html
  49. Project vs. Product: https://www.thoughtworks.com/insights/blog/project-vs-product
  50. Product vs Project Development -- 5 factors that can completely alter your approach: https://zeroturnaround.com/rebellabs/product-vs-project-development-5-factors-that-can-completely-alter-your-approach/
  51. Difference Between Product and Project — with examples: http://www.testnbug.com/2014/12/difference-between-product-and-project-with-examples/
  52. Project management vs. product management (by Steve Kelman): https://fcw.com/blogs/lectern/2018/08/kelman-product-management.aspx
  53. Project .vs. Product, and, Product Owner .vs. Project Manager (from "#noprojects" perspective): https://www.adventureswithagile.com/2016/02/20/product-vs-project/
  54. Project Manager vs Product Manager: https://brainmates.com.au/brainrants/project-manager-vs-product-manager/
  55. Product Manager vs Project Manager – What’s the Difference?: https://www.projectmanager.com/training/product-manager-vs-project-manager
  56. Product Management vs. Project Management - What’s the Difference?: https://www.productplan.com/product-management-versus-project-management/
  57. The Difference Between Product and Project Management: https://www.koombea.com/blog/the-difference-between-product-and-project-management/
  58. What is Six Sigma and why is it important?: https://www.workzone.com/blog/six-sigma/
  59. Non Value Adding, Value Adding Activity, 7 Wastes: https://www.benchmarksixsigma.com/forum/topic/34875-non-value-adding-value-adding-activity-7-wastes/
  60. Drum Buffer Rope approach: https://www.benchmarksixsigma.com/forum/topic/35714-drum-buffer-rope-approach/
  61. The Goal -- Theory of Constraints (MOVIE): https://toc.tv/player/the-goal-movie-how-to-version ("Drum-Buffer-Rope" scene)
  62. You liked the book "The Goal" by Eliyahu Goldratt? It's time to implement it!: https://www.marris-consulting.com/en/training/training-theory-of-constraints-in-production
  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: http://theblogspotblog.wordpress.com/2014/02/18/six-sigma-methodology/ (Lean SixSigma .vs. DMAIC .vs. DMADV)
  70. SixSigma -- DMAIC vs. DMADV – What Are The Differences? (INFOGRAPHIC): http://www.6sigma.us/training/infographic-dmaic-vs-dmadv/
  71. Learning to Think Lean - Six Steps with Review Points: http://www.isixsigma.com/methodology/lean-methodology/learning-think-lean-six-steps-review-points/
  72. 8 Wastes of Lean: https://www.isixsigma.com/dictionary/8-wastes-of-lean/
  73. Who is TIM WOODS and why is he killing your business?: http://www.lbspartners.ie/eight-wastes-of-lean-tim-woods/
  74. DMAIC vs. DMADV – What Are The Differences?: http://www.6sigma.us/training/infographic-dmaic-vs-dmadv/
  75. Jidoka: https://www.lean.org/lexicon/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: https://www.allaboutlean.com/monozukuri/
  78. MONOZUKURI -- ANOTHER LOOK AT A KEY JAPANESE PRINCIPLE: https://www.japanintercultural.com/en/news/default.aspx?newsID=88
  79. Agile – DevOps – Organizational Change Management: https://www.captechconsulting.com/blogs/using-the-5-whys-to-find-change-management-and-devops-impediments-to-agile-transformation
  80. wikipedia: Kaizen
  81. Kaizen institute explains meaning of the Kanji & Japanese word/concept: https://web.archive.org/web/20131029204446/http://www.kaizen.com/about-us/definition-of-kaizen.html
  82. KAIZEN overview: https://www.kaizenworld.com/kaizen/index.html
  83. Intro to Kaizen (SLIDES): https://www.slideshare.net/bengeck/free-kaizen-guide
  84. Shipping More Safely by Encouraging Ownership of Deployments : https://www.infoq.com/news/2018/12/safer-shipping-ownership
  85. Kaizen & The Toyota Production System (SERIES): https://www.bulsuk.com/p/the-toyota-production-system.html
  86. Management by Stress (in the Auto Industry): https://www.multinationalmonitor.org/hyper/issues/1990/01/slaughter.html
  87. Single Piece Flow, Continuous Flow & Standardized Work: http://www.sixleansigma.com/index.php/wiki/lean/single-piece-flow-continuous-flow-standardized-work/
  88. Why Process Improvement Matters For Your Team (And How To Implement It): https://blog.trello.com/why-process-improvement-matters-for-your-team
  89. ShuHaRi: https://martinfowler.com/bliki/ShuHaRi.html (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: http://theleanstartup.com/principles
  92. Lean UX. Is it *really* about start-ups or something more profound?: http://zenexmachina.wordpress.com/2013/03/28/lean-ux-is-it-really-about-start-ups-or-something-more-profound/
  93. Announcing a New Lean Innovation Series: http://bradenkelley.com/2014/04/announcing-a-new-lean-innovation-series/
  94. The Lean Startup Cheat Sheet - v1.0: http://www.developmentthatpays.com/files/DevelopmentThatPays-TheLeanStartup-CheatSheet-1_0.pdf
  95. Falling in Love with the Problem: https://leanstartup.co/falling-love-problem/
  96. Good enough never is (or is it?): http://www.startuplessonslearned.com/2010/09/good-enough-never-is-or-is-it.html
  97. Lean Startups aren’t Cheap Startups: https://steveblank.com/2009/11/02/lean-startups-aren’t-cheap-startups/
  98. The Forrester New Wave™: Value Stream Management Tools, Q3 2018: https://www.forrester.com/report/The+Forrester+New+Wave+Value+Stream+Management+Tools+Q3+2018/-/E-RES141538
  99. Forrester report -- Where's The "Value" In Your Value Stream?: https://resources.collab.net/forrester-vsm-research/value-stream-management
  100. SixSigma -- Value Stream Mapping: https://www.isixsigma.com/dictionary/value-stream-mapping/
  101. What is Value Stream Mapping: https://www.lucidchart.com/pages/value-stream-mapping
  102. DevOps & Value Stream Mapping: https://www.slideshare.net/DevOpstastic/webcast-devops-and-value-stream-mapping
  103. DevOps and Value Stream Mapping -- Why you need metrics: https://techbeacon.com/devops-value-stream-mapping-why-you-need-metrics
  104. How value stream mapping delivered on DevOps' promise for Hearst Business Media: https://techbeacon.com/how-value-stream-mapping-delivered-devops-promise-hearst
  105. How value stream mapping, Kanban, queue management rival automation: https://techbeacon.com/how-value-stream-mapping-kanban-queue-management-rival-automation
  106. Value Stream Mapping vs. Metrics-Based: https://www.slideshare.net/KarenMartinGroup/vsmmbpmwhenyouoptforeach/34-Value_Stream_Mapping_vs_MetricsBased
  107. Value Stream Mapping & Metrics Based Process Mapping (MBPM): https://www.slideshare.net/KarenMartinGroup/vsmmbpmwhenyouoptforeach/34-Value_Stream_Mapping_vs_MetricsBased
  108. 10 Tips for Getting the Most Value from Value Stream Mapping: https://www.lean.org/LeanPost/Posting.cfm?LeanPostId=417
  109. Value Stream Mapping -- How to Visualize Work and Align Leadership for Organizational Transformation; by Mike Osterling, Karen Martin (BOOK): https://www.oreilly.com/library/view/value-stream-mapping/9780071828918/ch01.html
  110. Drive Alignment -- 5 Strategies for Burning Down Silos and Building Bridges: https://www.productplan.com/driving-alignment-burning-silos-building-bridges/
  111. 2019 is the year of the Value Stream: https://sdtimes.com/devops/2019-the-year-of-the-value-stream/
  112. Flow Framework: https://flowframework.org/
  113. Project to Product -- Value Stream Architecture: https://www.tasktop.com/blog/value-stream-architecture/
  114. Project to Product -- What Flows through a Software Value Stream?: https://www.tasktop.com/blog/what-flows-through-a-software-value-stream/
  115. Value Stream Mapping (VSM) and metrics-based process mapping (SLIDES): https://www.slideshare.net/KarenMartinGroup/vsmmbpmwhenyouoptforeach
  116. Value Stream Mapping -- How to Visualize Work & Align Leadership for Organizational Transformation (SLIDES): https://www.slideshare.net/KarenMartinGroup/10-082013-slides/1-2013TheKarenMartinGroupInc_8The_newbibleforvaluestreammappingandimproving_organizationalperformanceArtByrneformerCEOTheWiremold_CompanyandauthorTheLeanTurnaroundValueStreamMapping
  117. Value Stream Mapping -- Case Studies (SLIDES): https://www.slideshare.net/KarenMartinGroup/value-stream-mapping-case-studies/1-PrepareUnderstandCurrentStateDesignFutureStateDevelopTransformationPlanExecuteTransformationPlanThreeConsecutiveDays4WeeksPriortoMappingFollowingMappingRepeatValueStreamMappingActivityPhasesandTiming10January72014_February182014January212014wwwksmartincomwebinars
  118. Learning To See -- Making Value Flow…From End to End, v1 (BOOK): https://eclass.duth.gr/modules/document/file.php/TME159/Mike%20Rother%20-%20Learning%20to%20See%20Version%201.2%20%28kanban%29_value%20stream%20lean.pdf
  119. Learning To See -- Making Value Flow…From End to End, v2 (BOOK): http://sahibkarol.biz/gen/html/azl/kitabxana/44.pdf
  120. Learning To See -- Making Value Flow…From End to End, 2012 state of VSM (SLIDES): https://www.lean.org/Search/Documents/503.pdf
  121. Value Stream Mapping Math -- Rolled throughput Yield: http://www.leanmath.com/blog-entry/value-stream-mapping-math-rolled-throughput-yield
  122. Value Stream Segmentation and New Product Development: https://trace.tennessee.edu/cgi/viewcontent.cgi?article=4605&context=utk_gradthes
  123. Lean institute -- Total Value Stream - What is Value-Stream Mapping: https://www.lean.org/Search/Documents/80.pdf
  124. Value Stream Mapping - The Concept (SLIDES): https://www.slideshare.net/subhra2jyoti/value-stream-mapping-the-concept
  125. Does Value Stream Mapping Work for Software Development?: https://www.infoq.com/news/2010/11/does-value-stream-work
  126. Value Stream Diagram: https://www.conceptdraw.com/How-To-Guide/value-stream-diagram
  127. The Customer Value Problem: Ditch the Value Stream!: http://noop.nl/2010/10/the-customer-value-problem.html
  128. [wikipedia: Value stream mapping software]]
  129. Best software package for value stream mapping: https://www.lean.org/FuseTalk/Forum/messageview.cfm?catid=49&threadid=5998
  130. Value Stream Mapping for Software Development: https://leankit.com/blog/2017/08/value-stream-mapping-for-software-development/
  131. Creately - VSM guide: https://creately.com/blog/diagrams/value-stream-mapping-guide/
  132. ConceptDraw -- Value Stream Mapping Software: https://www.conceptdraw.com/How-To-Guide/value-stream-mapping-software
  133. MS Office -- VISIO - Create a "Value Stream Map": https://support.office.com/en-us/article/Create-a-value-stream-map-35A09801-999E-4BEB-AD4A-3235B3F0EAA3
  134. eVSM tool -- VSM examples: https://evsm.com/example-manufacturing
  135. Mapping Your Value Stream: https://portal.netobjectives.com/pages/books/adopting-safe-for-your-organization/mapping-your-value-stream/
  136. Looking at Your Work From a Value Stream Perspective: https://portal.netobjectives.com/pages/books/adopting-safe-for-your-organization/looking-at-your-work-from-a-value-stream-perspective/
  137. What's wrong with your value stream mapping: https://techbeacon.com/devops/whats-wrong-your-value-stream-mapping
  138. How to defrag your DevOps value stream: https://techbeacon.com/devops/how-defrag-your-devops-value-stream
  139. 6 steps to optimize software delivery with value stream mapping: https://opensource.com/article/18/12/optimizing-delivery-value-stream-mapping
  140. 10 steps to successful value stream mapping: https://www.thefabricator.com/article/shopmanagement/10-steps-to-successful-value-stream-mapping
  141. Learn the 10 Key Steps to Value Stream Mapping (VSM) for Software Delivery: https://www.plutora.com/blog/value-stream-mapping
  142. Flow Metrics -- An MRI of your Product Value Streams: https://go.tasktop.com/Flow-Metrics-MRI-Product-Value-Streams-OnDemand-Webinar.html | SLIDES
  143. Driving Digital Transformation Insights with Value Stream Management (WEBINAR): https://go.tasktop.com/driving-digital-transformation-insights-with-vsm-ondemand.html SLIDES
  144. Identify bottlenecks with Value Stream Mapping (VSM): https://www.ibm.com/garage/method/practices/discover/practice_value_stream_mapping
  145. What do you need to be successful at Value Stream Management, and how can you help?: https://sdtimes.com/value-stream/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: https://sdtimes.com/value-stream/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: https://techbeacon-com.cdn.ampproject.org/c/s/techbeacon.com/devops/5-reasons-why-cicd-vital-your-organizations-value-stream
  148. VSM DevCon 2021: https://www.accelevents.com/e/VSMDevCon2021/portal/schedule
  149. Challenging the way we organize around value: https://sdtimes.com/value-stream/challenging-the-way-we-organize-around-value/
  150. Why "Value Stream" matters to DevOps and the business: https://sdtimes.com/devops/why-value-stream-matters-to-devops-and-the-business/?activecampaign_id=123002
  151. A BizOps Manifesto aims to close gap between business, IT: https://sdtimes.com/devops/a-bizops-manifesto-aims-to-close-gap-between-business-it/
  152. Maximizing the ROI of your Agile transformations: https://sdtimes.com/agile/maximizing-the-roi-of-your-agile-transformations/
  153. Improve operational efficiency with value calculators: https://sdtimes.com/valuestream/improve-operational-efficiency-with-value-calculators/
  154. The Forrester Wave™ - Value Stream Management Solutions, Q3 2020: https://reprints.forrester.com/?mkt_tok=MjQ2LVdERy0xODUAAAGAi16KsA5f8RhcSXywjPnxuWW8i7NWwASNJJy_xORopKK6cuRpXlot9um-sfqG-guXFvc1uqQoLCZ80wn_5Rri54F-htHyKRzI-QybyOnlKgyH0Q#/assets/2/1365/RES159825/reports
  155. How to improve DevOps security with value stream management: https://www.adaptavist.com/blog/how-to-improve-devops-security-with-value-stream-management
  156. Why You Need a Value Stream Delivery Platform: https://devops.com/why-you-need-a-value-stream-delivery-platform/
  157. Building DevSecOps with Value Stream Management: https://devops.com/building-devsecops-with-value-stream-management/
  158. 6 steps for defining Product Value: https://www.youtube.com/watch?v=pNEkW9-de4A
  159. Tracking Value Delivery - A Case Study: https://www.youtube.com/watch?v=J-GB-7QvnGs
  160. Sequence Your Value Delivery with Impact Mapping: https://www.youtube.com/watch?v=ZHdGwkRtkvo
  161. "Continuous Improvement" throughout the value stream: https://www.vsmtimes.com/continuous-improvement-throughout-the-value-stream/
  162. Value Stream Management and Organizing Around Value: https://itrevolution.com/value-stream-management-and-organizing-around-value/
  163. wikipedia: Toyota Production System
  164. wikipedia: Lean manufacturing
  165. wikipedia: Kaizen
  166. Kanban the game: https://getkanban.com/ (learn about Kanban by practicing)
  167. Evolving the Kanban Board: https://dzone.com/articles/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)
  168. What is Kanban?: http://kanbanblog.com/explained/
  169. Kanban Thinking: http://kanban-thinking.net/
  170. Personal Kanban (BOOK): http://personalkanban.com/pk/
  171. Making Work Visible -- Exposing Time Theft to Optimize Work & Flow (BOOK): https://itrevolution.com/book/making-work-visible/
  172. The Five Time Thieves: https://itrevolution.com/the-five-time-thieves/
  173. Scaled Agile Framework -- Team Kanban: https://www.scaledagileframework.com/team-kanban/
  174. Kanban boards -- step by step: https://www.slideshare.net/GiulioRoggero/how-a-kanban-board-works
  175. 7 Obstacles to Enterprise Agility: http://scrumreferencecard.com/7-obstacles-to-enterprise-agility/
  176. Beginner’s Guide to Kanban for Agile Marketing: https://www.digite.com/blog/kanban-agile-marketing/
  177. Kanplan -- where your backlog meets Kanban: https://www.atlassian.com/agile/kanplan
  178. Kanban vs. Iterative Development: https://agileweboperations.com/2009/10/17/kanban-vs-iterative-development/
  179. Scrum .vs. Kanban (CHEAT SHEET): http://www.developmentthatpays.com/files/DevelopmentThatPays-ScrumVsKanban-CheatSheet-1_6.pdf
  180. Don't Push. Pull Work Items for Better Results: https://kanbantool.com/blog/dont-push-pull-work-items-for-better-results
  181. JIRA -- Using your Kanban backlog: https://confluence.atlassian.com/jirasoftwarecloud/using-your-kanban-backlog-856846180.html
  182. JIRA -- Monitoring work in a Kanban project (using a BOARD): https://confluence.atlassian.com/jirasoftwarecloud/monitoring-work-in-a-kanban-project-764478148.html
  183. Intro to Kanban (SLIDES): https://kanbantool.com/kanban-library/introduction (also has many article & terminology links)
  184. Benefits of Kanban (when done right): http://www.yodiz.com/blog/the-benefits-of-kanban/
  185. Ditching Scrum for Kanban  —  The best decision we’ve made as a team: https://medium.com/cto-school/ditching-scrum-for-kanban-the-best-decision-we-ve-made-as-a-team-cd1167014a6f
  186. Kanban vs Scrum -- Which One Is the Better Approach to Use in 2019?: https://www.proofhub.com/articles/kanban-vs-scrum
  187. Agile vs. Waterfall vs. Kanban vs. Scrum: What’s the Difference?: https://www.lucidchart.com/blog/agile-vs-waterfall-vs-kanban-vs-scrum
  188. What is Kanban System & kanban Board ? (scrum vs kanban): https://medium.com/agile-project-management-scrum-lean-kanban/what-is-kanban-system-kanban-board-scrum-vs-kanban-8a08673b0e55
  189. ScrumBan overview: http://leansoftwareengineering.com/ksse/scrum-ban/
  190. The Kanban Guide for Scrum Teams: https://scrumorg-website-prod.s3.amazonaws.com/drupal/2021-01/01-2021 Kanban Guide.pdf
  191. Embracing Uncertainty: https://lizkeogh.com/embracing-uncertainty/
  192. Kanban Metrics to Track Performance (Throughput) and Responsiveness (Cycle Time): https://kanbanzone.com/2017/throughput-cycle-time-metrics-kanban-performance-responsiveness/
  193. Cycle time vs Lead time – what is the difference?: https://mauvisoft.com/2021/02/24/cycle-time-vs-lead-time-what-is-the-difference/
  194. To estimate (or not) in Kanban? Leveraging lean thinking to eliminate waste.: https://www.linkedin.com/pulse/estimate-kanban-leveraging-lean-thinking-eliminate-waste-ponomareff
  195. Forecasting and Simulating Software Development Projects -- Effective Modeling of Kanban & Scrum Projects using Monte-carlo Simulation: https://www.amazon.com/gp/product/1466454830/
  196. #NoEstimates Part 2 – Contract Negotiation and the Old Banger: https://web.archive.org/web/20151221012844/http://neilkillick.com:80/2013/02/08/noestimates-part-2-contract-negotiation-and-the-old-banger/
  197. The perils of estimation: https://dannorth.net/2009/07/01/the-perils-of-estimation/
  198. All Estimation is Waste – Rubbish!: https://leankit.com/blog/2012/02/all-estimation-is-waste/
  199. Estimating defects in Agile is an anti-pattern: https://www.extremeuncertainty.com/estimating-defects-agile-anti-pattern/
  200. Is There Any Value in Estimating if You're Using Kanban?: https://dzone.com/articles/is-there-any-value-in-estimating-if-youre-using-ka
  201. Cynefin for Devs: https://lizkeogh.com/2012/03/11/cynefin-for-devs/
  202. How to release with Kanban?: https://stackoverflow.com/questions/3436666/how-to-release-with-kanban
  203. Visualizing Agile Projects using Kanban Boards: https://www.infoq.com/articles/agile-kanban-boards/
  204. 7 Steps to Build a Kanban Board for a Scrum Team’s Impediments: http://agiletrail.com/2011/09/05/7-steps-to-build-a-kanban-board-for-a-scrum-teams-impediments/
  205. How One Piece Flow Can Reduce Your Operations Time by 96% : https://www.process.st/one-piece-flow/
  206. Scrum Is Dead. All Hail Kanban, the New King: https://medium.com/better-programming/scrum-is-dead-all-hail-kanban-the-new-king-2cd6249feef8
  207. How to structure your teams when you scale Kanban: https://www.iancarroll.com/2014/12/23/scaling-kanban-organisational-design/
  208. 3 signals to watch out for when scaling your teams: https://www.iancarroll.com/2015/05/15/a-signal-from-conways-law/
  209. Can You Scale Kanban?: https://www.infoq.com/articles/can-you-scale-kanban/
  210. Large Scale Kanban with Klaus Leopold: https://www.digite.com/webinar/large-scale-kanban-with-klaus-leopold/
  211. Going Beyond WIP Limits for Ever-Higher Organizational Performance: https://leankit.com/blog/2017/02/wip-targets-organizational-performance/
  212. Balanced Flowchart Exercise: https://itrevolution.com/balanced-flowchart-exercise/ (finding where your time goes over a daily, then weekly, then monthly, then quarterly basis)
  213. Hiding in plain sight -- the everyday concept that can turbocharge your Kanban - Kanban Maturity Model: https://www.kanbanmaturitymodel.com/2020/08/11/hiding-in-plain-sight-the-everyday-concept-that-can-turbocharge-your-kanban/
  214. How to Use the Dependency Management Poster?: https://mauvisoft.com/2020/10/15/how-to-use-the-dependency-management-poster/
  215. 7 lessons about Dependency Management: https://djaa.com/seven-lessons-about-dependency-management/
  216. An intro to Jiko Kanri: http://jikokanri.org/essays/an-introduction-to-jiko-kanri
  217. "Jiko Kanri" literally means "self-managing" in Japanese: https://www.linkedin.com/company/jiko-kanri-dot-org
  218. Kanban Maturity Model -- Cost of Delay: https://djaa.com/wp-content/uploads/2021/01/Cost-of-Delay.pdf
  219. AgileAlliance -- Glossary of Agile Terms - Backlog: https://www.agilealliance.org/glossary/backlog/
  220. Crowded backlog? A product is more than the sum of its features: https://blog.codecentric.de/en/2021/03/crowded-backlog-a-product-is-more-than-the-sum-of-its-features/
  221. A Definitive Guide To Product Backlog – How To Build and Maintain It?: https://www.crayond.com/blog/product-backlog/
  222. Product Backlog Building Canvas: https://martinfowler.com/articles/product-backlog-building-canvas.html
  223. Product backlog prioritization quadrants: https://medium.com/101ideasforagileteams/product-backlog-prioritization-quadrants-f00b725c3756
  224. How to Prioritise Your Product Backlog: https://www.stepsize.com/blog/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)
  225. Why Impact/Effort Prioritization Doesn’t Work And why you should keep using it: https://itamargilad.medium.com/why-impact-effort-prioritization-doesnt-work-57d141fafc2c
  226. Scaled Agile, inc. -- Weighted Shortest Job First: https://www.scaledagileframework.com/wsjf/
  227. wikipedia: MoSCoW method
  228. DSDM Agile Framework -- Ch.10 - MOSCOW PRIORITISATION: https://www.agilebusiness.org/page/ProjectFramework_10_MoSCoWPrioritisation
  229. What is MoSCoW Prioritization?: https://www.productplan.com/glossary/moscow-prioritization/
  230. Cycle Time Goes Visual: https://www.digite.com/blog/kanban-cycle-time-analysis/
  231. wikipedia: 5S (methodology)
  232. Kaizen Institute - About the 5S approach: http://www.kaizen.com/knowledge-center/what-is-5s.html
  233. Using 5S Lean Methodology to Create an Agile Workplace: http://dzone.com/articles/lean-agile-software-development-workplace-with-5s
  234. Making a Case for Continuous Improvement: https://itrevolution.com/making-a-case-for-continuous-improvement/
  235. What Does "Kvetch" Mean?: https://www.chabad.org/library/article_cdo/aid/4029348/jewish/What-Does-Kvetch-Mean.htm (an interesting companion to "Kaizen" perhaps?)
  236. Enduring Ideas - The three horizons of growth: https://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/enduring-ideas-the-three-horizons-of-growth
  237. The Google Way of Building A Strong Learning Culture: https://www.shiftelearning.com/blog/building-learning-culture
  238. Creating a Culture of Learning in 6 Steps: https://learning.linkedin.com/content/dam/me/learning/EMW/lil-guide-creating-culture-learning-6-Steps.pdf
  239. Creating a Learning Culture in 6 Steps — and Why You Should: https://www.linkedin.com/business/learning/blog/culture-of-learning/6-steps-to-creating-a-learning-culture-and-why-you-should
  240. 20 Tips for Creating a Learning Culture in the Workplace: https://www.learnupon.com/blog/learning-culture/
  241. Cumulative Flow Diagram explained: https://kanbanize.com/kanban-resources/kanban-analytics/cumulative-flow-diagram
  242. Cumulative Flow Diagram - You Still Do Not Use It?: https://berriprocess.com/en/cumulative-flow-diagram-you-still-do-not-use-it/
  243. How to use the Cumulative Flow Diagram to visualize your project workflow: https://www.nutcache.com/blog/cumulative-flow-diagram/
  244. Cumulative Flow Diagram: http://brodzinski.com/2013/07/cumulative-flow-diagram.html
  245. What your CFD is telling you?: https://www.nutcache.com/blog/cumulative-flow-diagram/
  246. Cumulative Flow Diagram benefits: https://getnave.com/cumulative-flow-diagram
  247. Introducing the Time In State InSITe Visualization: http://maccherone.com/publications/LSSC2012-IntroducingtheTimeInStateInSITeChart.pdf
  248. User Stories - An Agile Introduction: http://www.agilemodeling.com/artifacts/userStory.htm
  249. wikipedia: User story
  250. wikipedia: Planning poker
  251. wikipedia: Anchoring
  252. Better Together — XP and Scrum: https://medium.com/agile-outside-the-box/better-together-xp-and-scrum-c69bf9bffcff
  253. User Stories overview: https://www.mountaingoatsoftware.com/agile/user-stories
  254. SPIDR – five simple techniques for a perfectly split User Story: https://blogs.itemis.com/en/spidr-five-simple-techniques-for-a-perfectly-split-user-story
  255. My Slicing Heuristic Concept Explained: https://medium.com/@neil2killick/my-slicing-heuristic-concept-explained-810ee70b311e
  256. The essence of story slicing in agile development: https://medium.com/@neil2killick/the-essence-of-story-slicing-in-agile-development-fc16a1226941
  257. Slicing, Estimation, Trimming: http://ronjeffries.com/articles/015-jul/slicing/
  258. Quick Reference Guide for Splitting User Stories: https://www.agilelearninglabs.com/2013/05/new-quick-reference-guide-for-splitting-user-stories/
  259. How to Work with Complex User Stories That Cannot Be Split: https://www.mountaingoatsoftware.com/blog/how-to-work-with-complex-user-stories-that-cannot-be-split
  260. Getting Small Stories: http://ronjeffries.com/xprog/articles/getting-small-stories/
  261. Epics, stories, versions, and sprints: https://www.atlassian.com/agile/delivery-vehicles
  262. Agile User Stories -- The Building Blocks for Software Project Development Success: https://www.scrumalliance.org/community/articles/2013/september/agile-user-stories
  263. Writing User Stories, Examples and Templates In Agile Methodologies: https://www.yodiz.com/blog/writing-user-stories-examples-and-templates-in-agile-methodologies/
  264. Myth -- In Scrum, the Product Backlog has to consist of solely User Stories: https://medium.com/the-liberators/myth-in-scrum-the-product-backlog-has-to-consist-out-of-user-stories-276b9ce758ce
  265. 5 Common Mistakes We Make Writing User Stories: https://www.scrumalliance.org/community/articles/2011/august/5-common-mistakes-we-make-writing-user-stories
  266. 10 Tips for Writing Good User Stories: http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/
  267. Write a Great User Story: https://help.rallydev.com/writing-great-user-story
  268. User Stories are Not Enough for a Great User Experience: http://www.romanpichler.com/blog/user-stories-enough-for-a-great-user-experience/
  269. User Stories -- Ready, Set, GO!: https://rgalen.com/agile-training-news/2014/9/14/user-stories-ready-set-go
  270. Want to write better user stories? Stop using “can”: https://morethancoding.com/2022/04/21/want-to-write-better-user-stories-stop-using-can/
  271. 12 Signs You’re Working in a Feature Factory - 3 Years Later: https://amplitude.com/blog/12-signs-youre-working-in-a-feature-factory-3-years-later
  272. Exclusive Excerpt from "The Value Flywheel Effect": https://itrevolution.com/exclusive-excerpt-from-the-flywheel-effect/
  273. What is this thing called (Business) Value?: https://medium.com/the-liberators/what-is-this-thing-called-business-value-3b88b734d5a9
  274. Business Value cheatsheet: https://drive.google.com/file/d/1Rq7hdFH8zG9eIhQNhW9ya0SnImiLwovn/view
  275. What is Business Value Engineering?: https://www.leanagiletraining.com/better-agile/what-is-business-value-engineering/
  276. What Is The Value of Perspective?: https://www.linkedin.com/pulse/what-value-perspective-michael-douglas/ (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)
  277. Business Value matrix to prioritize the Backlog: http://agilethings.nl/value-matrix-to-prioritize-the-backlog/ (consistency is key)
  278. Better (business) Value Sooner Safer Happier (BVSSH) principles: https://itrevolution.com/bvssh-principles/ (includes poster summarizing each principle)
  279. Business Marketing - Understand What Customers Value: https://hbr.org/1998/11/business-marketing-understand-what-customers-value
  280. Value-focused versus value-washing: The agency role in a sustainable future: https://www.campaignasia.com/article/value-focused-versus-value-washing-the-agency-role-in-a-sustainable-future/453424 (Prof. Philip Sugai):
  281. Value Washing: https://customerthink.com/value-washing/ (Prof. Philip Sugai)
  282. Story Points or Hours?: http://www.agilemarketing.net/story-points/
  283. What is a story point?: https://agilefaq.wordpress.com/2007/11/13/what-is-a-story-point/
  284. The secrets behind story points and agile estimation: https://www.atlassian.com/agile/estimation
  285. The Main Benefit of Story Points: https://www.mountaingoatsoftware.com/blog/the-main-benefit-of-story-points
  286. Estimating Agile Story Points Using Fibonacci: https://xbosoft.com/software-quality-blog/estimating-agile-story-points-using-fibonacci/
  287. What Is The Fibonacci Sequence? And How It Applies To Agile Development: https://elearningindustry.com/fibonacci-sequence-what-is-and-how-applies-agile-development
  288. Why is the Fibonacci series used in agile planning poker?: https://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker
  289. Why Progressive Estimation Scale Is So Efficient For Teams: http://www.yakyma.com/2012/05/why-progressive-estimation-scale-is-so.html
  290. Fibonacci -- The Math of Agile: http://www.elegantcoding.com/2012/02/fibonacci-math-of-agile.html
  291. Agile Estimating Tool – Planning Poker using Fibonacci Sequence: http://www.the-program-manager.com/project-management/agile-estimating-tool-planning-poker-using-fibonacci-sequence/
  292. Story Points vs. Development Hours: https://myagilemind.wordpress.com/2011/10/18/story-points-vs-development-hours/
  293. Story Points -- Estimate delivery "Effort" (not just) "Complexity": https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity
  294. Story Points Are Still About Effort: https://www.mountaingoatsoftware.com/blog/story-points-are-still-about-effort
  295. SWAGing -- A Rapid User Story Estimation Exercise for Distributed Teams: https://clarkn.medium.com/swaging-a-rapid-user-story-estimation-exercise-for-distributed-teams-fd57d9742b94
  296. Swimlane Sizing – Complete & Fast Backlog Estimation: http://theagilepirate.net/archives/109
  297. 12 CORE PRACTICES OF XP: http://basusourav.wordpress.com/2015/05/18/12-core-practices-of-xp/
  298. Extreme Programming FAQ: http://www.jera.com/techinfo/xpfaq.html#learningmore
  299. The 3 laws of TDD: http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
  300. wikipedia: Class-responsibility-collaboration card (CRC cards)
  301. "Team" room: https://www.martinfowler.com/bliki/TeamRoom.html
  302. Central Desk .vs. U-Pod seating arrangement: https://www.martinfowler.com/bliki/UPod.html
  303. User Story Mapping (BOOK): https://www.agilealliance.org/resources/books/user-story-mapping/
  304. The New User Story Backlog is a Map: http://jpattonassociates.com/the-new-backlog/
  305. Essentials of Agile User Story Mapping at Twitter - Atlassian Summit 2016: https://www.youtube.com/watch?v=svquaeyKg5E
  306. Story Mapping: http://www.jpattonassociates.com/wp-content/uploads/2015/03/story_mapping.pdf
  307. User Story essentials (quick reference guide): http://www.jpattonassociates.com/wp-content/uploads/2015/03/story_essentials_quickref.pdf
  308. DDD-Domain Driven Design (DDD) or Deadline Driven Design (DeadDD)?: https://dzone.com/articles/ddd-domain-driven-design-or-deadline-driven-design (how to salvage the bad DDD with the good DDD)
  309. It’s all in how you slice it -- Design your project in working layers to avoid half-baked incremental releases (by Jeff Patton): https://www.jpattonassociates.com/wp-content/uploads/2015/01/how_you_slice_it.pdf
  310. Story Mapping: https://www.productplan.com/glossary/story-mapping/
  311. Can a Traditional SRS Be Converted into User Stories?: https://www.mountaingoatsoftware.com/blog/can-a-traditional-srs-be-converted-into-user-stories
  312. Use cases vs user stories in Agile development: http://www.boost.co.nz/blog/2012/01/use-cases-or-user-stories
  313. Developing Effective Agile Requirements Relies On Both User Stories And Use Cases: https://www.batimes.com/articles/developing-effective-agile-requirements-relies-on-both-user-stories-and-use-cases.html
  314. User Stories to Functional Requirements in IT: http://www.brighthubpm.com/monitoring-projects/13143-implementing-functional-requirements-in-it-part-1/
  315. The Fallacy of Converting Requirements into User Stories: https://www.linkedin.com/pulse/fallacy-converting-requirements-user-stories-john-eaton
  316. User Stories – the Bridge Between Requirements and IT Project Implementation: http://www.blueprintsys.com/blog/the-bridge-user-stories-and-requirements/
  317. How Programmers and Testers (and Others) Should Collaborate on User Stories: https://www.mountaingoatsoftware.com/blog/how-programmers-and-testers-and-others-should-collaborate-on-user-stories
  318. 5 Must-Haves For Great Story Writing: https://blog.3back.com/infographic/5-must-haves-great-story-writing/
  319. Walking Through a "Definition of Done": https://www.scrum.org/resources/blog/walking-through-definition-done
  320. Should Documentation be in the "Definition of Done"? http://www.agiledocumentation.co.uk/2015/02/should-documentation-be-in-definition.html
  321. Improvement Stories - a simple alternative to User Stories: https://hackernoon.com/improvement-stories-a-simple-alternative-to-user-stories-714723c6a13e
  322. User Story Mapping and probabilistic forecasting: https://medium.com/serious-scrum/user-story-mapping-and-probabilistic-forecasting-4100832c09a
  323. Agile Progress and Quality Reporting: https://blog.scottlogic.com/2020/02/29/agile-progress-and-quality-reporting.html
  324. Why Agile Teams Put So Much Emphasis on Being Done Each Iteration: https://www.mountaingoatsoftware.com/blog/why-agile-teams-put-so-much-emphasis-on-being-done-each-iteration
  325. Swarming -- One-Piece Continuous Flow: https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/development-team/swarming--one-piece-continuous-flow
  326. Swarming - How To Instantly Boost Your Scrum Team’s Productivity: https://www.scruminc.com/swarming-instantly-boost-scrum-team-productivity/
  327. Process Efficiency in Scrum – Why it Matters and How to Measure it: https://www.scruminc.com/process-efficiency-scrum-matters-measure/
  328. Making Your User Stories "Ready" to Get to "Done": SLIDES | VIDEO
  329. The Evolution of the Scrum Guide— ‘10 to ‘19: https://medium.com/serious-scrum/the-evolution-of-the-scrum-guide-10-to-19-f3ac4d82cfcb
  330. A list of Scrum Articles, Guides and books that have defined Scrum: https://medium.com/serious-scrum/a-list-of-scrum-articles-guides-and-books-that-have-defined-scrum-7e4556beba69
  331. Agile "(Story) Point" System vs. Hours System: https://www.mountaingoatsoftware.com/blog/how-do-story-points-relate-to-hours
  332. Why do we use Story Points for Estimating (in Scrum)?: https://www.scrum.org/resources/blog/why-do-we-use-story-points-estimating
  333. Who Writes User Stories in Agile with Scrum?: https://everydayagile.com/who-writes-user-stories-in-agile-with-scrum-5b5ab4803015
  334. Scrum - stop marginalizing the Dev manager: https://www.reddit.com/r/agile/comments/3vlytm/scrum_stop_marginalizing_the_dev_manager/
  335. Scrum – are you Serious?: https://medium.com/serious-scrum/areyouserious/home (a series to address the malpractices of Scrum)
  336. Top 10 Scrum and Agile (INFOGRAPHICS): https://blog.3back.com/scrum-tips/top-10-scrum-agile-infographics/
  337. Scrum Project Life Cycle (SPLC): https://agile-mercurial.com/2019/03/13/scrum-project-lifecycle/ (how to "ease into" Scrum when stuck in a Waterfall organization by introducing SPLC as alternative to SDLC)
  338. Post Mortems Vs. Agile Retrospectives: https://softwaredevtools.com/blog/post-mortem-vs-retrospectives/
  339. Make the most of mistakes -- Best practices for agile retrospectives, postmortems: https://techbeacon.com/app-dev-testing/make-most-mistakes-best-practices-agile-retrospectives-postmortems
  340. The Definitive Guide to Agile Retrospectives and Post-Mortem Meetings: https://academy.nobl.io/definitive-guide-to-agile-retrospectives-and-post-mortem-meetings/
  341. Scrum And DevOps: https://dzone.com/articles/scrum-and-devops (how they can work together)
  342. Same or Different? Retrospectives and Post-Mortems: https://www.logigear.com/magazine/test-methods-and-metrics/same-or-different-retrospectives-and-post-mortems/
  343. Agile Retrospectives: https://agilepainrelief.com/blog/agile-retrospectives.html
  344. The Relationship Between Team Reflection and Planning: https://blog.trello.com/team-reflection-and-planning
  345. Who is the Project Manager in Scrum?: https://agile-mercurial.com/2018/08/16/who-is-the-project-manager-in-scrum/
  346. “Scrum doesn’t have Project Managers, so we ignore them in our organisation”: https://medium.com/serious-scrum/scrum-doesnt-have-project-managers-so-we-ignore-them-in-our-organisation-3f63d3744472
  347. Scrum and best practices (@ Microsoft): https://docs.microsoft.com/en-us/azure/devops/boards/sprints/best-practices-scrum?view=azure-devops
  348. Timing for Sprint Reviews & Retrospectives: https://www.mitchlacey.com/intro-to-agile/scrum/sprint-review-retrospective
  349. How To Install Apps On Older Devices Running Older Versions Of iOS: https://macreports.com/how-to-install-apps-on-older-devices-running-older-versions-of-ios/
  350. 6 diagrams I use to explain "Product Management" concepts: https://medium.com/@crstanier/6-diagrams-i-use-to-explain-product-management-concepts-b9d9e79880bf
  351. 12 Signs You’re Working in a Feature Factory: https://medium.com/hackernoon/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2
  352. A 12-Step Program for Recovering Product Managers: https://cutle.fish/blog/a-12-step-program-for-recovering-product-managers | VIDEO
  353. The Four Big Risks (to both projects & products): https://svpg.com/four-big-risks/
  354. Behold, the Product Management Prioritization Menagerie: https://deanondelivery.com/behold-the-product-management-prioritization-menagerie-7615ebe6167f
  355. Serious Scrum - Will the real Product Owner please stand up?: https://medium.com/serious-scrum/will-the-real-product-owner-please-stand-up-951917cf7b18
  356. Marty Cagan - What is Product Ownership?: https://www.youtube.com/watch?v=287IG1KCbm8
  357. What is an "Agile Coach"? A valuable role for organizational change: https://www.cio.com/article/3294700/agile-coach-role-defined.html
  358. Serious Scrum - "Sorry Scrum, the Game Might Be Over for You!": https://medium.com/serious-scrum/sorry-scrum-the-game-might-be-over-for-you-915227f3a0d
  359. How Do You Identify a Successful Scrum Master?: https://www.scrum.org/resources/blog/how-do-you-identify-successful-scrum-master
  360. wikipedia: Scrum Sprint
  361. Agile Scrum overview: http://www.mountaingoatsoftware.com/agile/scrum
  362. 5 Key Patterns from "A Scrum Book" (and ScrumPLoP.org): https://leanagiletraining.com/video/5-key-patterns-scrum-book-scrumplop-org/
  363. CSM-Moncton November 2017: http://agileconsortium.pbworks.com/w/page/121689657/CSM-%20Moncton%20November%202017
  364. University of California - CS course in Agile: http://athena.ecs.csus.edu/~buckley/CSc231_files/ (lots of books/whitepapers/material)
  365. When did Scrum stop being a methodology?: https://www.quora.com/When-did-scrum-stop-being-a-methodology (re-dubbed a "Framework" instead)
  366. 2017 Scrum Guide Revision Webinar: https://www.scruminc.com/scrum-guide-revision-webinar/
  367. Agile Product Management with Scrum (BOOK): http://www.romanpichler.com/romans-books/agile-product-management-with-scrum/
  368. Scrum Essentials Cards: https://queue.acm.org/detail.cfm?id=3418775
  369. The Beginner’s Guide To Scrum And Agile Project Management: https://blog.trello.com/beginners-guide-scrum-and-agile-project-management
  370. Business Analysts in Scrum: http://www.romanpichler.com/blog/business-analysts-in-scrum/: http://www.romanpichler.com/blog/business-analysts-in-scrum/
  371. What is an AGILE Business Analyst?: http://www.batimes.com/steve-blais/what-is-an-agile-business-analyst.html
  372. The Role of the Analyst in Agile Projects: http://www.infoq.com/articles/agile-business-analyst-role
  373. What does a business analyst do in a scrum team?: http://www.quora.com/What-does-a-business-analyst-do-in-a-scrum-team
  374. Agile Testing -- The Role Of The Agile Tester: http://www.slideshare.net/dwhelan/agile-testing-and-the-role-of-the-agile-tester
  375. Role of Testers in Agile?: http://stackoverflow.com/questions/1640911/role-of-testers-in-agile
  376. Role of Testers in Agile Teams: http://www.infoq.com/news/2015/11/testers-agile-teams
  377. The Tester’s Role in Agile Is More than “Just Testing”: http://www.scrumalliance.org/community/articles/2014/june/the-tester%E2%80%99s-role-in-agile-is-more-than-just-testi
  378. Why the Whole Team Should Participate When Estimating: https://www.mountaingoatsoftware.com/blog/why-the-whole-team-should-participate-when-estimating
  379. The Role of an Architect on a Scrum Team: http://dzone.com/articles/role-of-architect-in-scrum-team
  380. Programmers vs. Developers vs. Architects: http://akselsoft.blogspot.ca/2013/06/programmers-vs-developers-vs-architects.html
  381. Essential Scrum -- Chapter 6 - Product Backlog: http://www.innolution.com/essential-scrum/table-of-contents/chapter-6-product-backlog
  382. Product Backlog Item (PBI) vs User Story: http://softwareengineering.stackexchange.com/questions/102523/pbi-vs-user-story
  383. The Art of Product Backlog Refinement: https://dzone.com/articles/the-art-of-product-backlog-refinement
  384. Sprint Planning for Agile Teams That Have Lots of Interruptions: https://dzone.com/articles/sprint-planning-for-agile-teams-that-have-lots-of
  385. Does Scrum really work?: http://blog.apterainc.com/custom-software/does-scrum-really-work
  386. Scrum and Team Effectiveness - Theory and Practice: https://www.researchgate.net/publication/221592867_Scrum_and_Team_Effectiveness_Theory_and_Practice
  387. Agile Project Development at Intel -- A Scrum Odyssey: http://scrumtrainingseries.com/Intel-case-study.pdf
  388. A Case Study on the Applicability and Effectiveness of Scrum Software Development in Mission-Critical and Large-Scale Projects: http://aisel.aisnet.org/cgi/viewcontent.cgi?article=1993&context=amcis2006&sei-redir=1&referer=http%3A%2F%2Fwww.bing.com%2Fsearch%3Fq%3Dstudies%2Bon%2Beffectiveness%2Bof%2Bscrum%26src%3DIE-TopResult%26FORM%3DIETR02%26conversationid%3D#search=%22studies%20effectiveness%20scrum%22
  389. Are there any studies on the Efficiency/Effectiveness of Agile vs Waterfall: https://softwareengineering.stackexchange.com/questions/125429/are-there-any-studies-on-the-efficiency-effectiveness-of-agile-vs-waterfall
  390. Introduction to Scrum (PRESENTATION): https://www.mountaingoatsoftware.com/presentations/an-introduction-to-scrum
  391. Reusable Scrum Presentation: http://www.mountaingoatsoftware.com/agile/scrum/resources/a-reusable-scrum-presentation
  392. Solve Scrum Problems Today -- 5 Free Preview Lessons From The Scrum Repair Guide: https://www.mountaingoatsoftware.com/training/courses/scrum-repair-guide/five-free-preview-lessons
  393. An Iterative Waterfall Isn’t Agile: http://www.mountaingoatsoftware.com/blog/an-iterative-waterfall-isnt-agile
  394. Scrum Training series -- Module 4 - Daily Scrum Meeting (aka. 15-minute Standup): http://scrumtrainingseries.com/DailyScrumMeeting/DailyScrumMeeting.htm
  395. The 3-5-3 of Scrum: https://www.scruminc.com/the-3-5-3-of-scrum/
  396. The Daily Scrum: https://www.leanagiletraining.com/better-agile/the-daily-scrum/
  397. Suggestions for a better Daily Scrum: https://www.leanagiletraining.com/scrum-meetings/suggestions-for-a-better-daily-scrum/
  398. Do Scrum Teams Meet Too Much?: https://www.mountaingoatsoftware.com/blog/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?)
  399. Stop Calling Your Sprint Review a Demo WORDS MATTER!: http://www.scrumalliance.org/community/spotlight/ken-rubin/january-2015/stop-calling-your-sprint-review-a-demo%E2%80%94words-matte
  400. Sprint Review Meeting: http://www.scrum-institute.org/Sprint_Review_Meeting.php
  401. Microsoft - Sprint Review Meeting: https://msdn.microsoft.com/en-us/library/ee191592(v=vs.100).aspx
  402. Agile Management for Dummies - Sprint Review: http://www.dummies.com/careers/project-management/the-agile-management-sprint-review/
  403. Sprint Review: https://www.mitchlacey.com/intro-to-agile/scrum/sprint-review
  404. Scrum Training series -- Module 5 - Sprint Review Meeting: http://scrumtrainingseries.com/SprintReviewMeeting/SprintReviewMeeting.htm
  405. How to facilitate an awesome Sprint Review in “Bazaar mode”: http://www.dcme.nu/how-to-facilitate-an-awesome-sprint-review-in-bazaar-mode/
  406. Retrospective Plans: http://retrospectivewiki.org/index.php?title=Retrospective_Plans (different games/playbooks for running effective & engaging Sprint Retros)
  407. Sprint Retrospective: http://www.scruminc.com/sprint-retrospective/
  408. The Four Questions of a Retrospective and Why They Work : https://dzone.com/articles/“-4-questions”-retrospective
  409. 3 Simple Steps to Effective Retrospectives: https://web.archive.org/web/20140831021840/https://gerryclaps.com/agile-retrospective-steps/ (1-Collect Data, 2-Look for Patterns, 3-Determine Actions)
  410. Sprint Retrospective: http://www.scruminc.com/sprint-retrospective/
  411. Sprint Retrospective summary: https://sites.google.com/site/agiledevelopmentsite/process/sprint-retrospective
  412. Sprint Retrospective overview: https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-retrospective
  413. What is a Sprint Retrospective?: http://www.scrum.org/resources/what-is-a-sprint-retrospective
  414. Key Elements of the Sprint Retrospective: http://www.scrumalliance.org/community/articles/2014/april/key-elements-of-sprint-retrospective (what: went well, went wrong,
  415. The Upward Spiral -- Sprint Retrospective Techniques: https://waynedgrant.wordpress.com/2012/04/01/sprint-retrospective-techniques/
  416. Agile Management for Dummies - Sprint Retrospective: http://www.dummies.com/careers/project-management/agile-management-and-the-sprint-retrospective/
  417. Scrum Training series -- Module 6 - Sprint Retrospective Meeting: http://scrumtrainingseries.com/SprintRetrospectiveMeeting/SprintRetrospectiveMeeting.htm
  418. Applied Macro-measurements to Ensure On-Time Delivery, an Agile Approach to “Metrics”: http://scrumreferencecard.com/MacroMeasurementWhitepaper.pdf
  419. Do Scrum sprints mean to work at the fastest pace possible?: https://softwareengineering.stackexchange.com/questions/223250/do-scrum-sprints-mean-to-work-at-the-fastest-pace-possible
  420. What is the difference between Sprint and Iteration in Scrum and length of each Sprint?: https://stackoverflow.com/questions/1227318/what-is-the-difference-between-sprint-and-iteration-in-scrum-and-length-of-each/1227406#1227406
  421. What is Pig and Chicken in Scrum?: https://www.visual-paradigm.com/scrum/scrum-pig-and-chicken/
  422. Commitment-Driven Sprint Planning: https://www.mountaingoatsoftware.com/blog/commitment-driven-planning
  423. Commitment vs. Forecast -- A Subtle But Important Change to Scrum: https://www.scrum.org/resources/commitment-vs-forecast-subtle-important-change-scrum
  424. How to measure the accuracy of forecasts: https://blog.asmartbear.com/forecast.html
  425. ScrumMaster and Product Owner Sprint "Commitments": https://www.scrumalliance.org/community/articles/2013/july/scrummaster-and-product-owner-sprint-commitments
  426. Must a Scrum team stick with the Sprint commitment or is it just a Forecast?: https://www.quora.com/Must-a-Scrum-team-stick-with-the-Sprint-commitment-or-is-it-just-a-forecast
  427. What is a scrum master?: https://www.atlassian.com/agile/scrum/scrum-master
  428. Why Scrum needs Product Leadership: https://medium.com/@chrislukassen/https-medium-com-chrislukassen-why-scrum-needs-product-leadership-bb4362ea77ff
  429. 9 Questions Scrum Masters and Product Owners Should Be Asking: https://www.mountaingoatsoftware.com/blog/nine-questions-scrum-masters-and-product-owners-should-be-asking | PDF
  430. 3 Mistakes Scrum Masters Make and How to Correct Them: https://www.mountaingoatsoftware.com/blog/three-mistakes-scrum-masters-make-and-how-to-correct-them
  431. Spikes and the Effort-to-Grief Ratio: https://www.scrumalliance.org/community/articles/2013/march/spikes-and-the-effort-to-grief-ratio
  432. Spikes: http://www.scaledagileframework.com/spikes/
  433. PlanningPoker: https://www.planningpoker.com/
  434. JIRA plugin - PlanningPoker: https://marketplace.atlassian.com/plugins/agile.estimation.3.0_private/cloud/overview SRC
  435. Planning Poker deck (and walkthrough): https://www.crisp.se/bocker-och-produkter/planning-poker
  436. How to play planning poker… Badass Mode! : https://philippe.bourgau.net/how-to-play-planning-poker-badass-mode/
  437. The Case for Poker Cards in Sprint Planning: https://www.scrumalliance.org/community/articles/2013/february/the-case-for-poker-cards-in-sprint-planning
  438. Agile Estimating and Planning: https://www.mountaingoatsoftware.com/books/agile-estimating-and-planning
  439. Process Efficiency in Scrum – Why it Matters and How to Measure it: https://www.scruminc.com/process-efficiency-scrum-matters-measure/
  440. Velocity - How is it useful?: https://www.leanagiletraining.com/better-agile/velocity-how-is-it-useful/
  441. Velocity - Some preliminaries: https://www.leanagiletraining.com/better-agile/velocity-some-preliminaries/
  442. THE IMPORTANCE OF THE PRODUCT OWNER: https://www.leanagiletraining.com/agile-business/the-importance-of-the-product-owner/
  443. WHAT DOES A "PO" DO?: https://www.leanagiletraining.com/bv-engineering/what-does-a-po-do/
  444. Requirements for Product Owner -- Common Pitfalls: https://www.scruminc.com/requirements-for-product-owner-common/
  445. Keep Scrum retros positive with “Appreciative Inquiry”: https://medium.com/serious-scrum/how-you-can-keep-scrum-positive-85291b87caf9
  446. The only thing that matters when planning a Sprint: https://productcoalition.com/the-only-thing-that-matters-when-planning-a-sprint-1bf65c059110
  447. Why I Hate Scrum: https://dzone.com/articles/why-i-hate-scrum
  448. So, what is ‘Water-SCRUM-fall’?: https://sdarchitect.blog/2012/05/07/so-what-is-water-scrum-fall/
  449. The Comprehensive Guide to Making Agile and Waterfall Methodologies Get Along (And Avoid Drama and Delays along the Way): https://reqtest.com/agile-blog/agile-waterfall-hybrid-methodology-2/
  450. What is Water-Scrum-Fall (and is it inevitable)?: http://www.agiledocumentation.co.uk/2015/02/what-is-water-scrum-fall-and-is-it.html
  451. Analyst Watch -- Water-Scrum-fall is the reality of agile: https://sdtimes.com/agile/analyst-watch-water-scrum-fall-is-the-reality-of-agile/
  452. Waterscrumfall -- the new hype in software development?: https://labs.sogeti.com/waterscrumfall-new-hype-software-development/
  453. Water-Scrum-Fall — is it a Myth or Reality?: https://www.knowledgehut.com/blog/agile/water-scrum-fall-myth-reality
  454. Water-Scrum-Fall Tons of upfront planning. Iterate. Tons of post code testing & Deployment steps: https://twitter.com/AgileAlliance/status/598910669170290688
  455. Water-Scrum-Fall Model in Life Sciences: https://www.iquestgroup.com/news/press-release/water-scrum-fall-model-life-sciences
  456. Leveraging DevOps in a 'water-SCRUM-fall' world: https://www.ibm.com/developerworks/community/blogs/invisiblethread/entry/leveraging_devops_in_a_waterscrumfall_world
  457. What Does QA Do on the First Day of a Sprint?: http://www.threefivetwo.com/blog/what-does-qa-do-on-the-first-day-of-a-sprint
  458. Avoiding Squirrel Burgers By Insisting on Quality: https://www.threefivetwo.com/blog/avoiding-squirrel-burgers-by-insisting-on-quality
  459. The Trouble with Sprint Burndowns: https://resources.scrumalliance.org/Article/trouble-sprint-burndowns
  460. Scrum by Example – Overtime on a Scrum Team is an Unhealthy Sign: https://agilepainrelief.com/blog/scrummaster-tales-overtime-on-a-scrum-team-is-an-unhealthy-sign.html
  461. wikipedia: Scrumban
  462. Lean/Kanban – The Perils of Partial Adoption: http://www.worldofchris.com/blog/2013/06/12/leankanban-the-perils-of-partial-adoption/
  463. Advantages and Disadvantages of Kanban: http://functionalguy.blogspot.ca/2007/04/advantages-and-disadvantages-of-kanban.html#axzz4fMwl88pr
  464. The Perils of Project Parallelization: https://agilefixer.com/2017/03/13/the-perils-of-project-parallelisation/
  465. Why is Agile/Scrum compared to Rugby?: https://www.captechconsulting.com/blogs/why-is-agilescrum-compared-to-rugby
  466. Let's Stop "Adopting" Agile and Start Becoming Agile: https://www.scrumalliance.org/community/articles/2014/july/let’s-stop-adopting”-agile-and-start-becoming-agil
  467. When Not to Use Scrum: http://www.scrumcrazy.com/When+Not+to+Use+Scrum
  468. Scrum Will Die: https://simpleprogrammer.com/2010/02/23/scrum-will-die/
  469. How scrum can stop you being agile?: http://www.global-integration.com/blog/scrum-stop-agile/
  470. Challenging Why (not if) Scrum Fails: http://www.netobjectives.com/blogs/challenging-why-not-if-scrum-fails
  471. 24 Common Scrum Pitfalls Summarized: http://www.agileadvice.com/2011/12/05/referenceinformation/24-common-scrum-pitfalls-summarized/
  472. What to do when Scrum doesn’t work: http://blog.crisp.se/2010/09/01/henrikkniberg/1283373060000
  473. An Introduction to Scrumban for Agile Marketing: http://www.marketergizmo.com/an-introduction-to-scrumban-for-agile-marketing/
  474. Scrumban -- A different way to be Agile: http://www.deloittedigital.com/us/blog/scrumban-a-different-way-to-be-agile
  475. What is Scrumban?: http://www.solutionsiq.com/what-is-scrumban/
  476. What is a Bottleneck and How to Deal With It?: https://kanbanize.com/lean-management/pull/what-is-bottleneck/
  477. Breaking Agile’s QA Bottlenecks: http://cdn2.hubspot.net/hubfs/169989/Solutions_Website_Resource_Center/Breaking_Agiles_QA_Bottlenecks.pdf
  478. Clearing the Software Testing Bottleneck: https://www.devopsdigest.com/clearing-the-software-testing-bottleneck
  479. Scrum & Kanban - Battle Royale or Save the World?: https://www.infoq.com/presentations/scrum-vs-kanban
  480. MercuryApp - poll/index tracking tool: https://www.mercuryapp.com
  481. Tracking Project Emotions Using MercuryApp: tooky.github.io/2010/11/23/tracking-project-emotions-using-mercury-app.html
  482. How to Track the Team’s Mood with a Niko-niko Calendar: http://agiletrail.com/2011/09/12/how-to-track-the-teams-mood-with-a-niko-niko-calendar/
  483. Why having a Niko-Niko chart is just as important as having a Burndown Chart: https://talentedtester.com/tag/niko-niko-calendar-agile/
  484. Niko-niko Calendar: https://www.agilealliance.org/glossary/nikoniko/
  485. Attention! Niko-Niko Calendar, it’s important to any Agile teams: https://ahmadi.pm/articles/attention-niko-niko-calendar-its-important-to-any-agile-teams
  486. Information Radiators: https://www.agilealliance.org/glossary/information-radiators/#q=~(infinite~false~filters~(postType~(~'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)
  487. Why a Niko-Niko Calendar Kills Workplace Morale: https://www.tinypulse.com/blog/sk-niko-niko-calendar-workplace-morale
  488. SMILE, Dammit -- Some Companies Are Using An App To Track Your Moods At Work: https://www.fastcompany.com/3040755/smile-dammit-some-companies-are-using-an-app-to-track-your-moods-at-wor
  489. The Hot Potato Process: http://danmall.me/articles/hot-potato-process/
  490. No Projects - Beyond Projects: https://www.infoq.com/articles/kelly-beyond-projects/
  491. NoProjects -- SAMPLE CHAPTER - An introduciton to a new way of thinking about work: http://theagiledirector.com/images/noprojectsbook.pdf
  492. Using the NoProjects Paradigm: https://wiki.businessagility.institute/w/CaseStudies:Using_the_NoProjects_Paradigm
  493. #noprojects -- Outcomes - The Value of Change : https://www.infoq.com/articles/noprojects3-value-change
  494. #NoProjects - Teams over Projects: https://www.slideshare.net/allankellynet/noprojects-teams-over-projects
  495. The agile guide to winning at team development: https://www.atlassian.com/blog/teamwork/navigate-tuckman-stages-of-team-development
  496. #NoProjects everywhere: https://www.allankellyassociates.co.uk/archives/4313/noprojects-everywhere/
  497. The #NoEstimates Movement: https://www.barryovereem.com/the-noestimates-movement/
  498. The Estimates in #NoEstimates: https://lizkeogh.com/2015/05/01/the-estimates-in-noestimates/
  499. Ryan Ripley on #NoEstimates movement: https://www.youtube.com/watch?v=-eE7rtCQHI8 | SLIDES
  500. #NoEstimates -- 6 Software Experts Give Their View on the Movement: https://plan.io/blog/noestimates-6-software-experts-give-their-view/
  501. The Throw Down -- "Agile Estimation" .vs. #NoEstimates: https://lithespeed.com/throw-agile-estimation-vs-noestimates/
  502. The NoEstimates book (overview from the author, Vasco Duarte): http://softwaredevelopmenttoday.com/noestimates/
  503. Planning with #NoEstimates: https://www.infoq.com/news/2015/10/planning-noestimates
  504. (Agile) Forecasting for Beginners: https://www.infoq.com/presentations/forecasting-spreadsheet
  505. The logic of #NoEstimates -- #NoEstimates follows in the footsteps of Agile and Scrum: https://medium.com/serious-scrum/the-logic-of-noestimates-4238e0be3bb6
  506. #NoEstimates and why Estimates are almost always wrong (by Allen Holub): https://www.youtube.com/watch?v=QVBlnCTu9Ms
  507. Time Tracking is Essential to Agile Development?: https://www.myintervals.com/blog/2010/03/02/time-tracking-is-essential-to-agile-development/
  508. Time Tracking on an Agile Team: http://stephenwalther.com/archive/2014/04/21/time-tracking-on-an-agile-team
  509. Strategies for Tracking Time on Agile Teams: https://disciplinedagiledelivery.com/time-tracking-strategies/
  510. Time Tracking and Agile Methodology: https://stackoverflow.com/questions/2234851/time-tracking-and-agile-methodology
  511. Six Reasons for Time Tracking in Agile Projects: https://www.timecockpit.com/blog/201a3/06/25/Six-Reasons-for-Time-Tracking-in-Agile-Projects
  512. Lean Accounting -- Does IT Need a Time Out on Time Tracking?: https://leankit.com/blog/2017/01/lean-accounting-time-tracking/ (answer: NO, measure Business Value/ROI, Cycle Time & Throughput instead)
  513. To estimate or not to estimate, that is the question: https://www.allankellyassociates.co.uk/archives/634/to-estimate-or-not-to-estimate-that-is/
  514. Why Agile (by itself, often) Doesn't Work for Large Projects: https://dzone.com/articles/agile-for-large-projects
  515. Scaling for End-to-End Agility: http://innolution.com/blog/scaling-for-end-to-end-agility
  516. Don’t Organize Around Projects! Choose a Better Unit of Focus to Eliminate Waste & Increase Agility: http://innolution.com/blog/dont-organize-around-projects-choose-a-better-unit-of-focus-to-eliminate-wa
  517. Agile at scale -- Movin' on up: scaling agile in large organizations: https://www.atlassian.com/agile/agile-at-scale/
  518. SCALING Agile: PART 1 | PART 2
  519. Scaling GitHub's Employees: https://zachholman.com/posts/scaling-github-employees/
  520. Why it’s difficult to build teams in high growth organisations: https://jchyip.medium.com/why-its-difficult-to-build-teams-in-high-growth-organisations-e1aee8446337
  521. Scrum of Scrums (DEFINITION): https://www.agilealliance.org/glossary/scrum-of-scrums/#q=~(infinite~false~filters~(postType~(~'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)
  522. Scrum of Scrums overview: https://www.scruminc.com/scrum-of-scrums/
  523. Scrum of Scrums -- implementation example: https://www.scrum-tips.com/2018/02/18/scrum-of-scrums/
  524. All About the Scrum of Scrums: https://www.eylean.com/blog/2016/05/all-about-the-scrum-of-scrums/
  525. Scrum Team & Scrum of Scrums: https://www.mountaingoatsoftware.com/agile/scrum/roles/team
  526. What is Scrum of Scrums?: blog.scrumstudy.com/what-is-scrum-of-scrums/
  527. Scrum in practice -- the Scrum of Scrums meeting: https://manifesto.co.uk/scrum-of-scrums-meeting/
  528. What is a Scrum of Scrums?: http://rgalen.com/agile-training-news/2016/11/9/what-is-a-scrum-of-scrums
  529. Using Scrum of Scrums with Agile Teams to Coordinate and Collaborate: https://www.infoq.com/news/2014/03/scrum-of-scrums/
  530. SAFe or Scrum at Scale – Which Framework is Best for You?: https://content.intland.com/blog/agile/safe/safe-or-scrum-at-scale-which-framework-is-best-for-you
  531. SAFE or Scrum@Scale which is best for you?: https://content.intland.com/blog/agile/safe/safe-or-scrum-at-scale-which-framework-is-best-for-you
  532. Scaling Agile Scaling Agile -- LeSS vs. SAFe: https://blue-agility.com/scaling-agile-less-vs-safe-2/
  533. wikipedia: Scaled Agile Framework
  534. Introducing the scaled agile framework: https://www.cio.com/article/2936942/introducing-the-scaled-agile-framework.html
  535. dzone -- Pattern of the Month - Increment: https://dzone.com/articles/pattern-of-the-month-increment
  536. What is an Increment in Scrum?: https://www.scrum.org/resources/what-is-an-increment
  537. Scaled Agile Framework (SAfe) -- Program Increment (PI): https://www.scaledagileframework.com/program-increment/
  538. Scaled Agile Framework (SAfe) -- Features and Capabilities: https://www.scaledagileframework.com/features-and-capabilities/
  539. Scaled Agile Framework (SAfe) -- Milestones: https://www.scaledagileframework.com/milestones/
  540. Scaled Agile Framework (SAfe) -- PI Planning: https://www.scaledagileframework.com/pi-planning/
  541. Scaled Agile Framework (SAfe) -- Innovation and Planning Iteration: https://www.scaledagileframework.com/innovation-and-planning-iteration/
  542. Scaled Agile Framework (SAfe) -- Portfolio Level: https://www.scaledagileframework.com/portfolio-level/
  543. Scaled Agile Framework (SAfe) -- Value Streams: https://www.scaledagileframework.com/value-streams/
  544. Scaled Agile Framework (SAfe) -- Agile Release Train (ART): https://www.scaledagileframework.com/agile-release-train/
  545. Scaled Agile Framework (SAfe) -- Release Train Engineer and Solution Train Engineer: https://www.scaledagileframework.com/release-train-engineer-and-solution-train-engineer/
  546. Scaled Agile Framework (SAfe) -- Release "on Demand": https://www.scaledagileframework.com/release-on-demand/
  547. Scaled Agile Framework (SAfe) -- Business Owners: https://www.scaledagileframework.com/business-owners/
  548. Drive Innovation in Software Development -- How to Choose Between Incremental and Fundamental Change: https://blog.overops.com/drive-innovation-in-software-
  549. What is SAFe?: https://www.atlassian.com/agile/agile-at-scale/what-is-safe
  550. SAFe® 5.0 -- How to Avoid This Big Mistake - Tasktop Blog: https://blog.tasktop.com/safe-5-0-how-to-avoid-this-big-mistake/
  551. SoS vs LeSS vs SAFe – Which One Is Right For You?: https://www.eylean.com/blog/2016/05/sos-vs-less-vs-safe-which-one-is-right-for-you/
  552. Atlassian summary - The Large-Scale Scrum (LeSS) framework: https://www.atlassian.com/agile/agile-at-scale/less
  553. Scrum@Scale -- The Path to Agile - 30 Years of Large-Scale Agile Transitions @ Agile Amsterdam 2017 - Tobacco Theatre: https://34slpa7u66f159hfp1fhl9aur1-wpengine.netdna-ssl.com/wp-content/uploads/2017/10/Scrum-at-Scale-Keynote-Amsterdam-Sep-2017.pdf
  554. Scaling Scrum – What People Are Not Talking About!: https://www.scruminc.com/scaling-scrum-what-people-are-not/
  555. An Introduction to the Nexus Framework: https://www.scrum.org/resources/introduction-nexus-framework
  556. Spotify Engineering Culture: Part 1 | Part 2
  557. Scaling Agile at Spotify: https://www.youtube.com/watch?v=jyZEikKWhAU
  558. Scaling Agile at Spotify (presentation): https://www.slideshare.net/vmysla/scrum-at-spotify
  559. Case Study -- When emulating Scaling Agile at Spotify went awry at Refinery29: https://medium.com/@andy.park/when-emulating-scaling-agile-at-spotify-goes-awry-d297dc006763
  560. ORGANISATIONAL STRUCTURE -- MATRIX ORGANISATION HARMS YOUR COMPANY (if done wrong): https://luis-goncalves.com/organisational-structure-matrix-organisation/
  561. Thoughts on emulating Spotify’s matrix organization in other companies: https://blog.kevingoldsmith.com/2014/03/14/thoughts-on-emulating-spotifys-matrix-organization-in-other-companies/#content
  562. Failed #SquadGoals Spotify doesn’t use “the Spotify model” and neither should you: https://www.jeremiahlee.com/posts/failed-squad-goals/
  563. Spotify Doesn't Use the Spotify Model: https://www.agility11.com/blog/2020/6/22/spotify-doesnt-use-the-spotify-model
  564. Why Copying Spotify’s Squads and Tribes Model Probably Won’t Work for You: https://www.harbott.com/why-squads-and-tribes-probably-wont-work/
  565. Atlassian -- Team Playbooks - Discover the Spotify model: https://www.atlassian.com/agile/agile-at-scale/spotify
  566. Agile Team Organisation: Squads, Chapters, Tribes and Guilds -- why reogranize?: https://www.theproducthub.io/2019/10/20/agile-team-organisation-squads-chapters-tribes-and-guilds/
  567. Set-Based Concurrent Engineering: Toyota's Principles of Set-Based Concurrent Engineering (SBCE): https://sloanreview.mit.edu/article/toyotas-principles-of-setbased-concurrent-engineering/
  568. Toyota production system (SLIDES): https://www.slideshare.net/akshayjain186590/opc-tps
  569. Agile Topics card deck: http://blog.crisp.se/2015/10/08/jimmyjanlen/agile-topics-card-deck
  570. Card Decks for Agile Transitions: http://leanpizza.net/card-decks-for-agile-transition/
  571. 10 Best Free Scrum Tools: http://knowscrum.com/10-best-free-scrum-tools/
  572. JIRA + HipChat = real-time communication for agile teams: http://blogs.atlassian.com/2015/03/jira-hipchat-real-time-communication-agile-teams/
  573. The complete guide to using HipChat as an agile team: https://blog.hipchat.com/2015/08/25/the-complete-guide-to-using-hipchat-as-an-agile-team/
  574. HipChat vs. Yammer and Office 365: http://www.agileit.com/news/hipchat-vs-yammer-office-365/
  575. 5 open source alternatives to Trello: http://opensource.com/business/15/8/5-open-source-alternatives-trello
  576. Definition of Ready: https://www.scruminc.com/definition-of-ready/
  577. Product Backlog Item (PBI): https://www.scruminc.com/product-backlog-item-pbi/
  578. http://www.infoq.com/minibooks/kanban-scrum-minibook
  579. Servant Leadership, by Robert K. Greenleaf (BOOK): https://www.goodreads.com/book/show/181737.Servant_Leadership
  580. The Power of Servant Leadership, by Robert K. Greenleaf (BOOK): https://www.goodreads.com/book/show/406321.The_Power_of_Servant_Leadership?from_search=true
  581. 5 Agile Metrics you won't hate: https://www.atlassian.com/agile/metrics
  582. How to do Scrum with JIRA: https://www.atlassian.com/agile/how-to-do-scrum-with-jira-software (Steps 1-11)
  583. Learn advanced scrum practices with JIRA Software: https://www.atlassian.com/agile/how-to-do-advanced-scrum-practices-with-jira-software (Steps 12-15)
  584. Agile by Design: https://www.atlassian.com/agile/design
  585. Creating a lean, mean product requirements machine: https://www.atlassian.com/agile/requirements
  586. Agile Roadmaps - build, share, use, evolve: https://www.atlassian.com/agile/roadmaps (going agile doesn't mean not knowing where you're going. It means being flexible about the path you take)
  587. The Product Backlog -- your ultimate to-do list: https://www.atlassian.com/agile/backlogs
  588. Escaping the black hole of technical debt: https://www.atlassian.com/agile/technical-debt
  589. How to build a kick-ass agile team: https://www.atlassian.com/agile/teams
  590. Customer Development Labs -- How to Interview your Customers: https://customerdevlabs.com/2013/11/05/how-i-interview-customers/
  591. Customer Development Labs -- The Customers you Should be Interviewing: https://customerdevlabs.com/2017/03/27/where-to-find-early-adopters/
  592. Customer Development Labs -- You’ve Interviewed Customers. Now what?: https://customerdevlabs.com/2013/09/10/customer-development-notes-finished-post-its/
  593. The FOCUS framework: https://thefocusframework.com/
  594. UserTesting -- Discovery Interviews: https://university.usertesting.com/discovery-interviews
  595. Discovery interviews -- a deeper kind of networking: https://www.nonprofithearts.net/rich/discovery-interviews.html
  596. 10 Tips To Conduct Customer Discovery Interviews and Questions: https://studiozao.com/10-tips-to-conduct-customer-discovery-interviews-questions/
  597. 3 Goals for Blueprinting Discovery Interviews: https://theaiminstitute.com/customer-insights-voc/discovery-interviews/
  598. What Customer Discovery Questions To Ask To Validate Pain Points: https://studiozao.com/what-customer-discovery-questions-to-ask-to-validate-pain-points/
  599. Never Ask What They Want  —  3 Better Questions to Ask in User Interviews: https://medium.com/user-research/never-ask-what-they-want-3-better-questions-to-ask-in-user-interviews-aeddd2a2101e
  600. A 5-Step Process For Conducting User Research: https://www.smashingmagazine.com/2013/09/5-step-process-conducting-user-research/
  601. Get better data from user studies - 16 interviewing tips: https://library.gv.com/get-better-data-from-user-studies-16-interviewing-tips-328d305c3e37
  602. How to Test Prototypes with Customers -- The Five-Act Interview: https://library.gv.com/how-to-test-prototypes-with-customers-the-five-act-interview-80305d98c407
  603. AgileAlliance -- glossary of terms - Personas: https://www.agilealliance.org/glossary/personas/
  604. Yes, Personas Focus on Demographics (And How to Fix That): https://jtbd.info/yes-personas-focus-on-demographics-and-how-to-fix-that-f27c02498e9d
  605. Story-centered design -- hacking your brain to think like a user: https://library.gv.com/story-centered-design-hacking-your-brain-to-think-like-a-user-1a1e7d7eb642
  606. Atlassian - User Stories with Examples and Template: https://www.atlassian.com/agile/project-management/user-stories
  607. Atlassian - Persona template: https://www.atlassian.com/software/confluence/templates/persona
  608. 10 Tips for Creating Agile Personas: https://www.romanpichler.com/blog/10-tips-agile-personas/
  609. "Choose your Wow!" codifying your User Archetypes as Personas: http://www.agilemodeling.com/artifacts/personas.htm
  610. Customer Personas: How to Write Them and Why You Need Them In Agile Software Development: https://blog.easyagile.com/customer-personas-how-to-write-them-and-why-you-need-them-in-agile-software-development-3873f3525975
  611. Scaled Agile -- Design Thinking: https://www.scaledagileframework.com/design-thinking/ (overview of Personas, Empathy Maps, Customer Journey Maps, and how they tie into User Stories and the design/dev cycle)
  612. 4 Characteristics Of A Personable And Useful Customer/User Persona: https://agilevelocity.com/4-characteristics-personable-useful-customeruser-persona/
  613. What is an Information Radiator?: https://www.atlassian.com/wallboards/information-radiators
  614. Do you have the Ultimate Wallboard? (CONTEST): http://blogs.atlassian.com/2010/10/the_ultimate_wallboard/
  615. Agile Software Development -- Forming Teams that Communicate and Cooperate: http://www.informit.com/articles/article.aspx?p=24486
  616. Agile Alliance -- GLOSSARY - Information Radiator: http://www.agilealliance.org/glossary/information-radiators/
  617. Information radiator: http://alistair.cockburn.us/Information+radiator
  618. Agile Technique Guideline - Information Radiators: http://www.projectconnections.com/templates/detail/agile-information-radiator.html
  619. Minimum Viable Product (MVP) overview: http://practicetrumpstheory.com/minimum-viable-product/
  620. 15 ways to test your Minimum Viable Product (MVP): http://thenextweb.com/dd/2014/11/12/15-ways-test-minimum-viable-product/
  621. Choosing the MVP: http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html
  622. Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable: http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
  623. Estimation? It’s Complicated...: http://blog.lunarlogic.io/2015/project-management-estimation/
  624. PERT Chart example: http://web2.concordia.ca/Quality/tools/20pertchart.pdf
  625. PERT overview: http://www.netmba.com/operations/project/pert/
  626. PERT for Project Planning and Scheduling: http://www.sce.carleton.ca/faculty/chinneck/po/Chapter11.pdf
  627. Critical Path Analysis and PERT Charts - Planning and Scheduling More Complex Projects: http://www.mindtools.com/critpath.html
  628. Tools for Systems Thinkers -- The 6 Fundamental Concepts of Systems Thinking: https://medium.com/disruptive-design/tools-for-systems-thinkers-the-6-fundamental-concepts-of-systems-thinking-379cdac3dc6a
  629. Reigniting Creativity in Business: https://www.ted.com/talks/alan_iny_reigniting_creativity_in_business
  630. FeatureToggle: https://martinfowler.com/bliki/FeatureToggle.html
  631. Feature Toggles (aka Feature Flags): https://martinfowler.com/articles/feature-toggles.html
  632. Use Canary Deployments to Test in Production: https://www.infoq.com/news/2013/03/canary-release-improve-quality
  633. Canary release strategy vs. Blue/Green: https://stackoverflow.com/questions/23746038/canary-release-strategy-vs-blue-green
  634. Deployment Strategies Defined: http://blog.itaysk.com/2017/11/20/deployment-strategies-defined
  635. Using Blue-Green Deployment to Reduce Downtime and Risk: https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html
  636. The DOs and DON'Ts of Blue/Green Deployment: https://minops.com/blog/2015/02/the-dos-and-donts-of-bluegreen-deployment/
  637. Blue-green Deployments, A/B Testing, and Canary Releases compared: http://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/
  638. On the importance of a Team Manifesto: https://blog.scottlogic.com/2021/01/26/on-the-importance-of-a-team-manifesto.html ("ways of working", "team etiquette", etc)
  639. The "Command and Control" Military Gets Agile : https://www.infoq.com/news/2010/06/c2-military-gets-agile/
  640. Agile Metrics -- Progress Monitoring of Agile Contractors - by Will Hayes, Suzanne Miller, Mary Ann Lapham, Eileen Wrubel, Timothy A. Chick (WHITEPAPER): https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=77747
  641. The Defense Innovation Board wants to help the military recognize ‘agile BS’: https://www.fedscoop.com/defense-innovation-board-wants-help-military-recognize-agile-bs/
  642. The U.S. Department of Defense on How to Detect ‘Agile BS’: https://thenewstack.io/the-u-s-department-of-defense-on-how-to-detect-agile-bs/
  643. The Importance of Product Management in Government: https://medium.com/the-u-s-digital-service/the-importance-of-product-management-in-government-b59933d01874
  644. Risk Management – How to Stop Risks from Screwing Up Your Projects (with ROAM)!: https://www.101ways.com/risk-management-how-to-stop-risks-from-screwing-up-your-projects/ | ARCHIVE (ROAM = Reduce, Owned, Accepted, Mitigated)
  645. wikipedia: Risk management
  646. ISACA Journal Volume 2, 2016 -- Risk Management in Agile Projects : https://www.isaca.org/Journal/archives/2016/volume-2/Pages/risk-management-in-agile-projects.aspx
  647. Agile Risk Management: http://itsadeliverything.com/agile-risk-management
  648. Working Product and the DOD: https://www.leanagiletraining.com/better-agile/working-product-dod/
  649. Why isn't Agile working - the best comment from the Reddit discussion: https://www.reddit.com/r/programming/comments/75p00n/why_isnt_agile_working_good_one_about_devops/do81l2n/
  650. Robert C. Martin - The Land that Scrum Forgot: https://www.youtube.com/watch?v=hG4LH6P8Syk
  651. wikipedia: Technology roadmap
  652. How to Prioritize Product Features and Improvements: https://medium.com/@freshtilledsoil/how-to-prioritize-product-features-and-improvements-8aea72c8bf27
  653. Agile roadmaps -- build, share, use, evolve : https://www.atlassian.com/agile/product-management/roadmaps
  654. Aha! vs JIRA Portfolio: https://www.reddit.com/r/agile/comments/4q9fl0/aha_vs_jira_portfolio/
  655. Agile roadmap planning done right with Jira Software and Portfolio for Jira: https://www.atlassian.com/blog/jira-software/agile-roadmap-planning-done-right-with-jira-software-and-portfolio-for-jira
  656. Creating and Managing a Product Roadmap in JIRA: https://community.atlassian.com/t5/Jira-Software-questions/Creating-and-Managing-a-Product-Roadmap-in-Jira/qaq-p/598301
  657. 2015 Chaos Report - (overview) Q&A with Jennifer Lynch: https://www.infoq.com/articles/standish-chaos-2015

See Also

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