Category: Uncategorized

Get your priorities straight

Featured

Channel your inner Leslie Knope or Amy Santiago and grab your favorite post it notes or flash cards.

booyah | Leslie knope, Amy poehler, Knope

1. On each card write out everything you have to do this week, seven days.

2. Now lay out all those cards so you’ve got a good view of them all and ask yourself the following questions: what has to get done? What would be nice to do? What has to be done today? As you ask the questions, you probably are rethinking some of those things, right? Do you really need a Target run or would it be great to sip a Starbucks and wander the aisles aimlessly listening to your favorite podcast?

Writing out the tasks helps to visualize and move things around in priority.

3. Next with those same cards, what if you only had 1 day to get anything done? Can some of those cards wait? Could you get more done in 1 day vs 7?

Congratulations! You’ve just gone through a prioritization exercise! We prioritize everything in our lives, what we do, where we go, which party to attend, which stores to run to for supplies, which chores to do. Why should work be any different?

There are dozens of prioritization methods and measurements out there that you can use. Some are more financial focused, some are business value focused. No matter what method you choose, choose the one that works for you and your team.

Seeing everything out can help you start to group similar items and recognize themes

Here are some prioritization methods: MoSCoW, Backlog Grooming, WSJF, story mapping, QFD, and so many more. My go to is the MoSCoW method, it’s an acronym broken down in the following way: Must have: these items are must haves for companies, customers must have it in order to sell, use, buy, you name it, it’s in. Should have- these are features or things the product should have to make it more useable, more buyable, etc. these are close follows to should have but in the event of money or budget constraints when something’s gotta give, these sit out. Could have- sure, the coffee maker could have two hot pots for two mugs of coffee, but it’s not absolutely necessary, lower priority or easy backlog candidates. Wont have (also ‘would be nice have’ for POs who like to say gentle nos): strong POs can say no easily, but back it up with metrics, stats, business objectives, levels of effort, etc…, nicer POs can say these items would be nice to have but offer no particular value, as in no one would notice of it wasn’t in there, and few people would use it/like it, even if Bob in sales wants it.

Prioritization is not done in a vacuum, but if you find yourself having to prioritize a series of stories or bugs or projects, consider a method above or try a bunch of different ones that work for you, your team, or your company. At the end of the day, it doesn’t matter how you get there, only that you do get prioritized.

If the Nine-Nine was a Life Coaching Center - The Happy Sensitive
Make it official with a binder (or the digital binder of confluence, both are good)

Tl;Dr: pick a method that works for you to prioritize your time, your team’s time, and try out MoSCoW, hey it even has it’s own theme song ;).

There aren’t enough dried pineapple slices: Agile Transformations and Corporate Fads

Featured

Way back in my early product days, the company I worked for rolled out perk after perk for employees: omelet day, all-you-can-encouraged-to-drink happy hours, catered lunch and learns, summer hours, the works. One of the lesser perks was a dried fruit and nut bar. When the young company polled it’s equally young employees, the number one feedback was there weren’t enough pineapple slices in the dry food bar and it was really affecting morale. DiD tHe ComPaNy EvEn CAre?

A Guide to Dried Fruits: Varieties, Tips, and Recipes | The Vegan Atlas
Not Enough!

Free food as a perk was all the rage at the time and companies were eager to deliver the latest fad to their employees. In retrospect, the dried fruit bar was short lived and was replaced with beer bitch Fridays and luau themed holiday parties. Corporate flavors of the week come and go but the general idea remains: how does a corporation motivate workers and improve processes? This agilest submits the latest corporate fad for review, one considerably more expensive than dried pineapple slices: Agile Transformations.

A Fad is an intense and widely shared enthusiasm for something, especially one that is short-lived and without basis in the object’s qualities. The “Agile Transformation” is anything but short-lived. Transformations take years to undergo and are extremely costly and time consuming. I’d argue that Agile Transformations are even more difficult as it’s not about making people go faster or produce more, it’s about being more deliberate and smart about what work is done, how, and when, and most importantly by whom. A great agile leader once told me that above all Agile is a mindset, one that everyone must adopt to be successful.

Dilbert saves the Agile day – Agitma

