Agile style customer collaboration

Don't we all aspire to build a product that will be a smash hit success? If you are interested in how the product team can engage customers to make this a reality read on.

One of the founding principles of Agile Software Development manifesto teaches us to value customer collaboration over contract negotiation. In this modern world we often hear calls to "fail fast and often" and for "end of sprint customer demos". As the product managers of hi tech products we ought to accept the uncertain nature of innovation. At the same time, while we are innovating, we should strive to keep up with the ever transforming reality of our customers world, avoiding the trap of the ivory tower. The ultimate success in our job comes with the product that every customer wants to have, not necessarily a research paper published in the scientific journal.

So, let’s engage our customers early and often. Let’s validate our vision, feature list, deployment diagram, UI wireframe, first build, second build and so on. Let’s not wait for feature completeness, code freeze or QA approval. Don’t be afraid, customers will understand the early nature of what they are looking at. They will appreciate the opportunity to have a say in what’s being built for them. Come back next sprint or iteration and show them your progress. If you are truly on track to develop something that will solve their real problems, customers will actively participate, test and feed ideas.

Don’t be afraid to engage too many customers. The more voices you hear the better you will be equipped to guide your team to deliver the product for your market rather than for a handful most vocal customers.

On a practical side, get ready to collaborate in three key areas:

• Questions: a message board of some sort might work well, make sure your responses are visible to others so you don’t have to repeat yourself;
• Ideas: if possible find a way to let your customers submit their ideas and vote up/down on ideas posted by others;
• Defects: look for a way to track them using a structured defect tracking tool.

As you move through the release cycle, you will notice the distribution between these three areas changes. Questions and ideas typically dominate the early part of the project. In the latter stages, as we often shift focus to stability and performance, majority of the feedback tends to be centered around defects. Anticipate this shift and be ready to deal with it.

Happy collaboration!

The dark side of Agile (Part 2 of 2)

6. Is the rest of your organization ready for Agile? Developing a great product is half the story. Depending on your organization setup and practices, you will need to go beyond your development team to conduct beta program, develop sales collateral, train account teams, solution architects and technical support to sell and service the new product, develop customer education content, set up back-office systems to accept and process purchase orders, etc. If your development team has only recently embarked on Agile path, chances are the rest of the organization will need some help to understand how they can best help successful product launch in this setting.

7. Arbitrary deadlines. I hear a lot about time, as opposed to feature, driven nature of Agile development. At the beginning of our project we had to put a stake in the ground, decide on the product launch date. We picked a date that happened to coincide with a major trade show so that we could announce a new release there. The thought was Agile forces us to work of the ranked backlog and produce a working product at the end of each sprint, so in theory any date is as good as any other. The problem I see with this arbitrary approach however, you are not necessarily giving your team adequate time to develop and introduce to the market a winning product.

8. Size is not everything, or is it? Not all aspects of new software product development can be broken down into chunks of work that fit in one sprint and still make sense. Consider a user interface design. What could fit in one sprint may resemble raw database tables exposed to the end user. On the other hand a wireframe that has gone through multiple revisions and validations by customers may seem to be too big to fit into one sprint.

9. The “wisdom” of not thinking too far ahead. I often hear: “it’s just software”, “let’s fail quickly and often”, “we always refactor later”. Not so fast. Later, we don’t have time because we are working on something else, so we end up with poorly designed product, missing on important objectives. Alternatively we create mountains of technical debt or technical stories. A good example, manually creating tens if not hundreds of similar views vs. investing some time upfront to have the same views automatically created by the product using data driven approach.

10. Multiple scrum teams. We have seven scrum teams and despite our efforts to follow best practices, we all the time deal with stories spanning multiple scrum teams. This leads to all kinds of drawbacks: developers from one team struggling to find time to help another team, Product Owners not always ranking/prioritizing their backlogs with respect to these dependencies, creating bottlenecks and delays for other teams. At the end of the day, the end to end stories and workflows are more likely to be left unattended without anyone fully taking care of them.

I am not trying to paint Agile in dark colors here. However, I have to admit adopting Agile approach like any other organizational transformation is a challenge in itself. In my future posts I'll look to share with you how I dealt with some of these issues and what happened.

In the meantime, if any of the points I described in this blog resonate with your own experience please share with me and other readers.

Thank you for reading, and may the force be with you!

The dark side of Agile (Part 1 of 2)

10 pitfalls likely to be encountered by the Product Owners

