Working with Cross-Functional Teams: Engineers

Empathize with the team you're working with

Engineers are essentially creating something from nothing.  They have to be very detailed oriented and think very logically.  They have to consider various implementation details, weighing trade offs, making judgement calls, and coming up with creative solutions to problems. As a PO you want to be technically curious and enjoy what they are doing so you can empathize with their work and you yourself should be working the same way with your work.  You need to be thinking about all the different scenarios and edge cases that might come up.  The goal with writing specs is to not have the engineer come back to ask clarification questions about the spec written.  If/when something isn't developed corrected it should be on the PO to step up and take responsibility because it is the PO's fault for not clarifying that.

Don't micro manage and micro pester

Don't pester devs too much throughout the day.  Pick up skill sets like learning SQL and how to run your own basic data queries and run analysis on said data.  Learn how to change copy on a website or go and find the id of a split test you're running.  These types of things will help you as a PO.  If you do have things try and batch them together to ask them all at once.  Don't check in lots either throughout the day, i.e. 3 times a day.  They know they have code/product they need to push out and if you're constantly checking in while to you it is something you're anxious to get an update on and get to the customer for them they may have another one or two projects they're working on and your ping is just another interruption or context switch that disrupts their flow and eats into their focus.  If you need an emergency solved sure, but status updates can and should be gathered at the very least from the daily stand up.  There you will find out what the team is working on and if there are any blockers/impediments from getting the work done on time within the sprint's time box.

Encourage ownership

Make sure you're making the dev team feel like they have ownership in the project instead of just feeling like they're executing something you're tasking them to do.  Sit down and explain what the product vision is and why you're prioritizing this particular need and solution so that they can provide their own input and ask clarification questions.  Doing this will also help the engineer/dev because while they're working they may see something say during implementation that just wasn't thought of by you and they'll be able to solve it on their own or with minimal outside input.

Agile Method: Kanban

As I've discussed on this blog some of the intricacies of Scrum in an agile environment I thought I'd also touch briefly on what Kanban is as it pertains to an agile environment.

For starters typically a Kanban board is made up of three columns as seen below.

Instead of having a product backlog and a sprint backlog like you would see in a scrum agile environment in Kanban you only have one backlog for the product and it occupies the whole of To Do on the Kanban board.  As with scrum the very top item in the product backlog is the most relevant/highest value item to work on next on down the list to the bottom.  The next available dev team member will just take the next available item and work on it until it is complete at which point they'll then move it over to the Done column.

Kanban is also unique in that it doesn't utilize sprints to complete the work, i.e. there isn't a one to four week time frame for which the work in the To Do column must be completed.  While it may seem like there'd never be a break from the action teams can implement certain constraints to the board, i.e. only 2-3 items in the To Do or In Progress columns at a time.

One other benefit to utilizing Kanban is that there aren't a lot of meetings as it pertains to sprint planning, sprint review, and daily stand ups.  Also it works well for teams that don't want to do a lot of costing or estimating of each individual item so that they're having to figure out exactly when something will be released and in which sprint.  The drawback to that of course is that you then may not know close to when something will be released.

And there you have it.  A quick touch on what Kanban is.  What do you think?  What do you do differently on your team?

Sprint one of Grandpa Pops Hot Fudge Sauce

As I transition from being a developer on a dev team inside the scrum structure to the product owner and scrum master roles I thought it’d be a fun thought experiment to document my journey of how I’d take a product from idea to development and release.  It is a simple product, my dad’s amazing hot fudge recipe, but one that I think will demonstrate my experience with releasing something in an agile environment.  And who knows maybe you’ll even see it end up on the shelf at your grocery store one day.

That said there are lots of things to do when getting a product off the ground and running and since I’m a scrum team of one I started by logging and creating my own Jira account to manage my product since that is a very common software app that is used today to run agile projects.  From there I made a list of things that need to get done in my very first Sprint Planning meeting and have more or less ordered them by importance and value for the first sprint. 

Then I went ahead and listed out a bunch of things that I know need to be worked on eventually for the product backlog and did a rough ordering of the stories as well, which can be seen here.

Stick around for more updates as I go.