Qualities of a Healthy Relationship Between Engineering and Product

Early in my career in software development as I reflected on what makes a great product, I began to formulate the opinion that success was 90% engineering and 10% everyone else. What I mean by this is that if the engineering team was top class: filled with talented people, had great coding standards, embraced testing, had seamless continuous integration, etc that you would most likely have an amazing product.

Now keep in mind, as a former developer, I was biased. Heavily biased.

As my career progressed, I began to appreciate more and more the impact product managers and their teams can have in the overall quality and success of the product. I learned that you can have a rock-solid piece of software that has 100% test coverage and is functionally sound yet fails miserably in the market.

I learned that if you really want to have a successful product, you need a healthy relationship between Product and Engineering.

What does that look like?

Product Owners are team members

Are Product Owners really considered members of the team? The Scrum Guide,” clearly states that the "Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master," so it should be a settled matter yet much digital ink has been spilled on this point alone. And I don't think it's a trivial one.

Many think that it's the ScrumMaster's job to handle the details throughout the sprint while the Product Owner (PO) goes back to their market research and wire-framing. This is not the case. Product Owners are the "CEO" of the product. While the success or failure of the product falls on everyone's shoulders, there is an extra amount of ownership and responsibility that rests on Product. Therefore, when some decisions need to be made during a sprint, such as negotiations on specs, the PO needs to be ridiculously available for these discussions.

The PO should be an ever-present figure who is there for their product. This means the PO shows up at most of the stand-ups, sits in on retrospectives, and is physically located (when possible) near where the work is being done.

Product simply doesn't hand off specifications and user stories to the development team then disappear for two weeks until demo time. This is a sure-sign of an unhealthy relationship that will ruin your product.

Product Owners and ScrumMasters are best friends

Professional best friends, anyways. What does this look like? It means that the ScrumMaster (SM) and the PO spend a lot of their time throughout the day together.

Why do ScrumMasters and Product Owners need to spend time together? Two primary reasons:

1. The SM should know almost as much about the product as the PO (yup, I said it).
2. The PO should know exactly how groomed the backlog should be for the development team to successfully build what they want.

These two facets can often times feel unnatural since the SM isn't normally as strategic and the PO not as tactical in the way they approach their jobs but they are areas both need to learn in order for their careers to thrive. 

The better the SM can understand the product, the more effective he will be in identifying if the team is making the right kind of progress. The SM can also make better decisions with the team in the absence of the PO. 

The better the PO can understand the level of story detail required to direct development the more efficiently engineering can go about their days. UAC should be defined for all known requirements. Not only will this show the team if they sufficiently completed a task, but QA will be using UAC to help build their tests. This drives the whole team forward to their shared goal of a successful release.

As I mentioned before, these skills may not come naturally for the SM or PO, so it's the job of the Agile Coach to make sure the PO is educating the SM on the Product and the SM is educating the PO on the level of granularity acceptable for each story.

I could go on at length on this topic, but if this relationship doesn't work, then the product will fail.

Product Owners and the team share the spoils of victory.... and blame in defeat

We're all in this together. And this all seems pretty obvious, but often times there are devastating rifts that can grow between Product and Engineering if we're not careful.

This is where good coaching comes in very handy. An effective Agile Coach can catch symptoms before it blows into a full-blown disease. Ask yourselves these questions:

• Who is writing the user stories? If it's the SM by his lonesome, you have a problem.
• At what point in the process is the PO getting her hands on some version of the product? If it's at the end or around demo time, you have a problem.
• Who owns and grooms the backlog? If it's your ScrumMaster alone, you have a problem.
• What do retrospectives reveal about the health of the Product/Engineering relationship? If the team provides feedback around not being provided timely or detailed enough information from Product, you have a problem.
• Can the SM effectively describe the product, its features, and where it's headed in 30, 90, 120 days? If not, you have a problem.
• How often are the SM and PO seen collaborating? If these two appear more like ships passing in the night, you have a problem.

While there are many nuances to this relationship, it's now very clear to me after over 10 years of software experience that the ScrumMaster/Product Owner relationship can make or break your product. 

How do your ScrumMasters and Product Owners get along?

Are There Too Many Meetings in Agile Software Development?

I happened across an article that was suggested to me by Google written by someone in the software industry complaining that there were too many meetings in Agile software development, particularly in Scrum.

In searching for the article so I could post the link here (with no luck), I found there's no shortages of articles containing people complaining about the amount of meetings as well as from those Agilists in defense of their framework.

In thinking about this problem, I boiled it down to three questions:

1. Who are the people complaining about the amount of meetings?
2. What is the core problem when people discuss meetings like this?
3. What can be done within the Agile framework?

Who are the people complaining about the amount of meetings in agile software development?

Traditionally, when a company or team announces a desire to move to Agile software development, the framework of Scrum initially is on everyone's radar.  When you attend ScrumMaster Certification training, the basic list of meetings is this:

