Reads on Evolutionary Organizations

I read Aaron Dignan’s Brave New Work: Are You Ready to Reinvent Your Organization? last January, and in the past week I read the illustrated version of Frederic Laloux’s Reinventing Organizations. As I read the latter, a lot of the stuff mentioned — terms, concepts, examples — felt so similar and consistent with BNW which made me think if Dignan just made a spin-off of Laloux’s work. Maybe he did, maybe he didn’t. Either way, I found both books interesting and they were both easy reads.

As for differences, I think RO elaborated more on the evolution of organizations throughout our history. It also promotes the metaphor of organizations as living systems. There were some enumerations on management structures and practices that need upgrading, but not all items were discussed in the book (but maybe they’re covered more in the non-illustrated version). The book does have companion resources including a crowd-sourced wiki that has elaborations on the stuff not elaborated in the book.

BNW focuses more on the organization’s Operating System — elaborating on the different domains or parts that make us the OS canvas. Examples of the domains (there are 12) include purpose, strategy, meetings, membership, etc. Each domain gets covered with examples and you get ideas or suggestions of what you can consider applying to your own organizations. I think BNW also offers more guidance or aides e.g., sensing tensions (78 tensions that can be used as conversation fodder), proposing practices (deck of practice cards), conducting experiments (experiment worksheet).

I made a lot of highlights in both books, and I saw several instances of me saying “interesting…” in my notes. I guess one of my favorite ones (might be trivial) is on the use of the word “fractal” in BNW.

“Like organizational purpose, strategy is multidimensional and fractal—it’s happening on many fronts at many levels. Which means coherence matters.

Say fractal and images of geometric figures with repeating patterns come into mind. A definition of fractal is “a curve or geometric figure, each part of which has the same statistical character as the whole.” To describe something consistently happening at all levels at all fronts as fractal is such a cool word choice.

Do we size bugs with story points?

I found a question posted in one of the social channels at work: How should one give out story points to bugs/defects that one does not yet know how to fix yet and requires investigation? The original question asks how but I think even before we go there it would be nice to know whether we need to in the first place. I plan to write about this in 2-parts: (1) how I might go about with it — no explanations, but based on past experiences as a member of Agile Scrum teams and what I’ve read on the topic, and (2) links and quotes galore.

How I might go about with it

  • If it’s a bug found during testing of a user story we’re working on in the sprint AND it’s small enough (implicitly sized) to be fixed within the same sprint: It goes into the sprint backlog. No need to size it. Just prioritize it accordingly.
  • If it’s a bug unrelated to user stories that we’re testing this sprint (say, from an older feature) OR it’s too big a bug or complex (again implicitly sized) to be fixed within the sprint: It goes to the product backlog. It’ll be groomed as you would with other user stories to give it enough details for the team to work with. And if it makes it way into the Sprint Planning, then size the bug.
  • Now what if the bug that goes into the product backlog requires more investigation than usual (all bugs require investigation, but in some cases I suppose devs already have an idea of how to fix it, in some, totally no idea hence more investigation is needed): Tag it as a spike (not a term in the Scrum Guide, FYI). If it goes into the Sprint Backlog, meaning the team agrees to invest time on investigating that bug within the Sprint, no need to size it.
    • For that spike in the Sprint, it’ll just mean there’ll be a time-box (1-3 days of effort) for investigating that bug. At the end of the time-box, whoever works on it reports their findings and the team can discuss the next steps.
    • Assuming the team agrees on a resolution, duplicate the bug with the spike tag. Close the original one. In the duplicate, remove the Spike label. If it’s to remain in the Sprint Backlog meaning the team will fix it within the Sprint, then size the bug. Otherwise, the new bug (the duplicate) goes to the Product Backlog and no need to size it yet.
    • But what if there’s still no resolution or identified workaround. The team can opt to extend the time-box. But at some point, you can’t just extend and extend it forever. Once a threshold is met (is 3 months too long/short?): Tag it with a label your team agrees to use on such items, and then archive it.
  • At the end of the Sprint, the Scrum Master will be able to gather the following data in case they want to use it for some forecasting:
    • User Stories – total story points, bugs per user story
    • Bugs – total story points, total number of bugs
    • Spikes – total number of Spikes worked on, total number of Spikes closed, total points from Spikes that were converted to new bugs

