Brian Pan - Notes on PM and Agile

  An interesting video fairly describes it well.  The V-P-C Framework presents distinctions between value, price and cost. As a reference to the image above, the green represents the value to customers, blue is the value to the company, and orange is the cost of producing said value/service. Companies naturally want to increase their blue value. In an effort to do that, they may do one of several things:  1) Decrease the value of green 2) Decrease the value of orange  3) Increase the value of green  4) A combination of the above choices. While certain companies may choose to under-deliver to their customers as a result of trying to capture the optimum gain, the best answer is (4). More specifically, the company should decrease their cost of production, increase their price to customer, and also increase the benefits to customer to which the customer does not lose any value. Essentially, it is baking a bigger pie.  So how can companies bake a bigger pie?  1. Optimize value to customers

 Reading here The author references the book "Conscious Capitalism"  by John Mackey and Raj Sisodia. It identifies four categories of conscientiousness:  1. Knowing a higher purpose of the work (beyond profit) 2. Having consciousness of stakeholders  3. Consciousness in leadership (and teamwork) 4. Consciousness on building culture and management (trust) 

 Manual here The Evidence Based Management allows users to empirically measure, manage, and maximize a product. This framework is defined by four values: 1. Unrealized Value This requires some legwork. Organizations need to measure opportunities where customers are underserved.  2. Current Value This is the value the product brings to its current users, customers, employees, and investors.  3. Ability to Innovate Organizations need to identify new markets and measure room for procedural innovation, product innovation, as well as market disruptions.  4. Time to Market Organizations measure their agility, or responsiveness to the market. For instance, how often they roll out updates/new products and how soon they are able to identify and act on new information. 

 This is an opinion on this article .  Straight from the heading, you could easily tell this was going to be a can of worms. Philosophers have been largely knocking their brains with the idea of utilitarianism since ages, as well as the concept of what is utility, what is value?  But I digress. It's already well established, especially with the advent of the Balance Scorecard that there is much more to value than money. And the author mentioned it briefly that it's more than money. Although he failed to make any substantial cases beyond that other than introducing the typical business intangibles and opportunity costs (in terms of lost time). He then, to no surprise, concludes that value is in the eye of the beholder. Essentially, saying that value is what you define as valuable. I am writing this off as a junk article piece for sheer nominal publication quotas.  Personally, I feel like he had so many points he could have addressed. What are some common "values" that

Link here

  This is a technique lifted from XP (Extreme Programming).  Card On each card is enough text that identifies a requirement. Notes of priority and cost are written on it as well. They serve as tokens for requirements and are handed to developers during implementation and returned to customers when completed. Conversation  Conversations are collectively exchanges of thought between customers and programmers. It is largely verbal, but may be communicated with supplemental examples. Confirmation Confirmation, in other words, acceptance tests, are defined at the start with the customer and shown to customer at the end of the iteration to confirm the story's completion. Note that extra documentation, while seemingly helpful, hardly "confirms" anything and cannot replace acceptance tests. 

  John Sweller’s Cognitive Load theory adapted to Software Development context (inspired by  Team Topologies ) — the visual created by Sahin Guvenilir

 This is an opinion on this article .  At a first glance, I think it is great that the author is pushing for more females to pursue Scrum. It is quite reminiscent of the push within STEM for more female participation. However, closer inspection within this article seems to be more of a back-patting on Scrum with aesthetic Eastern laud.  The article goes over the main premise of how women are fitting into a primarily male mold in the tech industry. She then summarizes that you need yin-yang, male-female components within the work structure, and how embracing the diversity is welcomed and productive in the SCRUM model. She later references Conway's Law, which bluntly put, says that the communication defines the product. (In this case, ratios of men:women influence the communication, and hence positively affect the product.) But to backtrack, I do agree that the tech field, in general, has a lot of men, and hence might be heavy on the male-dominated culture, so it is great to have mor

 Notes are from here . Do's: 1. Craft Sprint Goals     Sprint goals help guide the Development team to meet objectives from the Product Backlog. It should be specific. For example, “policy renewal for individual policyholders” for an insurance product rather than saying, the goal is “complete all Product Backlog Items selected during the Sprint.” 2. At least one retrospective commitment for the sprint  3. Refer to Definition of Done 4. Review Team Capacity 5. Come up with Plan for initial few days      Have an initial few days plan to avoid the analysis paralysis of planning, especially in trouble of formulating a sprint plan Don'ts: 1. Don't assign Developers stories.      It undermines team mentality. 2. Don't create skill-based tasks.      Instead, create component based tasks. This way team mentality is reinforced and people are not silo-ed into their roles. 3. Don't force development team to match velocity      Use velocity as a forecast, not a driver. Variabil

 This is an opinion in response to this article .  At a glance, I thought this would give me some new insights in looking at Scrum and its organization processes, but it turns out to be more the usual ho-hum complain about implementing Scrum. The author makes a neat reference to the book "Scrum: The Art Of Doing Twice The Work In Half The Time," but fails to draw out any details or references within it. It is a quick read, but essentially the diagram below is his five reasons. (1) Over-promising, (2) Resistant culture, (3) Ineffective metrics, (4) Faux Agile, (5) although not elaborated, in-congruent work culture. The comment section provides a dim outlook of reality - without management's support, Scrum is only apt as zombie scrum. The only glimmer of hope is to better understand the current flow of events and play with the cards you are dealt.   