• Daily stand-up
• Sprint planning
• Backlog grooming
• Demo
• Retrospective

Depending on your deployment process, you may have a release warroom-type meeting where the entire team is holed-up until code is released, tests pass, and all systems are green. (These "meetings" often suck)

When looking at the prospect of all those meetings that the team will have to embrace it's the engineers who generally start complaining to themselves about spending half of their week in meetings. 

Being a ScrumMaster, I can't blame the team for this. As I've written before, I too hate meetings. Usually they are poorly organized, little to no preparation had done by facilitators beforehand, unnecessary participants are invited and not allowed to leave, and they drag on forever! Engineers are paid well because they are good at what they do.... building things. They want to be at their desks building things, and they should be!

When teams start openly deriding meetings, ScrumMasters can often receive that feedback as personal criticism, since it's sadly one of our tasks to round people up for meetings (maybe it shouldn't be, in a perfect world). Perhaps this is why ScrumMasters call meetings 'ceremonies'. We're not fooling anyone though; these are meetings. If not handled correctly, indeed the team will blame you for the meetings being so awful, so pay attention!

This is why good ScrumMasters are adept at identifying the core issue, which really aren't the number of meetings themselves.

What is the core problem when engineers are complaining about too many meetings?

Yes, engineers need to be engineering but the plain fact of the matter is that meetings need to occur in order for the team to best know what they are trying to accomplish. You just can't get around that. There simply has to be planning; no one will be able to deny that.

The real problem behind the meeting complaint is not the number of meetings, but that too much time is taken up with poorly prepared meetings.

In my career, I've seen it all with regards to meetings. I've made all of the bad mistakes that are still sadly so prominent in software teams throughout the world. I've seen the "let's set apart mornings for meetings so we can work in the afternoon." I've been a part of the dreadful 6-hour sprint planning meetings that lead to so much soul-crushing.

These are dead giveaways that your software developers probably are frustrated at their companies.

This is one very important problem the ScrumMaster needs to be actively solving or risk losing the trust of their team.

What can be done about awful meetings within the Agile framework?

Keep. Meetings. Short. Live by this motto; embrace this motto; weave it into the culture of your team. When I work with new teams, one way I get engineers excited about my being there is the promise that "I am going to ensure our meetings are no longer than 50 minutes." After about 50 minutes, people start to fade and the meeting loses its effectiveness exponentially.

Many people (mostly team members) will be excited at your seemingly bold claim. Some (mostly managers) will be skeptical. (After all, it's not uncommon for certain professionals to validate their usefulness by the number and length of meetings they facilitate.)

How can this be done?

Well, you don't start immediately, especially if long meetings are ensconced in the culture. You declare to the team that this is the goal we will be working towards and hopefully within the quarter, all meetings will indeed be down to 50 minutes or less.

One of the key ways this will be accomplished is through the unsung hero of agile meetings: backlog grooming. If you have painfully long sprint planning meetings, it's probably because the team doesn't groom well or at all.

If the team is grooming in multiple short-bursts in the run-up to the sprint, your planning meetings should be really short. The team should already be familiar with the stories at the top of the backlog. They should have already thought through key areas in how they will approach their solution. User Acceptance Criteria will have already been defined and thus QA will have been planning their tests in advance. Estimates are already made and agreed upon so we don't sit there and haggle for 15 minutes on each story.

How often you need to be grooming is up to the team, but the goal is to get the things at the top of the backlog refined in such detail that at the start of a sprint the team can immediately begin working. I wouldn't worry too much about grooming stories that may come into view more than a sprint or two down the line. It's just not worth it at this stage because things are so fluid in software development.

While engineers may initially balk at the thought of having yet even more grooming meetings, you will convert them into believers when you are in and out of a planning meeting in 15 minutes.

Tip: in order to not disrupt the artistic focus of the development team, try scheduling grooming meetings right after lunch or at the end of the day. 

If you're grooming well and following a more 'kanban-style' approach, you may simply remove the sprint planning meeting altogether. Victory! (Just don't leave out the retrospective)

While all of this concern about meetings may seem trivial, it's really strikes at the heart of Agile software development which values the minimal amount of overhead in order to produce something of quality. Finding that balance is unique to every team, but rest assured if your team is spending over 25% of their time in meetings, not only are you not maximizing their value, but they're also likely unhappy with their jobs.

Ignore meeting optimization at your own peril.

A Feel Good Retrospective

If you're not careful, retrospectives can sometimes feel like work or routine for your team. Chances are that if you see the retrospective on your calendar and think to yourself "ugh, another retrospective," that your team is saying the same among themselves. This is a sure indication of the need to freshen things up.

A problem with freshening up your retrospective format is that many of them are pretty derivative. How many times have you tried to find a new format and come up with the "pretend your team is a hot air balloon or pretend your team is a boat" type of retrospective? Not very original and you're not fooling the team by changing your boat into a rocket ship. It's the same exercise.

