Daily planning

Many months ago I started writing a 10-part series on Agile planning (you can read the first post here if you want to catch up; then keep going forward from there to find the other pieces, most of which are tagged as “Planning”).  Since that ambitious beginning I got frequently sidetracked and so I never made it past the seventh section of this planned series.  Here I want to pick up where I left off and talk about part eight of that original plan.  I’ve already discussed the context for Agile product development planning, the importance of listening to the market to discern meaningful problems to solve, and the construction of roadmaps for both an individual product and the broader product portfolio.  I wrote about sprint planning (using the two-week iterations that we practice in my current firm as an example) and the need to incorporate new feedback both within and between sprints to ensure that the team is focused on building the most important thing.  With this post I want to talk about daily planning.

As a brief side note, I’ve been reading and learning a lot about different approaches to Agile this year.  I’ve been to several Scrum Alliance area meetings as well as their Certified Scrum Product Owner training (and I plan to attend their Scrum Master training in the fall with a colleague).  If you’ve been reading my blog lately you know I am reading a book about XP entitled The Art of Agile Development.  And for both my job and my personal life I have been exploring Kanban as a way to track the progress of items on my plate.  Elements from each of these approaches – along with other things I have read or learned about practicing Agile – have informed my own perspectives on this topic.

One key to daily planning is the daily stand-up meeting; Scrum, XP and Kanban all have a version of this as a core practice and it’s not hard to understand why.  Having the team meet daily to discuss progress from the day before, expectations for the current day, and impediments that block potential development facilitates the team’s focus on pursuing their sprint goals together.  This daily communication promotes collaborative problem solving, assures efficient knowledge transfer as new issues and opportunities arise, and keeps everyone aware of the team’s incremental progress toward the sprint goals and the broader product vision.  Brief daily stand-up meetings (even if folks are actually sitting down) serve a number of valuable purposes – including providing a forum to surface questions that can be addressed outside of the meeting itself – but they are crucial in my experience to allowing effective daily planning for the development team.

A second item that I have found very valuable in encouraging daily planning is some sort of visual representation of the team’s progress throughout the sprint.  This could be a Kanban board (learn more about these here if you aren’t already familiar with the idea), burndown chart (check out this link if you want more details on these) or some other way of representing what the team is working on and what progress is being made to get each task accomplished.  There are plenty of online tools that can provide this visual depiction, allowing even remote teams to have a consistent view of the most important tasks for the sprint and what stage of progress each item is in on any given day.  When larger tasks or stories can be broken into daily pieces (or smaller) it becomes even easier to plan for the day and for the team to track its daily progress.  Reviewing our Agile board at each morning’s scrum allows the teams I work with not only to decide clearly what will be worked on each day but also to know if we are on track to meet our sprint goals or if instead we need to adjust our plans.

Employing these elements of daily planning and cooperation leads to daily progress toward established goals even as it provides room to respond to changes.  With the frequent delivery of working software as a core principle behind Agile development, practices that promote and support daily delivery of incremental steps toward broader product goals play a key role in effective execution.  Balancing wider strategic goals for the product lifecycle with tactical daily progress on specific fixes and features facilitates team focus on accomplishing the items most important for success.  The discipline of daily planning does not ensure that the team won’t get side tracked of course because in truth it’s not that simple.

Perfectly Effective Short-term Results


More great thoughts on leadership here; hope you all enjoy them.

Originally posted on Applied Product Management Leadership:

I took this picture at the local office watering hole that I frequent in the mornings.  Yes, I admit it, I like my coffee … and generally the stronger the better.  No frills either, just black.

coffeeBut I’m betting you probably don’t read these posts to understand my coffee preferences, and are likely wondering what this has to do with leadership.  Good question, but first take a long look at the picture and tell me what you see.

At first glance, one observation would be that a conscientious colleague made sure a mess wasn’t left at the coffee pot.  To whomever took that initiative, thank you. But as a leader, I am going to ask you to look closer because there is another underlying observation to be drawn.

View original 545 more words

Technical debt

