Handling Requests for Unnecessary Artifacts

“Working software over comprehensive documentation.” You’ve certainly seen that statement on the Agile Manifesto. It is perhaps the most important of the Manifesto’s four value statements—working software is, after all, the reason a team has undertaken a software development effort.

It is also one of the most misused parts of the Manifesto. This is the quote people cite when trying to get out of all documentation, which is not what the Manifesto says we should value.

Introducing Agile

Your company is thinking about the best way to introduce Agile. Here is my thoughts on the best way to do it. I think there are two keys to a successful implementation especially if you have been in the waterfall for awhile. I know what you are thinking…

“We just make the switch to agile and move forward.”

I have done that without much success. That could have been us but we had your usual bell curve of people. Your top performers will naturally gravitate towards Agile and will adapt quickly in my experience. But there will be resistance for a variety of reasons and possibly from your higher performers if they feel that waterfall is what got them recognized.


You need to provide ammunition for your Agile evangelists. The single best way to do that is to have a team successfully doing Agile and talking about how great it is. It is like a gift that keeps on giving. The team is happy, product is improving and shipping faster, transparency is up. All good things! This becomes infectious. The team starts talking with people who are not in the Agile team and saying how much they like it. Management and especially senior management is happy because they really know what is happening (assuming they are paying attention but that is another blog post) and the top features are showing up every two-three weeks.

Not only is it infectious, but it undermines the neigh naysayers at the same time. When they say it cannot be done — and trust me they will — you just point at the functioning team and say maybe not.


“I don’t need any training to understand Agile. It is incredibly straightforward. I read some Web sites and bought a couple of books.”

Well, I can say that is a great start. It will give you a decent foundation. But I would ask you would you want someone to perform a tracheotomy on you after reading a web site or two? I thought not. I think understanding the framework is actually very easy. Christ, the manifesto is twelve steps er I mean principles. It is not the PMBOK now is it… In my experience, the change experience is much, much harder without training. Training is invaluable if you get the whole team to take the training. I have been very lucky to have participated in several classes with two great instructors. One did CSM and senior management training and the other did CSM and CSPO training. I was in almost all of these classes and engagement was very high and people left the training very excited.

The best part of training is level setting everyone and getting them away from work for a couple of days to focus on the framework. We also split up the pilot group and put one at each table in the CSM training and it helped calm the naysayers and those who are less engaged.

Even better is getting senior management involved in a shorter, simpler version of the training. Then everyone is using the same terminology. You don’t have to explain to senior management what a burndown chart is or where their EVM charts went.

Product Owners


I think the Product Owner is uniquely challenged in Scrum. You are both externally focussed on the market/customers and internally focussed on keeping the team moving in the right direction. As a Product Owner, it was my responsibility to

  • know the market,
  • demo the product to prospective customers,
  • work directly with UI/UX personnel to improve the customer’s possible interactions, and
  • come up with competitive pricing.

I was also responsible to the team for

  • providing a vision
  • managing the backlog and
  • guiding each release of the product.

This Agile Life added an interesting task to the Product Owner’s list of things to do.

  • Work with the team in identifying what will be reviewed with stakeholders at the Sprint Review.

So what is the difference between a Product Owner and a Product Manager?

According to Mike Cohn of Mountain Goat Software

The Scrum product owner is typically a project’s key stakeholder. Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is key to successfully starting any agile software development project. The agile product owner does this in part through the product backlog, which is a prioritized features list for the product.

The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed.  1

According to Roman Pichler, a product owner is more than just a re-branded product manager: Product owners tend to take on a wider range of duties, which makes the role multi-faceted and challenging. 2

In my experience, I have worked with Product Managers who were mostly outwardly focussed. They might provide direction to the team at a high level and usually at the beginning of a project but they were not interacting with the team on anything more than an occasional basis once a release was begun. I have also seen Product Owners who were mostly internally focussed on managing the teams’ backlogs. In fact, on a product that has multiple teams, managing the backlog and handling team questions for 2+ teams can consume in large amount of your day.

So which is it? Outward or Inward?

Is one more important than the other? Well like most of life, it depends. In an organization with a fractured upper management, having an outward focus is huge. The Product Owner must frame the discussion and guide the organization (and its politics) to a successful conclusion. Navigating upper management’s conflicting interests is essential to the success of especially a new product. On the other hand, a novice or weak team will need the focus.


