Product Owner: Value Maximizer

How do you maximize value in the workplace or as a business owner?

I’ll tell you what I’ve done.  I have a list of things that I’ve made for when I start a new business to get it off the ground and running.  Here is what that looks like.

Then in my trello list I’ve got over a 100 things to do and continue doing list for me and my team.  Not always are the things listed about making more money.  Sometimes it is a list of things to do to improve employee morale and smooth out processes for the production manager or appointment setter. 

I also like to set aside time once each week to focus on business development things so that at least once a week I’m focused on things outside of the day to day to improve how the company is run.  This same tactic is applied in scrum with the sprint reviews and should be done at least once every sprint so that the entire gets to benefit from the results of process improvement.

The scrum guide says that the product owner is a value maximizer.  I think the key to prioritizing what is most important first, second, and third is to ask the customer (stakeholder) and listen to what their biggest pain point is.  If you can key in on that, create actionable steps to solving it, and then either complete the actions needed to solve that pain point yourself or source it out to your team then you are on the right track for how to maximize the value you render to your stakeholder and make sure that everyone is successful.

Nobody cares how much you know until they know how much you care

So as I jump into a career pivot from developer to product owner, scrum master, project manager type roles and I’m interviewing and submitting resumes and a common task/assignment with the job is to interface with the customer (stakeholder for you scrum-ites) and take down their information/needs, formulate said needs into actionable bite sized pieces that can be done in a time boxes event of one month or less, and be in contact with the team performing the work to help where needed and update the client as needed.

As I interview though and ask what it takes to really excel at these jobs the common response more or less is to just jump in and get to know people, what their problems are, and show that you care and that is about it.  I don’t know if this is brought up because people just don’t do it or maybe we’re all just craving for someone to do that for and with us.  By the way I can and do totally do this for those who were wondering.  And because this is what it will take to be an outstanding product owner/manager I know that I’ll be quite good at this job.

As I run my business this is where camaraderie and growth among the team and with your clients happens.  It’s when you actually show them you care by asking how their dog is, family is, etc and then you actually follow up with that care whether that is through a text, call, email, or in person is where in my opinion real progress gets made.  The quote from Teddy Roosevelt, “Nobody cares how much you know until they know how much you care” applies in product owner management and any professional interpersonal relationship or personal relationship.  So yes learn all the latest agile and scrum and best practice techniques and certifications you can, sure.  But don’t let that get in the way of just being a good person and caring and helping when and where there is a need.

Timeboxes in Agile Meetups

As I dive deeper into the Agile world and continue learning I’ve been going to meetups one to two times a week.  I found a few groups on meetup.com and have attended lots of meetups to learn, help, and network where I can.

For the uninitiated I thought I’d just publish what the experience typically looks like there in case you were interested in coming, but didn’t really know what to expect.  Depending on the size of the group they will break the group up into smaller groups to facilitate more in depth conversations, usually in size from 5-9 people.  This of course is in line with the recommendation of Scrum where dev team sizes are anywhere from 3-9.  Any smaller and there wouldn’t be that much collaboration and any bigger there are obviously too many to really cover as many topics as the group would like and some people are more apt to not comment if they’re in a group that is too small or too big so this helps solve that problem.  Note that this same thing could and ought to observed in your own organization.

From here you’ll take roll and then in your group you’ll be asked to write down things you’d like to talk about.  These can be anything from how to manage problems in the team, duties of a product owner/scrum master, types of software used to track project progress to which certifications are the most relevant or not to get to excel in your role.  Then you yourself get 3 or 4 votes and you’ll mark which sticky notes you want to talk about with your votes. 

The highest voted topics are discussed first and a timebox is given of anywhere from 5 – 8 minutes.  When the timer goes off the group is asked if they’d like to continue, maybe they’d like to continue, or would not like to continue.  This is done by thumbs up, thumbs sideways, or thumbs down.

Now you know what to expect at most meetups.  Others will also include a guest speaker(s) or perhaps a presentation on the company hosting the meetup along with split out group discussions. 

What are your most effective ways to holding meetings and learning and networking?

My experience on agile teams

Someone asked me the other day what my experience on agile scrum teams has been like so I thought I'd write it out here as well.

Some of the teams that I’ve been on are much more structured than others when it comes to agile scrum implementation and use.  My most recent stint was at MasterControl where they did a pretty good job of it and are actively implementing SAFe right now.  When I first started there a couple months into it we all went to a big house in summit county (Park City area for those who don’t know where that it is) and we holed up there with tons of goodies and what not to plan out upcoming projects and things we were going to improve on in the coming year.  Essentially this was like a BIG sprint retrospective where you identify one or more things to do in the upcoming sprint (year) that will improve the overall efficiency of the dev team and for our stakeholders. 

Once we were back we went to work on those things.  My team worked on a 2 week sprint time frame.  We used workfront to track our projects, which were estimated by hours.  We met every week on Monday to talk through progress of each project, any impediments, and renegotiated what was to be done next or what needed some changes on the existing projects. 

Every day we held a daily standup to talk about what we’d worked on the day previous, what we were working on that day, and any impediments or items that were a dependency from somewhere else.  Afterwards the project managers could and would check in with other teams and the dev team/person assigned to a project to get a status update and help in removing said project along.

This was the bulk of my experience in our agile scrum teams with little nuances here and there with MasterControl.

Why Scrum?

What is Scrum and why use it?

Scrum is a way, a framework, to complete projects.  These honestly can be any kind of project that you’re working on from simple to complex.  It was created as a framework to push out complex projects.  Before scrum they were just projects and done in a linear fashion and once the project was finished it was pushed out to the public in the form of a service or product.  Certainly there are variations on this, but that is the general gist of how projects went.  Nowadays this method of dreaming up a project or product and doing the entire thing and releasing it once it is done is called the waterfall methodology. 

Basically you do all of one thing before moving on to the next thing.  While this is nice sometimes for the customer it has its pros and cons. 

Agile allows for rapid iteration on a product.  It also limits time to work on a particular part of a project to a set short period of time.  This allows for trying things quickly and getting them out quickly.  The last thing you want in a product is something that isn’t needed in the marketplace anymore.  Also I feel like the agile method lends itself to more emotional wins within the team that is actually working on the product. 

If a team is assigned to work on the product at hand and they miss their waterfall deadline of having it out the door after 6 months vs 2 weeks for the next most valuable thing in agile, then it just feels like a bigger problem though theoretically it is possible to do potentially the same amount of work in the same amount of time.

What do you think of scrum vs waterfall methodology?