If you lead a team in technology and don’t read Rands in Repose, now is an excellent time to start.
Government agencies either by preference or by statue tend to issue firm fixed price (FFP) Requests for Proposals (RFP). The draw is that costs are capped and the contractor assumes all the risk. From a lawmaker’s point of view, they look responsible and frugal. This is extremely misleading for several reasons.
By definition, the only thing the contractor can control is scope (and schedule to a lessor degree). Unless you have a project with little or no unknowns or your team has the world’s greatest requirement writer, this tends to become contentious. I have literally had conversations with clients where they knew what they meant and I knew what they meant but it did not say that. You build exactly what was asked for. If a better idea comes up, hey great, write it up, scope it, cost it and send it to the Change Control Board.
Most contractors love to delight their customers but FFP forces both parties to fight tooth and nail over what every requirement exactly means. I have been involved in many different customers at both the state and federal level and have spent ungodly chunks of those contracts pouring over contracts with the client . This wastes an inordinate amount of time. Time that would be much better spent building what you are supposed to be building.
FFP also allows little or no flexibility. Yes, you usually have a Change Control Board but now you have made the process slow. You interrupt the whole flow of the project. You make the process cumbersome. The project can turn but like a carrier group it takes awhile and you keep losing momentum.
Not So Hidden Costs
- Endless debating about what a requirement means rather than building the requirement
- Paper. Paper defines FFP. You have the requirements, the SOW, the contract itself, the change requests, the massive amounts of contract documentation, the ponderousness of the whole process.
- Time of course. Time debating. Time debating change requests, time writing them, time deciding them. Time not delighting the customer. Time no one will ever get back in their lives.
“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.
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.
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.