Many corporations have the capacity and desire to go Agile but where corporations have failed is in the implementation. It’s not a thing you can pluck off a shelf and install. It takes executive buy in, consistent trainings, incremental improvements to people and processes, and a lot of time and money. Results of any investment in Agile can take years to see, even though employee morale and team engagement might be up and bought into it (as a good quality of Agile is teaming and focused projects and objectives). Instead companies think Agile will be their magic wand and solve all their problems. It’ll be easy! They said. It was help us do more and go faster! They said. Narrator: They were wrong.

Agile comes in many different flavors and spices these days: Scrum, Kanban, SAFe, Agile OG (not a thing…yet). Another new big box Agile solution pops up claiming to have all the links worked out. But no matter what flavor you prefer there’s a similar ingredient to all: Agile was meant to mold to what works for a team, an org, a corporation. If you look at the Agile Manifesto‘s values and principles, it strives for simplicity and common sense, and serves as the gospel for this entire Agile genre. But like any Fad, the manifesto could be over as it approaches it’s 20th anniversary this year. The again, with the prevailing call of humanism emerging from workers of all generations in today’s corporate world, Agile is a compelling and alluring concept, even if it is still elusive. it could see a revitalization if corporations get their Transformations right, or at the very least make a concerted effort.

Time will tell whether this Fad is here to stay or not. But take a look at job postings and in your own org to see the signs or rumblings of “Agile Transformations.” Some companies will adopt the mindset and really be truly Agile. But those corporations that fail know that if and when they fail, they can always buy more dried pineapple slices to improve company morale.

Fun Phone GIF by Sylvia Boomer Yang - Find & Share on GIPHY
Pineapples…so hot right now.

When nobody has time for that…and how to combat it

Featured

It goes without saying that the roaring 20s 2.0 stopped many things in its tracks. The one thing it didn’t stop was the daily grind and hustle of work. Like a flapper on speed, work only seemed to intensify; hours became longer, days off were in short supply, and the thin line that separated work life balance dissolved. What we all collectively seem to realize is time is a precious commodity, and an absolute necessity, especially in the workplace.

COVID-19: Navigating life in quarantine, one Schitt's Creek GIF at a time | India Development Review

In Product, time is inextricably linked to another element in the lifecycle process. When there is not enough time, something has to give, be it key features, budget, or unrealistic expectations. Product is not grey area, it’s negotiation, compromise, and a healthy dose of realism. Here are some of the most common time constraints I’ve observed where time + insert-lifecycle-step converge and how to combat them:

  • Project goals + time: Goals and deadlines will almost always cause time constraints. When a project objective has to be met (whatever the reason), prioritization of features or fixes is key. In short, you want to meet that Q3 deadline, this is all we have time for the meet all the project milestones.
  • How to combat this time constraint? Know the projects goals, sub goals and how they rank. Maybe hitting the deadline is more important than delivering everything originally desired/in scope. Knowing the project goals and what the business and stakeholders want to hit will help to prioritize the most important features or fixes that align to those goals and also which blocks can be cut out if needed.
  • Budget + time: More often than not, budgets will dictate what can be in scope and out of scope of a project. Maybe there is not enough time to get more funds or money must be used within a certain time frame such as a quarterly end or fiscal close, but it tends to be “here is how much money I have, how many bells and whistles will this buy me?”
  • How to combat this time constraint? Know what the budget is and who are the major line holders. How much budget is allocated to people vs resources? Does the budget reflect the amount of work estimated? What features or fixes does the budget cover? Knowing what budget is allocated will help to trim potentially expensive and costly feature and allow for more to be in scope.
  • Prioritization + time: What people want to see from a product is not always in the cards (see project goals and/or budget). It takes time for product to meet with stakeholders, research markets and product landscapes, roadmap, and storymap, and requirement breakdowns.
  • How to combat this time constraint? Use the prioritization methods that work for you. The business or your team might have a model that works for them but there are dozens out there: Kano, MoSCoW, Quadrant, etc. Knowing what’s always top of mind and what ultimately is most desired sought after, and more importantly why they are most desired and sought after, will aid dramatically when time is of the essence. In other words “knowing what we know today, here are the biggest must haves today” will be the best asset when time is constrained.
  • People + time: Did you know that people only have so much time to give? Really, corporate daddies, it’s true! People only have two hands and so many hours in a day to meet, ideate, plan, work/produce, etc. People need time to not only recharge physically but also mentally. People should never be expected to produce at 100% every single day, especially when work gets in the way.
  • How to combat this time constraint? Take your lunch hours, your vacation time, your mental health days. Encourage and allow your teams do the same. Countless studies have proved that healthy people work better and ultimately produce better. Be sure time for these activities is accounted for in budgets and project plans because if your people go, you lose a lot of time trying to bring newbies up to speed and get back on track. Work will always be there so take the time you need to be healthy and well, deadlines, budgets, and all be damned.
  • Ideas + time: I debated about this one but it needs to be said- people need time to create and think of new ways of doing things. At the very least, people need time to process the copious amount of meetings, data points, analysis, and feedback and synthesize it into a tangible and easily distilled idea. If you’re into brainstorming, you know the number one thing you need? Time! Brainstorms don’t always produce quality ideas so time is absolutely needed.
  • How to combat this time constraint? Appreciate people’s time. Not everyone in the business is afforded it with deadlines and marks to hit, and not everyone thinks creatively on an 8-5 clock. Also allow yourself time to decompress and especially sleep. Some of the best ideas and thoughts come from minds drifting off to sleep or after having a restful night’s sleep. Best way to combat this time constraint is to take as much control over your time as possible and respect other’s time to do the same.
