Assessing Readiness for Speed - Product Management
A few articles ago I started a series on speed with the intent to create an assessment that could be used by new and experienced teams to gauge their readiness for speed and ability to perform with agility. Now, here I am three articles later and I am still struggling to start on that assessment. So, as with anything I intentionally ignore or avoid, I have to ask myself, what is it that is keeping me from doing this?
As I reflect on my hesitation, I think about what it would be like to create a similar assessment for effective parenting. My first thought (and maybe yours too) is that anyone who thinks they can define good parenting in specific and universal behaviors is either way too pompous or totally out of touch with reality. Parenting practices, like project team behaviors, are just too situational. To try to create a single set of practices that epitomize the perfect parent or the perfect agile project team comes across to formulaic and equally out of touch with reality. In fact, at some level, agile is a revolution against this institutionalization: People over Process.
That being said, I do think that in the early stages of team development, adherence to some tried and often true behaviors, sometimes referred to as "best practices," can provide the necessary boundaries and guide posts by which a team can empirically gauge its readiness for speed. While these practices may not all apply or be appropriate for every team in all circumstances, they can be used as a call to consciousness, where deviation or adherence is a deliberate and acknowledged choice.
So, at the risk of being considered either pompous or out of touch, I'm going to take a shot at identifying and assessing readiness for speed. Starting with this article and over the next several articles, we will virtually and collaboratively create a Speed Readiness Assessment. Each article will focus on a specific area. Each area will be primed with a preliminary set of empirically measurable questions that I will post to get the ball rolling. Then, after each article, anyone who wants to make a contribution with additional questions or ideas can respond through the blog comments. Each week I will collect and consolidate the ideas and repost the updated assessment on the site for all to use or comment on. So, let's get stated.
The Three Disciplines
When I work with development teams, looking at the team as a whole can be overwhelming. I remember helping my daughter clean her room, an equally daunting endeavor. It helped to break the whole into parts that could be worked on, not entirely independently, but at least separately enough to focus energy and see progress: something that could be visually measured. For software development teams I like to break the team down to three primary disciplines: Product Management, Project Management and Software Engineering.
Although each of these areas has numerous certifications and bodies of knowledge, I am deliberate in using the term "discipline." Competency or capability might be more in vogue today, but to me the word discipline implies a level of conscious competence garnered through experience that is necessary to deal with the myriad of situations that can occur when individuals behave as a team and when the team meets the organization. If you have ever heard the phrase, "Yah but, in my team/organization…" you know what I mean.
The Discipline of Product Management
I'm starting with Product Management because in the lifecycle of an application or product, it all starts with an idea or shared vision. Without effective Product Management there will be no vision to share, no purpose to inspire, and no direction for the team to focus on. At its fundamental level, Product Management is designed for and responsible to answer the questions Where, Why and When. Where will we be when we are done -- the vision; Why are we doing this -- the business value; and When do we need to be there to realize the optimum results -- the roadmap.
The discipline of Product Management is not exclusive to the Role of Product Manager (or Product Owner) and in fact the more team members who exercise this discipline, especially from their unique perspective and skill set, the more rounded and robust the product will be. While all team members should be asking and answering the questions where, why and when, Product Managers/Owners are expected to be driving these answers and therefore will benefit most from exercising the practices that develop the discipline of Product Management. Team = Software.
However, different organizational structures, team sizes and product characteristic may warrant exercising varying types and degrees of Product Management disciplines. Additionally, the discipline may be embodied in roles like Business Analysts, Architects and User Experience as well as many other roles and titles. Each of these may display certain visible behaviors or produce tangible outputs that are evidence of their discipline. These are the types of observable behaviors we will attempt to capture in the Speed Readiness Assessment.
So, I'm not going to use this article to describe or define the discipline of Product Management in detail, but rather to introduce the questions in the assessment.
The Assessment Questions
Each assessment question should be an objectively measurable behavior that is a revelation of the underlying values and principles as defined in the Agile Manifesto. Some may be universal and some may be product- or organization-specific. If you have seen something working, or the absence of something causing problems, it is probably a good data point for the assessment. Pass it along. The goal of the assessment is to present a collection of best practices and behaviors that teams might consider doing. This "open source" approach will hopefully attract a large ecology of ideas. So additions, subtractions, improvements and comments are all welcome and will be incorporated into the assessment for all to use and enjoy.
The Safe Harbor Statement
One caveat. Caution should be taken when proposing ways to measure and (especially) evaluate people's behaviors. Keep in mind the old adage, "Tell me how you'll measure me, and I'll tell you how I'll behave." The behavior is never as important as the intent. Unfortunately, intent is much more difficult to measure than behavior. Rather than being dogmatic about the practices, it is important to keep in mind the main metric that should always be used: Is business value being delivered to the business? The purpose of this assessment is not to achieve a specific score but rather to see incremental progress in disciplines that enable a team's readiness for speed. You might want to consider using The Perfection Game as a format for rating each observable and empirical data point, determining which ones are applicable, and then use that feedback to get better at delivering business value. Agility is not the goal, only one method to achieve business value. So, as you review the Product Management discipline questions in the assessment, keep the goal in mind. We are looking to develop disciplines, not institutionalize the "right" behaviors or deliverables.
After reviewing the assessment, please add your thoughts and ideas on ways you can witness the discipline of Product Management in action. The assessment will also have placeholders for the other two disciplines, Project Management and Software Engineering, which will be covered in the next articles. I look forward to hearing all your great ideas and collaborating with such a diverse and experienced group. To quote Ken Blanchard, "None of us is as smart as all of us." Thanks in advance for participating.