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

Agile teams SAFe LeSS Estimating / Decomposition Metrics Product Mgmt. Tech Debt Agile Planning Feature / Bug Triage Jir

6 downloads 21 Views 167KB Size

Recommend Stories


MGMT 602
Raise your words, not voice. It is rain that grows flowers, not thunder. Rumi

MGMT 3301
I want to sing like the birds sing, not worrying about who hears or what they think. Rumi

Forest Mgmt
Don't count the days, make the days count. Muhammad Ali

PDF DOWNLOAD MGMT GUIDELINES GERON
Almost everything will work again if you unplug it for a few minutes, including you. Anne Lamott

MGMT 490 Portfolio Assignment
I cannot do all the good that the world needs, but the world needs all the good that I can do. Jana

Technology Strategy (MGMT 731)
Where there is ruin, there is hope for a treasure. Rumi

Iowa Arena Mgmt RFP
Don’t grieve. Anything you lose comes round in another form. Rumi

Surf Mgmt Lease Application
If you are irritated by every rub, how will your mirror be polished? Rumi

Second Entrance Result MGMT
Forget safety. Live where you fear to live. Destroy your reputation. Be notorious. Rumi

Kiwi Identification and Mgmt
Be grateful for whoever comes, because each has been sent as a guide from beyond. Rumi

Idea Transcript


26thcentury futuristic musings