Maxine Waters Reclaiming My Time GIF - Find & Share on GIPHY

Time ultimately is a social construct. Not everyone or everything is meant to work within tight time confines. The best developers I know work best around midnight. Problems can be solved and lessons can be learned, ideas can be born and beautiful products can be created. All we need is the time.

If time cannot be bought, and it’s the one thing we don’t get back, then following that logic we should know time is precious and use it well and realistically.

Featured

Retro in the New Year

Happy New Sprint everyone! What? You don’t celebrate the start of a new sprint? How about the start of a project? Well I for one want to advocate for it! While there might not be confetti, or champagne, or hats emblazoned with a sprint number, the start of a sprint is a fantastic time. Beginnings also symbolize a fresh start, a reset, an opportunity to try something new or validation that everything is going great. In Agile, these fresh starts are thanks in large part to one of the key ceremonies in Agile: the retro.

Retros give a forum to reflect on a period of time collaboratively

As 2020 approached, you probably reflected on your 2019, the good and the bad. Maybe you didn’t take those guitar lessons and want to try again in 2020. Maybe you want to test those new Spanish skills you learned during spring break in Mexico this year. Or maybe you decided 2019 didn’t deserve any attention and best to move on and focus your attention on 2020. Well done! You just participated in a retro! Retrospectives are simply a way to look back on what occurred in a past set of time (for example a project or sprint of work) and determine what could be improved.

There is no wrong way to retro! Like most things agile, retrospectives can be molded and defined by the team that is holding them. Here are some more commonly used retro styles and my recommendations for getting started:

  • 4 Ls: Loved, Liked, Learned, Lacked
    • As team members bring up a topic they’d like to discuss, utilizing this method can help them to shape and categorize the reflection; a Product Owner loved the team’s demo, a Lead Dev liked how meetings were succinct and to the point, a Junior Dev learned how to troubleshoot a common merge conflict, and maybe the team as a whole lacked time or clarity on stories. Whatever the topics raised, this method can help shape the retro in a constructive and easy to bucket way.
  • The Good, the Bad, the Ugly
    • For the movie buffs out there, this homage to Clint Eastwood. Like the wild west, it’s more to the point and doesn’t try to sugar coat the negatives, in fact it’s where this style tends to focus. Maybe it was good the team met regularly, maybe it was bad the project manager didn’t attend, and maybe it was ugly that UAT happened in production because the marketing team wasn’t available. You can categorize all the topics raised and then provide some quick outlaw justice to discussing them and moving forward.
  • Start, Stop, Continue:
    • A basic format for retro, this style simply allows for a forward-thinking collaboration of what a team wants to start doing (that they weren’t doing before), stop doing, and continue doing. A Team Lead wants to stop doing early morning demos, a Business Analyst wants to continue to have product backlog refinement meetings, and the Dev Team wants to start doing hack-a-thons. This method tends to focus more on the outcomes the topic raised vs. the topic itself, and is a good entry into retros.

No matter the style, the purpose of the meeting is for a team to get together and reflect on the work that was done. The takeaway from this event should be a collective path forward and a desire to continuously improve, whatever the focus of the team is. Agile mirrors our lives which is why it’s a great methodology. Agile also presents more opportunities to start fresh as retros tend to be follow the end of a sprint which can range anywhere from 2-4 weeks; thus improvement doesn’t require a full revolution around the sun.

