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
Issue Triage
Jira-specific
Personal Time Management
Waterfall, Earned Value etc.
General process themes
Lists

Kanban / Scrum-ban

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”

Estimating / Metrics / Decomposition

Product Mgmt.

Tech Debt

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

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

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 )

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