Product Manager as Team Members

There is that aspect of agile approaches that emphasizes the "whole team". For more details see here, here, here, here, and here. In my opinion this includes every person that works towards a deliverable of your project. Other people may call that a cross functional team since it not only includes the developers but other professionals as well.

So you may also need subject matter experts (SME's) for different areas. Maybe your application is extremely sensitive to security. Then you may want to include a security expert. Or your system might need to process a lot of data in which case you may want to include a performance expert. Or your system needs to interact with that old mainframe application in which case you want to include a person who is sufficiently familiar with that. In all these cases you may want to add the person full time or part time on an as-needed basis.

One of the most important people on such a team is the subject matter expert (SME) for the business side of the application. E.g. for a hotel reservation system you would want to have a person on the team who is familiar with that industry.

In some companies that domain expert is equal to the product manager. OK, I'm simplifying here a bit. But stay with me as the simplification is for illustration purposes only.

So with the above mentioned concept of the "whole team" you'd assume that this product manager is part of your team as well.

Well, just until a few weeks ago I would have said yes.

In the meantime I have come to the conclusion that I have to qualify this answer. And here is the reason.

To some degree, the product manager is part of the team in that she provides the input that is required from a product perspective for example the business side of the software.

But then, the product manager is also a customer. Do we treat customers the same way as we would treat our fellow colleagues?

Sure, it definitely would be nice and desirable if the relation would be just the same. We could have Friday afternoon drinks and have all the fun by telling all the war stories from the week. But wait! Is this really what you want?

Here is something to think about: Your customer is the one with the money (or budget). So here is something that is different. Your customer wants to spend money only on items that make sense to her. Your customer doesn't want to hear about that database problem that you encountered this week because it might actually mean - in her perspective - that the project is at risk, and all the sudden this anecdote, shared over a beer on Friday, takes on a life on its own.

Does this indicate a failure of the process? Does this mean you should exclude your customer from the team? I think that would go too far.

I think, based on my experience over the last 12 months, the customer (e.g. your product manager) is probably the most valuable person on the team. That means that person needs special treatment. Does that mean you should say "yes" to everything? No, it doesn't. Does it mean that the customer gets her way all the time? No, it doesn't.

So what does it mean? It means that you can still share most of the information with your product manager that you would share with your other team members as well. But it might mean that you rethink the way how you represent things.

Depending how you communicate with the product manager you craft her perception of you and your team. Say the same things, but say them in such a way that considers how you may influence perception. Don't walk on egg shells either. You still need to be self-confident, and that means for each conversation it is good if you have prepared a view. Don't go into a meeting without a view.

I have changed my model for how I look at internal customers in that I try to provide to them the same service I would provide to external customers. Although there is no written contract, a product manager (or any other business domain expert) is a customer to you, and the way you treat your customer will have a huge impact on the outcome of your projects. Work for your customer, work with your customer, come with solutions instead of problems, and ultimately make your customer happy.

"Healthy Noise": Introducing Automated Performance Testing

Starting with the current release cycle I have introduced automated performance testing for my project team. Not that we didn't test performance in the past, not that we didn't assess performance related items during a release cycle. But the fact that it is now becoming part of the automated development environment creates a number of interesting collateral effects. I'd like to highlight a few.

Reduced Latency

First of all there is the fact of performance testing itself. I strongly recommend not to wait until you are in the last few weeks or days before a release. That may be too late. If you discover a performance related issue then you may be forced to take shortcuts so your product meets performance requirements. And indeed in the past we already did assess the performance of the product throughout a release cycle.

What is different then? In the past we had to get performance engineers to set up the test, maintain test scripts, run the tests, analyze the results, identify root causes, and suggest solutions. Now the tests are written by developers and they are integrated into the test suite and then executed immediately after integration. No need to wait until a time slot with a performance engineer becomes available. The tests are now written and maintained by the developers. The performance engineer's time is freed up and in that time they are available to consult to the developers. The feedback loop is much shorter. A few hours instead of a few days or weeks. And this is also helps reducing risk since stories that may have a performance impact can be played earlier.

General Benefits of Automation

And you also get the obvious benefits of automation such as repeatability, lower costs, higher quality. Not that the performance engineers make mistakes consciously. As humans we are not fail safe whether we like it or not. So the major drivers for the automation were: cost, time, quality.

Impact on Behavior

But then there are less obvious effects caused be the introduction of automated performance testing. For instance I am observing that the thinking of the entire team is influenced by it. The performance aspect has been promoted and is not playing a much more important role in the considerations of the cross functional teams. Performance is built in instead of bolted on. Should a particular design or implementation cause a performance issue it can be dealt with immediately. Bad practices are no longer proliferated.

With our customers I am also observing an improved understanding of considering non-functional aspects such as performance engineering when deciding about backlog priorities.

And although it is not the main driver, and I didn't think of this aspect at all, there is also the impact it has on the developer. I sense that improving the development environment with automated testing has a positive impact on the morale of the engineering team. We continue to improving the development environment providing all people an opportunity to improve velocity while improving quality at the same time.

"Healthy Noise"

Certainly this change wasn't painless. The development teams had to negotiate with their customers the right amount of performance related work that needed to be accommodated in the backlogs. The automated build environment has to be extended.

We may have to purchase additional licenses for the performance toolset. I hoped I could get away with just the floating licenses we already had but that doesn't seem to pan out! However, now the bottle neck is no longer the performance engineer. Now it looks more like the number of licenses. When I compare the "price" of an engineer with the price of an additional license, it becomes apparent that the license is definitely cheaper.

Introducing automated performance testing caused some issues. But I would call this "healthy noise". All participants - customers, user experience experts, performance engineers, developers - are working very focused to iron out these hick-ups and they have made a lot of progress.

Wrapping Up

Introducing a somewhat significant change like this requires adaptation by everybody. Processes, tools, etc. need to be adapted as well. The result, however, is that you are moving closer to a holistic approach to software engineering that also considers performance engineering and testing as an integral part of the process. In particular I am very pleased how all the people involved grew as part of this process. The team and the product will be better because of this. Well done, folks!

Are your stakeholders on the same page?

Sometimes it's not good to rely on assumptions. One of those assumptions might be that you work with people from your product management team and you assume that a key stakeholder of that team is fully in line and on the same page with them.

This doesn't have to be the case as I just had to find out.

Over several months I used the assumption that the product specialist, who I have on my team as the proxy customers and backlog owners, were on the same page with their manager, the product manager. I think all of them thought, too, they were on the same page.

Only two weeks ago it turned out that the product manager had an entirely different understanding of the scope that would be available for an internal release than what at least one of the product specialists thought.

The result was a "sticker shock" for the product manager. With reason!

So what can we learn from this? There is certainly no guarantee that communication would have prevented this form happening. Remember all participants acted in good faith. Still more and more focused communication with your key stakeholders will reduce the likelihood of bad surprises.

So in my case I have arranged for weekly catch-ups with the particular product manager (Agile value: adapt). The intention is to keep each other informed as much as possible about developments that may have an impact on each others work.

Again, this highlights the superiority of direct communication (agile value!) over comprehensive documentation. Of course, regular written progress reports were provided during the same timeframe. And everybody thought everything is alright. Well, it wasn't. A key stakeholder wasn't on the same page.

Are your key stakeholders all on the same page?

I want you to do more!

I have been in the industry for over 15 years now. I have worked in many different environments. There were approaches that you could have called "waterfall", and there were approaches that you could have called "agile". And there were approaches that were somewhere in between (using a linear spectrum).

One thing that has stayed the same during all this time: A customer asking for more. "I want you to do more." And what they mean is: "I want you to increase productivity." (And for the records: A customer could equally be an internal stakeholder, e.g. a product manager.)

The interesting question is, though, how do you measure productivity? The trouble is, if you don't know how your customer measures productivity then how can you improve it? I have approximately 20 or 30 books on metrics in software engineering. Many of them contain attempts to measure the productivity of a software engineer. I am not aware of any metric that really works. If you know of such a metric: Please, I am begging you! Tell me!

An exercise: Let's assume you count lines of code (LOC).... Ok, ok, I got it. We want maintainable code so less is probably better.

Let's try "number of screens". This is more difficult. Do you want to have as much information on one screen as possible? Maybe the screens are used by professionals every day 200 or 300 days a year. In that case, again, less is more!

Let's try "number of stories". Ok, that's an easy one, isn't it? A few years ago a manager asked me how we could motivate the team to deliver more stories (For the less familiar: story = a small piece of work). I thought for a moment and then I said: "Just tell them!" Then he thought for a bit and understood that people would just make the stories smaller and smaller and so we would - on paper - see improvements all the time. In other words "inflation".

Let's try "Defined Scope": I have this statement of work that also includes "The Scope". Let's assume it contains the requirement that on one screen you need a table. For that table you want to reorder the rows because the sequence matters (think of prioritization items for instance). One way to implement that could be that each row gets a unique identifier (or you can select it), and then there are two buttons with "Up" and "Down". Functionality complete! - Well, hang on, wait a second. This is - at least for web applications - what we had about 10 years ago. Today, we need AJAX, and hence at the very least you want the rows to be draggable with the mouse. - Whatever you answer to this is - whether or not the fancy version is in scope or not - the difference between these two versions is about 1:10 in terms of effort.

So where does this take us? It's about scope. And it is about making sure you have the right scope in place. So wouldn't it make sense to precisely define the scope? Absolutely! Have you tried it to define scope in a "waterproof" way? If you were successful please let me know!

Yet another approach is: Just mandate more work to complete. Well, if you don't have family how can you possibly imagine that there are people out there who have family and who do care about their family? How do you know what it feels like if you have to call your partner that you won't be home for dinner? That you won't be home for the weekend? What if your kids start asking who you are? How would you feel? If you are a human being, you know exactly what I'm talking about.

I think all of this is not very constructive. Try to better specify scope is definitely a good thing. Assuming that the scope is completely defined at the beginning of a project - regardless of effort - is in my view a ridiculous assumption. As the project progresses you will discover new items. All IT project, all software projects are so complex that we have to assume that there will be new scope discovered. Do we know how much ahead of time? No we don't. We can try to "guess" as best as possible but there is no guarantee that we will be correct.

So it basically boils down to ensure that all stakeholders are involved, that they always get a sufficient and complete picture of where the project is going. If the remaining capacity is not sufficient for the remaining scope then this needs to be addressed as early as possible, so change management has to kick in.

Creating a blame culture and start finger pointing when coming under pressure won't help make any issue go away. A unilateral mandate or a dictatorial approach will destroy all teams. Requesting respect for one's role and at the same time ignoring a different persons role is destructive and ignorant. It reminds me of the days of the cold war. The Soviet approach was: What mine is is mine, and now let's negotiate about yours. We all know that this approach didn't survive.

Increasing and continuously improving communication and collaboration is the required forward looking approach. Contributing and constructively participating in a proper cross-functional team is where good solutions are created. (And whether or not you use an agile approach doesn't matter at all!)

The ripple effects of moving in a release date

When a project is behind schedule several options are typically considered. The schedule is adjusted, the number of people working on the project is increased, or the scope is reduced.

A few days ago I met Susan, an old friend of mine. She is working for a very small software company, and she told me about a project that she used to work on until a few months ago. The project was an online reservation system for hotels, and as the hotel owner decided to go into business sooner than originally planned the schedule for the project had to be shortened by a few weeks as well.

This decision caused a number of ripple effects, mostly undesired side effects.

First it turned out that the staffing level wasn't high enough to achieve a sufficient velocity for the shortened time line. Additional engineers were required. As the company is only a very small outfit, they had reassign engineers from a different team to this project team thus sacrificing valueable work in the other team.

This in turn not only reduced the velocity of the other team. As a consequence the scope for the other team's deliveries had to be reduced.

Also, it turned out that in order to make the shortened deadline the project team had to take a number of short cuts, e.g. by using a less elegant design in some places or by not refactoring code to the degree it deserved.

There were many more impacts, but so far we have:

1. Need to increase staffing level in the project team: additional project cost
2. Need to reassign engineers from the other team: cost in the form of delayed deliveries in the other team
3. Need to clean up the "short cuts" caused rework after the release

Bottom line: Moving in a release date had not only the immediate impact but also cause a number of side effects, each of them causing a number of additional problems and/or cost.

The software has been released a few months ago, and the project team is onto a new project. My friend reckons that it probably will take a few more months until the effects of the changes have been resolved.

On the positive side, Susan's team delivered on time and with functionality and quality as specified. In addition the customer is very happy with her company's ability to adapt to the changed plans. Susan and her colleagues are, however, very aware of the price they had to pay.

Customers Writing Executable Specifications

About two years ago I worked with a team which had to live (or suffer?) from requirements specifications with hundreds of pages of prose. This kind of document is hard to read, understand, and maintain. If you want to change it, and your customer is external, you have to follow a change management process which typically includes exchanging and having drafted and approved even more documents.

Ideally, requirements would be written in a way that makes it easy for the development team to verify whether the system satisfies them. So why not making requirements executable? That way your team members can run them as often as needed, and they could stop immediately once the system passes those tests.

The way to go forward is therefore executable specifications, or story tests. The most prominent thought leader on this is probably Rick Mugridge, on whose web site you can also find further information.

One tool to create and maintain such customer tests is Fitnesse. It is available for many different languages.

The benefits are very compelling. You have a much tighter link between your customer (might also be a product manager) and your development team. Executable specifications are a means for improving communication. You also get a tool that reduces the gap between what your customer wants the system to do, and what the system really does.

From my experience, it's worth playing with this concept. It might turn out to be an excellent addition to your toolbox for agile project management.