The topic of technical debt came up in a couple of settings this week at work.  I’ve written about this topic before here (among other places) but two different situations raised this issue in the past week and a third provoked an interesting set of questions.

First was a response from one of my readers.  He noted an unfortunate tendency even in Agile development shops to focus on new projects and features while allowing existing products that work ‘well enough’ to accumulate technical debt that the client support team has to work around.  In spite of the Agile principle emphasizing, “Continuous attention to technical excellence,” there is generally more excitement in developing something new and cool than there is for refactoring existing code and decreasing technical debt.  In their strategic and tactical thinking, the product manager and product owner have to remember the importance of maintaining a clean and easily supported codebase, even if doing so decreases development velocity in the short-term.

The second context in which technical debt came up this week was my continued reading of The Art of Agile Development by James Shore and Shane Warden.  In discussing XP adoption for existing codebases, they make the following assertion:

The biggest challenge [in starting to use XP on a legacy project] is setting aside enough time to pay down technical debt.  If you have a typical legacy project, your current velocity is a polite fiction based on shortcuts… You incur new technical debt in order to meet your deadlines.  To improve productivity and reduce bug production… you need to set aside extra slack for paying down the existing debt.

I have seen firsthand on projects in the past couple of years the palpable difference it makes when development teams prioritize both writing clean code and refactoring existing code to diminish existing technical debt.  The payoffs that come in the form of easier client support, faster issue analysis, and more confident new coding all make a commitment to regular refactoring well worth the investment of time and effort.

Which brings me to the third and most provocative context in which technical debt surfaced this week.  In talking about important prerequisites for a company wanting to move to XP, the authors of The Art of Agile Development call for “compensation and review practices that are compatible with” this programming approach.  A group of people in my firm who are reading this book together raised the question of what it really looks like to provide proper incentives for pursuing the XP practices.  Are people rewarded for taking extra time to write cleaner code and for refactoring code in other parts of the system because it makes everyone’s life easier?  How do you balance encouraging development teams to focus on the critical path to building a minimum viable product with the value of wider refactoring in the broader codebase to benefit the entire product suite?  When a specific business team is watching its development spend is it ok for the coders to clean up related functionality or should they leave those issues for some future team to (hopefully one day) address while narrowly focusing only on their own product code?  How much – if any – slack is acceptable to leave in a sprint plan when a team wants to get a marketable product delivered to prospective clients before a competitor can develop it?  We batted these questions around a bit – at both a theoretical and a practical level – but couldn’t settle on any clear solution because in truth it’s not that simple.

What do you think?

The role of strategic thinking

I came across this quote in a book several of us are reading in my firm:

The job [of the product manager/product owner] is to maintain and promote the product vision.  In practice, this means documenting the vision, sharing it with stakeholders, incorporating feedback, generating features and stories, setting priorities for release planning, providing direction for the team’s on-site customers, reviewing work in progress, leading iteration demos, involving real customers, and dealing with organizational politics. (The Art of Agile Development, James Shore and Shane Warden, 2008)

This set of responsibilities – which corresponds well to the framework for product management that Pragmatic Marketing lays out here – outlines the core strategic functions of a product leader.  Whether the person exercising this role is called a product manager (the title we and some other companies use and that fits with general XP practice and Pragmatic Marketing) or a product owner (the title typical Scrum practice uses), she carries the strategic direction for the product.  Her job is to think big picture, to know the market well enough to define core problems to be solved through product development and to understand internal decision making well enough to navigate issues of resourcing and politics.

Carrying out this strategic role effectively requires a mix of practical and people skills in addition to curiosity about understanding the market and solving problems.  It also requires a strong tactical person working alongside the product manager as a true partner and not just a sidekick (think this and not this).  Whether translating market problems into discrete user stories for developers to address or communicating technical tradeoffs to the right stakeholders when decisions about direction are needed, a tactical teammate enables the product manager to stay focused on pressing strategic issues.

