Reading List: Agile (Kanban, Time mgmt., Change mgmt., etc.), Product Mgmt.

Agile Definitions and Comparisons
Kanban / Scrum-ban
Kaizen
Scrum
Pairing and Mobbing
Agile meeting approaches (planning, retro., etc.)
Agile teams
Agile documentation
Platform teams
Scaling Agile
Estimating / Decomposition
Agile Metrics
Product Mgmt.
Product Metrics
Technical Project Mgmt. / Tech Lead. / DRI
MVP, MMF, MMP, MMR etc.
Tech Debt
Agile Planning
Feature / Bug Triage
Jira-specific
Personal Time Management / Effectiveness
Change Management
Waterfall, Earned Value etc.
Sociocracy, Holacracy
General process themes

Lists

Agile Definitions and Comparisons

  • Shore / Larsen: The Agile Fluency Model – Achieving; Losing; Organizational; Learning Zones: “Focusing”, Delivering”, “Optimizing”, “Strengthening”
  • Excella: Word on the street: What is agile? (5m vid) – humorous take – featuring Phil Rogers
  • Tom Mellor: Real Agility…Not Fake Agile – “You keep using that word. I do not think it means what you think it means”; “… agility has moved beyond software development (or even product development) to describe an organization…”;  13 characteristics of organizations that are probably not very agile, 13 opposing characteristics that can indicate agility in organizations
  • Peter Merel: Disrupting the Agile Industrial Complex Part One: Through The Sunglasses – series of blog posts defining “top 10 agile anti-patterns”, critique of the Agile Industrial Complex (AIC): 1) Big transformation up front; 2) Certified Vanity Planes; 3) The Frozen Middle; 4: The Agile Greasy Pole; 5) Voodoo Accounting; 6) Product Muggins; 7) Scrum Nannies; 8) Change-cost catastrophe; 9) Mindset Mindtricks; 10) The Agile Roman Empire
  • Joshua Keviersky: An Introduction to Modern Agile – “Modern Agile is ultra-light, the opposite of mainstream Agile, which is drowning in a bloated tangle of enterprise tools, scaling frameworks and questionable certificates that yield more bureaucracy than results”;  “Modern Agile has no roles, responsibilities or anointed practices. Instead, it is defined by four guiding principles” (including “Make Safety a Prerequisite”); “the Agile Industrial Complex (including tool vendors, sales and marketing people, consultants, certification groups, certified trainers, etc.) is challenged by changes to Agile, since those changes require updating learning objectives, training materials, exams, tools, web sites and more. While we can understand their focus on monetization, we don’t have to let it stand in the way of modernization”; modern agile principles, agile manifesto values
  • Joshua Keviersky: Modern Agile blog post – reinventing agile; what’s in modern agile; embrace change; comments section very good
  • Joshua Keviersky: Modern agile webinar (2015) (58min vid)
  • Anthony Mersino: How Leaders Can Use Agile to Solve Common Organizational Challenges – good non-method-specific summary of key techniques, with emphasis on kanban-like techniques; match demand to capacity; start fewer things and finish more things; deliver the highest value features first; let teams pull work rather than pre-assigning; build long-term stable teams with great people; stop focusing on individual utilization; direct work to teams and not individuals; stop pulling team members away to fight fires; focus on fire prevention; don’t continually change priorities; build long-term stable teams; align incentives to both individual skill growth and team work; don’t reward individual hero behavior
  • Thoughtworks: Road-mapping your way to Agile Fluency – more of a pattern compared to the prescriptive CMMI; case study
  • Simon Powers: What is the agile mindset? – Powers’ definition of the agile mindset; Cynefin; The complexity belief; the people belief; the proactive belief; “If the problem sits in the Complicated domain, this means it will require the help of specialists (domain experts) to derive a solution rather than a lay person. The solution can be known in advance through planning and analysis, and the result can be predicted with reasonable accuracy at the outset”; “If a problem sits in the Complex domain, the solution can not be predicted in advance because the act of solving the problem changes the problem itself. Often volatility, uncertainty, ambiguity, and an increasing rate of change, play a critical part in defining the challenge of solving problems in the Complex domain…An example of a problem in the Complex domain is innovative product design…Building software products is another example”; “Agile is for solving problems in the Complex domain”; “agile teams are optimised around cross-functional teams comprising of ‘business people’ as well as different technology specialisms, so that all the skills that are needed are easy accessible. This is an optimisation to reduce the time it takes to deliver and get feedback. A critical component of success when solving complex adaptive problems”; “the management style for bringing the optimal outcome in a complex adaptive environment is for managers to stand outside of the system, manage context, and let the people self-organise…it is best not to have a solid blueprint of centralised control that defines culture and behaviours, but to let leaders and managers stand outside of the process and identify the minimum constraints and create the context to produce self-organisation”; “the optimal way to motivate people is through purpose… vision without purpose is just a good idea”; “If we are to succeed in solving large complex problems we need to create teams that self-organising, motivated, and empowered to make local decisions”; “The 3 pillars of Scrum are Transparency, Inspection, Adaption, that like the Demming cycle are implementations of the relentless pursuit of improvement”
  • Jim Highsmith: The Future of Agile: Innovators, Imitators, and Idiots – the three Is: Innovators, imitators, idiots; “…large organization that had a corporate-wide phase-gate process for project governance. They were able to work out an agile version for software development that still fit within the overall governance process”; “dual importance of both doing agile (practices) and being agile (values)”; “without the shift in thinking [about values], methodology becomes technique and practice becomes imitation”
  • beyondagile.com: We just can’t afford Taylorism anymore. Now what? – how software is different; taylorism history; waterfall; command and control

Kanban / Scrum-ban

Kaizen

