Project Management

Taking the Plunge

In case you actually read this description, the beginning of the blog is about preparing for the PMP exam. It then evolved into maintaining my credential. After taking a break for a few years, I'm back and will be blogging about project management, in general, and probably a bit of agile on a regular basis.

About this Blog


Recent Posts

Festina Lente

Everything Old is New Again

What's in Your Project Management Tool Belt?

Scale Your Product Owners

When is a Good Idea a Bad Idea?

Everything Old is New Again

Categories: Agile, Exam Prep

In the spirit of the reason I started this blog - preparing for the PMP exam in 2008 - I’ll start this post with my latest certification path - PMI-ACP.  To quote myself from that first blog post:

“The important thing to keep in mind when preparing for the PMP exam is that just getting started is a step in the right direction.”

Fast forwarding to the present, I was recently approved to schedule the PMI-ACP exam (the application was soooo much easier than the PMP exam application), so now it’s time to hit the books, or more accurately:

  • An exam prep book (I’m looking for a good one.  Recommendations, anyone?)
  • An online prep-class from Udemy (we always need more PDUs!)
  • Flash cards
  • Practice exams

Can I claim PDUs for reading the exam prep book?  Hmm…

February sounds like a good time to take the exam, but that would put my renewal at about the same time as my PMP and annual membership renewal.  It might be good to stagger these, a little.  Once I get the exam prep book, I’ll put together a study plan and set a realistic date.

I’m thinking I’ll do us all a favor and NOT make my next several posts about preparing for the PMI-ACP exam.  It may come up, but I have a few other ideas that might prove more interesting.

Posted on: September 02, 2021 11:19 PM | Permalink | Comments (4)

Scale Your Product Owners

Categories: Agile

A few weeks ago, I was fortunate to be able to attend the [email protected] certification course, taught by Jeff Sutherland and Kim Antelo.  There is a lot, from this class, that I could write about, but I'd like to focus on just one topic that I think is critical to effective Scrum, Scrum transformations, and scaling Scrum:  Product Owners.


If you have multiple Scrum teams that are working on different features for the same product, you need to scale your Product Owners.  I'll explain what I mean by that in a moment.


When you take the Certified Scrum Master (CSM) class, you learn the basics of leading an individual Scrum team as the Scrum Master (leading in the sense of a servant leader, not a manager).  When you take the Certified Scrum Product Owner (CSPO) class, you learn the basics of participating on an individual Scrum team as the Product Owner.  Neither class goes in depth into what to do when multiple Scrum teams are working on different features of the same project.   I wouldn't expect them to; it's not the purpose of either class.


You might hear mention of Scrum of Scrums in the CSM class.  If you're not familiar with the concept, a lot of people think of it as a combined standup meeting where a representative from each Scrum team reports on his or her piece of the product.  They don't go into as much detail, and they only bring up blockers that can't be addressed at the team level. 


In [email protected], the Scrum of Scrums is actually what you might call the Team of Teams.  The meeting, described above, is called the Scaled Daily Scrum.  Do you see what is missing?  If you're going to scale your Scrum teams, you need to scale your Product Owners.  Why wouldn't you have a scaled, refined, prioritized backlog, a roadmap that covers the features that each Product Owner is responsible for, and a team of Product Owners that is responsible for these things?  This is called the MetaScrum, and it is sometimes missing when a company is trying to adopt Scrum.  Without this, your Scrum of Scrums, whether you consider it a team or a meeting, will be less effective, which means you won't be delivering value as quickly as you could be.


For more information on the terms I've mentioned and how to scale both Scrum teams and Product Owner teams, please refer to the [email protected] Guide -

Posted on: March 01, 2019 04:17 AM | Permalink | Comments (6)

Is it a Project or Maintenance?

Categories: Agile

Since switching my mobile app "project" from Scrum to Kanban, my initial suspicions have become cemented in my mind - this project I've inherited really isn't a project.  The biggest giveaway?  Now that my Product Owners are producing roadmaps, I've found that there is no end in sight.

So, if it's not a project, what is it?

Maintenance.  It's a mix of new feature development and bug fixing.  It was assigned to me as a project, and it has a project number, but the product owners expect it to continue until the products are no longer supported.  That might be a while.

I'm not complaining.  It's providing me with the opportunity to gain experience transitioning a team from Scrum to Kanban.  It has also helped me to realize that Scrum has the ability to blur the lines between projects and maintenance. 

As I'm re-reading what I've written so far, I'm asking myself a question that you're probably asking, too.  "So what?"

I think that the first "so what" is the realization that when a company is making a transformation to Scrum, there is the potential for everything to look like Scrum.  So what? 

Mobile application maintenance does look like something that you can do in sprints.  But, all of a sudden, you go from traditional release management processes to needing a Scrum Master to accomplish something that you've been doing successfully.  Hmm… potential increase in overhead costs, but now you can say you're doing agile.  Again, so what?

This isn't to say that maintenance can't benefit from Agile processes.  It certainly can.  My primary caution is that if your company is making an agile transformation and you have selected a single flavor of agile to implement, don't try and force everything to fit the flavor you have selected.  You might also want to avoid trying to turn things into projects that are not - being able to use Scrum-like processes for ongoing maintenance does not turn maintenance into a project. 

More about our transition to Kanban…

I talked a little about switching my team to Kanban in my post in February:

The team has been making great progress, although we're still trying to figure out meaningful metrics for our consultant development team.  There are times when I wonder if a project manager should be running this effort; it really is a long-term maintenance effort.  If this is what the PMO Director wants me to do, in addition to my SAP projects, I'm not going to argue.  There is the possibility, however, that at some point, I will either need to be more dedicated to the mobile effort, or focus on my projects that have end dates.  Either way, it's in my best interest to make sure that I have a documented process.

Posted on: June 05, 2017 03:50 PM | Permalink | Comments (23)

Do You Deliver Product or Value?

Categories: Agile

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.

Enter Agile.

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.

Posted on: May 07, 2017 12:03 AM | Permalink | Comments (16)

Is it Agile?

Categories: Agile

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:

  • 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.

Posted on: April 10, 2017 12:08 AM | Permalink | Comments (15)

I don't like to carry my wallet. My osteopath says it's bad for my spine. Throws my hip off kilter.

- Kramer