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! 🙂

Notes from webinar: Write Better User Stories…

Last week, I attended a free webinar by Mike Cohn of Better User Stories on the topic of “Write Better User Stories in Less Time With Less Aggravation”. Right after, I shared the replay link to some colleagues along with a few bullet points of pros and cons.

(+) interesting, maayos explanation
(+) ok din yung q&a
(+) insightful naman, gives you something to think about, stuff to google further
(-) promotional, the whole course is expensive $395

Posting my notes here since the learning from the webinar is something worth revisiting.

3 Techniques

  1. Conduct a quarterly story-writing workshop
  2. Split stories to demonstrate progress even if the result is not truly shippable
  3. Strive to add just enough detail, just in time

Technique #1: Conduct a quarterly story-writing workshop

  • Deliberate, focused meeting
  • Brainstorm the stories needed to achieve the period’s most important goal
  • Short-term focus causes teams to give in to what’s urgent over what’s important
  • Team able to step away from day to day crisis… Without that big goal, the crisis always wins

Focus on a single objective

  • “What shall we build?” — Wrong question, too broad, anything is fair game
  • PO selects the significant objective (SO)
  • SO typically achievable in about 3 months
  • MVP, sometimes overused, seems can only be used once
  • MMF = Minimum Marketable Feature = subset of overall feature that delivers value when released independently, smaller than MVP

Involve the whole team in writing stories

  • Time investment, pays back on time savings when team works on the user stories
  • They’ll have fewer questions later, they’ll have more context
  • Fewer interruptions to devs’ day
  • Devs may come up with better implementation, increased creativity

Visualize user stories with a story map

  • Story maps invented by Jeff Patton
  • Each card = 1 user story (1 thing the user needs to do)
  • Horizontally = sequence of activities (don’t obsess over combination of sequence at this point, some steps may be optional)
  • Vertically = alternatives (with most important on top)

Technique #2: Split stories to demonstrate progress even if the result is not truly shippable

  • 90% joke – Ask dev how done are you and he replies 90%. Come back after a week, and answer is still 90%.
  • Devs are not evil or liars, Estimating how done we are with something is notoriously difficult.
  • In Agile, easier, no need to estimate. Just 2 states = Not started or Done
  • 5 techniques for splitting stories (Lookup SPIDR), shared in the webinar were Splitting by Interface and by Rules
  • When you split stories remember the goal is to be potentially shippable — (1) high quality, (2) tested, (3) what it does, it does well

Technique #3: Strive to add just enough detail, just in time

  • Too much detail, too early vs Too little detail, too late
  • Bad habit – want to know all before starting — when they do that they’re not doing overlapping work (analysis first, before coding, testing…). Overlapping work is central tenet in most Agile processes (that’s why we don’t have phases in Agile). Time to market gets stretched.
  • Err on the side of too little, too late — you can improve by adding more detail next time
  • Question 1 (during refinement or other discussions on a user story): Do you need the answer before you start on that story? Sometimes you need it before you finish work on that story, not before you start.
  • Question 2 (during retro): Did we get answers just in time in just enough detail?

Reference / links:

Reads: On skills for Product Management

This morning’s read tried to capture the job of a PM into 4 words: “Figure out what’s next.” I think in the work we do in building software (regardless of what your role is in your Agile project), we have to do a lot of figuring out. Coming with ideas or solutions independently is so important, and so is working collaboratively to further refine those solutions. Although it’s important to differentiate when it’s collaborating from spoon-feeding or unnecessary hand-holding.

Anyways, the post also enumerates 7 core skills to build for the Product Management role (actual text from the post are in bold, elaborations that follow are mine). But regardless of what role you are in the project, I think these contribute to being a good team player.

1. Taking any problem and being able to develop a strategy to resolve it — When you’re in the business of building software, figuring things out (preferably independently, with little to no hand-holding) is a critical skill.

2. Executing, getting shit done*in any role, this is valuable*

3. Communication — *same… in any role, you need this*

4. Leadership through influence

5. Making decisions, informed by data

6. Building great products, and having taste — As PM/PO/PPO/BA, you work closely with your designers. I think you also need to brush up on UX so that you don’t undo any of the good work your UX designers present to you for your feedback.

7. Always be prepared — *important for any role* I like the quote the author shared.

[Great PMs] say what they’ll do, and then do what they say. Their follow-through is impeccable, and they don’t let details slip. When they join a team, quality and pace seems to dramatically improve overnight.
— Noah Weiss

And I couldn’t agree more with his recommendations for developing your “I got this” aura. Over the years, I’ve worked with a few folks who would sound like they’re so unsure of what they’re doing. It just doesn’t bode well — it doesn’t give the team (or worse, their stakeholders) confidence that they’ll get the work done. I mean it’s OK to admit that you don’t know everything, because no one does — even “experts!” And it happens, I’ve gotten into countless of interactions where I really have no idea on what to do. But I guess my confidence (or my display of not panicking) stems from knowing that I have the capability and means to figure it out. (And that it’s not the end of the world if I don’t.)