Scrum

  • Mia Kolmodin: Poster on Agile in a Nutshell – with a spice of Lean UX  – infographic comparing waterfall and agile in a number of ways including: risk – time – cost graphs; ways of working; modern agile; “to be agile” mindset -> tools / processes spectrum; Cynefin decision-making model (unordered (complex / chaotic)-> ordered  (complicated / obvious) domains); scrum overview
  • Robert Galen: Why the Scrum Product Owner is a Project Manager – 4 quadrants of product ownership, risk mgmt., proj comm.
  • Philip Rogers: Being a Scrum Master is all about facilitation, so let’s call it what it is – “it can be “Team Facilitator” (TF), or something similar”; “Calling a person a “master” of anything can suggest that a Command and Control mindset is at work”; “in many instances, Scrum Masters (and others) take it to mean that process compliance is one of the most important things, if not the most important thing, that informs how they spend their time. Nope”
  • Yuval Yeret: The Scrum Sprint Forecast as an Expectation – “a team that meets its forecast each and every time might be a predictable team but not necessarily a hyper-productive team and for sure not a learning team. For learning, you need to hypothesize that you can stretch yourself a little beyond your current capabilities supported by an experiment for how to achieve that stretch”; “similar to how Limiting WIP drives improvement in Kanban. It re-emphasizes how working in a pull system driven by commitment to either WIP Limits or Sprint Forecast are very similar concepts of constraints and expectations – explicit process policies that drive learning”
  • Ron Jeffries: Developers should abandon Agile – big business; good for the enterprise; not so good for developers; maybe XP!
  • Daniel Jones: Scrum makes you dumb – “Continuously delivering the most important thing in the simplest way is a much better solution”; “sprints are the problem”; “Enterprises with functionally-aligned silos are optimising for the wrong kind of cost saving”; “An insidiously pervasive reason for the prevalence of deadline-driven practices is an absence of trust and motivation”; longer-link at bottom (and video): “silos breed apathy”; cross-functional product teams; “silos create high transaction costs”; “continuous delivery can help us reduce technical debt”; “Waterfall and Scrum are Harmful”; “Scrum is a methodology for low-trust environments“; “Continuously delivering the most important thing in the simplest way allows us to escape the tyranny of deadlines, and the technical debt that scarcity of time causes”; “Many teams I visited had no empowered Product Owner. Often, a “Shadow Product Owner” pulled the strings in the background”
  • John Cutler: Stop Obsessing Over “The Teams” – “… we shouldn’t focus on “The Teams”, until the conditions for effective teams are in place”
  • John Cutler: The Trouble with Scrum – descent from mount scrum; technical practices matter; legally scrum; works great (not scrum); aggressive scrum / true scrum
  • John Cutler: Scrum is the Best Thing in the Whole Wide World – thoughts on how it is oversold, overhyped and misused
  • Robert Martin: The Land that Scrum Forgot (45min vid) – scrum forgot TDD, CI, simple design, refactoring, pair programming
  • Ron Jeffries: Dark Scrum (blog filter) – including Dark Scrum; Implications of Enterprise Focus in Scrum
  • Bertil Muth: Why Agile sucks at your company — and what you can do about it – “In Scrum, you don’t fix the scope before development starts. You can’t have both: perfect predictability, and unlimited responsiveness to change”; “job of the Product Owner to always request the most valuable feature next. A Product Owner does not need to reach consensus with the stakeholders. He needs to say no to feature requests that provide little value for the customer and the company”; “company must empower the Product Owner. He must have the authority to decide what is part of the product, and what not”

Pairing and Mobbing

Agile meeting approaches (planning, retro., etc.)

Agile teams

  • kislay: Independence, autonomy, and too many small teams – collaboration is not good; independence is not autonomy; autonomy is a customer-facing construct
  • unremarkabletester.com: Balancing between stream-aligned and enabling-teams – references Team Topologies; “Having the experience of working in a Stream-aligned team makes you better at helping out others when you join an Enabling team. And having been part of an Enabling team you have a broader knowledge to help out your Stream-aligned team. Given the chance, shifting between the two every so often can be a really beneficial thing for you, the people you work with and your business. “
  • What Google Learned From Its Quest to Build the Perfect Team – “… on the good teams, members spoke in roughly the same proportion, a phenomenon the researchers referred to as ‘‘equality in distribution of conversational turn-taking.’’ On some teams, everyone spoke during each task; on others, leadership shifted among teammates from assignment to assignment”; “… good teams all had high ‘‘average social sensitivity’’ — a fancy way of saying they were skilled at intuiting how others felt based on their tone of voice, their expressions and other nonverbal cues”; “Within psychology, researchers sometimes colloquially refer to traits like ‘‘conversational turn-taking’’ and ‘‘average social sensitivity’’ as aspects of what’s known as psychological safety”; “In the best teams, members listen to one another and show sensitivity to feelings and needs”
  • Joshua Kerievsky: Size Teams for Few To No Handoffs – “The more handoffs between teams, the more time it takes to complete and deliver valuable work. Ideal teams have few to no handoffs”; “… situation gets even worse when an organization adopts SAFe and one team in one release train must handoff work to other teams in other release trains”
  • Doc Norton: Tuckman was Wrong – “Tuckman’s Theory of Group Development was first published by Bruce Tuckman in 1965. In Tuckman’s original explanation, groups and teams go through four stages as they become a cohesive, high-performing unit; Forming, Storming, Norming, and Performing”; “…Storming, they concluded, is not a stage at all, but a consistent occurrence”; “Stable teams creates a constraint that limits the bad behavior of over allocation and multiple assignments. If we don’t have this bad behavior, we don’t need the constraint of stable teams”; ”

    These days, more and more organizations are moving away from the model of stable teams. They’re mature enough to know better than to manage from the top in a complex environment. They don’t utilize people’s time at 100% and they manage their work in progress at all levels; enterprise, division, department, product, and team. These companies are discovering that allowing people the autonomy to move from assignment to assignment and from team to team, is not only increasing productivity, it is accelerating learning, and improving retention”

  • Simon Knight: Testers Diary – Moving From Silo to Team Room – describes “throw it over the wall” mode and the long release cycles that result; importance of a strong culture of communication with the dev team; participation in reviews for each new story; “ask questions during the final review of a user story that reveal some acceptance criteria that hadn’t been recorded”
  • Jo Freeman: The Tyranny of Structurelessness – structurelessness tends to create its own informal power structure and elites; “… some principles we can keep in mind that are essential to democratic structuring and are also politically effective: “; “1) Delegation of authority to specific individuals for specific tasks by democratic procedures”; “2) Requiring all those to whom authority has been delegated to be responsible to those who selected them”; “3) Distribution of authority among as many people as is reasonably possible”; “4) Rotation of tasks among individuals”; “5) Allocation of tasks along rational criteria”; “6) Diffusion of information to everyone as frequently as possible”; “7) Equal access to resources needed by the group”

Agile documentation

  • Diátaxis – “…aims to solve the problem of structure in technical documentation… identifies four modes of documentation – tutorials, how-to guides, technical reference and explanation”; tutorials: learning-oriented (getting-started/intro); how-to guides: problem-oriented (specific scenarios); reference: information-oriented; explanation: understanding-oriented (can include discussions); the first two are practical steps; the last two are theoretical knowledge; tutorials and explanation serve our study; how-to guides and reference serve our work