Most retrospectives end up with the team being told to identify some problems and a solution or two for these problems. Yay. We all get it.

Having felt like this over our past few retrospectives I did lots of research to find something, anything, different. Lo and behold I came across a retrospective format on respected Agile evangelist and speaker Ben Linders' website.

It's called the Core Qualities retrospective which focuses on identifying each team's members strengths and then aligning them with problems your team is facing.

While we didn't come away with any takeaways (we ran out of time and I'm a stickler for schedule), I feel like this was one of our most enjoyable and beneficial retrospectives ever. In my almost five years at Business.com, I can't recall a time during a retrospective that our team members smiled and laughed so much. I found myself also grinning ear-to-ear as we went around and talked about the qualities we appreciate in one another.

People simply don't get enough praise and appreciation in their lives (especially at work) and this exercise was really powerful for the team. I can honestly say that despite the fact that no problems were surfaced and no solutions provided our team came out of that room as tighter-knit group. It may sound sappy, but there you have it.

Here is our tangible output:

How can you not feel good about seeing words like that under your name? (BTW I got helpful, organized, concerned, disciplined, flexible.... not bad for a ScrumMaster ;) )

So if your team is feeling a bit burned out on retrospectives I highly suggest giving this one a shot and your team will be able to reestablish why you all work together. You've got nothing to lose and I assure you that your team members will feel appreciated. What more do we want at work?

Scrum and Large Projects; Yes They Work Well Together

"Does Scrum work on large projects?" is a question that I often wondered throughout my career. I've participated in a lot of large projects which started off as Scrum but then morphed into some weird waterfally/agile hybrid mess. These types of projects still had bi-monthly planning, demo, and retrospective meetings but only had a singular release. We found these frustrating projects to be a part of because they usually ran long and were really buggy when launched.

Because of our previous failed attempts, I had all but reserved myself to the grim reality that Scrum probably wasn't the most ideal methodology for projects that take at least 6 months and touch many different parts of your application. But that's only the start of the story.

In the beginning of 2014, our development team was tasked with a large rebuild of Business.com, including; big data visitor intention profiling, a custom content management & tagging system for content publishing, overhauled site architecture, and more. I was skeptical that we'd be able to pull off a single public release while also continuing to adhere to the principles of Scrum, but we did it and learned lots of lessons in the process.

I wrote an article about the agile development lessons learned on a large project. If your team is embarking on a large project and you understand that benefits that Scrum brings to your organization, read the above link so you don't have to learn the lessons the hard way, as we did.

Are Your Agile Retrospectives Growing Stale?

The other day I stumbled upon Michael James' ScrumMaster Checklist and decided to fill out and see where we were at as an agile team. While I'm not going to go into detail, there were some things that caused a great deal of self-reflection for me; in particular:

Have you tried a variety of formats and locations for Sprint Retrospective Meetings?

This is something I've been wanting to do since last time I decided to breathe life into our agile retrospectives with great success. While this method has been a tremendous format for gathering feedback on the previous sprint, it seems that the team is getting a little too familiar with how it's supposed to go. Another problem is certain team members struggle to think of two positives and negatives in advance of the meeting so we waste time as they frantically try to get something on paper.

In researching different formats that people have used, I stumbled across this list of agile retrospective formats and think I'll be rolling out the 6 Thinking Hats Retrospective Plan for next week's retro. I'll be posting my experiment on my blog when the results are in!

What kind of formats have you used in your retrospectives? Any thoughts or suggestions are much desired.

Agile Manifesto in One Simple Image

I ran across this tweet today and loved it.

Our "product" after a day of certified #scrum master training #agile @scrum_coach @macterry pic.twitter.com/3PClFEuJTk
— Ryan Rhoten (@RyanRhoten) February 20, 2014

I couldn't think of a simpler yet effective summary of the goals of agile software development.

A Useful Resource to Share With Your Boss or Customers About Estimation

Our development team has recently undertaken a new project which is the biggest initiative for the company in 2014. Since we were dealing with some large and complex components, we've been struggling with how we can provide the business with a reasonable estimate for completion of our minimally viable product (MVP).

I began doing research to see what others in our field have done and polled other Certified ScrumMasters on what their struggles & successes have been. I tapped into a such wealth of knowledge provided by leaders in our field that I felt compelled to compile that information and format it for broader consumption.

Face it. Software development teams suck at estimating when their projects are going to be completed. For anyone involved in software development; be it engineers, product managers, and customers this scene is all too familiar:

“How’s the project coming? Will it be done in mid-April like you said?”
“Well, we’re actually way behind. April doesn’t seem doable, but that was always just an estimate.”
“How is that possible? You estimated up front that it’d only take you 3 months!?”

Read more: Why Your Tech Team Missed Their Deadline

 Tell me what you think and how your team deals with estimates.