Which brings me to my role.  The company where I work currently calls this a product owner and much of what I do is tactical.  Similar to what a scrum master does I facilitate our daily scrum meetings, organize and help lead both our planning meetings and our retrospectives, provide subject matter expertise or pull in insights from those inside and outside the company to provide this expertise when it is needed, and generally make myself available to the design and development teams.  At the same time I also work closely with the product manager and the sales team to understand what issues are emerging in the market, to sort through priorities for future development, and to test what we are building to make sure that it meets the identified business needs

Regardless of the title (and I’ve been called a lot of different things over the years) the image I regularly return to in describing my job is that of bridge builder.  I need to understand and communicate well with both the development team and the business team, helping folks discuss benefits and tradeoffs during the process of creating, marketing, and supporting our products.  I am ‘in the trenches’ with our coders, designers, and testers making sure that they know what to work on next and can get answers to questions they have; and I am often on the ground with the sales and support teams learning up close what potential clients are wrestling with and what aspects of our product don’t work as smoothly as we hope.  In the midst of what can be very tactical and specific I also poke my head up to the strategic level from time to time to ensure that our incredibly talented development team is adding the features and fixes that the product manager has identified as most important.  There is a lot about the product owner role in my firm that is tactical in nature, but in truth it’s not that simple.

State of the blog

The past few months have continued the trend in my life of finding very little time and energy for blogging.  Those of you who follow me on Twitter (@asbiv) may even have noticed that in the past month I’ve been way down on my tweeting as well.  Lots of factors have contributed to this:

  1. Work and home life have both been extremely busy leaving me little time or intellectual energy for blogging (though this lack of creative capacity hasn’t kept me from some excellent reading and some fun television watching – check out Orphan Black if you get the chance).
  2. My job has kept me focused on a number of tactical items which are harder to draw material from for a more big-picture and strategy-focused blog (I talked some about this here: http://wp.me/p2BePD-6h).
  3. Trying to write regularly about multiple different topics actually left me feeling less clear on what to blog about (some of my thoughts about this are here: http://wp.me/p2BePD-6f).
  4. Part of why I started blogging and tweeting was to contribute to a wider conversation around topics that interest me (Agile software development and leadership being two of those themes) and so when I’m not getting many responses to my blog posts or tweets it decreases my motivation for writing (though I’ve been glad to reblog good posts I’ve come across from other people in the past month or two).
  5. I’ve also been spending more time pursuing other interests lately – including lots of the reading I mentioned above as well as getting time outside and time with good friends – which has meant less available time to blog.

Over the summer I want to get back to regular blogging (as well as re-invigorating my tweeting).  I’ve got a few ideas about topics I want to discuss, and I also plan to resurface some of my older blog posts that address some key topics that continue to surface on the team that I work with.  I hope to get to posting weekly but we’ll see how it goes.  I think I can make that happen but in truth it’s not that simple.

A Predecessor to Integrity in Leadership


Good reminders about a core leadership quality.

Originally posted on Applied Product Management Leadership:

Last week my post quoted Howard Schultz … the currency of leadership is transparency.  The point being that people are looking for open, honest leaders … leaders they can trust because they are consistent in behavior and truthful … leaders who have integrity!

Make no mistake, being a leader with integrity is not an easy ask!  You may be asked to make bold and sometimes unpopular decisions (will you seek what is best for the business rather than yourself?)… you may be held accountable when things go wrong (will you accept responsibility, or pass blame?) … you may be asked to say or do things to meet the numbers (are you willing to compromise, even just a little bit?).

View original 531 more words

What Were You Thinking?!


Some good thoughts here and links to other interesting posts.

Originally posted on Applied Product Management Leadership:

Whether you call them a town hall meeting, an all-hands meeting, a quarterly business review, a state of the business address … I’m sure we’ve all had the opportunity to sit and listen to key business leaders within the companies we serve speak to the broader company.  Sometimes it is compelling, other times not so much.  And sometimes we are left with the thought … “what were they thinking”?

I have to admit that often times I wonder about that about key leaders I’ve been exposed to.  Not in the negative context that you might be imagining right now, but rather in the context of thoughts like:

  • what drives them?
  • how did they get to where they are today?
  • what is the essence of what makes them a good leader?

If you ever have the opportunity to sit and chat with a key business leader to explore these types of questions, jump at…

View original 547 more words