Platform Teams

  • martinFowler.com: Mind the platform execution gap – “A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product.”; Internal DevEx; “Communicating your roadmap, accepting feedback and harvesting experiences from your users will contribute to your platform’s ongoing relevance.”; “Product developers have experienced the offerings of commercial cloud providers and to live up to those raised expectations platform engineering teams must be mature in both product management and technical implementation. “
  • Product for Internal Platforms – “…where I work it means the software side of infrastructure. Compute platforms like kubernetes, storage systems, software development tools, and frameworks for services are part of the mandate”; “The migration strategy must be a primary part of the product planning.”; “Without a clear strategy for showing impact and value, you end up overlooked and understaffed, and no amount of cool new technology will solve that problem.”Q&A with Galo Navarro on Building an Effective Platform Team -Interview-style article on same topic, also with Galo: Talk write-up: “How to build a PaaS for 1500 engineers”; “…an effective platform team needs to find the balance between setting organizational standards and permitting product team autonomy”; “A good deal of the job is ultimately about finding the right balances between standardization and autonomy. To make meaningful impact, Platform teams depend on having standards in their organization. Trying to too support every possible language ecosystem, framework, DB, messaging system, and whatnot spreads Platforms teams too thin to be effective.”; “On the other hand, it is also wise to respect every other team’s autonomy to make their own technical decisions. Opinionated Platform teams risk coming across as a patronizing, ivory-tower-dwelling jerks that impose capricious choices on other engineering teams. Standardization and autonomy are complex factors to juggle.”; “Standards should focus on “effectively encode and disseminate existing organizational knowledge”“; “…I stress “existing” because I think you don’t want to introduce innovations through standards, but rather consolidate choices that have been tested and hardened by experience, and are trusted to be applied across the organization. These are best practises, successful patterns, scar tissue, etc.”; “Providing the product team with a clear mandate and goals helps them “introduce tools that generate small impacts to a wide surface”; “…We’re seldom told “build this tool”, but rather “power-up product teams”, and it’s expected that we’ll walk up and down the organization to understand what challenges product teams have and which are worth solving”
  • Providing pierceable abstractions. -“Fail open and layer policy is a design principle for infrastructure, which emphasizes building flexible systems with a decoupled policy enforcement layer constraining usage. For example, building a Dockerfile based deployment system which can accept any Dockerfile, and then adding a validation step which only allows a certain set of base images.”; “failing open means to default to allowing any behavior, even if you find it undesirable. This might be allowing a user to use unsupported programming languages, store too much data, or perform unindexed queries. Then layering policies on top means adding filters which enforce designed behavior. Following the above example, that would be rejecting programming languages or libraries you find undesirable, users storing too much data, or queries without proper indexes.”; “The key insight for me is that a sufficiently generic implementation can last forever, but intentional restrictions tend to evolve rapidly over time; if infrastructure maintainers want to avoid rewriting their systems every year or two, then we need to be able to tweak policies to enforce restrictions while independently maintaining and improving the underlying capabilities. (I sometimes also describe this concept as “self-service with guard-rails”, for cases when these layers are more about providing informational norms than about enforcing restrictions.)”; “…when you do get the chance, build layers which compose together into a complete solution, rather than trying to have any given layer do everything for everyone.”

Scaling Agile

  • Dan North: In Praise of SWARMing – SWARMing: Scaling Without A Religious Methodology – Cost efficiency: utilisation vs flow; Managing work: project vs product management; Portfolio planning and governance: up-front vs ongoing; The appeal of frameworks; Scaling Without A Religious Methodology; slide deck from prezo with Katherine Kirk; video from prezo with Katherine Kirk
  • Jennifer Riggins: Scaling Agile: When to Build a Scrum of Scrums – “The larger the organization, typically the older it is and the more bureaucracy it has, so the proposed solution is often to add more teams and more bureaucracy rather than cutting back as they should have done. “Having documentation 20 pages long and nobody reads them—it doesn’t make any sense…””; “… a major Czech bank automatically choose the SAFe framework simply because it is the most popular, a mistake witnessed by all the participants at one point or another”; “…sometimes the most popular method doesn’t work for everyone. Indeed, often, when companies are looking to fix a problem, they often look for the most complicated solution, when simplification is often the way”; “complications arise when managers and coaches don’t have an understanding where the teams you are trying to scale intersect with the rest of the organization. He says you need to “basically have conversations: How does that intersection happen and what do we need to do?””;”Addressing teams from the bottom up and then facilitating the conversation between those teams makes all the difference”; “take agile, scrum and frameworks in general out of first discussions, instead more broadly asking: Where does your work come from? Who gets it when you’re done with it? What restrictions do you have?”; “…focus has to be on figuring out how to simplify things so teams can coordinate their own work, and to look for how to standardize processes to increase stability in teams. It’s all about simplifying things so teams can coordinate their work”; “the moment to scale is when you find that a product is growing at a rate that one team can’t handle all of the features”; “enforcing a framework that no one wants will simply never take hold, so you need to constantly be asking team members what they want”; comparison to LeSS; “… address the problem that, by maintaining the same people and trying to fit these pegs into different shaped holes, you perpetuate the same problems you started with, which implies you have to get rid of or demote a large number of people”; “He looks at the SAFe framework as “like a paint job,” where the organization continues in the same way but with new titles. He says it can be OK as a starting point but only when it’s then followed by the Large Scale Scrum Framework with a focus on continuous improvement, which, of course, brings difficult conversations with it. But, he says that if you are not changing anything for years, by definition, you’re not agile”; ““My experience with SAFe is that it just allows that managerial override of the agile process, and I saw that really get in the way of any kind of productivity.” He actually witnessed product teams maintaining secret backlogs to work around the SAFe framework”; “… control is why traditional management tends to like SAFe and its traditional structure and presentation. “You don’t see that in the LESS framework because LESS is about descaling the organization, making it simpler. [But] safe is about keeping the hierarchy and somehow making it work.”; “… sometimes organizations give the framework more importance than the problem at hand, which just, in turn, complicates it all again”; “you can’t over-standardize to a point that teams lose their sense of fun and identity, particularly in areas that are already working”
  • Stefan Wolpers: Agile Failure Patterns in Organizations – “… Agile is not the quick fix for everything that’s going wrong. Each organization has it own set of dysfunctions and hence solutions dealing with them need to be tailored specifically to that organization”; “There is no culture of failure: Teams therefore do not move out of their comfort zones, but instead play safe”; “The organization is not optimized for a rapid build-test-learn culture and thus departments are moving at different speed levels. The resulting friction caused is likely to equalize previous Agile gains”; “Product management is not perceived as the “problem solver and domain expert” within the organization, but as the guys who turn requirements into deliverables, aka “Jira monkeys””; “Other departments fail to involve product management from the start. A typical behavior in larger organizations is a kind of silo thinking, featured by local optimization efforts without regard to the overall company strategy”; “Teams are not self-organizing. That would require to accept responsibility for the team’s performance and a sense of urgency for delivery and value creation”; “Faux Agile: Teams follow the “Agile rules” mechanically without understanding why those are defined in the first place. This level of adoption often results often in a phenomenon called “Peak Scrum”: There is no improvement over the previous process, despite all Agile rules are being followed to the letter. Or even worse: morale and productivity go down, as the enthusiasm after the initial agile trainings wears off quickly in the trenches.”
  • The Big Picture of Agile: How to Pitch the Agile Mindset to Stakeholders
  • Steve Denning: What Is Agile? The Four Essential Elements – delighting customers; descaling work; enterprise-wide Agility; nurturing culture; Copernican Revolution in management (user/customer-centered rather than company-centered); “achieving continuous innovation is dependent on an entrepreneurial mindset pervading the organization. Where the management tools and processes of Agile, Lean or Kanban are implemented without the requisite mindset, few, if any, benefits were observed”; “It is an interesting feature of firms that are on successful Agile journeys that there is little sustained reliance on external consultants or scaling frameworks. Their journeys tend to be characterized by organic growth nurtured by a shared Agile mindset of those leading the organization at every level”; “These leaders recognize why scaling frameworks, such as SAFe, LESS and DAD, have proliferated… it’s also easy to see why these leaders have reservations about implementing predetermined frameworks. First, the prescriptions of a predetermined framework (regardless of its content) smacks of top-down command and control—namely, the very thing that Agile management is trying to get away from”; “most of these frameworks focus on specifying the internal functioning of the organization, whereas the spirit of Agile as perceived by the SDLC members is externally focused on delivering more value to customers. The more a firm is preoccupied by the internal machinations among its silos and its levels, the more it is distracted from achieving its true goal: delighting the customer”; “It is not surprising to find that most scaling frameworks assign a derisively tiny role to the customer, for example, as shown in the most popular of the frameworks, the SAFe framework. Such charts are a vivid illustration of pre-Copernican management thinking in action”
  • LeSS: Large-Scale Scrum – infographic; case studies; resources
  • Eylean: SoS vs LeSS vs SAFe – Which One Is Right For You? – “Both SoS and LeSS rely solely on Scrum, applying its practices and roles at a larger scale. This makes these approaches ideal for teams that are already using Scrum and want to scale up without having to go through a large reorganization for it”; “SAFe on the other hand, does not focus on a single approach and instead is based on Agile as a whole. It Adapts Agile values from the small team environment into a large organization and allows each team to choose which method they want to use, be it Scrum, Kanban, Scrumban or other. Due to this, the framework requires much more effort in the implementation, but is a great option for teams that do not want to be tied down to Scrum and have an ability to choose”; “if you require a full set of rules for the company structure all the way up to the executive floor SAFe is the way to go. It provides detailed definitions for all company levels and thus creates an environment where Agile can be adopted through and through. However, with all of the rules and definitions one has to be prepared to have a longer adjustment period than with the other two”; “For the low cost implementation, teams should be looking at SoS and LeSS. As they are a natural progression of using Scrum, the teams already have the know-how and are simply adding a few more layers and practices to their daily routines. There is little to no training and restructuring, which means that the implementation costs will be slim”; “When talking about SAFe on the other hand, no matter what Agile practice has been used beforehand, there will be a need to restructure and rethink the organization. This means that the transition will be more costly and most likely will take more time as well”