So anyways, I’ve rambled on. Go check the post for the recommendations!

Busy-ness

I saw this title in Medium – Being ‘Busy’ Doesn’t Mean You’re Successful – and had the feeling that I was going to pretty much agree with the content. And I was right. I’m really not a fan of being busy – Especially of being fake busy or of perceiving busyness as a sign of importance or, as the post mentioned, of success.

I looked back at an older post (from nearly 9 years ago!!). And I’d just like to reiterate some quotes and links. Who knows, maybe 9 years from now, if I happen to be swamped or overwhelmed at work, I’ll need a gentle reminder that there’s more to life than being “busy”.

  • “It is not enough to be busy. So are the ants. The question is: What are we busy about?” – Henry D. Thoreau
  • The Cult of Busy (Mar 2010, Scott Berkun)
  • You’re Only as Busy as You Want Yourself to Be (Jun 2009, Jurgen Appelo)
  • Being ‘Busy’ Doesn’t Mean You’re Successful (Jul 2019, Darius Foroux)
  • Derek Sivers’ notes to “A Guide to the Good Life: The Ancient Art of Stoic Joy” by William Irvine
  • “A good man will not waste himself upon mean and discreditable work or be busy merely for the sake of being busy.” – Seneca
  • “To live is the rarest thing in the world. Most people exist, that is all.” – Oscar Wilde

Keep the Backlog clean

I just mariekondo’d our backlog. So far, so good, I’ve removed 85 items from the backlog — 53 of which were over 200 days old! My thinking is if we won’t be touching them anytime soon or at all, I want them out of the backlog.

Idk but some lessons to share or possibly reminders to my future self here…

  • Get to know your tool – Find out how you can “archive” user stories that you want shelved, and also how you can access the shelved items in the future just in case you need to. Until recently, my options in the tool was limited to either delete or mark as done (which I didn’t want to do for items we won’t actually work on). We then found out that we can do project customization in the tool contrary to what we’ve been initially told, and so I’ve tweaked the workflow to also consider user stories that I want shelved.
  • Housekeeping keeps the backlog tool more usable – At some point, it was hard to move things around the backlog because of too many useless items that cluttered the list. Having a lean backlog also makes the items we actually need to work on more visible.
  • Maybe it shouldn’t be a list of wishful thinking, or a place for idea dumps – And TIL, using the backlog as a storage of ideas is a Product Backlog Anti-pattern.
  • Keep it aligned with the roadmap – Again, (“The product backlog is not reflecting the roadmap.”) another anti-pattern. I guess in conjunction with the previous item, a lot of the user stories that I cleaned up were raw ideas that they had wanted to build “someday”. Keep it real by keeping the backlog items as a list of things the team will actually work on.
  • Avoid / minimize duplication – For some reason, if a user story has to be kept duplicated, ensure they are linked to each other. The risk of duplication is in case of refinements, updates might be made on just one of the user stories when in reality you want it to be carried out across all.
  • Do periodic cleanups – This clean up is not and should not be a one time thing to keep the backlog relevant. An idea I picked up here is about setting a limit to your Design in Progress (DIP) or the number of items you have in the backlog.
  • Be mindful of what you add in the backlog – You don’t want the backlog items to keep growing and growing and revert back to a state you find less desirable. And an idea I picked up here is about setting a limit to your Design in Progress (DIP) or the number of items you have in the backlog.

So there, future me, keep the backlog clean. Keep it useful not only for yourself, but more importantly, for the rest of the team.

Something to google: Sprint 0

There was an interesting topic while a couple of colleagues and I were on our way to buy coffee. It was triggered by a question about Sprint 0. Based from my limited working experience, Sprint 0 is like an initiation phase wherein the project gets set up. Dev environments get set up. First set of epics and user stories are created. Some initial designs get created. Project team members get on-boarded. Working agreements get defined. Collaboration tools like where to capture user stories and clarifications get finalized. Etc, etc. Basically, the team buys itself some prep time so that they can hit the ground running by the time Sprint 1 comes — ideally, by then, the team could commit to completing user stories and actually have features working at the end of the sprint. But then I thought, we don’t necessarily release anything after Sprint 1, so would calling Sprint 0 “Sprint 1” make any difference?

Idk. Maybe there’s this extremely high expectation about being or switching to Agile that makes it feel like you’re doing it wrong if you don’t have anything visible to some of your stakeholders by the end of a Sprint N. Being part of the development team, I know that infra setup is important, design work is important, all those other prep work are important. I know how 2 weeks could so easily fly by without seeing something that an end-user could potentially see. But to someone outside of the development team who might not be so familiar with Agile, they might have this extreme notion that “Hey, you’ve just completed 2 weeks! Where’s my working software?” And so maybe project teams resort to having a Sprint 0 to “protect” themselves or the concept of Agile to better manage expectations. Idk.

