Product Owner or Product Manager?
One of the points from the CSPO class I attended, last year, that stood out to me more than anything else, was when the instructor told us that one of the roles of the CSM is to coach the CSPO and make sure the CSPO is fulfilling his or her role.
That statement, by itself, was not a cause for concern. The concern came from realizing that there were things taught in the CSPO class that were not taught in the CSM class. My question to the instructor was, "How can the CSM coach the CSPO on things the CSM is not taught?"
I don't have a satisfactory answer, but over the past several months as a ScrumMaster/Agile Coach, I've come to realize that the Product Owner is the most important role on the team, and I'm coming to appreciate the challenge created when the Product Owners are also Product Managers.
Is there a difference between Product Owners and Product Managers? Your company might not treat them like there is, but I'm learning that there is enough difference in the roles that it is difficult when one person is expected to do both, when both are required.
The simplest way to put it is that the Product Manager is externally focused, getting funding for product development and working closely with customers, while the Product Owner has an internal focus, creating user stories and supporting the development team. Yes, there is much more to both, and some overlap, but the Product Owner role is different from the traditional Product Manager role.
When I attempt to look at this situation as a ScrumMaster, I have to wonder, does this mean that I am also expected to understand the Product Manager role?
I'm not ready to tackle that question, right now. However your organization is organized, make sure that your Product Owner/Product Manager is empowered to make product decisions. How effective would sprint planning or backlog review be if your Product Owner had to take a list of questions back to someone else to get answers or approval to changes? It doesn’t matter if you have separate a Product Owner and Product Manager, or one person filling both roles, as long as the person filling the Product Owner role has the authority to make decisions for the project. If your Product Owner is also a Product Manager, recognize that it is a big job and be supportive. If the Product Owner fails, the project fails.
How Flexible is your Agile?
At the end of our last sprint, I switched my mobile team from Scrum-like to Kanban-like.
Why would I do that, and what does it even mean? Both good questions.
My mobile team has five developers, two testers, one designer, three products with both iOS and Android apps, and three product owners. Each of the product owners have other products they are responsible for, and these other products have a higher priority. I am fortunate if all three product owners are able to attend the stand-up meetings we hold three days a week.
When I took over, there was no velocity, and it became clear, fairly quickly, there wasn't likely to be. I have been able to hold retrospectives, but sprint reviews are basically demos in the Friday stand-up, and sprint planning was the first stand-up meeting of the sprint. These were 30 minute meetings. Having developers split across three time zones didn't help. The result of sprint planning was, usually, that unfinished work was rolled into the new sprint, and a few new stories were added.
I'm sure there's a strict Scrum advocate whose head just exploded, somewhere.
As a team, we decided to switch to a Kanban-like process; this is more in line with how the team works. The product owners manage their backlog. When they are ready, they move their story cards into the To-Do column, which makes them available for the developers to work on. I've got a sneaking suspicion that we may encounter some issues with WIP, but we'll work it out.
We'll continue to hold retrospectives and evaluate our process as we go. If it doesn't work, we can go back to sprints.
Overall, I like the direction we're taking. I was struggling to figure out how to make the team more Scrum-like. It wasn't until I began to understand more about how the team works that I realized it makes more sense to make the process fit the team than it does to try and make the team fit the process. I work with a great team, and I need to make sure they know that.
There are other products, in our company, that have dedicated teams. They're doing well using Scrum. If I had three different dedicated teams for my three products, I'd probably be running them all on Scrum, still.
I want to be clear about something. I am not a proponent of customizing an approach before you even try it. Scrum, out of the box, can work great. As you use it, you may identify constraints and will need to choose to either eliminate the constraint or change the process.
Being agile isn't about strictly using Scrum, or Kanban, or some other flavor of agile. There are no methodologies or frameworks mentioned in the Agile Manifesto. An important part of agile is experimenting; learning how to deliver value more quickly than you've done in the past. Where you end up may not look the same as where you start, and that's okay.
Where are you on your Agile journey?
Insights from The Goal
Categories: Project Management
I'm currently listening to The Goal, by Eliyahu Goldratt and Jeff Cox, while I commute to and from work. I'm about halfway through it and, so far, it reminds me of some problems we experienced load testing our ERP and sales systems.
We encountered login failures during load testing, where we hadn't before. A little digging revealed that recent performance improvements had sped up our submit times but we hadn't accounted for the impact on other processes. As a result, we experienced failures. Our attempt to become more efficient made us less efficient because the improvements we made ran into downstream processes which choked due to greater volume than anticipated.
One possible interpretation of the message of The Goal is that overemphasis on efficiency when doing something can lead to ignoring the reason why you're doing what you're doing, in the first place. You basically end up failing efficiently, but that is a little oversimplified. A bigger concern is whether or not you are focusing on the right efficiencies. It doesn't matter how efficient your production is if you're not selling anything. From a software development perspective, it doesn't matter how efficiently your team is developing code if they're not delivering code that the customer wants.
From a project management perspective, are your projects helping your company achieve its goals? A project can be on time and within budget, yet still do nothing to help a company achieve its goals.
Don't worry, I'm not about to segue into Portfolio Management. I could, but if you're not doing Portfolio Management now, you're not going to automagically be able to start once you finish reading this. You can, however, examine your products with the critical eye of The Goal (with the caveat that I have not finished the book, yet). Does your project help your company meet its goal through some combination of reducing inventory, reducing operational expenses, and increasing cash flow?
What about you? Have you read The Goal? If so, what insights did you gain from it, as it relates to project management?
Innovation and project management go hand in hand. If you're innovating, you probably have at least one project on the burner. So, why is innovating so much harder than project management?
The easy answer is that, usually, project management is a highly structured, well documented process, whereas there does not seem to be a magic formula for successful innovation. A project has a point at which it is done, by definition. Innovation evolves. Scrum-based flavors of Agile seem like strong candidates to use for a project management framework for innovation, but will it still look that way when you peel the onion and see what's hiding inside?
I know, the onion analogy is old, but it is appropriate, although slightly flawed. What makes it appropriate is that there is more to innovation than what you see on the surface. Each layer may be similar to the one before it, but without the underlying layers, there's not much to it.
I'm seeing a parallel between Agile and onions, now. Please, make it stop!
My point is that, like the outer layer of an onion, an innovation effort does not stand alone. There is a core of culture, people, processes, tools, and data that all affect a company's ability to innovate.
I'm going to borrow a concept from Agile to describe a common challenge to innovation: technical debt. In Agile, technical debt refers to old or poorly written code that needs to be refactored in order to deliver a desired feature. From the perspective of innovation, I am using this concept to represent systems, software, and processes that need to be changed before an innovation can be successful. If you ignore this technical debt, you risk failure, and we're not talking about a software release, any more.
If not addressed properly, technical debt can become part of a painful cycle. With software used in multiple markets around the globe as an example, let's say it's been several years since the last major upgrade. The required downtime wasn't feasible because of global sales events, which is how your company earns revenue. Your company has reached the point where the software cannot reasonably support the changes you want to make. You either need to perform the upgrade, or implement new software. Either way, there will be downtime. It takes close to a year, but you make the change and start innovating, only to realize that you've started the cycle over again and 5 years later you have to make the same decision; upgrade or replace your software.
The flaw in the onion analogy is that innovation is not occurring on the outside of the onion. The growth of an onion occurs in its core, forcing the outer layers to stretch and grow.
If you're expecting me to compare the core and outer layer of an onion to IT and the Business, prepare to be disappointed. This mindset is a factor in why some innovation efforts struggle. IT provides the business with functionality; the Business provides IT with purpose. It should be a symbiotic relationship, where both stretch and grow together, but it is often hampered by those that view it as a parasitic relationship, both in IT and the Business.
Once upon a time, I was an IT project manager at a claims processing center. The Business was frustrated with the service not provided by IT, even though the real problem was due to software that the business forced upon IT. IT, feeling like it was performing miracles just keeping the software running, expressed that the Business could not function without IT. One day, the software crashed. Hard. After a couple of days with no real progress, the Business began processing claims by hand. It was much slower than normal, but they made it clear they could function without IT.
And with this adversarial relationship, it took significant time, effort, and money (to replace the software and fix relationships) before innovation could begin again.
Back to my original question, "Why is innovating so much harder than project management?" Because it's not just one thing. Innovation is many things happening at once. Good project management can help an innovation effort be successful, but unlike an onion, if you're only looking at the surface, you really have no idea what else is going on. All parties need to realize that business and technical innovation go hand in hand. If you try and accomplish one without the other, you're missing the big picture.
Projects and Holidays
Categories: Project Management
It's that time of year again. You know what I mean. The time of year when you try to find your project team and ask yourself, "Why did I commit to a deadline between Thanksgiving and New Year's Eve?"
For those of you who don't work with US teams, you probably have a similar experience around other holidays. I worked with a team located in Europe and found that August was not a good time for deadlines. Golden week, in China, is not the most productive time, either. Fortunately,we can account for these events in our schedule.
I'm finding that a bigger challenge is trying to run a distributed agile team with three sets of holidays. The running joke is that Argentina is always on holiday and Peru never gets a holiday. As long as the developers don't have urgent questions for the product owners, over US holidays, their productivity is not greatly affected. It's not actually hard, it just slows the work down, and we need to coordinate our release dates a little more carefully.
I enjoy what I do at work, and I also enjoy being able to step away from it, over the holidays, and focus on things other than project management. That's where I'm at, this year. Unlike the person in the video below, when I step away from work for the holidays, project management the last thing I want to think about (except for my blog, of course). You don't have to watch the video; it's just six minutes of someone's preparation for and execution of Thanksgiving, shown in Jira. Masochist.
If this is you and your holidays, I hope it's by choice. If I had to use project planning software to schedule my vacation, I would look forward to going back to work so that I could take a break. My only plan for the long weekend about to start is to smoke a turkey. Deboning it is a chore, but it is soooo worth it.
Whenever your holidays are, I hope you get to enjoy some combination of good food, good friends, family, and doing things you enjoy.