Estimating /Decomposition

  • Nave: Effective Forecasting: Estimation in Kanban – “Some teams prefer not to estimate at all – time spent making estimates is time that could have been spent creating more value. Others prefer to set direction using Kanban roadmaps, while leaving the details to be worked out day-by-day”; “The Kanban method suggests data-driven, probability-based future predictions using only historical performance records”; “In Kanban, Monte Carlo simulation uses past throughput data to estimate future throughput”; “In any process with multiple variables, relying on “single point” estimates for likely delivery times is simply inaccurate. Kanban estimates give both timeframes and probabilities, keeping customers informed of the range of different possible outcomes. Using these data-driven probabilistic methods keeps estimates reliable and eliminates guesswork.”
  • Debbie Madden: Your Agile Project Needs a Budget, Not an Estimate – 4 steps: 1) Identify decisions; 2) Match precision to decision; 3) Budget; 4) Ranges and Confidence levels
  • Phillip Armour: Estimation is not Evil – requirements vs. estimation; workflow vs. resourcing; estimation vs. commitment; return and cost plus risk
  • Philip Armour: Counting Boulders and Measuring Mountains – weaknesses of WBS; boulder-counting estimates take a long time to produce; “The defining characteristic of modern software development is uncertainty. This uncertainty is not simply present in the measurement activity—it is present in the development activity. When we begin a software project we don’t know in detail what it is we need to do. Our primary job as software developers is to figure this out. Once that activity is out of the way, building the system is usually pretty straightforward. Since it is inherent in the job, any legitimate estimation process must embrace and model this uncertainty, otherwise it is behaving dishonestly”
  • Kerievsky: Stop Using Story Points – “Technical practices like test-driven development and refactoring are often the first things to be dropped when someone is trying to “make their estimate.””; “one of our customers found story points to be so confusing that he renamed them NUTs (Nebulous Units of Time).”; “We have been counting items done. Each week we just choose the most important items and sign up for them up to the number from last week. It turns out that we get about the same number of them done regardless of estimated effort. “; “We tracked real-time hours instead of story points, but we were essentially doing the same thing with hours as we had done with story points…”; “No longer happy to work in fixed-length timeboxes, we would simply pick a small amount of important work to do, complete that work, ship it and repeat.”; “If we had a deadline, we would make it by either getting everything done or finding work that could be safely deferred until a later release”; “You could spend days or weeks attempting to get more accurate estimates, yet I find it is better to just make rough estimates for each user story based on 10-15 minutes of analysis and discussion per story. To get more accurate estimates, I coach teams to periodically (say, every 2 weeks) re-estimate the user stories on their release plans.”; “I coach teams to write user stories for their releases and estimate them using “team weeks”: the amount of time it will take the whole team to complete the work.”; “To better manage risk, it’s useful to combine evolutionary design with release planning. Your first embryonic version of the product/system should include high value features and address your highest risks. That release (which could take 1-3 months to produce) may be an internal milestone rather than something released to customers. The next release will add further sophistication to the emerging software by adding functionality to existing features or producing new features. And so it continues until you are ready to release to your customers.”
  • Matt Heusser: Story points and beyond: How to improve software estimates – making story points work, eliminating story points via story-splitting
  • Lasse Koskela: Ways to Split User Stories (with comments at end) – by implementation (last resort!); by quality; by data/details; by operations (CRUD); by major effort; by role
  • Christiaan Verwijs: 10 useful strategies for breaking down large User Stories (and a cheatsheet) – downloadable cheatsheet; 1: Breaking down by workflow steps; 2. Breaking down by business rules; 3. Breaking down by happy / unhappy flow; 4. Breaking down by input options / platform; 5. Breaking down by data types or parameters; 6. Breaking down by operations; 7. Breaking down by test scenarios / test case; 8. Breaking down by roles; 9. Breaking down by ‘optimize now’ vs ‘optimize later’; 10. Breaking down by browser-compatibility
  • Adobe: Splitting stories into small, vertical slices – horizontal vs. vertical slices; four techniques for vertical slicing: vague terms, conjunctions, acceptance criteria, workflow steps; advantages of vertical slices
  • Thoughtworks: Slicing your development work as a multi-layer cake – the downside of horizontal slicing; system complexity versus long stories; how to slice the cake
  • Fowler: The Purpose of Estimation
  • Shore: Estimation and Fluency
  • Fowler: Story Counting
  • Thoughtworks: How estimating with “story counts” worked for us
  • Killick: The #NoEstimates debate
  • Johanna Rothman: The Case for #NoEstimates – “It’s not really about no estimates. It’s about working in a sufficiently agile way that you don’t need estimates”; deliver small, valuable chunks of work every day, or more often
  • Johanna Rothman: The Case For and Against Estimates (5-parts) –  Part 1 agile roadmaps and gross estimation and/or targets for projects and programs. Part 2, when estimates might not be useful. Part 3 how estimates can be useful. Part 4, #noestimates
  • Premios: What is #NoEstimates – “People like Vasco Duarte champion the second camp who practice #NoEstimates from a lean or Kanban perspective. We recently heard David Anderson, the Kanban visionary, discuss a similar #NoEstimates position using throughput as a forecasting tool”; “There are many levels of estimation including budgeting, high-level estimation and task planning (detailed estimation)”; “#NoEstimate proponents leveraging Kanban techniques perform this level of estimates as forecasts using average flow rates and queuing theory (an application of Little’s Law).”; “Johanna Rothman stated in her article “The Case for #NoEstimates,” that “when you deliver small, valuable chunks of work every day or more often” that you can avoid estimation”
  • Tom Sylvester: How I use Earned Value Mgmt (EVM) to Track Agile Scrum Projects
  • Tamara Sulaiman: AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle
  • David Bulkin: Can Earned Value Leverage Agile Methods? – pros and cons, including link to Scott Ambler con article
  • Richard Lawrence: Patterns for Splitting User Stories
  • Cohn: User Stories, Epics and Themes
  • Anderson: Project Management with Kanban (Part 3) – Forecasting – “how do you plan a project with a method that doesn’t use estimates? The answer is that you use historical data or a model of expected capability to build a probabilistic forecast of the project outcome”; lead-time distribution, Little’s law equation from queuing theory determine probabilistic distribution
  • Anderson: Kanban & #NoEstimates: How to use Kanban for Probabilistic Forecasting and Making Commitments (1hr video) – describes how probabilistic forecasting may be used to make commitments, vs. traditional estimating approaches
  • StoriesOnBoard: Useful resources for user story mapping – including articles, videos, Tools – one tool not listed is FeatureMap.co
  • Twitter: #NoEstimates
  • ResearchGate: Articles by Phillip Armour

