If not you, who?


In my current firm we are wrestling with many of these same issues and trying to figure out appropriate staffing. Do we need a sales engineer and if so what would that person do? Do we need more product owners? How much should product managers or product owners be involved in selling to strategic clients? How can we keep a market focus (building for the many) while not losing a key competitive advantage we have in providing outstanding service to the one? These are key questions and this post from an industry expert offers one way to answer them.

Anyone reading this want to share your thoughts? Please comment here or connect with me on Twitter and let’s talk more.

Originally posted on Under 10 by Steve Johnson:

Don’t drop the ball; either arrange for someone to catch it or let your boss know.—Julie Bick, author, All I Really Need to Know in Business I Learned at Microsoft

My first business trip was from Dallas Love Field (DAL) to San Antonio (SAT) on Southwest Airlines. (Exciting, eh?) On the flight, I was seated next to our VP of Marketing and we talked about marketing and sales. She said something that has been a guiding principle for me throughout my career. “Marketing people move all customers forward in their buying cycle; sales people move one customer forward.”

shouldnotToday I help teams clearly define their roles and responsibilities. What accountabilities to assign to which titles. This “one customer vs market full of customers” rule provides a lot of guidance and we always identify a number of activities that should be done by others.

However, we can’t just stop doing them…

View original 400 more words

An awesome and inspiring model

I will blog more about this soon but had to put it up as soon as I saw it.  This is about Agile development at Spotify.  I’ve got a link here to part 1 (of 2) but once you see the first part it gives you a link to the second.  Maybe you’ve seen this before but I encourage you to check it out if not.  It’s all about the culture at a company trying to balance autonomy with alignment, mission with innovation, and productivity with fun – and the discovery that these are not necessarily opposites.  As I said I’ll share more on this soon but wanted to post the link right away.


Not surprisingly, one thing I like about this is how they describe this as a journey they are on to find more and better ways to flesh out these goals.  The theory is awesome but in practice the reality is that in truth it’s not that simple.

Goals for 2015 and beyond

I spent some time today writing up goals for 2015 and for the next 5 years as part of my ‘end of year review’ for work.  The goals flow from my performance review ending 2014 as well as from my reflections on what I would like to do and how I would like to grow in the next year.  Here are some of my goals:

  1. Grow as a product owner by getting some training, attending some area meet-ups, and reading more books.
    1. I’m going to the Scrum Alliance training in January in Wilmington and would be glad to connect with others either at this training or who have been to similar Scrum Alliance training events in the past.
    2. If you’re part of a Philly-area Agile group I’d be glad to connect.
    3. If you know some great books on product development, Agile, scrum, and the like please recommend them.
  2. Communicate better about what the development team has been doing in a given sprint.
    1. Recently I recorded a web demo for our team and I think I will do more of these in 2015 because it gives me a way to showcase what the team has built.
    2. As we roll out new features and as we explore potential enhancements, I plan to get end-users involved in more user-acceptance testing and review and to spend more time with clients and prospects discerning what the market is looking for.
  3. Train more people on the team to give basic product demos for prospects.
    1. Showing our software to potential clients is something I do really well (that’s what folks tell me anyway) and also something I enjoy; but to grow the way we want to I have to leverage my own skills in this area by training and equipping other people on the sales and marketing team to communicate the central benefits of our product and the problems we are solving for real clients.  I like training people so I’m looking forward to doing more of this.

These are more professional goals; but I have personal goals that overlap these a bit.  As usual I plan to do a lot of reading (I generally get through 10-15 books each year), to keep working on my distance running and my squash game, and to spend as much time outside as I can.

What are your goals – personal and professional – for the new year? Feel free to share them here in the comments section.  Someone said if you aim at nothing you’re sure to hit it, so I’m a big believer in setting goals.  Of course, having a goal and meeting it aren’t the same thing because in truth it’s not that simple.

Regrouping on Agile planning

