Taking the Plunge

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:

https://www.projectmanagement.com/discussion-topic/56782/Is-it-Agile-

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:

• Are we able to rapidly and consistently deliver value?
• Are we able to respond quickly to changing priorities?

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?

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.