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

Making stories small and valuable.

I had a great example of how to negotiate and split stories so they are small, achievable pieces of work without being dependent on each other the other day.

One of the teams I’m working with is just starting trying to build a site that will handle the sharing and collaboration of images for design work.  I discussed with them the need to have a log-in/security feature and the need for a comments system for the images.  The conversation came around to tagging others is a comment and how to best allow that.  The team seemed to be getting stuck on implementing the security first then the comments system so that they could communicate with others.  While that’s a nice to have that, the dependency makes it less feasible.

So what I suggested was a story that implemented the security piece, and a separate story that built the comments section, without the tagging.  Individually they were small enough to build in their sprint and they were not dependent on each other.  We can then add another story in a future sprint that does the tagging.  This way the dependency in the sprint is broken, and the future story is part of the iteration of the product.

I really like this example because of a few things:

  1. Keeps the focus on the core product, what does it NEED to do. ( I like to have 3 things )
  2. Remove dependencies from the sprint so the team can complete work.
  3. Allow the product to improve in future iterations.
  4. Negotiate with the team so they understand the main goals and are involved in the decision.



Posted in Uncategorized

Telling Stories

New ideas and new projects really make me happy and a bit excited. The possibilities, journey, and actions are great things to brainstorm and talk about with the team and customers.  In agile contexts we present these as epics, themes and user stories, all elements of classic storytelling to try and relate a specific problem to a person and their goals. The storytelling elements go much deeper than that on agile teams and I think nearly everything we do should be in the form of a story.

  • For the team:
    • Daily stand-ups are the team members story, what trials and success they have uncovered and won or lost.
    • Demo’s are a way to tell not only how a story has gone, but a way to link those stories for that iteration together for a larger story that the stakeholders can relate. Presenting the user stories in a priority order or as just work that was done doesn’t get the users involved, these stories are way they will solve their problems and how the solutions flow or relate to one another should matter. Presenting them with a good flow from one to another helps them understand and begin to see how this will change their day/behavior/attitude. Jerry Seinfield had a great line at his Clio acceptance speech about the moment when you first hear about something and then realizing its crap when you get it.  The point here is that it is a marketing opportunity, they should be excited or at least interested enough to want what they see.  Once they get it ( soon after for an agile team ) they can begin to see if it lives up to what they saw.  If not then what went wrong, lets correct it. If we did score, what else can we do?
    • In most games, movies, and most other stories is the concept of a “Hero’s Journey”. When you think about your users as the hero’s in their own journey and the application you are creating for them as a way to help them get there is something I really enjoy.  Depending on what the problem your application is trying to solve, the users need to either use your app heavily for several hours, check in on it occasionally a few minutes at a time, or only use it when there is an issue.  Their interaction with it and their goals should drive the story process.
    • In most media situations, the characters are something you observe or inhabit. You relate to them thorough their actions and how you process that reaction. In the agile world, we are trying to help them achieve that goal, even if it’s something you see as  mundane as reporting data, or something exciting like a drone network in Africa.
Posted in Uncategorized

Stories without a net

Lately I’ve been working on a project that is envisioned as a “Proof of Concept”.  It’s a big important problem, and there is already a good direction in which to try and solve that problem.  The current solution is very large, error prone, and unable to scale.  However the team has been working isolated from all but a few folks who knew what was needed.  We had a very specific end state ( regulatory ) so there was lots of information about what it needed to do at least.

As I’ve been learning and researching the things that the product would do, I was doing it with the local team, lots of public documentation on what it had to do, and some bits and pieces of the current system.  Hearing some of the horror stories and issues gave me a lot of context for not only the problem space but what the solution needed to accomplish.

So for a little more than a month we created stories, sprinted, demoed, and iterated on the concepts and ideas we had.  It’s the first time I didn’t have customer contact or information from users for a system and it was both freeing and frustrating.  Freeing in a sense of anything is possible, just solve the problem. Frustrating from the fact that nobody was telling us if we are on the right track.

We recently did a demo for the larger business / IT team and it looks like we are on the right track.  So with that I have some suggestions if you happen to find yourself in this situation:

  1. Start with what you know.
    1. If the team already has an idea or you have something firmer than Jello, you can get started. It’ll change later.
  2. Find out what the end state is.
    1. Knowing where you need to end up is important.  You can change a lot of things along the way to that end goal but you have planned out some ideas.
  3. Show something to somebody as soon as you can
    1. Demo to the team, to the management on your side, to other interested people.  Get any feedback you can.
  4. What problem are you trying to solve
    1. I think this is key.  Don’t get bogged down in technology discussions or architecture.  What does the product need to do ( 30 sec pitch ) and how can you build a MVP to test that theory.
  5. Iterate and Learn
    1. What we’re doing isn’t final, or going to be kept. We have been learning ( new technology ), training ( new folks ), and getting setup to deliver.
    2. The things we learn will change the system, the 1st iteration will be supplanted by the 4th one.  That ‘s more than ok, that’s the best option in the end.


I’d much rather be working with our customers and working on solving their issues, and at some point we will be.  Until then, there is always something that can be done to prove your MVP.

 Safety 3rd

Posted in Uncategorized