Agile Metrics

  • Forsgren / Storey / Maddila / T.Zimmermann / Houck / Butler: The SPACE of Developer Productivity – Myth: Productivity is all about developer activity; Myth: Productivity is only about individual performance; Myth: One productivity metric can tell us everything; Myth: Productivity Measures ARE useful only for managers; Myth: Productivity is only about engineering systems and developer tools; Satisfaction and well-being; Performance “…performance is often best evaluated as outcomes instead of output.”; Activity; Communication and collaboration; Efficiency and flow; SPACE and SRE: The Framework in Incident Management; MYTH: Number of incidents resolved by an individual is all that matters; MYTH: Looking at one metric in isolation will tell you everything; MYTH: Only management cares about incident volume and meeting SLAs; MYTH: Effective IM is just about improving systems and tools
  • Avinash Kaushik: The Difference Between Web Reporting And Web Analysis – analysis includes interpreting the data, while reporting (aka data puke) does not
  • Jim Highsmith: The Problem with Velocity in Agile Software Development – “Having Velocity as a goal introduces trade-offs”; “When the only thing you are really measuring is your Speed, you will attempt anything to “make progress” as fast as possible. Anything that causes you to move slower may be considered a burden. Including improving your code. Including Refactoring. Including avoiding Technical Debt”; “…if people are using velocity as a stick they don’t understand that it’s completely arbitrary and team-specific. You can make the numbers add up to anything you please if you really want”
  • Martin Fowler: An Appropriate Use of Metrics – “… We need a number to measure how we’re doing. Numbers focus people and help us measure success.” Whilst well intentioned, management by numbers unintuitively leads to problematic behavior…”; “Single loop learning is the repeated attempt at the same problem, with no variation of method and without ever questioning the goal.”; “…metrics consequently drive developers to focus on getting stories Development Complete”; “… WIP limits work to overcome the undesirable behaviors that emerge when people are measured by the wrong metric of their individual productivity instead of overall value delivered”; Explicitly link metrics to goals: “With an appropriate use of metrics, every single measure should clearly be linked to its original purpose…. Without its purpose, the effort expended means people find ways to creatively game their system, ultimately detracting from the real goal”; Favor tracking trends over absolute numbers: “Trends provide leading indicators into the performance that emerges from organizational complexity”; Use shorter tracking periods: “Reviewing progress after each week generates many more options than reviewing progress after a year, simply because there are more opportunities to react and change”; Change metrics when they stop driving change: “An appropriate use of metrics drives people to question the goal and, based on collecting real data, implementing change to get there”; “Double loop learning helps us understand focusing on the individual to behave differently cannot exist until the organization learns a more appropriate use for metrics”
  • Velocity and Better Metrics: Q&A with Doc Norton – Velocity forecasts are usually around 50% probable; Monte Carlo simulations are a far better means of forecasting; Avoid setting targets for measurements; Focus on trends, not single data points; Measure multiple aspects of the system; “Velocity is also a lagging indicator of a complex system. As is true with all lagging indicators, they are not very useful for predicting the future, but they are good for confirming trends and patterns”; “I’ve now surveyed over one thousand individuals at agile conferences. Approximately 90% of those surveyed have low confidence in their velocity, have a disconnect between velocity and deployment, or cannot reliably project a large chunk of work using velocity alone”; “when management puts a focus on speed or, worse yet, sets targets for speed, the resulting behavior from the actors is a natural consequence. It is not the team that games the system, it is the system designer that creates the game”; “We’re measuring to inform, not setting targets to drive. We’re looking at trends and contrasting them against our expectations based on our strategy. And we’re looking at multiple dimensions to help ensure we don’t over-optimize on a particular dimension”
  • Heusser: How the Kanban Method Changes Software Engineering – Focus on throughput and cycle time instead of estimating
  • Yuval Yeret: Explaining Cumulative Flow Diagrams
  • Joshua Arnold: Using Cost of Delay to Quantify Value and Urgency – including further resources, how to get started measuring it
  • Tom & Kai Gilb: When you can Measure what you are speaking about, and Express it in Numbers, you know something about it – ‘Quantification’ alone, has great merit, even if you never actually carry out any measurement! ; Numbers clarify what words hide and confuse; If measurement is early and frequent, then we can usually adjust our plans, to be in better contact with reality, and in contact with our own objectives and constraints; Planguage Example:  Two different Meter specifications for the same Scale. One for early project feedback. The other for project completion testing.
  • Tom Gilb: How to Quantify Quality: Finding Scales of Measure – learn the art of developing your own tailored scales of measure for the performance and resource attributes, which are important to your organization or system. You cannot rely on being ‘given the answer’ about how to quantify. You will lose control over your current vital system performance concerns if you cannot or do not quantify the critical attributes; use the cheapest simplest measuring process that will give you adequate feedback for purpose; It is more important to get some early and frequent feedback, week by week, on your critical objectives’ value delivery, than it is to have accuracy greater than ±20%

