Efficient vs Effective


It’s been a fairly constant point of contention when adopting agile techniques that at some point, someone will say something to the effect of “…it’s not efficient”.

We can’t build the story like that, it’s not efficient…

In order to run an efficient stand-up…

Here’s how we can deploy efficiently…

Using the resources efficiently...

And, they are usually right. Sometimes it’s not “efficient” to do something in an agile way.  It is usually, however, much more effective. The efficiency play is a very comfortable thing for most people to want to do.  They are proud that they have a history and skill that they have used to optimize their time and abilities to do something in most streamlined way possible. The outcome? Well, we couldn’t really control for that so we did the best we could.

After hearing from someone about an efficiency play, my question is usually, is that going to be effective?

“We built the database story for the new site.”

Wonderful, can the client start to use it and give us feedback?

“Not yet, we have to build the other parts and then test it, it’ll be ready for them in 3 more sprints.

The teams may be building something “efficiently”, but their entire effort was wasteful because they haven’t produced anything of value yet, or worse, the wrong thing.

Being able to build something effectively is more critical than building that same thing efficiently.  Once the team, customers, and leadership learn the value of doing things in an effective manner, then and only then, should they progress to doing that same thing efficiently.

“We had an efficient stand up.”

Great did everybody understand what they needed to do?

“I don’t know, but we got done in 8 minutes.” 

I worked with a team that built the first version of a graph in an application in 6 weeks. The effort was all towards building that first version and get it to the customers.  We came back to that product and built another similar graph in another release. We came back a third time to turn that widget into a component when the need was clear.  Then we redid all the apps using that component so that it was consistent for maintenance, behavior, and look and feel.  Was that efficient? Hardly. Was it wasteful? I don’t think so.

The teams touched and redid that component many times.  If we waited and thought about all the times we might use that as a component, built it that way, and then deployed, we would not have released for months.  We would have missed valuable feedback, not learned about what worked and what didn’t, and not improved the experience near as much.  Which is more wasteful? Building something over and over, or building the wrong thing once?

From the 5th time on, when we needed to build that graph, we did it in a very efficient manner. The team took the time to understand the needs and I understood that this was something that we could now make efficiently.

The argument is very similar in nature to the Outcome or Output issue.

I know there are some people that would rather use the teams to 100% capacity and see a burndown track perfectly.  So what? What did you finish? What value have you added? We’ve proven we can build the wrong thing in record time.  Why are you happy about that?

“We finished the initial order process for the sprint, but they still can’t order all the products yet.”

Can they order the most important item from our feedback and tell us how it works for them?

“Yes but we might have to change it for the others.”

It’s a certainty that we will,  lets celebrate what they can do now.




Posted in Uncategorized

When to solve or save.

I recently had the pleasure of discussing Product Ownership with Bob Galen on a recent episode of Deliver It Cast.  Part of that discussion was the next level for Product Ownership to get to; the bottom line is that there really isn’t one. A lot of PO’s are still struggling with the basics and still need help and to focus there.

After I read Lyssa Atkins great book “Coaching Agile Teams“, one of the areas I now think should be an additive skill for PO’s is to help the team to get better.  That doesn’t mean a PO should morph into a coach per se, once they nail the basics and look for improvements, I think helping the team is likely the best place. In thinking about how to help them learn, Lyssa really emphasises having the team learn themselves, experiment, and have the PO/SM/Managers support them.

My usual reaction to things is to give an answer, or idea and work with the team to make it so.  Now I’m thinking of different times that I should not jump in and let the team handle it. In doing so, having a plan for when to intervene or not would be needed.

So lets assume you are a good PO with a good team, you are nailing the basics and looking to improve.

With that I can think of these 3 different outcomes:

  1. Paper cut:
    1. These are small items that the team can learn and recover quickly from.  They will sting a bit and be remembered in the sprint but may fade after time.  Enough of these and the team will learn they don’t like them.
    2. Don’t jump in here. Even if you see if coming, let it happen, help them recover, and support them when they come up with ideas and actions to prevent it from happening again.
  2. Broken leg:
    1. These are impactful issues that really stop the team. This one will hurt and  hinder them for a while.  The impact is big and they might need some time to recover, refactor, replan, or change something major with the team or product to get back working.
    2. I would feel really bad if I saw the team headed for something like this. I would want them to learn still and maybe head off the severity, but not the impact. If I could find ways to subtly suggest or show what would happen, I would do that. Otherwise, buy some get well soon ballons and a bear.
  3. 100 ft cliff:
    1. This is something the team likely would not recover from, if they survived it at all.  These things are bigger than just the team and the affect is felt in the largest possible sense. Heads might roll ( including yours ) and the blamestorming might become a Cat5.
    2. I would jump in here.  I would take 2 or 3 attempts at making sure the team understood the issue, consquences, and impact. As a last ditch effort I would create stories and acceptence criteria that greatly reduce the chance for a bad outcome. It might still happen but I will have done what I could as a PO to avoid it.