That turned out longer than I expected. The next part are for some links on the topic and could give you the opposing views to help you come up with your own answer.

Links and quotes galore

12 common mistakes made when using Story Points – This has a lot of other interesting points not just about on whether you size bugs or not.

  • “Story Points represent the effort required to put a PBI (Product Backlog Item) live.” So story points are not limited to user stories.
  • “Story Points are about effort. Complexity, uncertainty and risk factors that influence effort but each alone is not enough to determine effort.
  • [Common mistake #5: Never Story Pointing Bugs] “A bug which is unrelated to the current sprint should just be story pointed. The bug represents work the team needs to complete. This does not apply if the team reserves a fixed percentage of time for working on bugs during the sprint. A bug related to an issue in the sprint should not be story pointed as this is part of the original estimation.”

Should Story Points Be Assigned to a Bug Fixing Story?

  • [I think this is with respect to legacy bugs or when the team is dealing with a large database of agile defects] “My usual recommendation is to assign points to bug fixing the agile defects. This really achieves the best of both worlds. We are able to see how much work the team is really able to accomplish, but also able to look at the historical data and see how much went into the bug-fixing story each sprint.”

Should you ‘Story Point’ everything? – This is a thread in the Scrum.org forum.

  • (No points for bugs) ‘They are called story points for a reason. They are not call[ed] “Item Points”. Ideally you should only have stories in your backlog and the technical tasks should be inside…’
  • (Yes or no points for bugs) “It is critical as a Scrum Master to ensure that story points are being used properly within an organization. They serve two purposes only: to help the Development Team and Product Owner plan future sprints, and to be accumulated for done items at the end of a sprint for velocity calculation purposes. They are not a proxy for value delivery. … That said, it seems there are a number of different items (bugs, technical tasks, spikes) that have a capacity impact on the Development Team each sprint. For planning purposes, if the team prefers to not point these items, a mechanism to determine the capacity impact is still desired….”
  • (No points altogether) ‘I have found, and this may depend on your team, that removing story points entirely helps the team and stakeholders focus on the sprint goal instead of “How many points”….’

What’s a spike, who should enter it, and how to word it? Since I mentioned “spikes”, I’ve put in this other link about it.

  • “A spike is an investment to make the story estimable or schedule-able.”
  • “Teams should agree that every spike is, say, never more than 1 day of research. (For some teams this might be, say, 3 days, if that’s the common situation.) At the end of the time-box, you have to report out your findings. That might result in another spike, but time-box the experiments. If you weren’t able to answer the question before time runs out, you must still report the results to the team and decide what to do next. What to do next might be to define another spike.”
  • “It’s also best if a spike has one very clear question to answer. Not a bunch of questions or an ambiguous statement of stuff you need to look into. Therefore, split your spikes just as you would large user stories.”

Let me know if you find anything more conclusive or helpful.

Read: The Culture Code

Just finished reading The Culture Code: The Secrets of Highly Successful Groups by Dan Boyle. I read it even though I pretty much think the key to highly successful groups is having great individuals rallied together by a clear purpose and a selfless leader. That’s no secret — it’s just that getting that right mix is what’s elusive. Anyways, the book was a quick and easy read peppered with Ideas for Action (that’s literally the title of 3 chapters) on how you (but ideally your leader) can help in 3 things: (1) building safety, (2) sharing vulnerability, and (3) establishing purpose.

Actionable ideas

Be mindful of 3 basic qualities of belonging cues — Energy, Individualization, Future Orientation. So in your interactions with your team mates, invest energy by giving attention and being present in the interaction. Acknowledge the individual, don’t make him or her feel like he’s just another random person. Hint at a future, don’t make it feel like it’s just a hello and goodbye interaction.

Build Safety — We are safe and connected.

  1. Overcommunicate your listening – Start off with actually trying to listen, and hopefully your posture, expression, and whether you give a steady stream of affirmations (yes, uh-huh, gotcha) or encouragement to the speaker to keep going would shine through. If not, watch out for whether your posture, expression, reactions are conducive towards the speaker continuing to speak up.
  2. Spotlight your fallibility early on–especially if you’re a leader – Radiate humility and actively invite input with simple phrases like “This is just my two cents,” “I could be wrong here,” “What am I missing?”, “What do you think?”
  3. Embrace the messenger – When someone shares a truth especially bad news or tough feedback, don’t chew off their head. You have to make it feel safe for people to speak the truth.
  4. Preview future connection – Hmm… similar to above on future orientation. Maybe share some vision of the future that you have for the person (like if you see him or her as possibly the next great thing) or with the person.
  5. Overdo Thank-yous
  6. Be painstaking in the hiring process
  7. Eliminate bad apples – Bad apples like jerks, slackers, and downers just aren’t good for the psychological safety of the team.
  8. Create safe, collision-rich spaces – By “collision” he means serendipitous personal encounters. I guess this is about trying to increase the chances of interactions among the team. Could be as elaborate as setting up an extremely nice team area to something as simple as the team having coffee.
  9. Make sure everyone has a voice – Not just the loudest person gets heard. Everyone gets heard, and I guess what follows through is more important i.e., when it actually converts to change or action.
  10. Pick up trash – “Muscular humility”–a mindset of seeking simple ways to serve the group. Other examples could be allocating parking places, picking up checks at meals. “These actions are powerful not just because they are moral or generous but also because they send a larger signal: We are all in this together.”
  11. Capitalize on threshold moments – It’s not just in day one. In successful groups the author visited, they also paid attention to moments of arrival. “They would pause, take time, and acknowledge the presence of the new person, marking the moment as special: We are together now.” Think about it: A warm greeting to a team mate when he arrives versus not even batting an eyelash.
  12. Avoid giving sandwich feedback – Separate handling of negative and positive feedback — negative through dialogue, positive through “ultraclear bursts of recognition and praise.”
  13. Embrace fun

Share Vulnerability — We share risk here.

  1. Make sure the leader is vulnerable first and often – Recommended 3 questions for leaders to ask their people:
    • What is one thing that I currently do that you’d like me to continue to do?
    • What is one thing that I don’t currently do frequently enough that you think I should do more often?
    • What can I do to make you more effective?
  2. Overcommunicate expectations – People aren’t psychic and things don’t just magically fall in to place. “[Be] explicit and persistent about sending big, clear signals…”
  3. Deliver the negative stuff in person
  4. When forming new groups, focus on two critical moments – “At those moments, people either dig in and become defensive and start justifying, and a lot of tension gets created. Or they say something like, ‘Hey, that’s interesting. Why don’t you agree? I might be wrong, but I’m curious and want to talk about it some more.’ What happens in that moment helps set the pattern for everything that follows.”
    • The first vulnerability
    • The first disagreement
  5. Listen like a trampoline – Not just about nodding attentively, you add insight. “The most effective listeners do four things:…”
    • They interact in ways that make the other person feel safe and supported
    • They take a helping, cooperative stance
    • They occasionally ask questions that gently and constructively challenge old assumptions
    • They make occasional suggestions to open up alternative paths
  6. In conversation, resist the temptation to reflexively add value – Don’t try to end the conversation with your own solution. Let the discussion flow (except maybe if time-boxed or if the folks are going in circles).
  7. Use candor-generating practices like AARs, BrainTrusts, and Read Teaming – AARs are After-Action Review done by Navy Seals — It’s like our Retrospectives. BrainTrusts are by Pixar. Red Teaming is a way for exposing risks by creating a team to purposely think of ways to make you fail. One good AAR structure is to use five questions:
    • What were our intended results?
    • What were our actual results?
    • What caused our results?
    • What will we do the same next time?
    • What will we do differently?
  8. Aim for candor; Avoid brutal honesty
  9. Embrace the discomfort – “One of the most difficult things about creating habits of vulnerability is that it requires a group to endure two discomforts: emotional pain and a sense of inefficiency. But as with any workout, the key is to understand that the pain is not a problem but the path to building a stronger group.
  10. Align language with action
  11. Build a wall between Performance Review and Professional Development
    • Performance evaluation tends to be a high-risk, inevitably judgmental interaction, often with salary-related consequences.
    • Development is about identifying strengths and providing support and opportunities for growth.
  12. Use Flash Mentoring – Hours, instead of months or years
  13. Make the leader occasionally disappear – Not to be confused with toxic absenteeism. Given the right foundations and having set them up to know what to do, the team should still be able to perform.

Establish Purpose — This is what matters.

  1. Name and rank your priorities
  2. Be ten times as clear about your priorities as you think you should be – “Leaders are inherently biased to presume that everyone in the group sees things as they do, when in fact they don’t.” It doesn’t help when all the leader sees are nodding heads. Overcommunicate priorities.
  3. Figure out where your group aims for proficiency and where it aims for creativity – “Building purpose [for proficiency, machine-like reliability, usually for service] is like building a vivid map: You want to spotlight the goal and provide crystal-clear directions to the checkpoints along the way…. Generating purpose [for creativity, for empowering groups to build something that has never existed before] is like supplying an expedition: You need to provide support, fuel, and tools to serve as a protective presence that empowers the team doing the work…. Most groups, of course, consist of a combination… The key is to clearly identify these areas and tailor leadership accordingly.
  4. Embrace the use of catchphrases – No way, Jose. Corny. “They aren’t gentle suggestions so much as clear reminders, crisp nudges in the direction the group wants to go.
  5. Measure what really matters
  6. Use artifacts – “Their environments are richly embedded with artifacts that embody their purpose and identity … they all reinforce the same signal: This is what matters.
  7. Focus on bar-setting behaviors – Example given what about a hockey team that rallied their culture around a specific behavior they called “Forty for Forty” — it’s something that they do as part of their play and I guess it captures who they are in some way. I guess the closest analogy I can think of is for testers, we often said “Trust and verify.” Because that was really what was happening and what needed to continue happening. You have to take care of the relationship between you and the devs where you show them you trust them and you can be trusted; and that it’s not about distrust towards them when you do your checks or tests on their work; it’s because you have to do what you have to do i.e., to test.

That’s it. Summarized the 3 chapters (and I guess pretty much the whole book). Of course, the book can provide better context. Go buy it if you want, or buy me a hardcopy which I’ll gladly leave lying around in the office for sharing. Thanks for reading this far (or skimming this far, it’s ok), now maybe you can go over the list of actionable ideas again and this time look for what you can apply or explore further.

Read: Fast Times

I lucked out on getting a $0.99/month subscription to Kindle Unlimited (but only for a limited time–ironically). And earlier today, I found a new title that was just published quite recently. Coincidentally, it felt relevant because of some recent strategy/planning discussions that I’m hearing about. So I went ahead and read it.

The book is “Fast Times: How digital winners set direction, learn and adapt” by Arora, Dahlstrom, Hjartar, Wunderlich. It’s a short, easy read — finished it within half a day.

Some takeaways:

  • Speed is an outcome of deliberate actions and behaviors.
  • Emphasis on learn-and-adapt — ABL: Always be learning.
  • Bold aspirations must be matched by corresponding commitment. Tentative measures will not deliver.
  • Chapter 5 shows a few numbers illustrating how fast looks like (e.g., normal product launch is in 6 months, fast is in 2 weeks).
  • We’re inundated with how important it is to be safe to fail, BUT it’s not an excuse to say it’s OK to fail all the time. Chapter 6 supports that with its mention of “Failing is not always acceptable” with an enumeration of when it’s plain wrong.
  • “You’ve got to make sure that if you make mistakes, you learn from [them].”
  • Chapter 7 revisits the all familiar Tribe-Squad-Chapter-Guild model.
  • Chapter 13 just brings to mind how security needs to be integrated in development.
  • Chapter 14 shares the Digital Transformation Office’s (DTO) many roles — in injecting coherence to how squads are structured, in implanting importance of learning, in having visibility on what’s working (and not), in capturing, codifying, disseminating best practices, etc.
  • All that learning –especially from failing– isn’t worth much if no one can find it.

Trying to understand Design Thinking

Warning: Relatively long post, thanks to a cancelled meeting from 7AM which got me on my laptop hours earlier than usual. Jump to here to skip a lot of references.

Mention “Design Thinking” to me and what comes into mind are post-its, and the 5-phase process or cycles of Empathize-Define-Ideate-Prototype-Test. But what I’d really like to understand is what sets it apart from any other problem solving approach. Apparently, I’m not the only one because I found this in Quora: “How does design thinking differ from other approaches to problem solving or innovation?” I’ll get to that later.

Starting with definitions and differentiation

“Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.”
—Tim Brown, Executive Chair of IDEO

Googled top results

Here are today’s top 5 results when I Googled “Design Thinking” and what they essentially had to say about it. The first one’s actually an ad so I’ll skip that.

Result #1: What is Design Thinking and Why Is It So Popular? Written just 1 month ago. The take away from that article (literally, because the heading is “The Take Away”): “Design Thinking is essentially a problem-solving approach specific to design, which involves assessing known aspects of a problem and identifying the more ambiguous or peripheral factors that contribute to the conditions of a problem. This contrasts with a more scientific approach where the concrete and known aspects are tested in order to arrive at a solution. Design Thinking is an iterative process in which knowledge is constantly being questioned and acquired so it can help us redefine a problem in an attempt to identify alternative strategies and solutions that might not be instantly apparent with our initial level of understanding. Design Thinking is often referred to as ‘outside the box thinking’, as designers are attempting to develop new ways of thinking that do not abide by the dominant or more common problem-solving methods – just like artists do. At the heart of Design Thinking is the intention to improve products by analyzing how users interact with them and investigating the conditions in which they operate. Design Thinking offers us a means of digging that bit deeper to uncover ways of improving user experiences.”

Result #2: 5 Stages in the Design Thinking Process. Written 2 weeks ago. It’s more focused on the 5 stages as you would expect from the title. But in the take away, it did say: “In essence, the Design Thinking process is iterative, flexible and focused on collaboration between designers and users, with an emphasis on bringing ideas to life based on how real users think, feel and behave.”

Result #3: Design Thinking. Doesn’t really count since it seems to just aggregate items tagged as falling under the topic.

Result #4: What is Design Thinking? from IDEO U. “Design thinking is a process for creative problem solving. …Design thinking has a human-centered core. It encourages organizations to focus on the people they’re creating for, which leads to better products, services, and internal processes. When you sit down to create a solution for a business need, the first question should always be what’s the human need behind it?”

Result #5: Design Thinking from good ol’ Wikipedia. “Design thinking refers to the cognitive, strategic and practical processes by which design concepts (proposals for new products, buildings, machines, etc.) are developed. Many of the key concepts and aspects of design thinking have been identified through studies, across different design domains, of design cognition and design activity in both laboratory and natural contexts.”

Going back to Quora

Let me just try to go over the 5 available answers to the question “How does design thinking differ from other approaches to problem solving or innovation?“, and summarize them below.

  • Emphasis on “Empathy” for the people for whom you are designing for and its focus on human values at every stage of the process
  • Contrast against traditional innovation process which uses a linear funnel “Toll-gate” approach for problem solving; whereas Design Thinking is “an iterative and fluid approach that uses prototyping for continuous user feedback and engagement”
  • It’s reinventing the wheel but it comes with the major advantage that it “re engages the client with the designer as a proper process of design communication”
  • Respondent list down some attributes like “user-centric, human-centric” but then adds “process oriented”.
  • Human centered, using elements such as “experimentation and empathy to come up with inventive solutions while incorporating the people’s needs, the prospects of technology, and what is required for the success of a business”

Hmm… It’s still just problem solving

Idk. It still feels like problem solving to me. On the aspect of being human-centered or user-centered, you can’t really do away with that because a problem is a problem to someone. You can’t take that someone out of the picture when you’re trying to understand the problem, more so when you’re trying to solve it. On the emphasis on empathy, it feels like that’s a given essential when you’re trying to understand the problem space. You need to understand why, how and to what extent is it being a problem to someone.

On the aspect of being iterative and on using prototyping, it still doesn’t feel like a differentiation. After defining a problem and coming up with ideas on how to solve it, it just doesn’t make sense to jump on the first idea or run all ideas. It throws me back to grade school when they were teaching us the scientific method wherein you hypothesize, then test (which could go either way), repeat, until you come up with a conclusion based from your test results.

So does it add value?

I wouldn’t discount it as not having value. There’s way too much content out there to say it’s not valuable. And more importantly, it’s still problem solving and problem solving that’s able to bring forth solutions is valuable.

Maybe what really differentiates are Design Sprints?

Oh, no, another term. Now what are Design Sprints? It’s highly popularized by the book Sprint by Jake Knapp (which is still in my reading backlog). But a quick google search on the difference between Design Thinking and Design Sprint gave this very useful point.

‘One of the things companies are struggling with when it comes to integrating Design Thinking is that it’s more of a philosophy than a true “out of the box” method. This is precisely the value of Design Sprint.’

The value-add I perceive are:

  • Design Sprints put a time box or defines a more concrete recipe on the Design Thinking process.
  • It engages the customers — so it’s not just the designers or developers brainstorming on the problem space and solution space.
  • It allows for quick feedback — for some points, you can validate right there and then because you have customers in the room with you. No need to send out an email, and wait for a response only to realize a need for a follow up email later on.
  • It really sets the stage for a collaborative design process. With the framework, it’s clear who will be involved, what will be needed during the time box, what outputs to expect within the time box. As opposed to more traditional approaches, you don’t have to second guess whether you can talk to the customer or course it through some stringent RFI (request for information) process. It’s a given that customer stakeholders and the design team will directly interact.

Now as to how it’ll seamlessly integrate with Agile Scrum, maybe that’s for another cancelled 7AM meeting. 🙂

Reads from this morning

Trigon, this app I occasionally play, can be such a time sink. I’d say “just one more game,” then after a while, I’d realize that an hour had just gone buy and I spent it just arranging shapes to align and disappear (pretty much like my time). So I caught myself this morning just about to tell myself “just one more game,” and decided to get back into my reading in Medium. Ended up bookmarking several stuff and reacting to a few.

“Active reading — taking notes, sketching, and talking with a friend about the text — can also help forge mental connections between the information you’re taking in and what you already know, increasing your retention. This doesn’t mean passively highlighting, re-reading, or retyping what you’re reading but effortfully engaging with the text: jotting down your own thoughts, questions, and connections that occur to you, whether you do it in the margins or take notes elsewhere.”
How to Remember More of What You Read

Sometimes I have instances of “I’ve read somewhere that so and so…” and vaguely recall an idea from a book or text I’ve read. Or I’m able to connect something I’ve read about to something at work. To have been able to pull something out of the well of insights I gained from reading tells me that I do remember enough to make some use of it. With the little I remember (I admit to not having the best memory which is why I like that quote saying the mind is not a vessel to be filled but a fire to be kindled), the information and even knowledge I’m able to connect to real life has been helpful. I can only imagine how much more so if I can remember more. I’ve started doing that to some of the books I’ve been reading since September i.e., more actively highlighting, taking down notes, and occasionally putting in some lols and side comments. Whether my memory improves, I’ve yet to find out, but at least I know where to find my notes if I need them.

“A great culture can ensure you are able to do something repetitively if you have done it before. It brings sustainability. It brings certainty in outcomes.”
Well, culture DOESN’T eat strategy for breakfast!

I’m not exactly in charge of culture building at work (but I do know my behaviors, my mindset, how well I execute has the potential to contribute to the culture). Nevertheless, I found this post and the book it shared (“What You Do Is Who You Are” by Ben Horowitz) interesting — especially the little anecdotes. No PowerPoint presentations in meetings. Just kill the snake, don’t play with dead snakes, opportunities start out looking like snakes. Shocking rules. Don’t !@#% the customer as a value. Interesting.

“In late 2019, the US Court of Appeals denied LinkedIn’s request to prevent HiQ, an analytics company, from scraping its data. The decision was a historic moment in the data privacy and data regulation era. It showed that any data that is publicly available and not copyrighted is fair game for web crawlers.”
Web scraping is now legal

This just throws me back to when our team was looking into LinkedIn integration to strengthen the expert profiles in the in-house app we built. Crawling was an idea we were cautious about since we feared the legal implications (so we obviously did not go there).

Other reads from this morning before my Trigon time was up 🙂

Tech lead thinks it’s ok to skip Sprint Planning

I heard about a Scrum Master asking the Tech Lead to provide a heads up in advance in case he won’t be able to attend their meetings (in this case, it was their Sprint Planning). The Tech Lead said that his absence shouldn’t affect the Sprint Planning since the team would just be doing estimations (deduced meaning because the original reason he gave out didn’t make so much sense).

True that his absence shouldn’t keep the Sprint Planning from happening. But the Sprint Planning is not just about estimations. More than anything, it’s about alignment.

So what happens in a Sprint Planning? At least from my experience (affirmed by and sprinkled with some stuff I read about from Kniberg):

  • The team goes over the potential sprint backlog items from the Product Owner — sizing and discussing the stories, breaking them down further if needed, adjusting the prioritization if needed.
  • The team brings up any other technical user stories that need to be prioritized.
  • The team / Scrum Master brings up any user stories or improvement items from the retrospective that needs to be prioritized.
  • The team gets informed of any critical dates or targets that they should be mindful of in the sprint.
  • The team agrees on the following:
    • Sprint Goal
    • Sprint Backlog (defined as not just the list of stories, but also including a “plan for delivering the product Increment and realizing the Sprint Goal.”)
  • The team aligns on their availability (e.g., planned leaves, out of office dates for training, etc.)

So there. To me what’s essential about the Sprint Planning is starting off the sprint at the right foot with the team being in the same page. Ideally, it’s coming out of that meeting not feeling defeated (oh, no, we’re dead, we have an impossible deadline) but rather feeling united and empowered (we can do this).

Retrospection and learning time

Just recently, my engagement to my project since Nov of last year has ramped down. So the past couple of weeks has been a time of transition for me into my upcoming project and also from me to the new PO of my previous project. This allowed an opportunity for retrospection, and also a chance to pick up on new stuff.

While looking up the available knowledge sharing platforms within the company, I came across the option to host stuff in our enterprise GitHub instance. One link led to another, and I came across…

  • MkDocs – This is for project documentation; it allows the use of Markdown for writing content, and then you generate static site contents from that.
  • Documentation as Code (docs-as-code) – While I’m not a programmer, getting familiar with the concept wouldn’t hurt. And as I read more, it’s not really exclusive to programmers.
  • Diagrams as Code with Mermaid – Part of the family of stuff-as-code, this doesn’t trail far behind. I think what I find promising about this (apart from being free) is that this is going make comparison of versions easier since you’re comparing text files.

As mentioned, I did some retrospection. I collated some of my personal lessons learned and posted it in our project’s Confluence page. I also revisited Software Development’s Classic Mistakes. I tried rereading The Scrum Guide and some stuff on anti-patterns to see where we’re somewhat deviating (for guidance if it’s something we should continue or if we should “realign”). Then I tried to pull out project-agnostic stuff that could be helpful to me for starting a new Agile Scrum project and collated my notes.

With the notes in hand, I’m starting to use it as a reference for the new project, and I plan to just tweak accordingly as I find other useful stuff to add in. At this stage, there’s already a team working on the prototypes, and in theory, they’re prepping the solution or the design which will be handed over to the implementation team. So I’ll be keen on learning a lot more and looking for process improvements for the handover from Design Thinking to prototyping to implementation. Exciting stuff! 🙂

Highlights on “It Doesn’t Have to be Crazy at Work”

I was just looking for something to read in the hope of finding something to help myself with some of the stress at work. I came across this book by Jason Fried and David Heinemeier Hansson — published 2018, with 4.6 out of 5 stars from 114 reviews in Amazon. They’re actually the same authors of another title I was initially looking at, “Rework” — published 2010, with 4.5 out of 5 stars from 1280 reviews. I opted to go with the former just because the title seemed more relate-able.

Overall, the book was a quick and easy read. Started reading it late Saturday (nearly Sunday) and finished it Tuesday morning (not one sitting). There were indeed points that were relate-able but maybe for the most part it’s better geared towards management or folks who can really influence change. The last chapter did come with some sort of message in case “you don’t have the power to change at the company level” but really, mostly it’s for those with the power to change at the company level.

Sharing here some of the stuff I highlighted in the book…And there were a LOT of highlights I’ve noted…

Continue reading

Them product management links

Been bookmarking and clapping on several posts in Medium lately on product management. Thinking of consolidating them here for future reference.

What it is or what it’s not

Getting started

Taking care of the backlog

Capability assessment or building

Trials and tribulations

PO anti-patterns