Way back in January I posted a plan to write about Agile planning (see the entry here: http://wp.me/p2BePD-3x). It was supposed to be a ten-part series that I hoped to complete in 3-4 months.  The basic outline I wanted to cover in this set of posts was as follows:

  1. What’s so hard about Agile planning?
  2. The planning onion (or is it a flame?)
  3. Listening to the market – outside in
  4. Product roadmaps
  5. When worlds collide: functionality that impacts across products
  6. Sprint planning: how much is too much (or too little)?
    1. Incorporating code refactoring and addressing technical debt
    2. The pull mentality versus pushing
  7. Incorporating new feedback between and within sprints
  8. Planning for today – would Kanban help?
  9. Context is crucial but planned work should be in small chunks: Tell me a (short) story
  10. Use the retrospective to improve future planning

Almost a year later and I have completed only the first six of these topics.  Some of them have been two- or three-part posts, and I have also written about a few other things.  But mostly I have been much busier than expected (with work and with fun outside interests).  I mentioned that the lack of an editor has slowed me down a bit, and the fact that I have received some mixed messages about how useful folks are finding my blog has not been very motivating.  It’s also true that I have found it challenging to refine and articulate some of my thinking around Agile planning.  It really is true that I find this stuff less simple than it might appear and I want to share the complexities that I am wrestling with.

Even as I plan to restructure this blog to include additional areas of interest for me, I still want to wrap up with series.  My thoughts on incorporating feedback are almost complete so hopefully I will get this out before being completely swamped by the holidays.  Then early next year I will write about the final three topics and incorporate them into the new format of my blog.

As I have started writing again I am rediscovering my enjoyment in it.  I have also appreciated some fresh ‘likes’ and ‘follows’ from other folks out there; knowing that someone is reading this blog makes a huge difference in my energy level as a writer.  So stay tuned for the last few posts in my Agile planning series and get ready for some more new things on this blog.  I hope you’ll enjoy reading it as much as I like writing it, but I know that in truth it’s not that simple.

Update on what’s coming soon

I started writing this blog a couple of years ago with the intention of posting once or twice a week.  I wanted to share thoughts coming specifically out of my work as a product owner developing and selling software that enables users to manage their financial risks.  I wanted to share things I was learning both at my job and through the reading and thinking I did on Agile, Kanban, Lean and other aspects of product management.  And I hoped that just maybe I could contribute to or even help shape the conversation around product development both in my firm and more broadly in the industry.

There have been some successes in this effort.  For much of the past few years I have been able to post regularly – more like every 10 days than once or twice a week, although I posted every day for a two-week sprint at one point.  I have heard from some folks how much they appreciate my posts – some people I work with and other total strangers over Twitter.  And the writing I’ve done has helped me grow my own thinking.

There have been struggles as well.  As my role at work has evolved a bit it has been tougher to post regularly; since my previous editor left the company it has been harder to fully polish my thoughts and so several potential postings have been stuck in the ‘draft’ status for months.  And while I have gotten some positive feedback on my writing there have been others who’ve told me I’m wasting my time.  All of this has led to a major decline in the frequency with which I am posting here.

At the same time, I have continued to enjoy thinking and talking about product development and Agile.  I’ve read lots of interesting books, blogs, and articles.  And I’ve expanded the set of things that I want to write about.

So as I look into next year I plan to re-invigorate this blog and expand its content to include some of my other interests.  I’ve already changed the look of the blog a bit and I may make further modifications.  Once I have a little more clarity on what I plan to do, I will share my thoughts about it here.  But I can tell you to expect a few things:

  1. Posts will become more regular again
  2. Posts will often be shorter and (unfortunately) a bit less polished as I try to get more thoughts out there more quickly rather than editing my posts as thoroughly (so please be gentle dear reader with the typos I make and any diminished clarity and PLEASE leave comments or questions if you think I’ve misstated something in my future posts)
  3. I will write about more topics, including things like what I’m reading about and listening to or ideas on leadership
  4. I will share more links about things I’ve found on the inter-webs – so please feel free to point me to your favorite blogs on the topics I write about and I will be happy to repost or comment on them in my own blog
  5. I will finally finish the ’10 aspects of Agile planning’ blog series that I started many months ago (more on this in my next post)

I hope all of this will be interesting and even useful.  I still hope to add to and influence the conversation about Agile product development even as I also write about other things.  And I love to know that these words aren’t getting lost in the internet so please let me know if you’re reading these posts.

No matter what I’m writing about, I’ll continue to share my thoughts, questions, struggles and issues as I seek to learn more.  All opinions will continue to be my own and open for discussion because in truth it’s not that simple.

Doing sprint planning well

In my last post I stated that the goal of Agile sprint planning is for the development team to know what pieces of working functionality – prioritized by the business – they can commit to delivering with relative certainty at the end of the two-week sprint.  I also wrote that the keys to planning are priority and effort, allowing the team to pull as many of the most important items as possible into a given sprint and giving flexibility if they find capacity changes.  Here I want to share some thoughts on the best ways to do sprint planning.  As always my ideas are informed both by the reading and thinking I do on this topic and by things that I have seen work well in my current context; and of course all ideas are ultimately my own so direct your critiques my way here or on Twitter @asbiv.

We are spending a lot of time and energy thinking about the best ways to plan in my current company, so many of the topics I’ve been writing about are issues we have been wrestling with in the past few months.  As regular readers of this blog know, I work closely with two project teams and have been doing so for the past year or so.  One of the teams is smaller and focused on adding specific features to a developing product; the other team is larger and working on multiple facets of a product with more users in the marketplace.  Both teams work in two-week sprints and take time for planning both short-term and longer-term items to be addressed.  As these two teams (and the other development teams across our company) have learned about and practiced sprint planning, three essential components have emerged that make for effective sprint planning:

  1. A prioritized backlog free from clutter
  2. Appropriate estimates of near-term items (2-4 sprints)
  3. Balancing the need for refactoring with the desire for new functionality

In our experience, doing sprint planning well on a consistent basis requires these three key elements.

For some product teams, the backlog becomes a veritable dumping ground for any idea, tweak, enhancement, feature or product change that has ever come up.  Unfortunately this makes the backlog almost useless for planning purposes, since it is cluttered with ideas of questionable merit many of which may never get worked on.  I’ve written before (for instance here and here) about the importance of grooming the backlog to make sure it captures the items that the team actually plans to work on and indicates some level of priority for the items.  The other element of a strong and useful backlog is that items are clustered around elements of usable functionality.  The teams with which I work think of these as epics and user stories which provide adequate detail on the important aspects of functionality to be developed and prioritized (you can find hundreds of pages on the web about these concepts, but why not start here if you want some basic information).

In addition to a prioritized backlog free from clutter, the second key requirement for effective sprint planning is having appropriate estimates for near-term items.  If as I stated above the keys to good sprint planning involve knowing priority and effort, then this second component provides insight into the effort anticipated in developing the next pieces of important functionality.  A motivated development team can pull what they have capacity to work on from the prioritized backlog in an informed manner when they know the effort involved in completing a given task.  Working with the product manager and product owner, the development team can plan how much to commit to for a given sprint by reviewing the estimates of the highest priority items and deciding together what clustered sets of stories to work on.  Assessing the effort involved can also feed helpfully into the prioritization process itself; a new feature might seem more important to build if the effort required is relatively small but less crucial if it would require a larger investment to develop.

While there are many different ways to create estimates for items on the backlog, planning poker is one that the teams I work with have found helpful.  This simple process (which you can read more about here if you’re interested) allows the team to collaboratively decide the relative effort of a given task while also ensuring that estimated items have appropriate levels of detail before the team commits to delivering the requested functionality.  The same end result can come from collaboration between the product owner and development lead determining the approximate effort (as in small, medium, or large) and the development team further estimating more detailed tasks to gain greater granularity and precision on the estimates.

While understanding priority and effort are fundamental to engaging in effective sprint planning, the third element I mentioned above – balancing the need for refactoring with the desire for new functionality – adds a vital ingredient especially for on-going development teams.  One of the central principles for Agile software development is that continuous attention to technical excellence and good design enhances agility, and this means that the team must give regular attention to cleaning up older code so that the product functions as effectively as possible.  Addressing this need shouldn’t be left to chance or squeezed in if there is time; instead the teams I work with make it a priority to spend some time each sprint refactoring existing code even as we also build out new features.  Of course, this refactoring should have understandable business benefit for the product manager in terms of enhancing scalability, speed, or reliability for clients or reducing the support burden for the team.  This keeps ongoing investment in the product codebase as part of the overall set of priorities for the product.

As I mentioned in my last post, there is a ton of material available on the web and elsewhere about sprint planning and estimation.  Here’s a link to a set of articles exploring these topics if you’re interested in learning more: http://bit.ly/1nyHBn4.  Planning well is crucial to ensure that the team stays efficient and focused on moving the product forward.  Too much advanced planning wastes time because priorities change, new things are learned, and unexpected issues arise; on the other hand, too little planning means the team doesn’t know what to work on or doesn’t have enough information to start working on prioritized items.  A prioritized backlog with meaningful estimates on near-term items provides valuable insight as the team does its planning, while balancing continuous improvement on existing code with development of new features allows the team to plan progress in both key areas.  When the team knows the priority of issues in the backlog and the effort required to address the near-term items, they can make plans about what pieces of working functionality they can commit to delivering with relative certainty for a given sprint.  Planning this way doesn’t solve every issue that might arise for a team of course because in truth it’s not that simple.

The goal of sprint planning

Early on in this set of blog posts about Agile planning I talked about the common image of the planning onion, in which there are different layers of planning that start with the widest strategic view and progress all the way to daily planning.  So far I have written about strategy and portfolio planning in the earliest blogs in this series, then progressed to talk about product and release planning when sharing thoughts on product roadmaps.  Now I’d like to focus still further in and discuss planning for a specific sprint or iteration.  In my current context we work with two-week sprints and so my thoughts relate to team planning for a given two-week period of time.

This is really a huge topic; I could create several posts about it and people have written whole books on sprint planning.  Maybe I will write more extensively about this topic in the future, but for now I want to share thoughts on two big areas (broken into two posts):

  1. What is the goal of sprint planning?
  2. What is a good way to do this planning?

Weaving through both posts will be the idea that the key to effective planning is understanding priority and effort – relatively how important and how difficult are the various tasks.  This allows the development team to pull as many of the most important items as possible into a given sprint while also giving them flexibility if they find capacity changes.  With all of this in mind, let’s begin by talking about the goal of sprint planning.

To understand the goal of sprint planning, it is useful first to think about the reasons for developing software using an Agile methodology in the first place.  In this context several of the principles behind the Agile manifesto standout to me, including these:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

Working software is the primary measure of progress (for a complete list of the Agile principles see this link: http://agilemanifesto.org/principles.html)

The goal of Agile development with sprints is regularly delivering the most important increments of working software to the customer.

With this in mind, we can talk about sprint planning as having twin goals, one from the development team’s perspective and one from the viewpoint of the business.  For the coders, testers, designers, and architects working on developing the product, the goal of sprint planning is to make clear what they should work on next and roughly how much effort it will require.  For the business, the goal is to know what increment of working software they can expect at the end of the two-week sprint.  Pursuing these twin goals lets the development team know what to work on for the sprint and the business know what to anticipate from the sprint.

Taken together the goal of Agile sprint planning is for the development team to know what pieces of working functionality – prioritized by the business – they can commit to delivering with relative certainty at the end of the two-week sprint.  Regularly making and fulfilling sprint goals deepens the trust between the business and development teams as both come to understand the capacity or velocity of the team to produce on a consistent basis.  Certainly there are times when unanticipated problems arise that complicate development and compromise the team’s ability to deliver on the sprint goals – just as there are times when obstacles prove easier to overcome than expected and the team has added capacity at the end of the sprint.  However, making clear and realistic commitments through the regular process of sprint planning strengthens the relationships among the development and business team members as they together identify the most important things to focus on each sprint.  Disciplined planning promotes this focus as all the relevant stakeholders know what to expect each sprint.

In my current context I have seen greater benefits flow from sprint planning as we have invested more time in doing it well.  I’ll talk in my next post more about what ‘doing it well’ looks like for us, but for now I can confidently state that having the team take time to think through and plan its commitments for a given sprint makes the entire development process more satisfying both for the development team and for the business.  It doesn’t mean we never have problems meeting sprint goals or that we never have to abandon those goals mid-sprint when something unexpected occurs (you know that if you’ve been reading this blog for any length of time); but planning what we want to accomplish in a given two-week period and then tracking our progress against those goals energizes our team and deepens the trust that the business and sales folks have in our work.  Getting to this point hasn’t been easy of course because in truth it’s not that simple.