So that last one might be harsh, I thought about getting hit by a bus instead becuase I love that phrase.  Point being there is a level at which I would give an answer or idea to the team but I’d like it to be pushed back further than where it is now.

The more the team can learn and do for themselves, the better they will become.  Stepping up to help them as they learn I think is a great next area for Product Owners to reach for.



Posted in Uncategorized

Are you a Business or Technical Product Owner?

I attended my first Open Space conference this past weekend and really enjoyed it.  It was based around agile leadership challenges and I was most interested in a session with people discussing how to find the right product owner, and how to determine if you are working with a business or technical product owner.

There seemed to be a consensus in the room that it’s OK to have two product owners, one for the business and one for the technical items. I tried not to be overpowering in my attempts to say “Don’t do that” but fear my biases may have leapt out.  Having two product owners, or a product owner and product manager share the responsibilities or decisions for the backlog/vision/roadmap leads to conflicts and other undesirable outcomes.  A single product owner should decide what to work on, they should talk with both the business side and technical sides of the house to make sure nothing is missed. This helps to focus on the most important thing to work on next. Having one person make the decision with the best information from the larger team(s) is the best setup.

One of the interesting things that came out of the discussion was “What type of product do you have”.  The examples that I thought about were Slack and Docker.  If you need a product owner for either of those two products, does it matter what background/interest your product owner has? Slack does really well on the workflow, design, and business fit for their product so I imagine their PO is more focused or comfortable on that side. The PO for Docker is likely someone who helped create that technology and has people that work with them on the business side to push out into their market.

It’s just a theory at this point and I’d love to hear from PO’s who consider themselves more business or technically inclined and if that lines up with their products purpose. Might make for a great discussion with PO’s with different products and goals on Deliver It Cast.







Tagged with: , , , , ,
Posted in Uncategorized

What to do with “Non-Functional Requirements”

On our last Deliver It Cast, Kim and I talked about what to do with Technical Stories / Debt for your product. The TL/DR version is to schedule it just like the other work and don’t skimp on it.

One thing we left out of that conversation is what most waterfall projects call “Non-Functional Requirements”.  I dislike that term and the implications it has, especially for an agile project.  The idea that an attribute of a system is something separate from what you are building is alien to me now. All of the “ilities” should be a part of the story you are writing for the feature/benefit you want.  If performance is part what the story requires, then make that part of the story and acceptance criteria.  If scaling the app is important, it should be part of at least one story that is being created.  If you need to performance test your system outside of a technical / business user story then make a card for it and do it.   If it’s not part of the story, or if you can’t determine it’s value then don’t do it.  A product owner should only include and prioritize work that is valuable. Optional things are waste and don’t make it to the roadmap or backlog.

No matter what you want to call it ( but please not a non-functional ), it’s work that needs to be done and the team needs to do it.  Because of that, it’s a story that gets prioritized with the rest of the work that’s being asked.



Tagged with: , , , ,
Posted in Uncategorized

Product Ownership as a team sport

Interesting reading a couple of Leading Agile pieces about teams of product owners ( PO-team-why, PO-team-supporting-the-portfolio-team ).  I liked one a lot and the other not so much, I’ll try to explain why and some suggestions for scaling that role.

PO Team:

  1. A team of PO’s can be useful, successful, and improve the delivery if some simple rules are followed:
    1. Each team has 1 PO. Other PO’s can collaborate with them, but a single PO will give a team the stories for planning, acceptance, and for answering questions.  This avoids any conflict and makes sure each team knows where to go for what they need.
    2. The PO team communicates constantly. The PO’s should meet regularly to review, discuss, and align their directions, stories, and release information to ensure that no information is left on the floor.  I had really good success with a daily scrum type call with all the PO’s & BA’s on a team to make sure we were preparing the work for the team and to discuss any issues or new information that was discovered with the clients or teams.
    3. The Chief PO needs to make sure each team PO has a clear direction, epic, and authority for that product or area of the product to be successful.  It is the CPO’s first responsibility to make sure the PO team is running smoothly and spends time clearing the rails for them or getting answers to questions that are funneled up.
    4. Decision making needs to be swift and decisive.  If an issue comes up and time is of the essence, the PO team needs to be able to quickly analyse the situation, facts, and impact and keep moving forward if possible.  Sometimes this required input from the client/business and sometimes they won’t make a decision. If not, then you as a CPO or PO team need to decide and be ready to explain and possibly change that decision in the future.
      1. This usually isn’t a large gap.  If you’re in touch with the goals of the project, users and teams then your educated guess will be correct most of the time and if not, then you’re close enough to pivot into where you need to end up within another iteration most of the time.
      2. There are times where you cannot make a decision, you simply don’t have enough information. At that point it’s OK to decide that you can’t do anything yet, and to move that item off the team as you learn more.  Not making a decision is the worst thing you could do.

