Reading List: Agile (Kanban, Time mgmt., et al.), Product Mgmt.

Agile Definitions and Comparisons
Kanban / Scrum-ban
Scrum
Agile meeting approaches (planning, retro., et al.)
Agile teams
Scaling Agile
Estimating / Decomposition
Metrics
Product Mgmt.
MVP, MMF, MMP, MMR et al.
Tech Debt
Agile Planning
Feature / Bug Triage
Jira-specific
Personal Time Management
Waterfall, Earned Value etc.
General process themes
Lists

Agile Definitions and Comparisons

  • 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

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”
  • 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”

Agile meeting approaches (planning, retro., et al.)

Agile teams

  • 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”

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

Metrics

Product Mgmt.

MVP, MMF, MMP, MMR et al.

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”
  • 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

  • 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”
  • 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

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

Waterfall, Earned Value etc.

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:

WordPress.com Logo

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

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

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

Facebook photo

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

w

Connecting to %s