Agile | Project Management Leadership

Agile and CBPM

The question comes up: is CBPM Agile?

The answer is a definite yes. It follows the directions of the Agile Manifesto. It values rolling plans over crafted plans. It is based on regular interactions with project team members and stakeholders. It’s focus is on delivering (“working software” if it’s a software project).

It does not require a cycle such as Scrum, though. In that sense, it’s closer to Kanban, another agile method.

Key points of CBPM:
1. Develop the plan together
2. Make it a rolling plan. In other words, don’t over plan as things may change. Plan just enough to move forward, inspect results, adjust, and lengthen plan.
3. The persons doing the work are the only ones who can commit to a deliverable date.
4. The recipient or customer of the work is the one who says whether it meets expectations. In other words, agree up front on the expectations.
5. CBPM is agnostic with respect to product development methodology. In other words, it can be used for software, hardware, construction, medical devices, etc. Domain-agnostic! Much harder in software-based agile methods.

Why Does CBPM Work?

I continue to apply CBPM in my current work while at the same time using Scrum for our software delivery. CBPM addresses those situations that are not as easy to adapt to an iterative approach.

It continues to amaze me how effective CBPM is at getting projects planned and to successful completion. One of my current projects has over 370 deliverables, not including the user stories for rewriting the application, which are being managed through Scrum. Yet the project is doing extremely well and is on schedule.

So, once again, I wonder why CBPM and other Agile methods work? A few things come to mine:

CBPM and Agile methods are not deterministic but adaptive. That is, we as planners and team members, know that whatever plan we make will change. With that in mind we only plan enough to get us going and to more or less know how long it’ll take us to get there. We re-plan on a regular basis to adapt to changing conditions. By not planning in detail we avoid waste (lean concept) in planning for items that will change.
We use the entire team to plan the effort. There’s no “mind behind the curtain” approach to doing planning. In this way we get many minds looking into the problem, identifying things that otherwise would have not been identified until much later. Also, we leverage the expertise of those who are going to do the work.
We focus on what’s important: delivering a product to a customer. Task analysis are optional and typically up to the individual doing the work. While Scrum encourages team to decompose tasks and assign hours to them, tracking the work that remains, this is not a necessary activity. In CBPM there’s no focus at all in effort as the owner of the item is responsible for figuring out what needs to happen and getting it done by the committed date.
Transparency: in CBPM and other Agile methods it is clear who owns an item and where it is. There’s no hiding behind complex Gantt charts. Ownership is clear. Status is clear.
The PM is no longer the center of activity. In CBPM owners and users of deliverables need to talk to each other. In Agile the entire team is responsible for the delivery of a successful product. Reporting and accountability are where they should be.
There’s a clear definition of what “done” means. In CBPM the owner and the user of a deliverable need to agree on what being done means. In Scrum every team has one or more definitions of done (user story, iteration/sprint, release, project). BTW, 99% done is not done!

There are probably numerous other reasons. Add yours!

BTW, both a one-day CBPM workshop and a two-day Scrum/Agile Project Management workshop have been scheduled for July in the Research Triangle Park area of North Carolina. Come join us if you want to learn more about these approaches.

Updates from the Agile PM Front

For the last year I’ve been driving Agile adoption and use at a small but impactful organization. We sell services and data access for the railroad business in North America and, while in IT, 90%+ of our work is product related.

Early this year I initiated three major efforts: a mainframe migration — about 40 applications to be migrated over four years to a Java/Oracle environment, a Master Data Management (MDM) consolidation of our customer data, and a replacement and reengineering of our Single Sign On (SSO) services. This is in addition to still driving Agile, UX, and a brand-new services strategy that is being defined.

For the mainframe migration project we are using pure Scrum as it fits very well with the effort to be undertaken. The existing application is reviewed with the Subject Matter Expert (SME), functionality assessed; some functionality eliminated; rearchitecture decisions reached; and work defined through user stories.

The SSO and MDM effforts though are not pure software development. SSO entails acquiring a new engine, assessing how to replace the existing one, then taking the steps to deliver this functionality. User Stories (Scrum) are a bit cumbersome for this approach.

The MDM effort includes data modeling and data loading through ETL (Extract, Transform, Load) processes, the definition of data governance and quality processes, and the development of a simple application to view the data. Besides the application development (we are using Scrum for it) the other parts are cumbersome through user stories and Scrum.

Instead of Scrum we are using a modified and simplified CBPM processes. Rather than a full day planning process (Map Day) we undertook one to two hour sessions to define what we knew and got the ball rolling. As the teams are small the users for each deliverable were not defined. While modified CBPM is still very successful. We just implemented our new SSO engine and protected the first migrated application this week. For MDM we have a preliminary loading of the data and a first version of the application. The challenge with MDM has been understanding the data and how it has been loaded into the existing source systems, something that would have taken a long time through traditional data analysis processes