Product Mgmt.

MVP, MMF, MMP, MMR etc.

Product Metrics

  • mixpanel: A guide to product metrics – Focus, Level 1, Level 2 metrics; “It’s imperative to remember the goal of measurement isn’t just to track change over time; it is to effect change as well. To observe metrics over time requires rigor, discipline and focus. To improve them requires all that plus ingenuity. And that’s what building and managing products is all about”

Technical Project Mgmt. / Tech Lead / DRI

  • GitLab: Directly Responsible Individuals (DRI) – “up to that person to get it done or find the resources needed.”; “… DRI should consult and collaborate with all teams and stakeholders involved to ensure they have all relevant context, to gather input/feedback from others, and to divide action items and tasks amongst those involved.”; “… culture where DRIs are willing to put their ideas in the open. This enables feedback from a broad range of diverse perspectives, which the DRI can take into account and choose how (if at all) it shapes their thinking.”; “How do we get the best of consensus organizations? When we’re about to make a decision, we tell everyone. Everyone can give input.”; “How we keep the best of hierarchical organizations is by having a DRI — one person who will decide.”; “… you get to provide input, but you don’t have the right to feeling heard or being considered in the eventual decision.”; “… DRI should be wholly invested in their assignment and welcome collaboration in order to succeed. While they’re empowered to make all final decisions, they should know how and when to trust in the experience and judgment of their teams and peers.”; DRIs may be assigned at for a specific function within a project – e.g., a PdM / Prioritization DRI; Eng. Mgr. / Delivery DRI; DRIs may be at the project level; Project Management – 8 Characteristics of a DRI: “1. Detail-orientated without ever losing a strong strategic perspective; 2. Calm under the pressure of implementation and deadlines; 3. A strong listener with great skill at asking questions; 4. Able to vary the direction of project (or tactic or task) in smart ways to keep moving toward the objective; 5. Adept at anticipating potential problems and addressing them early;  6. Able to successfully interact at senior and junior levels within the organization; 7. Resilient in order to recover from setbacks; 8. Consistent in how they respond to comparable situations.”
  • Matthew Mamet: Directly Responsible Individuals – “… unlike functional leadership roles, Product leadership rarely comes with direct authority over personnel, plans, or teams.”; “When working on a new or particularly complex problem where the DRI is not yet known, we seek to establish the DRI early in the discussion.”; “The notion of the DRI is a fundamental component of the culture of modern product development teams. By seeking to create a culture of accountability with the group, we avoid dependencies on managers to tell the team what to do, and increase reliance on the team to self-organize and know how to proceed.”
  • Uber: Tech Lead Expectations for Engineering Projects – Project Roles: PdM, EM, Project Lead; Set up a framework for collaboration, incl. project wiki; Manage Risks: Understand all parts of project at a high level; Create an inventory of knowledge; Call out risks as they arise; Be accountable for keeping project on track; First-time checklist; PjM methodology: Macro vs Micro level PjM; Macro: scope, break into milestones, estimate, plan and keep-updated staffing; Micro: granular breakdown and estimation, regularly check if on-track, update macro staffing plan when nec.
  • Agile Laws & Distributed Teams: From Conway to Goodhart to Parkinson – Conway’s Law: Designs mirror org comm structure – see also Torbjörn Gyllebring: The Reverse Conway — Organizational Hacking for Techies; Brooks’ Law: Adding ppl to a late project makes it later; Hackman’s Law: The larger a group, the more process problems get in the way of work; Goodhart’s Law:  When a measure becomes a target, it ceases to be a good measure; Larman’s Laws: Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures; Parkinson’s Law: Work expands to fill the time allotted
  • Colin D Ellis: Please Don’t Set Up An Agile PMO – old emphasis: 1. Reporting and analysis, 2. Governance, 3. Training; new emphasis: 1. Helping build new mindset and skillsets fostering agile delivery / thinking, 2. Building talent profiles to facilitate swift mobilization of teams, 3. Create visual spaces charting strategic process, great ideas / failures, 4. Being the hub for cultural evolution initiatives, 5. Leading design-thinking (or similar) workshops; “Forward-thinking organisations do not need a central group to tell their people how to get the job done or to produce endless pointless reports that nobody reads anyway. They need people who role model what a growth mindset looks like; that know how to communicate; that value getting things delivered swiftly; and who create an environment where teams are allowed the time to concentrate on what’s important.The new emphasis should be on support, sustain and role model, not command, control and report. If they can’t do that, then, they have to go, regardless of what they call themselves.”

Tech Debt

  • John Cutler: Tech Debt Factors Diagram – Nice tech debt diagram of factors and symptoms
  • Michael Feathers: Toward a Galvanizing Definition of Technical Debt – “Technical Debt is the refactoring effort needed to add a feature non-invasively”
  • Laura Tacho: What is Technical Debt? – “the negative result of intentional or unintentional suboptimal decisions when building software”; “if you wait too long, it becomes technical debt”; “If we don’t have control over what we’re working on, we must be accruing technical debt, because only we would know how to avoid it”; “Coach your team to get better at advocating for technical debt projects with stakeholders”
  • Doc Norton: Technical Debt Trap (47min vid) – slides – Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code. These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions. What is technical debt? What is not technical debt? Why should we care? What is the cost of misunderstanding?; metaphorphosis, when metaphors go wrong (e.g., debt in tech debt); fowler’s tech debt quadrant (deliberate / inadvertent, reckless / prudent); “ability to pay back debt depends upon you writing code that is clean enough to be able to refactor”; “clean code is a prerequisite for refactoring”; “cruft is redundant or improperly written code”; “cruft or debt”; the trap: precedent for speed over quality; expectation of increased velocity; cruft slows you down; must write more cruft to keep up; ask permission to do your job correctly; managing cruft: cleaning sprint (does not improve long term trend); cleaning constantly; by doing this the areas of highest churn get better; monitor trends (vs. setting targets)
  • Maiz Lulkin: Technical Debt 101 – “writing bad code is not technical debt”; “bad code is almost universally unaccompanied by tests”; “Code without tests is bad code”; “The big rewrite is the default solution when developers are fed up with the lack of quality and they finally decide to stand up to what they believe. But most big rewrites are unsuccessful”; “the only realistic solution to legacy code is about radically improving the current code base in cycles. This must be done by introducing tests, even being really hard and time consuming. The monolithic app must be broken into uncoupled pieces. And all data migrations and more radical changes must be perfectly planned and synchronized”; “The problem of big rewrites is that they are a technical solution to a cultural problem”
  • Chad Fowler: The Big Rewrite – specific reasons things go wrong with rewrites: Software as Spec; Invention or Implementation?; The Wish List; The Big Bang; Justification and Lies; Who’s Tending the Store?
  • CMU: Got Technical Debt? Track Technical Debt to Improve Your Development Practices – provides a classification scheme and flow chart to determine whether something is tech debt or not; template: name, dev artifact, symptoms, consequences, analysis
  • Kane Mar: Technical Debt and Design Death Technical Debt and Design Death – “Technical debt is simply deferred work not directly related to new functionality but necessary for the overall quality of the system”
  • Atlassian: Escaping the black hole of technical debt – their definition, at least partially at odds with most of the above: “Technical debt is the difference between what was promised and what was actually delivered”
  • Michael Feathers: Is Technical Debt Just a Metaphor? – “Technical Debt, like most good metaphors, is more than a metaphor – it’s an accurate read of dynamics in a system”