Reading List: Agile (Kanban, Time mgmt., et al.), Product Mgmt. Kanban / Scrum-ban Scrum Agile meeting approaches (planning, retro., et al.) Agile teams SAFe LeSS Estimating / Decomposition Metrics Product Mgmt. Tech Debt Agile Planning Feature / Bug Triage Jira-specific Personal Time Management Waterfall, Earned Value etc. General process themes Lists 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 phasegate 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 beyondagile.com: 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 Scrum 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” John Cutler: The Trouble with Scrum – descent from mount scrum; technical practices matter; legally scrum; works great (not scrum); aggressive scrum / true scrum 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.) Roman Pinchler: Sprint Review Tips for Product Owners – consider splitting the meeting in two parts (dev-only, then with stakeholders); consider separately collecting user and stakeholder feedback Jason Yip: It’s Not Just Standing Up: Patterns for Daily Standup Meetings – (Spotify); we standup to keep the meeting short; what might “good” look like? the particular set of problems that occur when people attempt to work together; Patterns: Who attends?; What do we talk about? What order do we talk in? Where and when? How do we keep the energy level up? How do we encourage autonomy? Philip Rogers: Retrospective from a Hat – links to retro exercises / techniques incl. Retromat and Retrospective Techniques Trello board; Question bank (from author, Ben Linders, David Mole, Diana Larsen Madison Moore: Improv brings improvements to agile team standup meetings – e.g., the ‘alphabet game’ – particularly good for retros, to get everyone talking in first 5m; main benefit is to build team player culture Stefan Wolpers: 21 Sprint Retrospective Anti-Patterns Impeding Scrum Teams – noretro, dispensablebuffer, rushed, whining, unSMART, noaccountability, what action Neel Lakshminarayan: The Daily Kanban Stand-up – departure from traditional scrum 3 things – instead: 1) impediments; 2) flow (what actions team can take to smooth it); 3) Continuous improv. (ideas best coming from team, not mgrs.); show work done for week and since last standup Anderson: Project Management with Kanban (Part 3) – Risk Review – based on Blocker Clusters post; “Until recently there has only been 3 specific practices: the standup meeting; the service delivery review; and the operations review. With the official release of the LeanKanban Modern Management Framework in October this year, we are adding a fourth specific feedback loop practice, the Risk Review” Daily Plank Meeting – Going Agile (literally) – “Rest on the ground when you are not speaking, Must keep plank position if you are talking” Jessie Shternshus: Individuals, Interactions and Improvisation – line up agile practices with improve techniques, such as retrospectives; “most breakdowns happen for non-technical reasons” 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” SAFe 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 preCopernican management thinking in action” LeSS 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 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 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 Kerievsky: Stop Using Story Points – includes suggestion to use “team-weeks” 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 StoriesOnBoard: Useful resources for user story mapping – including articles, videos, Tools – one tool not listed is FeatureMap.co Twitter: #NoEstimates Metrics Avinash Kaushik: The Difference Between Web Reporting And Web Analysis – analysis includes interpreting the data, while reporting (aka data puke) does not Highsmith: Velocity is killing agility! 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. Jim Highsmith: Priorities and Politics – All priority setting is political; Authoritarian politics leads to dysfunctional priority setting; Collaborative politics leads to functional priority setting David Pasztor: How to turn a story point factory into a customer-centric team? – group backlog into 4 big categories: metrics-movers (short-term biz goals); under-thehoods (refactoring); user needs (usability issues / user requests); strategic / innovative (long-term goals) Cody Simms: Why Most Product Roadmaps are a Train-wreck (and how to fix this) – talks about prod viability, but approach is applicable to tech viability as well; “The key is to get away from a roadmap that assigns feature delivery dates and to move to one that establishes validation dates. Rather than having a 12 Month Product Roadmap, have a 12 Month Learning Roadmap”; “The dates you should represent to your stakeholders are the dates by when you hope to validate a problem” Thoughtworks: Products over Projects – “product-mode” way of working for non-software products, as an alternative to project-mode Satish Rao: Learn Fast, Learn Cheap: How Large Organizations Can Accelerate their Innovation Efforts – Learning Plans focus on what you need to learn re critical assumptions / uncertainties, how you’ll learn; “The key to a successful Learning Plan is to maximize learning at minimal cost” Andy Raskin: Strategic Storytelling is Product Management (23min podcast) – the five key components of an effective story and the secrets to getting buy-in for a big decision Rik Higham: The MVP is dead. Long live the RAT – “There is no need to build more than what’s required to test your largest unknown”; “Is this the smallest thing we can do to test our riskiest assumption?” Apple: Steve Jobs: Focusing is about saying no 280Group: How to Create Compelling Product Roadmaps | Tips and Best Practices for Success – types: Market and strategy, Visionary, Technology, Platform, Product (internal & external); eight step roadmap process; prioritizing & organizing (Themes, Golden Feature) Roman Pichler: 10 Tips for Creating an Agile Product Roadmap – focus on goals and benefits; do the necessary prep work; tell a coherent story; keep it simple; secure strong buy-in; have the courage to say no; know when to show dates; make your roadmap measurable; determine cost top-down; regularly review and adjust the roadmap Roman Pichler: Goals vs. Features: How to Choose the Right Product Roadmap Format – sample Goal-oriented roadmap format, product maturity / market dynamicness matrix Roman Pichler: Three Common Product Roadmapping Mistakes – Guarantee; including Epics and Stories; Speculation Roman Pichler: Decision Time: How Decision Rules Help You Make Better Product Decisions: Consensus / Product Mgr. Decides after discussion (best for highstakes); Delegation; Majority Vote; Product Mgr. decides without discussion; keep roadmap and backlog in sync with quarterly review Roman Pichler: The Product Roadmap and the Product Backlog – simple distinction drawn between roadmap (strategic plan, how prod likely to grow across several releases, “tells a longer-term story”) and backlog (tactical, with the epics / stories); minimize overlap (high-level roadmap, backlog details) slalom: Why you need a roadmap – benefits: focus; optimization of investment; alignment; better measurement AirBnb: Jonathan Goldman: The Power of the Elastic Product Team — Airbnb’s First PM on How to Build Your Own (interview) – make sure your vision is fully articulated; build modular teams for maximum flexibility; hire these 3 types of PMs (Pioneers, Settlers, Town Planners); demystify resourcing projects with clear process; rally teams quickly and scrap them when necessary 1871: Howard Tullman: You Can Pivot, But You Should Never Twirl – The lean-startup zealots are pushing terrible advice that can put your business in a death spiral. To avoid that, prioritize your customers over your product. Ash Maurya: How to Achieve Breakthrough By Embracing Your Constraints – Customer don’t care about your solution but your offer. Build that instead. You don’t need lots of time, money, or people to test an offer; The number one reason why new products fail is not a failure to build what we set out to build, but a failure to find the right customers and markets for our products Kavi Guppta: 8 Reminders To Motivate Your Search For Value Propositions & Business Models – 1. do nothing and your company will become disposable; 2. good business model innovation starts with your culture; 3. manage today’s business model while searching for tomorrow’s success; 4. reinvent constantly. Don’t wait for a crisis to surprise the org.; 5. innovation isn’t magic, it’s a process; 6. get leadership and teams to speak the same language; 7. your company’s existing assets might be the ticket to its next success; 8. always, always, always champion evidence Twilio: Jeff Lawson: SaaS & the Art of Software Pricing. A decade of AWS & Twilio – Cost-based, Value-based and Competitive-based pricing Silvie Spreeuwenberg: Being Agile with Rule-based Standard Software – argues that standardized E2E processes, for specific kinds of knowledge in a specific domain, delivered as SaaS will be more important than more generic business-rule-intensive systems Steve Blank: How to Build a Startup: The Lean LaunchPad (1 mo 6hr/wk online course) Alex Moy: Product Managers must be True Leaders – “CEO of the product” metaphor is about the role’s requirements and accountability, not about entitlement”; “True leaders influence using their relationships, their credibility, the development and empowerment of their followers, and their values. They inspire action. They inspire change. They lead in service to their customers, their team, and their community”; “Product managers are CEOs for the product and true leaders for those who bring the product to life“ John Cutler: Product Management Writing – 50+ articles and growing Twitter: #prodmgmt 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 Ole Jepsen: Scaling Agile – a Real Story – two-day big-room planning Feature / Bug Triage 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.” UserVoice: How we use Trello & Google Docs to make UserVoice better every day – They use Jira for ticketing, but Trello for (multiple) boards Jira-specific Atlassian: Working with Epics – approaches for both scrum and kanban boards Atlassian: How we do it (video) Atlassian: Using Jira for Test Case Management Atlassian: 3 ways to show waiting status on board Atlassian: Portfolio for JIRA – project managers edition – 3d part of 3 part series (preceded by development managers edition, product managers edition: plan according to milestones; managed dependencies so timeline is realistic; track progress toward your goals 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” 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. Mosaic: Sizing Using Testable Requirements Twitter: #ParkinsonsLaw 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 David J Anderson and Asso.: Articles – Kanban, DevOps, Lean et al. topics limitedwipsociety: Articles – Kanban AgileSparks: Kanban Basics Reading List AgileSparks: Agile Project Management Reading List Thoughtworks: Estimation articles AgileSparks: Improvement Reading List – Retrospectives etc.

Share this: Twitter

Facebook

Google

Loading...

26thcentury

Blog at WordPress.com.

Smile Life

When life gives you a hundred reasons to cry, show life that you have a thousand reasons to smile

Get in touch

© Copyright 2015 - 2024 PDFFOX.COM - All rights reserved.