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

Kanban / Scrum-ban
Agile meeting approaches (planning, retro., et al.)
Agile teams
Estimating / Metrics / Decomposition
Product Mgmt.
Tech Debt
Agile Planning
Feature / Bug Triage
Personal Time Management
Waterfall, Earned Value etc.
General process themes

Kanban / Scrum-ban

  • 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
  • Yaki Koren: Forward Looking Kanban – “… a scheme for visualizing my clients’ commitments. We call it a Forward Looking Kanban”; “The idea is to constantly look several months ahead”; “Each column represents a month”; “Each row represents a main step in the process, maybe like we would do on a regular kanban board, but I believe it should be less detailed”; “each cell contains a WIP limit”; “The main use of this board is that when something comes up we can try to schedule it, according to available capacity in the various cells. If there’s no capacity we may try to move some things”; “The initial WIP limit should take into account both future events and buffers for changes. In the example above December has lower values (due to holidays). The buffers are not shown here but the people working with this board should know not to use the entire capacity of January when we are in September – that is a promise that will not hold”
  • Toolbox for the Agile Coach – Visualization Examples – Inbox: “Policy: new tasks aren’t added to Planned or Doing, they must be placed in the Inbox. The following standup the whole team decides if the task should be done or not, i.e. if it’s valuable and aligned with the sprint’s goal. If the team decides it shouldn’t be done now, it goes into the Product Backlog or into the trash bin. Each Inbox should be empty by the end of the Daily Stand-up.”; Confidence Smileys: “This is a powerful alternative to a Sprint Burndown. At the end of every Daily Stand-up meeting the team asks themselves; how confident are we that we will be able to finish each User Story by the end of the Sprint? The answer is represented by a Confidence Smiley. “; Dependency Spider: “Draw a spider with your team in the middle. Around your team, draw your dependency sources that sometimes block your progress or force you to wait for some kind of response. On the legs of the spider you continuously add notes describing how you are currently blocked or dependent on that source”; Urgent lane + policy: “add a policy that describe what counts as an urgent task. This will act as a filter to prevent adding regular unforeseen tasks to the Sprint”; Team Rhythm / Cycle: “Many teams who use Kanban still experience value from having a rhythm. For example, backlog refinement every week, demo and retrospective every second week, and so on. Visualizing this rhythm, and where in the cycle the team is, helps focus and provides a sense of structure to an otherwise response and pull driven work environment”; Pair Programming Matrix: “Whenever you’ve done a pairing session, make a tick in the corresponding box. You need to agree as a team how much pairing is required for a tick.”
  • Steve Porter: A Scrum Primer for Kanban Teams – maps scrum Values, Roles, Events, Artifacts to Kanban teams
  • Thoughtworks: Road-mapping your way to Agile Fluency – more of a pattern compared to the prescriptive CMMI; case study
  • Karl Scotland: Kanban Thinking and the Kanban Method – systemic thinking; impacts; interventions; agendas; principles; practices
  • Yuval Yeret: A Kanban primer for Scrum Teams – first in the series Scrum and Kanban stronger together
  • John Cutler: 40 ways to invest in more resilient teams – including rotating who runs standup
  • 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”
  • Patrick Emmons: Get Lean: Avoid 8 Wastes in Software Development – good summary of some of the primary lean / kanban benefits over waterfall: unnecessary features; waiting (for requirements, testing, etc.); scope too big for resources / sprint; defect reduction through built-in quality; unused employee creativity
  • 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
  • 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)
  • Spotify: Henrik Kniberg: Spotify Engineering Culture (25min vid in 2 parts) – Self Service Model; Loosely Coupled, Tightly aligned project teams; Minimum Viable Bureaucracy; Experiment-friendly culture; Alignment – Autonomy quadrants; cross-cutting “Guilds” to complement functional cross-cutting areas; keep vs. skip/dump lists
  • Kniberg & Skarin: Kanban and Scrum – Making the most of both – free book download – process frameworks including Scrum, Kanban, XP compared on the prescriptive vs. adaptive scale; scrum’s iteration limit vs. kanban’s workflow state limits; board mgmt diffs; breaking down items to fit into a scrum sprint vs. kanban’s tolerance for longer-running items; prioritization strategies; scrum burndown vs kanban cumulative flow
  • Henrik Kniberg: Kanban kick-start example – compact 2-pager
  • Heusser: How the Kanban Method Changes Software Engineering – Compared to Scrum, Adoption Case Studies, Scaling
  • Alan Shalloway: Demystifying Kanban – managing points of interface with the biz; enables participation of mgmt vs. scrum which often marginalizes it; kanban as an aid to product portfolio mgmt.; how kanban is effective not just for support but also for new feature dev
  • Stormpath: So Long Scrum, Hello Kanban – Good discussion in comments
  • Kanban Tool: Scrum-ban – Intro
  • SolutionsIQ: What is Scrumban? – Overview, comparison charts of Kanban Scrum-ban Scrum, When to Consider
  • Ladas: Scrum-ban – The seminal essay on scrum-ban, with good discussion in the comments
  • Yuval Yeret: So what IS Scrumban?
  • Kniberg: Lean from the Trenches: An example of Kanban in a large software project – Book draft
  • Agile Sysadmin: Kanban for Sysadmin
  • LessThanDot: Applying Kanban to IT Processes (Part 2): Help Desk / Support Scenario
  • Payton Consulting: Agile Team Working Agreements How To Guide – how they help; work well when; examples; how to respond when broken
  • Cohn / Keith: How to Fail with Agile
  • Ben Linders / Yuval Yeret: Kickstart Agile the Kanban Way – Interview
  • TameFlow Chronologist: Risk Management in Kanban – Includes a 7-level Class-Of-Service
  • Anderson: Project Management with Kanban (Part 1) – “make policies explicit”; “scheduling, sequencing, selection (“the three S’s”) and options, commitment, capacity allocation, risk management and hedging. We don’t estimate, instead we forecast”
  • Anderson: Project Management with Kanban (Part 2) – Sequencing Policies – “prioritization is done dynamically each time an item is pulled through our kanban system. Prioritization isn’t an activity in Kanban, it is a consequence of decisions made dynamically based on the risk profile of available work when a pull signal is generated in the kanban system”; “Create Sequencing & Capacity Allocation Policies”; “Policy-Based Scheduling Is More Powerful Than Traditional Backlog Prioritization”
  • Anderson: Kanban Litmus Test
  • Anderson: State of KanbanLand (33min video)
  • Anderson: Adoption of Lean / Kanban Principles – Part 1 (79min video)
  • Anderson: Adoption of Lean / Kanban Principles – Part 2 (57min video)
  • Book: Anderson: Kanban: Successful Evolutionary Change for Your Technology Business
  • We just can’t afford Taylorism anymore. Now what? – how software is different; taylorism history; waterfall; command and control
  • SPR Consulting: Birth of a Service: Technical Agile Coaching – coaching of engineering practices vs. the people side
  • #modernagile    #kanban


  • Robert Galen: Why the Scrum Product Owner is a Project Manager – 4 quadrants of product ownership, risk mgmt., proj comm.
  • 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”
  • 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

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


  • 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


  • 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 / Metrics / Decomposition

Product Mgmt.

Tech Debt

  • 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

Feature / Bug Triage


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


Leave a Reply

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

You are commenting using your 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 )

Google+ photo

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

Connecting to %s