So, don’t be afraid to mix and match approaches and even modify them. Keep to the spirit of Agile.

Driving Agile into an Organization

Agile has exploded into organizations doing software development. Scrum, XP, and other methods (and combinations) are used by many organizations. Non-software organizations use approaches such as CBPM (see my other posts).

Recently I joined an organization that had brought in Agile (mostly Scrum) a couple of years back. While most projects were using this approach, there was no energy behind. In what is a common approach, they had launched it and left it to its own devices. Still, teams were successful with higher quality products and more satisfied customers. But management and the people in the organization thought there was more to be done.

Enter Jose. I started by assessing, along with a small team, of the situation. We ran an internal survey to confirm our findings. The #1 finding was the need for training. But how to bring the training in with limited funds? And what else to do?

We decided to deliver short (1-2 hour) sessions on specific Agile concepts (writing user stories, using Rally, our software development management tool, estimating and planning, etc) as well as doing some longer sessions (I had done a day-long session outside so brought that one in).

Attendance is very high, with no empty chairs. We’ve scheduled an external vendor for a two-day workshop for product owners. And we’ll be launching a coaching program in the near term.

Response has been very positive and we look forward to improved results.

CBPM — Going Strong

It’s been a while since I last blogged here so wanted to bring you up to date on what’s been going on.

Last week I had the pleasure to co-present with Timm Esque at NC PMI’s Annual Event. We had over 140 people present, with lots of interest. Our theme was “Agile is not just for software projects” and there was lots of interest with a number of follow-on requests for the Excel tool (let me know if you would like the latest version).

In June I started working for a local company as their Agile evangelist. While they are fully into Scrum, I will be working with their infrastructure team to use CBPM in their projects. Scrum is a hard fit for non-software projects.

Also in June I presented my one-day workshop at PMI Silicon Valley. I’m currently tentatively scheduled to teach this workshop in January with NC PMI. Timm and his business partner are teaching a workshop in November. While not published yet, we are doing a survey and the first 30 respondents will get a free copy of Timm’s No Surprises Project Management book.

How are you doing with CBPM? Let us know.

Where’s Project Management Going? Musings

A friend sent me a note today asking for a few minutes to talk about the future of project management. We are scheduling the time to talk, but his message and some of the insights he provided got me thinking.

He indicated that Gartner is seeing a leveling off of demand for project managers and an increase in demand for program managers. Why? Well, I think the bloom is off the PMP (Project Management Professional) rose. Too many projects continue to struggle if not outright fail even with PMPs at the helm. The PgMP (Program Management Professional) rose is just budding (New and Improved!) and I guess people feel that program management is what is needed to make projects successful. But, is that the case?

Program Management, as it is currently approached, continues to rely on predictive and prescriptive planning and lots of control, the approaches that have not been so successful in the past. As all of us with experience in project and program management know that no project survives first encounter with reality to borrow a phase from the military (Patton or Eisenhower? Actually, a Google search provides lots of other sources, including some older than these two outstanding generals, so let’s leave it at that.)

Not only is an encounter with reality detrimental to a project plan, but there are those agents (people!) who many times don’t follow the prescribed plan! So, since PMPs are not successful, let’s go with PgMPs that have a much harder job to do (as per PMI, a program has two or more projects and possibly some operations that managed together provide more benefit than managed independently). Do we think they’ll be successful? Personally, I do not.

Those of you familiar with my writings know that I prefer adaptive, flexible, Agile plans (Scrum and other Agile methodologies for software, CBPM for non-software as well as software projects where more “traditional” Agile approaches are not possible) to prescriptive, predictive plans. You also know that I put a lot of value on leadership. Even though Scrum teams are supposed to be self-leading, a leader is still key to provide the space necessary for them to be successful, whether it is a ScrumMaster or upper management.

In my view, project leadership is what is needed and what will start taking a much more significant role. This may not be good news for those who rely on the tools of project management but it is what is necessary to be successful. But remember, soft skills are very hard to acquire and use successfully!

More CBPM & Agile #2

I keep digging into other Agile approaches and comparing them with CBPM. Recently I attended a two-day CSM (Certified ScrumMaster) workshop, took the test and now have my CSM designation. There seems to be more and more recognition about this designation, similar to where the PMP was a few years ago. Having that designation has led to some new contacts.

But how does it compare with CBPM? Scrum, like CBPM, emphasizes the importance of the team, the need for frequent deliverables, and the constant monitoring (by everyone in the team) on progress and the identification of challenges and how the team can help overcome them. Scrum emphasizes iterations of 2-4 weeks (typically). CBPM, with its constant review of progress, could be viewed as either iteration-less or having weekly iterations. Either way works. While Scrum plans for each iteration CBPM plans out through the commitment horizon, modifying as appropriate.

A key difference in origin: most Agile approaches came out of software development. CBPM came out of semiconductor design. As such it is able to more easily be used with non-software projects than most Agile approaches. Not to say you cannot use Scrum with non-software projects, but the connection to software is very tight and I haven’t seen much documentation on how to use it with non-software.