Some questions and clarifications from the articles:

  1. “Provide timely information to the Portfolio Management for investment decisions”
    1. I’m having issues wrapping my head around this one.  If I think of this Portfolio Team as the stakeholders/customers then it makes sense.  Otherwise I’m not sure. It would be helpful to detail out the membership of this team as he did for the PO team.
      1. If this is leaning toward SAFE then some of this makes more sense.
    2. Having a team on the other side of the PO helps to gather ideas/input.  I see some of the PO responsibilities taken away in this scenario ( Epics for release, Features for MVP, and Prioritization to name a few ). POs should seek feedback and input on these but if others are deciding for them, then what exactly are we providing that’s different from a waterfall Project Manger?
  2. Product Owner Team Roles
    1. Product Manager (PROD), Solution Architect (SA), Release Manager (RM), QA Management (QA), Project Manager (PM), Product Owner (PO)
      1. To me this seems like a leadership team, there are people here that need to be informed about getting the product out but does not seem to be focused on the what, mainly the when.
    2. In my reference above I would have the following on a PO team:
      1. Chief Product Owner, Product Owners x n, Business Analyst, Data Analyst, Scrum Master ( Chief if there is one, coach if not ), and Product Manager ( if there is one ).

I can agree with the last statement he has ( with a slight modification ) and that should be what we are striving for as a Product Owner.


With a few brief reports and frequent communication, the Product Owner Team ensures

the Portfolio Team client has visibility and timely information they require to make good business decisions.


Posted in Uncategorized

What makes a MVP?

One of the best things I get to do is work with the NC State Computer Science – Senior Design Center on a project each semester.  For the last 6 semesters we have been working with a team of CS students, design students ( sometimes ), and our company people to help them solve a bank related issue.  Our approach is different from others in that we setup a problem that needs to be solved and ask them to help us figure out how.  There are a few limitations ( browsers supported by the bank as an example ) and for the most part the students figure everything out with our guidance.


My main goal is to get a working MVP that does the 3 things that I think that semesters product should do.  Getting everyone to focus on the goal of the product, the 3 things that it needs to do to meet that goal, and to have it installed at our location multiple times is the recipe that has emerged.  While not pushing agile practices, but collaborating with the students and focusing on the agile values is a great way to work.  It’s a tight window to get something usable in 16 weeks as the students do have other classes and projects and certain things they have to do for this class. All of the  semesters have been very good experiences, the last 2 have produced something we are actually trying to use.

The focus on the MVP was enhanced this week while reading posts about not shipping crap, making something work before you add the fancy UI to it, and the final delivery of this semesters project.

  • As a PO, I will prioritize refining the MVP and how it does the 3 things that I want it to over new features.
  • The MVP will look and feel great.  Design, UX, and quality are all part of that.
  • Repeated deployment and frequent feedback are critical.
  • Let the team learn what works and doesn’t work. Discovery and idea generation.
  • Quick decisions are critical, both design, function, and what’s next.
  • Demo or showing a working MVP is incredibly powerful and easy to do.
  • It’s your product, you have to be happy enough to release it.  Don’t wait for it to be perfect though, it will never be.

It’s a great feeling to be able to launch something that works and see what’s next.  Getting positive ( or negative ) responses will help determine what else can you do or if you need to do something else completely.

How have your MVP’s come along?

Drop a comment here or let me know at www.deliveritcast.com


Tagged with: , ,
Posted in Uncategorized

Deliver It! – A Product Owners Podcast

Recently a former colleague ( Kim ) and I started a podcast dedicated to Product Owners on agile projects/products.  I have been a fan of podcasts and listen to a good number of them during my commute, on lazy Saturdays, and waiting at the kids extra curricular activities. It’s a great consumer product and I really like the on demand format for specific things that interest me.  After getting more information and understanding about how they are created, I really wanted to create one of my own about something I’m excited about.  I’ve been having lunches regularly with Kim to talk about how we are doing as Product Owners, issues we are facing, and ways to improve.  One of the podcasts that I listened to had a director/producer on it and he said basically that if you are looking for something, and that something doesn’t exist, then why aren’t you doing it?  So taking that to heart and with the previous idea of expanding the PO space with a Community of Practice that didn’t draw enough interest where we worked, we have launched this podcast.

We plan on talking about topics specific to Product Owners, general agile/lean concepts and how Product Owners work with them, and talk to people who create products to find out how they do it.  We want to grow the PO community and help each other learn ways to improve.  I’m hopeful that the podcast can be a small part of that and would really like any feedback, questions, topics, and to hear from people who create products about their successes and failures.

Our current schedule looks like recording a new 30-45 min episode every two weeks and to talk about some things that interested us, a main discussion topic, and any feedback/questions about the role from you.

You can learn more at www.deliveritcast.com, follow on twitter @deliveritcast or email deliveritcast at gmail.com.


Posted in Uncategorized