Agile Planning

  • Atlassian: Stories, epics, and initiatives These simple structures help agile teams gracefully manage scope and structure work
  • Stephen Dubner: Here’s Why All Your Projects Are Always Late — and What to Do About It – “planning fallacy is a tendency to underestimate the time it will take to complete a project while knowing that similar projects have typically taken longer in the past. So it’s a combination of optimistic prediction about a particular case in the face of more general knowledge that would suggest otherwise”; Coordination neglect – “The failure to think about how hard it is to put stuff together when other people are involved”; “… the primary root cause of procrastination is impulse control. The fact that we tend to want to do what’s more instantly gratifying in the moment than what is better for us. And so we put off doing the things we know we should do, in favor of what’s instantly gratifying”; ““Continuous partial attention” is this term for this state that it’s easy to get into if you’re not careful, where you’re never quite focused on any one thing”; ” When people estimate how long a project will take, they focus too much on the individual quirks of that project and not enough on how long similar projects took. This second approach is called reference-class forecasting”
  • Robert Galen: Agile Chartering – Beginning With The End In Mind – “An agile charter clearly realizes that scope is the variable within agile projects and that team’s converge towards their customers’ needs and project goals”; “Running Sprint #0’s as needed; when your project and/or your team needs “directional alignment””
  • Ole Jepsen: Scaling Agile – a Real Story – two-day big-room planning
  • Pinterest: Unknowns / knowns refinement quadrant – unknown-knowns: hidden knowledge; known-knowns: probabilistic risks; unknown-unknowns: fog of ignorance; known-unknowns: gaps in knowledge
  • Phillip Armour: The Five Orders of Ignorance (5OI) – “hard part of building systems is not building them, it’s knowing what to build—it’s in acquiring the necessary knowledge…. if software is not a product but a medium for storing knowledge, then software development is not a product-producing activity, it is a knowledge-acquiring activity”; The Five Orders of Ignorance:  0th Order Ignorance (0OI)—Lack of Ignorance; 1st Order Ignorance (1OI)—Lack of Knowledge; 2nd Order Ignorance (2OI)—Lack of Awareness; 3rd Order Ignorance (3OI)—Lack of Process; “The critical levels seem to be 2OI and 3OI. I view most of our work to be the reduction of 2OI, and the development and use of all software and systems methodologies as being 3OI processes. The job of a 3OI process is to illuminate our 2OI. The application of
    3OI to 2OI generates either 1OI or more rarely 0OI—the process either gives us the answer (0OI) or more commonly, it gives us the question (1OI). This is one of the
    major purposes of process…”
  • Phillip Armour: The Nature of Software and the Laws of Software Process (chapter 1 excerpt from book: The Laws of Software Process: A New Model for the Production and Management of Software) – expands on the five orders of ignorance article above with additional examples and context
  • ResearchGate: Articles by Phillip Armour

Feature / Bug Triage

Jira-specific

Personal Time Management

  • StaffEng: Guides / Work on what matters – “…a few common ways to get tripped up: snacking, preening, and chasing ghosts. “; “…choice between shifting right to hard and high-impact or shifting down to easy and low-impact” (snacking); “In senior roles, you’re more likely to self-determine your work and if you’re not deliberately tracking your work, it’s easy to catch yourself doing little to no high-impact work”; “Preening is doing low-impact, high-visibility work. Many companies conflate high-visibility and high-impact so strongly that they can’t distinguish between preening and impact, which is why it’s not uncommon to see some companies’ senior-most engineers spend the majority of their time doing work of dubious value but that is frequently recognized in company meetings.”; “With your organizational privilege, relationships you’ve built across the company, and ability to see around corners derived from your experience, you can often shift a project’s outcomes by investing the smallest ounce of effort, and this is some of the most valuable work you can do.”
  • Laurie Vazquez: Why Monotasking Is the New Multitasking, According to Science – beware of the narcotic effects of multitasking; “paying attention to, and completing, one task at a time”
  • Nicole Lipkin: 7 Things Successful People Know About Decision Making – routinize; do quick things nite before; make most important decisions first thing am; set some boundaries; sleep off the emotion
  • Alice Boyes: 5 Ways Smart People Sabotage Their Success – 1. Smart people devalue other skills… over-concentrate on intellect; 2. Teamwork can be frustrating; 3. Smart people attach self-esteem to being smart… resulting in less resiliance and avoidance; 4. Smart people get bored easily; 5. … sometimes see in-depth thinking and reflection as solution to every problem
  • Sam Altman: Productivity – what you work on; prioritization “The right goal is to allocate your year optimally, not your day”; physical factors
  • Travis Bradberry: How Successful People Make Smart Decisions – routinize; make most important decisions first thing am; pay attention to emotion; evaluate objectively; sleep on it; avoid analysis paralysis; get exercise; moral compass; seek outside counsel; reflect on previous;
  • Ann Latham: 8 Secrets Smart People Know About Time Management – 1. You can’t manage time, you can only manage yourself.; 2. “Too much to do” and “Not enough time” are victim words; 3. Too many priorities means no priorities; 4. The more priorities you have, the less you will accomplish; 5. Your to-do lists are crazy; 6. Your to-do lists are incomplete; 7. It’s time to accept the fact that you won’t finish everything; 8. Of 6 ways to deal with work overload, most choose the only one that doesn’t work: Accomplish more; Postpone; Cut corners; Ignore; Delegate or outsource; Neglect to choose one of the above
  • Razor-Sharp Advice: How a startup CEO stays on task – “if you enjoy what you’re doing you’re going to be that much better at it”; “its when you really feel passionate about something organically”; “when you’re really excited, you can’t sleep at night”; “what is the one thing in the world you would do if you knew you wouldn’t fail? And then just go do that. Do what you want to do, do what you’re passionate about, don’t worry so much about the risk.”; “Every out-front maneuver that you make is going to be uncomfortable, and that feeling of discomfort is good. It means you’re pushing yourself”;  align your goals with the meetings you choose to attend; “for me work and life blend together a little bit, and that’s OK… flexibility has always been really important.. i want to go for a run a 4, i’m going to go for a run at 4”
  • Jeremiah Dillon: Read this Google Email about Time Mgmt Strategy – two paradigms to scheduling, manager and maker, as discussed in Maker’s schedule, Manager’s schedule from the article comments; interesting take in this article is that “we all need to be makers” – i.e., managers should budget more “make time”: Schedule blocks of “make time” on your calendar to avoid interruptions at those times; “Many of our meetings could be shorter or include fewer people, and some don’t need to happen at all”; Consider the “energy wave” model of the work week as a way of segmenting what work to do on what days (Tue/Wed – “Peak of energy?—tackle the most difficult problems, write, brainstorm”) – i think this is a useful model also for team-wide work scheduling (e.g., minimize meetings on Tue/Wed); Bias “make time” toward morning, before pm decision fatigue (aka food coma) – use late afternoon for mechanical rote tasks; A quote from the “Maker’s schedule, Manager’s schedule” link above that is more specific to non-manager makers: “Those of us on the maker’s schedule are willing to compromise. We know we have to have some number of meetings. All we ask from those on the manager’s schedule is that they understand the cost”
  • Maker vs. Manager: How Your Schedule Can Make or Break You – the intersection between makers and managers; the value of defining your schedule
  • Jim Benson: Personal Kanban
  • Keith Bryant: Pomodoro Productivity: A Simple Time-Management Technique to Eliminate Procrastination
  • Thanh Pham: Covey’s Time Management Quadrants – the classic Covey quadrants with not important->important, urgent -> not urgent axes, example scenarios
  • Rob Lambert: The Slight Edge at Work – be consistent every day with the “little things” – good habits and best practices – has a much bigger impact than a single large thing
  • Victor Savkin: Using Trello for your Personal Productivity System – compares to GTD, Kanban approaches
  • Matt Bilotti: This is your life on Trello – Personal working board; Our team Jobs To Be Done (JTBD) board; Design team board; Personal life board
  • Jeff Haden: Why the 8-Hour Workday Doesn’t Work for You (and What to Do Instead) – similar in concept to pomodoro technique with longer spans; right focus is on your energy, not your hours; physical (healthy), emotional (happy), mental (focus), spiritual (purpose); ultradian rhythm 90-120min task then 20-30min break; eliminate distractors when focused on a task; self-imposed deadlines, split day into 90-min focus windows; plan your rest
  • Getting Things Done (GTD) methodology: Capture, Clarify, Organize, Reflect, Engage