These days I rarely run into anyone who has not heard about Agile software development methodology. It has become almost universally accepted brave new way of taking on the world. Let’s admit it, it’s hard to stay unaffected, and most of us embark on this bandwagon. The benefits and advantages are all too convincing, sweeping the minds of young engineers and seasoned executives alike.

With so much said and written about what makes Agile good, I’d like to contribute to the knowledge pool about some challenges you might face in adopting Agile, so here come my 10 picks, in no particular order:

1.   The turnaround on customer feedback may be too slow. You read me right, taken too literally Agile can be used as an excuse for being slower than you need to be. Let me demonstrate this with an example. We work on large scale enterprise software destined for open market, so we don’t show end of sprint demo directly to 1,000s of potential customers. Instead Product Managers find a way to schedule customer demo to validate results of each sprint’s worth of work. In the ideal case, we can arrange such demo on Friday afternoon, at the end of the sprint. In reality the feedback does not rich the team till well into the next sprint. By the time this feedback is converted into a user story with clear acceptance criteria, the earliest the team can take this on is in the following sprint, i.e. nothing to show for 2 sprints. In our case this translates to 6 weeks for something that could have taken an engineer a couple of hours to correct. This inability to react fast is becoming more impeding as the project nears completion.

2.      You may end up developing the wrong product faster than you would otherwise. Okay, overall Agile can help speed things up, but here is another catch. If you don’t have enough seasoned Product Managers able and willing to take on the Product Owner role, be prepared for someone else to step into these shoes. Whoever turns up in the Product Owner’s role is responsible for day to day guidance for their scrum team, dictating essentially what gets done and what does not (the pitfalls of engineering driven organizational cultures has been a well-studied topic).

3.     Technical stories. I find developers like the idea of measuring team’s velocity by describing work that needs to be done in form of a user story added to the team’s backlog. From my point of view however, this is not a real user story, but a technical story. Why is this distinction important? Because in my experience, the Product Manager in the role of Product Owner, and by extension majority of real world customers, would not understand the essence, let alone the value of this type of story. This begs the question, how can a Product Owner rank such story on the backlog? If there are too many of these stories on the backlog, can the Product Owner still claim the ownership of the backlog, or is this now a development team who decides what to work on next?

4.     Underperforming super stars. Don’t be surprised to find your former top performers struggling in the new Agile culture. These seasoned developers have long basked in the glory of their superiority, and may find it less motivating to learn new roles, and to listen to the arguments of junior team members. In short, someone used to be star on the team will not fit in naturally in supporting role, or don’t expect Many Ramirez to thrive at pinch hitting.

5.      Generalists vs. Specialists. On a related note, Agile encourages erasing functional demarcation lines, asking everyone on the team to be able to work on any part of code, to be able to test, and contribute to the user documentation. The reality is, not all of us are equally good at everything. Taken to extreme this normalization of expected contribution leads to mediocre results. Just imagine the User Interface developed by color-blind database architect and IEEE network engineer who have neither talent nor desire to be good at GUI design (and let’s not go to Manny Ramirez pitching skills).

 

 

More to follow...

How to become a Product Manager?

I occasionally run into people who aspire to become a Product Manager and I try to help them with advice. Here is what I tell them.

A Product Manager is someone who owns the product from start to end, from cradle to grave, someone who ensures the product is a success in terms of market acceptance and profitability for the company. Essentially a Product Manager is a spirited leader and a CEO of the product.

This is a very diverse, multi-faceted role dealing with a broad range of aspects such as project management, design, market research, pricing, finance, operations, branding, public relations, communications and more. The good news is you don't have to be an expert in all of these functions, not as long as you can join or help build a team that is collectively strong in these areas. A good Product Manager knows how to succeed with rich but scattered resources that can be found at a large corporation as well as with scarce early stage start-up resources.

So, you might ask, where do I begin?

You do need to bring something to the table. And one thing that cannot be compromised is your expertise in one or more competence areas, be that the technology, the market place or the relevant industry. I really do think to make a switch into this career and succeed you have to be an established subject matter expert or on track to become one.

In addition to being an expert, rest assured your prior background will contribute as well. You may be an engineer or a scientist which will help you quickly establish good rapport with your product development team. You may be transitioning from sales and marketing, possessing knowledge and skills sure to come in handy when devising the best positioning and go to market strategy for your product. Dear I say, anything you were good at in the past will help you in your new Product Management career. Even if all it ensures is your attitude toward being good at whatever you do.

In any case, understand your strengths and strive to rely on them as much as you can. And where you know you have weaknesses seek to partner with other people who can complement you.

Good luck!