I continue researching some of these approaches as some of the concepts may be of value to CBPM practitioners. Stay tuned!

BTW, a CBPM session has been scheduled for June 19th in Santa Clara, CA. Another one will be held either on June 18th or June 21st in San Francisco.

Methodology wars … not!

Recently I reengaged with Agile methodologies, attending a ScrumMaster workshop conducted by LitheSpeed in DC (highly recommended if you are looking for a ScrumMaster workshop). Took the test and passed it.

I have been reading a lot about Agile, so nothing really new in the workshop. But I did get a sense that there are divisions among the various Agile practitioners (some of you may go “duh!”) There are the XP, Scrum, RUP, Lean practitioners that decry that their way is the only way. They all agree that waterfall doesn’t work (I too, although I’ve made it work by layering CBPM on top of it, making it somewhat Agile!)

Mark Kennaley’s SDLC 3.0: Beyond a Tacit Understanding of Agile does a very good job of tying the various Agile methodologies together, showing how to leverage the various strengths. To me, this is the way to go. In my experience, it is rare that one set of tools/methods can address any one situation. I pick and use what makes sense at the time, changing in mid-stream if necessary. Mr. Kennaley’s approach is refreshing and I’m sure there are many other Agile practitioners who feel the same way.

SDLC 3.0 also points the way forward from here. So, if you are interested in Agile and how they can work together, you may want to pick up Kennaley’s book.

Mathematical Explanation of why CBPM (and Agile) works

Just got from Amazon SDLC 3.0: Beyond a Tacit Understanding of Agile by Mark Kennaley. I have seen it mentioned in one of the Agile emails I get on a regular basis and sounded interesting: where do we go from current Agile?

As readers know, CBPM (Commitment-Based Project Management) is also an Agile framework that can help team deliver not only software but also hardware and other types of projects (it’s been used in semiconductor development, factory design, rocket design, radiation dosimeter development among other efforts).

So, I started the book thinking I was going to get a lot of words, some nice pictures, etc. Then I got to chapter 3 and I thought I was back at West Point in my EE3xx (can’t recall the number) Control Systems class! Here it was, including Laplace and Fourier transforms, stuff that I once knew about but could not remember much of!

Well, it turns out that while software development projects (the book is focused on Agile methods that are used for software development. However, the findings apply to CBPM which also does hardware as mentioned above) are chaotic in nature, they are still predictable, controllable, and can be modeled.

The model uses a proportional control (resources), an integral control (summation of past errors — test of deliverable), and a derivative control (how fast an error is changing).

Adding too many resources to a project (proportional control) to catch up make the project later (remember Frederick Brooks and The Mythical Man-Month? If no, time to read it!). It also leads to out of control situations as resources try to “help”, making things worse. Not providing resources doesn’t let the project reach it’s result.

Assessing how well the product meets requirements is the integral control. With CBPM checking weekly (derivative control), the error added in one week is minimized, controlling how far out of spec the solution gets. Traditional project management, with its limited, late in the cycle checking, has to deal with a potentially very large error.

Little did I know that my electrical engineering course work would come back so much later to be helpful! If you are interested in why CBPM (and Agile) works, take a look. It may give you ammunition next time your boss wonders why you are checking results so often.

Besides this chapter, there’s a lot of other good “stuff” in the book. So take a look.

More CBPM & Agile Thoughts

We had some good discussions in LinkedIn’s “Project Acceleration through Commitment-Based Project Management“group with respect to my prior blog. One individual indicated that CBPM should be viewed as another Agile framework, just like Scrum. That idea reinforced my thoughts about CBPM and the fact that it fits properly within the Agile philosophy.

CBPM focuses on getting deliverables done with as few “drag” (non-value or low-value) activities as needed. The owners determine how to deliver on their commitments, including making sure that any dependencies on other deliverables are understood and taken into account. Management oversight is minimal.

The inspect aspect of Agile is addressed via the discussions that owners and customers have on the deliverables and the final say that the customer(s) has/have on whether the deliverable is done or not done. This feature, the need for owners and customers to discuss the scope and status of deliverables, is a variation of the Agile inspect process at the end of an iteration.

Iteration-wise, CBPM is not fixated in any length of the iterations or cycles. The goal is to complete deliverables of value as quickly as possible. Due to its origins in the hardware business, there’s less emphasis in wrapping up a set of deliverables into a release or sprint, although that is very viable.

CBPM is an Agile framework that has some key capabilities (i.e., support for non-software projects) that other Agile frameworks may not. This does not mean that it is not usable in software efforts. As a matter of fact, it can easily be applied to software efforts, even to those run under the waterfall method (gnashing of teeth here! 😉

If Intel can plan and deliver some of the most complex products in the world using CBPM, almost any project can use it.