So the next time you find yourself post retro, at the start of a new sprint or a new project, celebrate it! (Preferably with champagne and confetti).

Party like it’s 2020

Happy retroing!!

Failure vs. Fault

Recently, I’ve been ruminating far too much on mistakes I’ve made. Replaying scenarios in my mind, thinking of what could have been done differently, rather than focusing on how I can improve and move forward. Soon after my own failure, I watched someone I love go through a similar internal crisis, they made mistake. I coached, consoled, and encouraged them to learn from it and move past it. As did everyone around them. They bounced back and moved forward with the same confidence as before. They made a mistake, but wasn’t overthinking it. So what was the difference between us? We both made mistakes, we both acknowledged our failure and wanted to move forward positively. So why the overthinking?

“To err is human, to forgive, divine.” -alexander pope

Failure, after all, is a necessary and often unavoidable part of life as countless quotes, Ted Talks, tech giants, and motivational speakers will tell you. For me it was not the mistake, not the failure that was the most difficult to process, but the focus on fault.

In software testing, there are three distinctions between failure, fault, and errors.

  • Failure: a difference from the expected result
  • Fault: the cause of the failure
  • Error: the mistake which caused the fault to occur

Let’s say you were typing too quickly and spelled something wrong in an email, this would be the error. The fault would be you dismissed the spell checker. The failure would be you sent out an email that had spelling errors. We all have examples of this, some are just more impactful than others.

I believe the difference lies in where teams focus their energies. If it’s on the failure, the team will often focus on the problem and look into how to solve it. The team might reference the fault and error but rallies to get it fixed, fix it, and move on. Perhaps it’s brought up in a retro meeting but it’s acknowledged and the team moves forward, much like my loved one and his team did.

In my case, leaders and team members continued focus on the fault overlooking the failure and the path forward entirely. When a team focuses on the fault, it’s looking at the wrong point. The fault is often inextricably tied to an individual who either caused or overlooked an error. “To err is human” after all. The team that digs into the fault can quickly dissolve into subjective rather than objective rhetoric. “Why’d that happen?” “Why did you do that?” “What were you thinking?” This focus on fault does nothing to move the team forward or move past the failure. Rather it seeks to find fault, point or deflect blame, and fails to acknowledge the failure.

In my experience, high performing team members know when they make mistakes. They’ll actively seek to fix them, with or without help, and desire to make amends and move past it. Leaders and team members who focus on fault can indirectly cause a rift and can negatively impact morale. Miscommunication can also happen when two parties or groups are focusing on two different parameters. So how do you move past it?

Focus on the right things

  1. Acknowledge the failure. We all make mistakes, the faster it is acknowledged, the faster the fix can be remedied.
  2. Align your team and leaders on the focus on their attentions. If they are focusing to much on the fault, simply accept the fault and try to refocus their energy and attention to the failure a d path forward. Often people will follow this lead if it’s well thought through and acknowledged
  3. Accept what happened. You cannot change what happened, you can only learn from it. We are our own biggest critics and high performers will always be more critical of their actions than anyone else. We often need to forgive ourselves more than have others forgive us.
  4. And finally, move forward even if others won’t. You can be on the last row boat on a desert island and some people will still not get on board. So is true with fault. Just because others focus on fault doesn’t mean you have to. Keep moving forward.

Winston Churchill once said, “Success is not final, failure is not fatal: it is the courage to continue that counts.” So don’t be like me and ruminate too long on your failures but strive to be better, benchmark yourself, and know where failure leads, success is sure to follow.

You Can Do It- Motivational Monday

What is it that makes us doubt ourselves? When we think about our accomplishments or our successes, why do we downplay them? Humility is one of the traits of great leaders but it can also hold us back from celebrating our successes, stepping out of a comfort zone to try something new, or simply by continuing to get out of bed and get to work each day.

Bet on you, this week, and every week

This Monday, whatever the week has in store for you, tell yourself that you CAN do it. Tell yourself that you’re awesome, and successful, and fun, and kind, and all of the traits that make you the remarkable you that you are. Then this week, take the time to acknowledge and recognize all the small things that you did well, or completed, or just feel like you gave it your best effort. These are worthy of celebration!

Stepping out of your comfort zone can you take you to unimaginable heights.
Rocky Mountains, 2017

Motivational jam of the week: You can do it