Surveys  Notes are from here .  To ask the right questions, par them down to be comprehensible to an eight-year-old. Avoid acronyms or industry jargons.  Common way to gather requirements from stakeholders is to send a list of general topic of survey questions. These should lead towards more detailed, specific questions.   Options/choices on how to respond within surveys will affect the data gathered. Answer ranges can skew a survey. People who don't fill out forms for exemplary service doesn't imply that there were none. In some local grocery and department stores, they now have "Outstanding Service" forms you can fill out to honor anyone who has gone out of their way to provide exemplary service for you. No mention of where to enter complaints. Interviews Notes are from here Interviews are preferable to surveys as they allow for follow ups and clarification.  Three phases involved: Preparation, Conduct, and Follow UP There are two types of interview: structured and

 An interesting, fun activity here . 

This video outlines some of the key differences, in usage and terminology of these terms.  Product Owner (1) Entrepreneurial - accountable for profit and loss of product (2) Has helicopter/holistic view of product. Initiates instead of relays ideas for product (3) Has long-term vision for the product for its success and sustainability (4) Is empowered by company to make critical decisions (5) Spends 80% of time on strategy instead of tactical (step-based) work Product Scribe (aka Business Analyst) (1) Spends 80% of time doing tactical work (2) Fine tunes Backlog items (3) Ensure acceptance criteria is well written (4) Analyzes requirements  (5) Fiddles around Jira too much  He notes that the Product Scribe is often preferred because of their meticulous and clear details for the project. However, I believe the distinction is made clearly to outline that the Product Owner requires the foresight of future improvements. 

 A great video highlights this.  The key concept is  (1) Sprints are not mini-waterfalls. Anything that is not done goes back to project backlog. There is no carry-over, extensions, or overtime.  (2) Done means ready to release. There is not half-dones' or almost done.  (3) Not-done in product backlog could be      (a) continued onto next sprint     (b) post-poned     (c) discarded

 An interesting read .  "In the South Seas there is a cargo cult of people. During the war, they saw airplanes with lots of good materials, and they want the same thing to happen now. So they’ve arranged to make things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head for headphones and bars of bamboo sticking out like antennas—he’s the controller—and they wait for the airplanes to land. They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No airplanes land. So I call these things cargo cult science because they follow all the apparent precepts and forms of scientific investigation, but they’re missing something essential because the planes don’t land." Cargo cults, or rather, Agile Cargo Cults, are faux Agile. It should be noted that organizations may easily slip into this behavior. This checklist would be helpful to assess you

 From selected link This provides an interesting work project-seminar for project team members to learn the basics of running through a project. An interesting idea is the concept of an idea being a commodity. 

 Notes are from here .  - Every "good practice" must be tailored to context. - Scrum Master should never act as enforcer  - Product backlog includes user stories, bugs, spikes, and non-functional requirements - A Product Backlog is “actionable” if the Scrum Team can organize a successful Sprint Planning at a moment’s notice. - Incomplete and poorly prepared work items seriously hamper the effectiveness of a Scrum Team. These items should never be selected for the Sprint Backlog, but instead sorted out during Product Backlog refinement meetings. - Daily Scrums cannot fix — and is not supposed to fix—, among other things: a dysfunctional organization, a dysfunctional Scrum Team, an inadequate Product Backlog, a Sprint Planning session gone wrong, low-quality user stories, or a missing product vision. - All issues, concerns and frustrations, should be documented — even if just temporarily using sticky notes. Though it’s always better to keep a formal document or file. (Limit acc

Below are some frameworks for Scrum Masters to help understand how their scrum teams may learn and develop competency. It serves as a reference and does not, in particular, dictate anything.  Shu-Ha-Ri  This is the Japanese model of skill acquisition, which Alistair Cockburn has personally referenced. It comes from Aikido, and it outlines that students goes through three stages: Shu, Ha, and Ri.  Shu - student follows masters teachings without question, understanding, or desire to make judgement on the underlying theories.  Ha - student has a good grasp on basic practice and begins to branch out and learn from other masters Ri - student develops own practice and creates approaches and adaptations to circumstances Dreyfus Model This model of skill acquisition was published within the scholastic circle, and largely implemented in schools. It is largely individualistic, and familiar to typical teaching styles.  Novice: Concepts are largely distilled, controlled, and rigid to allow formula

Notes from site RACI is a matrix to properly organize and define stakeholders' responsibilities in the project. While there are many methods in creating these organizations, this is just one method. Definitions should be kept nearby and the charts should be clear.  Responsible: This team member does the work to complete the task. Every task needs at least one Responsible party, but it’s okay to assign more. Accountable: This person delegates work and is the last one to review the task or deliverable before it’s deemed complete. On some tasks, the Responsible party may also serve as the Accountable one. Just be sure you only have one Accountable person assigned to each task or deliverable. (Note: It might not be your PM!) Consulted: Every deliverable is strengthened by review and consultation from more than one team member. Consulted parties are typically the people who provide input based on either how it will impact their future project work or their domain of expertise on the del

 Notes from this article  The article goes over several things, but applied specifically to Lean Project Management.  Epics are used in Lean to create Minimum Viable Product (MVP), the simplest working-grade product that may be presented to the market. Epics are (as a rule of thumb) projects but have the addition of a few factors that distinguishes them. They are measured against the anticipated outcome, as opposed to the desired outcome, tracks the benefits of the project as opposed to the ROI, and is used to evaluate the decision as opposed to the follow-through of the scope.  Epics are budgeted in advance with a hard-line STOP when the budget has been hit. It is then evaluated on whether or not the project is profitable and worth pursuing. In other terms, it may be used as a litmus test for a new venture.  Below is a template where you can use to create an Epic.  Template 

 Lifted from  here  is a great excerpt analogy on what KPIs are.  "Terminology Example:  Let’s say someone wants to use KPIs to help them lose weight. Their actual weight is a lagging indicator , as it indicates past success, and the number of calories they eat per day is a leading indicator , as it predicts future success.  If the person weighs 250 lbs / 113 kg (a historical trend is called a baseline), and a person they would like to emulate is 185 lbs / 84 kg (comparison research is called benchmarking ), they might set an 1,700 calorie-per-day target (desired level of performance) for the leading KPI in order to reach their lagging KPI target of 185 lbs / 84 kg by the end of a year. Let’s say my business provides coffee for catered events. Some inputs include the coffee (suppliers, quality, storage, etc.), the water, and time (in hours or employee costs) that my business invests. My process measures could relate to coffee making procedure or equipment efficiency or consistency

 In reference to the link , there are a couple interesting points for take-away.  The balanced scorecard, and its use, comes from the idea that the way organizations operate is in fact imbalanced. That is to say, organizations being profit-driven is too one-track-minded. There are other dimensions and important aspects that an organization needs to consider. This makes sense, as being purely profit-driven is the kindling to pure speculation.  The philosophy of the balanced scorecard is to start from the inner processes, which would eventually lead to good finance (or financial stewardship). Financial stewardship is an interesting concept introduced here, as it takes into account that profit is not to be optimized. In fact, the article references several organizations in which profit is not   optimized, specifically governmental organizations and non-profit organizations.  There are four dimensions that are commonly used and widely accepted: financial, customer and stakeholder, internal

 This is an evaluation of the post . Stefan has had experience as a Scrum Master, Product Owner, and Agile Coach. In reading the Q&A, there were a few interesting discoveries.  - The Product Owner should be the Number 1 person to ask about vision and strategy - Product Owner should have transparency in his thought process with the team - Product Owners are naturally resistant to pet projects. Assess the thought process if they have given the green light - Product Backlog Forensics explains a lot about an organization. Work items have expiration dates.  - Typical work items should not take longer than two sprints.  - Rejected work items must be reflected upon 

This is in response to the article . Ms. Firlit points out many reasons that companies, in adopting Agile, will fail. She lists a spectrum of reasons including corporate hierarchy, extraneous focus, passive management, lack of intention in using Agile, misaligned values, as well as politics. There are several good points, although the fact of the matter is that a lot of these companies appears to be using Agile in name but not practice.  As mentioned in the article, higher-tiered management is responsible for implementing Agile, as well as lower-tiered. The conflict of values would provide a source of friction in terms of working environment. I can see that this would be common in organizations making a transition into Agile, as their management has already well-adapted into a non-Agile framework and work processes. I think her arguments are fair, and while the intention to have motivated and motivating upper management is ideal, it would be a bit impractical to expect it. Perhaps it w