A very common question you get is what do a PMO and Project Managers do in a agile world. The development team is self-managing, the Product Owning owns the backlog and each team should include both dev and QA. So we are done right? Time to update the résumé…

My retort is that there is a lot that a PMO can bring even when Development is humming along in a perfect agile process. Here is a short but high value list to start the conversation:

  • Strategy
  • Reporting
  • Release Manager


One of the primary tenets of Agile is that the team should be working on the highest possible work at the present and the Product Owner should be sorting the backlog accordingly. Even if your product owners/teams are functioning at the highest level, one of the challenges to most companies is that they are still siloed by product. So a team could be working on a medium or low priority set of stories in one product when they could be working on another product with much higher priorities for the company. The idea is that you align at the portfolio level rather than the product level. The PMO’s job is to answer this question

What is the best use of our time to the company?

Once we have that answered and assuming the teams are aligned on sprint length and start/stop dates, Product Owners and teams can attack what brings the most value to the company right now. To the company, this brings additional value in that many developers are no longer being siloed into one product/technology and the company has many people cross-trained in multiple projects.


Another critical tenet of agile processes is the idea of information radiators. These should be essential for distributing information thoughout the stakeholder community and amongst the teams. Information radiators are also essential to the success of any agile implementation. Management is used to seeing metrics for project status and especially during the early stages of agile will be nervous that everything is going to go to hell in a handbasket. Information radiators provide that status comfort but I have yet to meet a scrum master/product owner who was not happy (ok one but see previous blog post) to get help with presenting metrics that were understandable. The PMO lives in the world of gathering, analyzing, and presenting metrics on project status!

The second big reporting area that the PMO can help with is risk. How is it measured, tracked, and reported. There are many different ways to present risk. My favorite is a 5 x 5 scale where 1–5 ranks severity and probability with 5 being high. Multiply the numbers together and anything over a 10 gets tracked and anything over 15 gets reported. I have found that Development can easily provide information on this scale and Management can easily understand the scale.

Release Manager

Great, the software is complete! The team should congratulate itself and probably schedule happy hour to celebrate. However while it is a significant accomplishment that the software is done, is the rest of the company ready to ship? One of the areas where most companies that adopt agile struggle is integrating the fast-paced cycles of agile with a company that has not fully adopted agile across the board. So is everyone else (Marketing, Sales, Documentation, Finance, Legal) ready to ship? Usually, the answer is no…

Here is a task that falls right into the wheelhouse of a PMO, release management. I have successfully used both MS Project and a newer, more agile product called Trello. Trello is very adept at this because unlike building an aircraft carrier, release management is less linear and more an aggregation of disparate single tasks. Trello allows everyone to filter on their tasks and statues and allows everyone constant visibility on the overall process. The PMO is more the shepard who guides the flock in the right direction.

Good references

I have done the reading so you don’t have to read the bad books. I would highly recommend these books on Agile Portfolio Management:

Picking Scrum Masters

What: Dogmatic Scrum Masters may doom your implementation

Symptoms: If you witness any of the following behaviors, you have a DSM

  • Displays limited flexibility. The DSM may be usually enthusiastic believers in scrum but they view the world through a black/white prism. The DSM may tie up scrum of scrums for hours fighting tooth and nail against the team “bastardizing” Scrum.
  • Does not hold their team accountable but fights when others do that they are “bastardizing” the team’s independence. I have witnessed a DSM who championed his team when he should have been trying to figure out why his team was repeatedly not completing stories for multiple sprints. When questioned, the DSM would vociferously defend his team from outside interference rather than try to get to the bottom of the problem.

Results: The DSM causes a triple whammy. One, they may poison their team by not holding them accountable. The team then thinks this is normal and begins to repeatedly miss commitments that they themselves had made. Second, other teams see this and it quickly spreads. Finally, upper management will also notice during sprint reviews that stories taken were not completed repeatedly. This will directly lead to upper management losing confidence in the agile implementation.

Actions: My recommendation would be to try to work with them for a sprint or two (no longer than a month to six weeks) and if you don’t see the changes that are necessary, change scrum masters. I cannot stress how corrosive this is.