Motivational Ted Talk: Celebrate your success

Happy Monday!

About Friday Releases

For the sake of team happiness, work-life balance, and general PO sanity, this is your friendly reminder to not release on Fridays.

In my experience, there is rarely a large enough bug that would not be caught during the week during daily stands and regular huddles. Unless patching is a weekend hobby, spend your Friday evening having a drink with the team and cruising into the weekend.

Ecto-Cooler 90’s throwback cocktail, like, totally!

Have a great weekend!

The Candy Debate; Your Next Agile Team Building Exercise

Post-Halloween is a candy sale bonanza. Couple sweet deals with the start of shorter days, colder weather, and the long anticipation of holidays, this is an excellent time to take advantage of some team building activities to boost morale and some agile skills. I introduce for your agile consideration: The Candy Debate.

The goal is simple, team up with fellow candy lovers in your designated candy of choice, and work together to debate why your candy is the best. What do teams get out of it? The power of debate cannot be understated. Multiple soft skills are exercised during debates that are critical to agile; constructing thoughts and presenting ideas confidently and concisely, working within boundaries both categorically and time-wise, and working together with a team to synthesize multiple viewpoints and ideas. 

And why candy? It’s fun! Candy is a universal entity. Everyone has a favorite (or a strong distaste for one), and in talking with your teams a good PO or coach can find out preferences and use that info to prep for The Candy Debate.

How it works (aka, coach’s notes):

  • Pick a well-sized room depending on the team size
  • Arrange candy options on different tables
  • Candy options (depending on team size): Chocolate (milk or dark), gummies, sour candies, classic candies, mint, no candy (some people don’t like it)
  • As your team enters the room, have them choose their candy of choice
  • Once everyone is settled, set up the debate

Round 1: ‘I want candy”

  • Teams will debate one another about why their candy of choice (eg: chocolate) is the best
  • Each team will have 5-10 minutes to discuss amongst themselves
  • Each team will nominate 1-2 people to present their argument to the group
  • Each team will have up to 3 minutes to present their argument
  • Coach will designate someone to be the judge, if no one is available, coach will be the judge
  • Rules: stay positive, focus only on their candy

Round 2: “Pour some sugar on me”

  • Teams will have a second round to debate, only this time, rules are out
  • Teams will have no more than 5 minutes to create a new argument about their candy
  • Teams can choose two options: double down on why their candy is the best, or attack other candies about why they are terrible, or both!
  • Team will nominate a new presenter
  • Each team has 1 minute to present their argument
  • Coach will designate someone to be the judge, if no one is available, coach will be the judge
  • Rules: none (maybe no profanities or derogatory terms, this is a work team building exercise after all)

Retro

After all the teams have presented their arguments, the coach will pick a winner and explain why they won (best argument, best teaming, most creative, etc). To mix it up, let the teams vote for a winner themselves, you might be surprised how people vote! Finally, let everyone enjoy their designated candies while the coach leads some retro time.

Questions for coach to lead the team:

  • How was it working with your team?
  • Purpose: Get the team to think about team dynamics, new people, different opinions, etc…
  • Were presenters nominated, volunteered, or voluntold?
  • Purpose: Do people naturally move into these roles or rise to the occasion, take note of the adopters/detractors in each group, and the introverts/extroverts, who did what.
  • What will people take away from the exercise?
  • Purpose: Perspective is critical to an agile team, and making sure people hear thoughts about exercises, good or bad, ensures that they can continue or discontinue as needed. Some teams build trust through team building, others see it as a distraction, it’s critical to get the pulse of the team to take it into the next exercise.
  • Coach’s note: Read the room and let the team drive the conversation

Sugar highs, and the inevitable crashes, are sure to happen during this fun team building exercise. I hope you and your teams find this a sweet escape from the norm and expands on their agile soft skills. Happy candy debating!

If you’re interested in an outside facilitator to work with your team, reach out to productoffensive@gmail.com.

Mondays get a bad rap…

What did Monday ever do to us but exist? They’re as hated a Product Owner who misses a scheduled release date. But like everything else in life, it’s all about how we look at Mondays. They can be weekend killers or they can be a symbolic fresh start. In any event, here’s some Monday motivation for you to manage that inbox and backlog of work.

Motivational jam of the week: Call on me-Starley

Try not to hate Mondays. Instead put that hate towards the real culprit, 8am status calls.