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?

Questions I ask to get up to speed on a new scrum team as a product owner or a scrum master Part 2

Welcome to part two of this series on questions I’d ask during hour one of meeting with the team to get up to speed on what they’re working on and how I could help or see where I know I could help.

1.      What is a typical distribution of story sizes in your sprint backlogs?  

This one tries to figure out, where the commitment sweet spot of the team is, based on the sprint backlog composition. To my observation, teams often work in a more successful way, when a sprint backlog comprises of one or two larger user stories, some medium sized stories and a few small ones.  Clearly actionable stories to start the sprint should always be ready with others that can be moved up to be worked when the first ones are finished.

2.      Are you re-estimating user stories at the end of a sprint? 

If so, under which circumstances are you doing so? That should always be done if a user stories turns out to be way off its original estimation.  The PO should update the stakeholder accordingly so they’re aware of the changes/delays in the project.

3.      What was your velocity of the last three sprints?  

The team should know its velocity, how could it otherwise possibly improve?  If you can’t measure it, you can’t improve it.

4.      How many user stories are typically not finished within a sprint and for what reasons?  

If the team is bullish and picked more user stories than it could probably handled at the beginning of the sprint, so be it—nothing to worry about. Also, there are other incidents that might negatively affect the team’s actual velocity, e.g. sick leave or a critical bug a few days into the sprint. If the team, however, is regularly leaving user stories on the board because estimations were wrong, this is a sign for concern that needs be resolved asap or at the very least the next backlog grooming session.

5.      Are you changing user stories once they become an item of a sprint backlog? 

If so, under what circumstances are you changing the user stories? Making them smaller if the team runs into a problem is certainly not great, but acceptable—if the user story in its reduced form still delivers value. Making it larger after the sprint planning is, however, not acceptable.  If they’re being made larger perhaps breaking it out into two stories would be better.

6.      What are the obstacles the team is facing today?  

If they’re systematic what ideas/tools/additional personnel brought on could be done to remove them?

7.      What are the dependencies on other teams?  

And if there are dependencies, are you waiting for other teams to complete their tasks?  

8.      Define and discuss at least two or three key team goals for the project.  

Some of the answers may seem obvious, i.e. meet our deadline within our budget, but this discussion can often bring out other goals which are not obvious to the team initially. It can help the SM or PO understand team motivations and dynamics.

9.      What are key success factors (KPI’s) to achieve our team goals?  

Defining and discussing key success factors, i.e. minimizing the impact of dependencies, can help identify project-level impediments, risks, and issues which the Scrum Master can begin to address. It also is a good benchmark to review and update as the project progresses.

10.  What do team members hope to achieve with this project?  

I like to get a sense of people’s personal goals for the project in addition to the team goals we will establish collaboratively. Having this information can help keep people motivated over the course of the project. Some people may want to learn new technologies, be part of a high-performance agile team, or have other goals.

11.  What type of work environment do we want to create on this project?  

This question can stimulate good discussion about how team members want to interact with each other to achieve the project goals. Often the discussion centers on trust, communication, collaboration, and respect, but it’s good to make sure there is some agreement (or an acceptance of differences) by the team about what is important.  If there are differences that need mending then a group setting may not be the best place to resolve said differences. 

12.  What can we do as a team to make sure that we support each other to achieve our team goals?  

This question can help the Scrum master understand how team members understand the importance of making commitments as a team rather than as individuals. It can also help the team establish informal agreements about the need for everyone to support each other, to take on roles outside their specialty, and trust their team when they need to ask for help.  Often there are senior or tenured people on a team mixed with newcomers that would love some mentorship and coaching.  Making this a regular goal helps elevate team cohesion, morale, and job satisfaction.

13.  What should we do when we are not achieving our goals or not supporting each other?  

Obviously, this can be addressed in a retrospective, but having the discussion early can be helpful to understand how team members perceive how these situations should be handled. It can help establish the need for open and honest communication built on trust.  Adding an impediment column to your workflow might also help the team feel and see that though work has occurred that just because it is stalled isn’t their fault.  Sometimes defects just need time outside of the team to be resolved and having that column could help in your workflow and planning.

14.  How should we celebrate success for achieving our goals?  

It’s important for the team to visualize and expect success. This discussion can help the team discuss rewards that are meaningful and keep them focused on realizing those rewards.  While monetary rewards can be nice, if you worked any amount of time you know other types of recognition often are more valuable intrinsically to a team and its members.

15.  Who are the domain experts outside of our team?

This is useful to establish who to talk to when a story comes to an impasse, but perhaps an official designee for resolving said impasse hasn’t been identified who could resolve the issue.

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.