Change Management

  • Evan Bass: Speeding Up Software Delivery With Effective Change Management – “In a true CD environment, there is no interruption of the progression of a deliverable from integration to deployment”; “A compliant change management process is one in which all changes conform to the documented process, and exceptions are rare and acceptable to management”: Quality, Consistency, Pervasiveness, Scalability, Reliability and adequacy; Governance: Applicability, Reliability, Consistency; CICD policies; “Because environments from development through production are tightly integrated, each environment should be secured as if production relies on it—because, in fact, production does”; “CM-04 All changes and test cases are reviewed by an individual other than the person who deeloped the change”; “CICD advocates and auditors alike can embrace the benefits of efficient and effective CICD, providing it demonstrates the core attributes of auditing:

Waterfall, Earned Value etc.

Sociocracy, Holacracy

  • Sociocracy Consulting Group: With Sociocracy, Hierarchy becomes Agile – overview, selection process, org structure
  • Blinkist: How One Guy Mixed Scrum, Lean, Holacracy, and Kanban to Make an Unstoppable Workflow System – HoLeBan: the hybrid of the Holacracy, Lean, and Kanban; “you have to fit a process to the roles they already have and the way they already like to work”; “As in a Holacracy tactical, we have a check-in round where everyone can say how they’re doing, if there are any administrative concerns… Then, you move on to the checklist of items that need to get done weekly. Here, we subbed product metrics, and then would move to project updates”; “… using a really standardized, strict format like Holacracy’s governance, but welcoming in introspection and giving the space to raise tensions, has really helped us work better”; see infograph
  • Sociocracy: The Movement – “Holacracy built on sociocracy. Holacracy emphasizes autonomy of individuals while sociocracy is less regulated and tends to keep more power and exploration in circles of peers. Holacracy is a more regulated version of sociocracy – holacracy gives more structure, sociocracy gives more choice”; Sociocracy is a set of design principles embodying equivalence in all areas of an organization: how we structure our work; how we learn and evolve; how we make decisions; Sociocracy 3.0 (sociocracy30.org) is an iteration of sociocracy that focuses on the exploration and expansion of patterns and the connection between agile and sociocracy; Sociocracy For All is aware of and connected to about 100 sociocratic organizations and we assume there are at least 3 times more organizations that have implemented sociocracy to some significant degree
  • Sociocracy 3.0: Effective Collaboration at any scale: A Practical Guide – the seven principles: effectiveness; consent; empiricism; continuous improvement; equivalence; transparency; accountability; pattern groups: co-creation and evolution; peer development; enablers of collaboration; building organizations; bringing in S3; defining agreements; focused interactions; meeting practices; organizing work; organizational structure; These patterns help you discover how to best reach your objectives and navigate complexity, one step at a time, without the need for sudden radical reorganization or planning a long-term change initiative: Simply start with your area of greatest need, select one or more patterns to try, move at your own pace and develop skills as you go; two categories of activities in an organization, one of which we refer to as governance, and the other as operations: Governance in an organization (or a domain within it) is the act of setting objectives, and making and evolving decisions that guide people towards achieving them. Operations is doing the work and organizing day to day activities within the constraints defined through governance; The S3 Patterns (by group, index by name, glossary)

General process themes

  • Steve Jobs Interview: Success is about creating content not managing process (2min vid) – 1996 interview just before Jobs’ 1997 return to apple – “…apple did not have the caliber of people who were capable of seizing this idea in many ways (most hired from HP), and there was a core team that did…”; “companies get confused when they start getting bigger, they want to replicate their initial success, a lot of them think there was something magic about the process, so they start to try to institutionalize process throughout the company, before long people get very confused that the process is the content”; “… that’s what makes great products, it’s not process, it’s content”
  • Aditya Gondhalekar: Paralysis through PoCs – diagram “journey of value discovery to value realization”, from “island of ideas & POCs to “Land of Industrialization”; “industries feel paralyzed as they sit of a pile of ‘working PoCs’ for which the feasibility is checked and the business case is proven. They don’t know how to take the next step”
  • Tanya Kravtsov: Finding the Bottlenecks in the Agile and DevOps Delivery Cycle – “The most common bottlenecks in the software delivery lifecycle often turn out to be environments, testing, and communication”; automate environment setups; embed testing in the dev cycle and automate tests appropriately; communicate well by defining ownership, clear and simple communications

Lists

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s

%d bloggers like this: