Taking the Plunge

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.

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.

An Agile Thanksgiving with Jira

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.

I thought I'd take a moment and think about something other than election coverage.

I'm not sure if it's cause, effect, or altogether something else, but optimism and vacuums seem to go hand in hand.  Think about your last project, for a moment. How accurate were the estimates given in the early stages of the project? If you have even a little experience in project management, you knew they weren't going to be accurate, but you may not have identified all of the reasons why.

The obvious reason is that the earlier it is in a project, the less you know about the project.  A factor that often gets overlooked is everything else going on in your organization.  You can know that it will take six months to complete the project... if that's all anybody did.  How long will it take when you account for everything else going on?  Planning projects in a vacuum happens all too often, and it results in optimism about how much work an organization can complete in a given amount of time.

We're all familiar with the concepts of effort and duration, I hope.  If you want to know when a task can be completed, you need to know how many hours it will take for the assignee to complete the work, but you don't stop there.  Next, you need to determine how many days it will take for the assignee to find the time to perform the work. I'm sure I'm not the only project manager who has seen a task that only required two hours of effort take more than two days to complete, for legitimate reasons.

Tasks are to individuals like projects are to organizations. There can be unknowns that make it difficult to estimate the "organizational effort" of a project. All project managers deal with this. We also need to understand the "organizational duration” of our project, taking into account the other projects and activities (priorities) our organization is pursuing that could affect our schedule.

If you think that this is starting to sound like portfolio management, you might be right. If your company is effectively managing a portfolio of projects, instead of running multiple silos of projects that, surprisingly overlap, you are doing better than many other companies.  This is the vacuum and optimism I'm talking about. When we plan our projects in a vacuum, our estimates are basically blindly optimistic.

What can we do about this situation?

Don't run out and buy portfolio management software. Throwing a tool at a problem, without at least minimal analysis, just creates another way to fail.  There are three aspects of problem solving that need to be addressed, in order. They are:

1) people

2) processes

3) tools

You won't solve the problems associated with optimism and vacuum-based estimates without the right people.  You might be able to deal with this approach internally, but don't ignore the value of a third party facilitator or coach to help guide the change. 

As you're getting the right people involved, make sure you all agree on the problem that you are trying to solve, then start identifying gaps in your current processes. From there, you can identify any additional processes and tools you may need.

Simple, right? Okay, maybe not as simple as I make it sound.  You may not need a robust portfolio management system. Alternatively, you may need one, but not be in a position to implement one.  Your mission, should you choose to accept it, is to gather the right people and figure out the best way for your organization to break away from optimism and vacuums.

When everything is a priority, nothing is a priority.

I've been saying that for over a decade and had no idea it was an actual quote, by Simon Fulleringer.  I'm not claiming it was me.  I just thought it was one of those things that was inherently true and often overlooked.  It's also a sign that priorities probably need to be addressed.  That is where I find myself.

I've been trying to do too many things for a while, now, and not gotten very far on any of them.  The impact to my blog is that I am going to start posting every two weeks, instead of weekly.  As I will also be cutting back on other activities and using my time more effectively, or trying to, anyway, this should give me time to finish one of the books I've been planning to post on  - The Agility Shift. 

My plan is to post more content about making an agile transformation, not just about adopting agile practices.  I'll also post about some of the personal projects I am working on, and will continue to give updates on my agile team, at work.  And, of course, anything else project management related that comes to mind.

Speaking of my team, we had our first formal retrospective, today.  One of the things that was identified was how valuable the communications tools we are using have been.  We've got developers in three different countries, but they are in regular contact with each other in spite of time differences.

The team is all on the same page with regards to improving our definition of ready.  We're going to make a conscious effort to examine our stories and determine when more detail is needed in the story before putting it into the sprint, and when we just need the appropriate conversations to take place.  There needs to be enough detail to estimate the work without BDUF - big design up front.  The conversation is key.

Back to priorities.  It's not that you're not important, but I have other priorities that I need to take care of tonight.  See ya' in a couple of weeks!

You might recall previous posts where I stated that making the transition to Agile can be challenging?  Well, this is where I give a personal example of my experience as the company I work for makes an agile transformation.

I was recently asked to be ScrumMaster over a mobile project.  Okay, it would probably be more accurate to call the project a program, and to call myself an agile coach, but that is not how it was presented.  Our framework is Scrum-like, but given the following conditions, I can't really call it by-the-book Scrum.  However, that does not mean we're not going to make it as Agile as possible.

• Six developers; two local, four off-shore.
• 4 product owners
• iOS and Android versions of each product.  Would that be four products, or eight?
• These are ongoing maintenance efforts

I joined the project team on the last day of the Sprint.  It was a 45 minute meeting where three different sprint backlogs were reviewed and two features were demoed (is that a word?).  A sprint retrospective was not held.

I know, some of you are probably ready to tell me how agile we're not and how I need to fix things, quickly, but would that be in the spirit of agile?

Currently, we are meeting 3 days a week for 30 minutes to an hour, on a video call with developers in three different locations.  Sprint planning is on the fly, and sprint retrospectives have not been done in a while.  Among the areas where I have identified that we can make improvements are:

• A consolidated story board and sprint backlog
• Potential changes to the meeting schedule
• A unified workflow across all products
• Product roadmaps
• Standard definitions for the following, across all products, since the developers all work on more than one product
  • Definition of Ready
  • Completion Criteria
  • Definition of Done

I've created a consolidated story board and sprint backlog, and we've started talking about the other items.  I intend to have a more formal discussion about these items during the retrospective, next week.  I could try to force changes in all of these areas, at once, but I think that would do more damage than good, not to mention that the team would spend more time on process improvement than development.  The team was getting work done before I became the scrum master agile coach.  Some people might have thought things were a little rough before, but change doesn't guarantee they won't continue to be rough; they'll just be different.

I am aware that there are times when it is best to just rip off the bandage, but my intent is to treat my team like a high performing team.  There are changes that can be made, sure.  Scrum has a process for fine tuning team processes, called the retrospective.  I will use this tool to make recommendations to the team, as well as encouraging them to identify areas where we can improve, and then let them decide the changes they want to make, determine the priority of the changes, and establish their own cadence in making those changes.  The collective team may have better solutions than I could come up with on my own.

I'm ready for this adventure and look forward to working with my team.  I'll share more as they become the high performing team that I know they can be.