Hopefully, the product of every project you finish delivers value. It doesn’t have to be an either/or proposition. If your projects are like mine, however, you don't always realize the value in the products you deliver.
It's not that you don't see value in what you're delivering, or that value is never realized. It's just that once the product of your project is delivered, your team might provide support for a short time, and then you're off to the next project. The reality is that the product you just delivered might not deliver tangible value to the business until you are getting ready to finish your next project.
It is difficult, to say the least, to assign a date to value realization. It can also create a bit of a conundrum when you are told you are responsible for delivering value, but you're assigned to do other things by the time someone else quantifies the value realized from the product you delivered.
Let me take a step back. What I'm really describing is a more traditional, big bang approach to delivering value.
One of the touted benefits of most flavors of Agile is that they deliver value faster than other project approaches. This can be true, but one of the caveats I would place on this is that you must have one or more Minimum Viable Products (MVPs) and be able to deliver your MVPs early enough to begin realizing value before the project is finished.
SIDENOTE - For those of you asking if you can benefit from using a flavor of Agile, my opinion is that one of the requirements to realizing the full value of Agile is that you have one or more MVPs. If you can't deliver value incrementally, or, in other words, if you can't deliver the finished product until everything is done, and you can choose your project approach, a flavor of Agile might not be the right approach for your project.
What is an MVP? Minimum Viable Product is the smallest discreet subset of functionality that can be delivered to and used by customers, or sold if your company sells product.
Should I repeat that in English? The MVP is not the finished product or a beta, demo, or proof of concept. It is something usable, and usable enough that your customer(s) would be willing to pay for it, before you deliver the finished product. When you deliver a true MVP, you are delivering value in the sense that the company you work for can begin generating revenue (or goodwill, for internal projects) months, or longer, before you deliver the finished product. You might deliver several MVPs before delivering the finished product.
The finished product is just that; finished. It contains all of the planned features and functionally that have been specified, or a decision is made that it is finished and no more work goes into that version.
You can take the big bang approach and try to deliver everything at once. Big bang can be your only choice on some projects, even if you can develop iteratively. But, if you can build AND deliver MVPs iteratively, and realize value incrementally, why wouldn't you?
I'm guessing you've noticed that I've used a couple of expressions that you don't normally hear in discussions about Agile. You might often hear about incremental and big bang delivery, but not incremental and big bang value. The difference is mostly, but not completely, mindset.
Incremental and big bang delivery is about delivering product. You can deliver working code almost every sprint (Agile), or you can deliver everything at once (Big Bang). These descriptions are most often used to describe one of the differences between Agile and Waterfall.
I am distinguishing incremental and big bang value from delivery because of my experiences. I've broken a project into phases and delivered value, incrementally, without iterative development. I've seen "agile projects" that were basically iterative development with a big bang product delivery. Let your decision about how to deliver value inform your decision regarding your project approach. Your project may be over long before the business realizes the value of the product your project delivers, and the amount of value that the business is able to realize may be beyond your control, but you can still keep value as the driver behind the product you are delivering. Look for ways to deliver value before the project is finished, whenever possible; delivering product is not the ultimate goal. Don't force an either/or proposition.
I recently posted a question regarding whether or not a project, that several of my peers are working on, is agile. You can read the responses here:
If you're thinking, "Who cares?" I don't blame you. Agile. Waterfall. Does it really matter how work gets done, as long as it gets done?
Some processes, however, make you wonder what is really getting done.
One of the concepts used in Scrum is the Definition of Ready. A simple explanation of this is that there is enough information on the story card for the work to be accurately sized. Obviously, you have the user story on the card. Then there are test cases, exceptions, you might need wireframes and a technical spec, and so on. Before you know it, you've gone from Scrum to Waterfall. This was what my peer's project was starting to look like. There were so many pre-conditions that needed to be met before development could begin that they created a Kanban board to track the stories through the pre-conditions, so that they would know when they could size the story and add it to a sprint. From an outsider's perspective, they were sacrificing speed for quality.
But were they? And were they still agile? While you could no longer call their process strictly Scrum, it still contains elements of agile. Scrum may be a flavor of agile, but agile is not scrum. It is not strictly adhering to a set of practices to the point that the practices get in the way of getting work done and delivering value.
Don't ask yourself, "Are we agile?" Instead, ask yourself (and others) the following:
Adopting a flavor of agile doesn't guarantee either. You may have organizational issues or other problems that need to be solved that have nothing to do with agile. Instead of pursuing an agile transformation and hoping that it solves your problems, take the time to find out what the problems are that are keeping you from delivering and responding. If you find that making an agile transformation will solve your problems, by all means, go for it. If not, then do what it takes to solve the problems. Being able to deliver value and respond to change is more important than the name of the process you use to get there.
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.
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?