I went out of that conversation thinking that’s something I’d google. Just a few of the interesting stuff I found, and I’m sure I barely scratched the surface:

  • Sprint 0 (forum topic) – there’s mention of using Sprint 0 as a crutch
  • Scrubbing Sprint Zero – apparently, there’s no official “Sprint 0”; there’s the idea that it’s an anti-pattern; it’s been discussed by Agile Manifesto signatories all way back in 2008. I loved the Alistair Cockburn (often pronounced like “Co-burn”) quote:

I have a sneaking feeling that someone was pressed about his use of Scrum when he did something that had no obvious business value at the start, and he invented “Oh, that was Sprint Zero!” to get the peasants with the pickaxes away from his doorstep.

… and then others thought that was a great answer and started saying it, too. … and then it became part of the culture.

  • Sprint Zero: A Good Idea or Not? – there’s mention of the “project before the project”; and it links another post about using scrum for an analysis project whose output is not necessarily immediately working software
  • Antipattern of the Month: Sprint Zero – Lol, that quote: “Sprint 0 is like Casper, the friendly ghost. Well-meaning, but creepy.”

And, that’s all she wrote! Time for bed!

Wondering how much it matters: initial load of page

Background: I found that when I accessed the home page of one of the apps our team was working on, there were around 1000+ requests and over 10MB transferred in a span of 10 minutes (and it was still going). On screen, what’s visible is just the login page.

After they’ve fixed it, I went ahead and checked our current apps in the test environment. Just a disclaimer though — I’m not a performance tester and I just gathered the info I got via Chrome Dev Tools.

AppRequestsTransferredFinishDOM Content LoadedLoad
App 1503.6 MB2.6 min28.4 s48.69 s
App 2301.9 MB19.06 s11.12 s12.35 s
App 3413.6 MB26.95 s7.52 s12.52 s
App 4181.7 MB9.41 s3.93 s9.41 s
App 514742 KB3.17 s1.36 s3.18 s

3.6 MB and all that’s visible is the login page?

That prompted me to then google what’s the average out there. I’ve come up with a bunch of interesting results that’ll most likely make up my weekend reading:

Feel free to suggest in the comments section if there are more relevant references I could also look into. Thanks!

Oh, those calendar invites

I keep getting these calendar invites from the recruiter to conduct interviews outside of the schedule I’ve aligned I could be available. Actually, I only aligned for January, but I’m still getting these invites these February but that’s beside the point. Anyways, numerous times, I’ve declined and informed them I’m not available, and I’m only available at so-and-so times. Still, they keep sending those invites. I’ve already come up with a template in my decline response. So I just keep on declining and sending that template reply.

And I’m reminded of that Peter Drucker quote:

“There is nothing so useless as doing efficiently that which should not be done at all.”

That I’ve come up with a minor shortcut is pretty useless when what should be addressed in the first place is their scheduling problem. I think it would help more people (or at least annoy fewer people) if they fix that.

On the other hand, I’ve given feedback, I’ve shared my availability. And I’m pretty sure others have as well. But unless they’re willing to listen in the first place (receiving the email with the feedback != listening), there won’t be any change.

Your presence is required

TL;DR: Presence is such a driver in how much someone can offer value and how good the quality of their interactions are. How much you can give (or get) out of an interaction depends on how present you are.

A couple of things got me started thinking about presence. One was this instance in a brainstorming session. It’s a brainstorming session so as one would expect there are a lot of inputs and feedback being shared. It’s anything but a passive activity. But then there was this guy who appeared to be doing admin stuff  — email and maybe some approval of overtime work. He didn’t end up joining any of the breakout groups which maybe why he wasn’t actively listening in the first place. It feels like such a waste though — to be there and not contribute, to have such potential to contribute (being a senior guy and all) and not contribute. This also just goes to show that your actual presence — not attendance, not just being there, but being engaged in the discussions — plays such a big part on how much value you can contribute.

Then there’s this other thing. A friend shared that her colleague was in a one-on-one meeting with her manager and her manager dozed off. Turns out, the same thing happened to my friend wherein the same manager fell asleep during the meeting. That’s a one-one-one meeting — a venue for you to raise your concerns, share successes if any, or just give relevant updates; and worse, there’s only the two of you in that meeting. Just how unimportant do you think that made those employees feel? Again, presence is such a key thing in the quality of the interactions.

Just to be fair, I don’t know their side so they might have some valid reasons, and I can’t really make excuses for them.

Now, useless meetings isn’t a new and rare thing (sadly) as there are memes and mugs on how a meeting could’ve been an email. But I’m not saying this to shift the burden or blame inattention to the organizers of the meeting. One one hand they do have that responsibility of making sure they get the right people into the meeting to make sure it’s relevant to attendees. But on the other hand, it’s really up to the attendees or participants how much they can give and get out of the meetings they attend.

So long story short: if you’re in a meeting (or more so in a conversation), and you can improve the conversation or you have the potential to add value with respect to that discussion, please try to do that starting with being actually present.