The Regenerate Web

The conference room was comfortable. New leather chairs and a marble top. Nothing like success to create a little overhead.

Sam had assembled a cast of the brightest minds in the company. Marketing was represented, sales, customer service, production and accounting. Everyone looked armed with official looking reports, charts and graphs, ready to defend the slightest attack.

Sam was good. He wasn’t looking for a scapegoat. He knew the problem wasn’t from someone being lazy, or even a wrong decision. He knew it was more likely that the organization’s system needed some attention.

He began by explaining what he had observed, and asked each member to accurately report the real figures behind the events. Unfortunately, four weeks worth of excess finished goods had translated into an eight-week inventory turn. Something had put the brakes on the market.

“So, take a piece of paper,” Sam began, “and write down your condition of satisfaction for this meeting? What has to happen in the next two hours that will indicate time well spent?”

The discussion around agile software development methods being considered Project Management processes brings up a core issue that has been around for a long time.

What do we mean when we say Project Management, when we say Project? Here's one starting point. There are other starting points, but this one is straight forward. It's the PMBOK Process Groups, with the PMBOK Knowledge Areas arranged under them. From the PMBOK Point of View, this is the full coverage set of processes and knowledge areas that are in place when you're managing a project.

Now when we start a conversation about an agile software development method being equivalent to PMBOK's project management framework, maybe it would be useful to ask a few questions.

• Does the proposed software development method have coverage for the elements of this diagram?
• Is this coverage equivalent in the ways PMBOK describe? Beyond just a name?

I often meet people who are transitioning to agile, and they decided to pick Scrum, because it’s a helpful project management framework. Ok, that makes sense. But then they decide that they no longer need project managers, and that the development manager can act as the Scrum Master.

The Scrum Master is not a management position. The Scrum Master protects the team’s process and removes the team’s obstacles. For me, the Scrum Master is analogous to the project manager. (I’ve never believed in command-and-control PMs.)

There is still a need for managers, but a little differently.  I don’t see the need for functional managers. The agile team needs a manager who champions that whole team. That means that the champion managers need to understand all the functional parts in the team, so they can help each team member.

But the real issue is that it’s a bad idea to have a manager be a Scrum Master. Here’s why:

1. The Scrum Master is a part of the team, and the manager, because of his/her titular authority can never be a part of the team.
2. People are reluctant to take a risk in front of their managers. (Bob Sutton in Weird Ideas That Work: How to Build a Creative Company cites data about this.)
3. Managers set direction, which is more strategic work. They do this with managing the project portfolio, looking at the makeup of the teams, seeing if they need more people. Scrum Master work is tactical, about the day-to-day work of the project team. If you have to choose between strategic work and tactical work, which one will win? (Tactical, all the time.)

So what does happen to the managers when an organization transitions to agile? They help teams self-organize. They manage the project portfolio. They provide feedback and coaching. They champion the team. They take the lead on hiring.

Managers, do your management job. Project teams, including the Scrum Master, do your project work. The two types of work intersect above the project, not in it.

Tweet This Post

I recently led a workshop on Hiring for an Agile Team.  We discussed diversity and I explained my position: the more complex the problem, the more personality and experience diversity you want on your team. That’s because different approaches to solving problems and backgrounds help the team see what their options are.

I once worked with a team who were all introverted, quick to come to decisions, and all had the same kind of product experience. When it came time to develop a brand new product, they had trouble. They had no one who came up with wacko ideas on the spur of the moment, and no one who could keep options open for a while. They hired someone who liked to wait longer to come to decisions. That person also connected problems and solutions differently than the original team members did, so he was a very helpful addition to the team.

When I worked for my first machine vision company, I had no idea how machine vision inspection worked. But I had a product to deliver, so I experimented with different algorithms, different lighting, and different placement of the piece to be inspected under the camera. I didn’t know much about machine vision, but I knew about problem solving. One of the more experienced engineers told me that the color of the light would not make any difference. Except, that was the variable that made all the difference in solving the problem.

I wish I could claim brilliance, but I can’t. I can claim that previous experience of varying parameters in experiments and keeping a notebook of the potential solutions and how they worked was helpful. That, I’d learned in an instrumentation company.

Remember that personality and experience diversity is a piece of diversity when hiring. Do you need people who think differently? How about people with different kinds of product experience than you have? You might be pleasantly surprised. Problem solving skills transcend product experience.

Tweet This Post

Ten reasons to use a team to solve a problem.

1. To generate fifteen alternative solutions instead of three.
2. To get more ideas on the way a project could go wrong. Think BP oil spill.
3. To gain technical insights that the manager doesn’t have. Managers think they know everything. They don’t.
4. To get Time Span perspectives on solutions from long-term impact to short-term execution.
5. To gain willing cooperation from the same team that identifies AND executes the solution. If the team does not believe in the solution, their execution will be poor.
6. To shift the energy from the manager to the team. Without this energy, the solution might not work. If all the energy comes from the manager, you will have a very tired, burnt out manager.
7. To increase engagement, team spirit, to build cooperation. If you want to build a team, give them a problem to solve.
8. To keep watchful eyes on the project, engaged watchful eyes, when the manager has to leave for a meeting.
9. To solve the same problem faster, the next time, even if the manager is not around.
10. It’s not that I am lazy, but my stress level, as a manager, goes down when I can share the work.

The next topic in our Working Leadership Online program is all about Team Problem Solving. It kicks off on Monday, July 5 (I know some of you will still be celebrating July 4). As is our custom, we are opening (50) Introductory Memberships to the program. If you would like to get on the list, follow this link to FREE Introductory Membership.

Your Introductory Membership makes you a full participant in this highly interactive learning program. Here’s what people say about it.

There’s a lot of valuable information in this course that isn’t easily available elsewhere, and the coaching from Tom in addition to accountability for actually carrying out the assignments makes for a solid learning experience. Keep up the good work. The online format makes the course accessible, and makes it easy to put into practice directly in a work environment. -Erik LaBianca

The option of learning online at my convenience is a great benefit. This program is excellent – I learned many things that I can apply as a manager. -Arlene Breitkreuz

I want to institutionalize this online training as a mandatory part of every manager’s experience in my company. -Derek Bullen

Why not take a minute, now, and sign up here? Working Leadership Introductory Membership

The talk around the agile community of The Oath of Non-Allegiance, got me thinking about the general question of how to deal with new ideas. There is nearly an endless source of ideas in any organization. Either internally generated or externally acquired.

The challenge is how to sort through all these ideas in the presence of a project environment. This means bounded scope, bounded time, and bounded deliverables. And bounded attention span for all the participants.

Measures of Effectiveness (MoE)

Measures of Effectiveness are intended to provide constructive, definitive indicators of performance. For example MoE's for operations might read like:

Are the users ...

• ... getting the support they need when and where they need it?
• ... "in charge" and able to control their assets to perform the needed work?
• ... getting support without having to worry about it any more that worrying about the support they are getting for other initiative?

So For Alistair's Oath

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

What are the Measures of Effectiveness (MoE) for this, where ...

• Measures of Effectiveness (MoE) represent the customer view, usually annotated and of qualitative nature. They describe the customers’ expectations of a product, project or system; the voice of the customer.
• Measures of Effectiveness (MoEs) are quantitative measures that give some insight into how effectively a idea, suggestion, process or method is, should, or could be performing.

Along with the MoEs come Measures of Performance (MoP)

• Measures of Performance (MoP) are the corresponding view of the engineer; a technical specification for a product. Typically Measures for Performance are quantitative and consist of a range of values about a desired point. These values are what an engineer targets when designing the product, by changing shape, materials and manufacturing process, so as to finally achieve the qualities desired by the customer.

What's the Point?

When we suggest something, like let's all take this oath, how can we tell that doing so has any effectiveness what so ever? What's the point of doing something if you can't tell it's going to result in some beneficial outcome? To someone, anyone? Why Bother?

There’s a push in the agile community to recognize women and see if we can’t get more women on agile teams. Whatever you think about the program, the goal is a laudable one. Hiring women creates a diversity that is difficult to match with an all-male team. Women tend to bring more collaborative skills and more empathy skills to a team. (That’s a gross generalization. I realize that.) Rick Scott in his, Response: Diversity in Agile twitter convo said something profound:

Screw that, it’s everybody’s problem.

He’s correct. That’s why I have several drafts lined up to discuss diversity.

The problem with hiring women is that if only about 20% of new college grads in computer science are women, are there enough women to work on our teams? Do we need to find women somewhere else? Is that what we want to do? I don’t know. (I am getting involved in a program to talk with middle- and high-school girls, so they can see that technology is a field to consider.)

Women are not the only disempowered group. Look around your workplace. How many people are white men? How many are not?

I want to hire people who are capable of doing the job. I don’t want to hire people to fill a perceived type of vacancy, an unfilled diversity bucket. But we need to do a better job of finding people who don’t look just like us to work on our teams. I don’t have all the answers. But I do know this: if you are a hiring manager, look inside yourself. Do you discriminate against people based on their gender or school affiliation or first or last name? If so, please reconsider.

P.S. In case I wasn’t clear, I never advocate hiring anyone who is not capable of doing the job, just to fill a diversity bucket.

Tweet This Post

Just a note when you hear any suggestion that new ideas can solve old problems.

In the business and practice of science - I come from the particle physics world - any new theory, suggestion of a change in principles, or a change in the practices of applying the theory, must be falsifiable to be considered a candidate for experimentalist (that was me) to be interested.

Falsifiable theories must make predictions that can then be tested.

So when someone postulates that such-and-such version 2.0 is now a replacement for the old such-and-such version 1.0, they are putting forth a "theory." In order to falsify this theory - that is show it is a candidate for replacement, the theory must make predictions is some sort. Something like...

My new proposal solves problems in this way and can be tested in that way in a broad enough set of examples to be statistically significant. 

"Enough samples" usually means 15 to 30 - considering the Clopper-Pearson testing applied to the population of possible places the new "thing" can be applied.

So the next time you hear someone say, my approach is much better than the old approach and you shoudl start using it, you can ask, how can you show that your approach can be tested?

Gretchen’s face displayed confusion. “What do managers do to their teams that systematically, over time, disables them from being able to solve even the simplest of problems?” I repeated.

“You’re not thinking this is my fault, are you?” she finally spoke.

I turned my head to the side, still staring at her.

“No way,” she protested.

“Every time a manager provides the solution to a problem, it robs the team of its ability to engage the problem. Over time, the team’s ability to solve problems begins to atrophy. Before long, even the simplest of problems will be brought to the manager for solution finding.

“The team begins to enjoy this new arrangement. With the responsibility for the decision now firmly resting on the manager, so goes the responsibility for the outcome. If the outcome is poor, it’s the manager’s fault. If the outcome creates more problems, it’s the manager’s fault. Your team likes this arrangement.”

“You know, you are right,” I told Gretchen. “Your team, over time, has systematically become incapable of solving problems.”

Gretchen didn’t speak, but began to slowly nod her head.

“How did they get that way? What happened to them?” I asked.

“What do you mean, what happened to them?” Gretchen’s nodding stopped.

“When the people on your team started working here, they were full of questions. They were curious. They experimented. They made mistakes. They learned.”

Gretchen began to nod again.

“But, now, you tell me they act more like zombies. So what happened to them?” I was looking directly at Gretchen, not blinking. Her nod stopped again, so I continued.

“Gretchen, what do managers do to their teams that systematically, over time, disables them from being able to solve even the simplest of problems?”

A recent post on PM HUT speaks about Balancing Quality, Schedule and Cost. Ignoring for the moment that Technical Performance Measures (TPM) are the new description of the olde PMBOK use of Quality.

These TPMs address Measures of Effectiveness (MoE) and Measures of Performance (MoP). These and the Key Performance Indicators (KPP) include product or service quality.

Once the project is baselined - and not baselining in some way, is a major failure mode of most projects that are headed to the ditch - the connections between cost, schedule, and technical performance is a NET SUM Game. Changing one value impacts the other values.

With a baselined cost, schedule, and technical performance, there is no way to create new time, new budget.

So "balancing" these "Trade Spaces" is done BEFORE the baseline is struck. At that point everything is up for trade options. After the baseline, only a change request can make change to undo what was baselined. This sounds so formal and draconian - it is not. You can manage the change processes in as light or as heavy a manner as needed. If you're flying to moon you do one thing. If you're building an emerging web site for internal use you do something else. But no change control on the baseline, usually means chaos reigns from day one and never gets better.

The conjecture that 

These days, the world is moving so fast that you have to constantly check to see if you are still on target for delivering value, even if quality, schedule and cost constraints are met. Technology cannot do this for you; it is a subtle, complicated process that requires market research and an understanding of your customers, for starters.

is actually NOT true. This is where technology can help the most. With a baselined cost, schedule, and connections to the technical requirements, an integration of these three factors provides visibility into schedule and cost performance against the technical performance.

The Technical Performance Measures are defined by Measures of Effectiveness and Measures of Performance along with the Measures of Physical Percent Complete. The briefing Knowing What Done Looks Like, Connecting the Dots Between Technical Performance Measures, Earned Value, and Physical Percent Complete is one starting point for addressing this Ponzi scheme found in many project domains.

Alistair's call for an Oath of Non-Allegiance, re-posted by Jesse Fewell about

Seems to be a call to come together on the processes of building software based products or services. Great idea. An idea worth pursuing. An idea that may have bookable value to the project management and software development communities.

But this call also seems to have no context or domain. It also seems to ignore to notion of current standard practices, past performance, established theory and established practice, and leaves the conversion open to very type of "cock-a-mamy" ideas that abound in the absence of a context, domain, principle, practice, and all the other guidance - that when ignored - and so times intentionally ignored - results in failure.

Here's a core issue.

How may ideas do we have time to consider? Every idea that comes in the door? EVERY idea? What are the qualification for being credible? Does an idea have to be feasible to be considered. Then credible? Given a project domain, with time, talent, and treasure - how many ideas are enough ideas to move forward?

What are the Measures of Performance (MoP) and Measures of Effectiveness (MoE) for these ideas?

• They've been shown to work before in similar contexts and domains?
• They have measure of effectiveness and measures of performance that are appropriate for the problem at hand?
• They have some basis in principles that are know to be effective in the current domain and context?
• When we say Best Suit the Current Situation, what are the measures of Best?
• Who defines Best?

There's a great quote from Gary Taubes, Bad Science: The Short Life and Weird Times of Cold Fusion, where the governor of Utah, Norman Bangerter is presented information by Ian Cumming, a Regent of the University of Utah, about the supposed discovering of Cold Fusion, by Stanley Pons and Martin Fleischmann. Cumming was asking Bangerter for State money to further develop the concept of Cold Fusion and have the State of Utah share in the riches to come from free energy.

Bangerter to Cumming Knowing nothing about it, I'm highly optimistic

So What is Best Suited for the Current Situation Mean?

We likely need to answer some questions

• What is the situation?
• Are we managing a project?
• If so, what kind of project?
• Are we building a product?
• If so, hat kind of product?
• What is the purpose is this project?
• Who's money are we spending?
• Do we know our tolerance for risk?

So Knowing about it, I'm highly optimistic.

But in the absence of Knowing Nothing About It - How About Some Immutable Principe's of Projects?

I'd suggest here's a way to test the optimism of this Oath of Non-Allegiance. What ever the idea, from what ever school of thought, with what ever heritage this idea has, in the situation let's ask some simple - and possibly immutable questions.

• Do we have means to know what done looks like in some measurable form meaningful to the buyer?
• Can we put forward some tangible evidence that we're making progress?
• When we say we're making progress, can we point to physical deliverables that represent that progress?
• Can we discover, through some means, the risks that will be encountered along the way to this progress. And can we, through some means, continuously mitigate these risk, in some way to remove them from impacting our outcomes?
• Can we speak, in some clear, concise, and semantically logical way, about progress toward the "Done" state of the project, product, service, and deliverable resulting from our efforts.

 My computer has been on the blink for the past couple of weeks.  Technical mumbo-jumbo.  At first I thought it was malware.  Then we thought the 2/3 of the RAM was kaputz.  Finally we figured out it was a hard drive problem.  Lenovo gave a startlingly fast turnaround time once the problem was diagnosed.

It's back in full working order now, and I'm very grateful for that.  It's hard being away from someone you love.  To be honest, blogging on another computer almost feels like cheating, so I've given myself a bit of a sabbatical.  Instead of writing, I've been doing more "listening" in the blogosphere.  No commenting... I just felt like lurking in the shadows of other people's thoughts.  And it's been really intriguing.

I learned about Patti Digh's friend, Celeste, who passed away recently, and how cool of a woman she was and the legacy she left on a lifetime of friends.

From Drew McLellan, I found out about Dawn dishsoap and how their brand message has a powerful impact on the disastrous BP oil spill.

Chuck Raasch of Gannett News told me that - rather than Republicans or Democrats - women were the big winners in last Tuesday's primaries... and why.

Because my colleagues and I recently discussed this issue, I read with interest Glen Alleman's short post about status reporting frequency and the one question we project managers should ask.

Canyon Girl caught my attention with Henry David Thoreau and the importance of paying deliberate attention to my surroundings and not taking things for granted.

My good friend, Pete Jones, shares my philosophy about avoiding chain restaurants.  I'll be eating at Pagliai's Pizza soon because of his recommendation.

Central College Professor Jann Freed gave a fitting tribute to coach John Wooden.  Jann totally nailed it, and her words inspired me.  I hope some day I can leave that kind of legacy.

There were some other blogs and posts and news stories I read on various sites whenever I could oust my wife or child from their computers, but I just wanted to share with you that some times it's OK to put down your own blog and take a little thought-romp in others' blogospheric back lots.

I realize I work in a unique domain compared the majority of highly vocal voices in the software development world - the agile software development world. Some times I get to connect to the software development world of small groups of individuals. Our software world is highly structured and sometimes over burdened with the formality of process - all for good reasons.

I attended the Pikes Peak PMI meeting Thursday to hear Dr. James Brown speak on two topics. He's a very good speaker, experience program manager, and thought leader in the domain of Program Management. His book, The Handbook of Program Management, is one of my favorites.

He had many "stories," and anecdotes directly applicable to our current situations. I'll use many of them in our daily practices and a few in our efforts to move our firm forward. More importantly was the re-connection with the project management community outside the local focus on IT. The Colorado Springs PMI community is more diverse than our Denver world of mostly IT.

I came across a posting tonight which reinforces this notion of a "project," that is not defined by an emerging set of activities hoping to stay connected with the customer. It's a small project compared to our mega projects - I just finished our section for a proposal valued at multi-billions for the USAF. I'm  jealous in some ways for those working projects that have direct beneficial outcomes in a short ot moderate time.

This project is Beach B200 King Air with two instruments. The project has aircraft, sensors, software, flight planning, data capturing and processing, science, and other tangible, measurable beneficial outcomes.

What Does All This Mean

After a long week of preparation for RED TEAM for a very large proposal effort, looking a small projects connects the dots between the universal aspects of success.

• Do we know what done looks like in some measurable form meaningful to the buyer?
• Is there some tangible evidence that we're making progress?
• When we say we're making progress, can we point to physical deliverables that represent that progress?
• Are the risks to this progress continuously be mitigated in some way to remove them from impacting our outcomes?
• Do we speak about progress toward the "first flight," "mission success," "be on station," words like that?

While these types of projects are confined to specific domains, where general IT projects are just that general, they are examples of the core project management processes. I'd strongly suspect that project manager and her support aren't arguing about the definition of "method" versus "methodology," or the purity of one processes over another.

Nope, they got to get that beach B200 in the air and "on station," at the time they told the flight planners they said they would

An article is the current PM Network, A Closer Look: Excel Energy, Boulder, Colorado, USA, describes the smart grid revolution and its deployment in Boulder. While there are many interesting aspects of the project. At $100 million, the project ambitious goals make tremendous strides in the integration of distribution and electrical management systems.

What's missing from this article - mainly because PM Network is one of those upbeat, feel good, type of magazines - is that the project is has a few problems...

Xcel originally anticipated that capital costs for the project, called SmartGridCity, would be around $15.3 million when the city was chosen as the site of the project in early 2008. But in May 2009, Xcel revised the number to $27.9 million — and now says a more accurate number is probably $42.1 million. The number excludes the cost of running and maintaining the grid.

From Smart Grid News

So much for project management examples. As a resident of Boulder, slightly outside the city limits in Niwot, this is not new news. A rate increase was passed by the PUC to cover the $11million over run. While the Smart Grid is certainly needed. We usually have to call Excel when the pole transformers get hit by lighting during our frequent thunder storms, o tell them the lights are out. No sensors to detect the pole mounted transform has failed, which I drive by everyday on the way to the office, having been struck. Same for Comcast's above  ground cable which also gets knocked out during our frequent thunder storms.

We have a policy at our firm - never name a project or show a picture in the literature of a launch vehicle before that vehicle as flown successfully - it may blow up in the lunch pad.

This may  be a a suggestion PM Network may want to consider.

“I know you think your solution is better than anything your team might come up,” I agreed. “Do you think that is really the point?”

Gretchen was resisting. “But, I don’t have time to have a meeting, and besides, I don’t think my team wants to be creative. Sometimes they act like dolts.”

“They act like dolts when you solve a problem like this for them?”

“Well, yeah. I can solve problems like this pretty easy. I have been in the business for six years. I have the experience. But when I tell them what to do, they’re like zombies from the Night of the Living Dead. Some of them walk around like they still don’t know what to do, even though I gave them the solution.”

“Why do you think that is?” I asked.

“Like I said, I just don’t think they care,” Gretchen insisted.

“You are right. They don’t care about your solution.”

This caught Gretchen off-guard. She didn’t expect me to agree so easily. “They don’t care about your solution,” I repeated. “So, who’s solution do they care about?”

“Well, I’m the only one who can solve the problem,” Gretchen tersely replied.

“Indeed?” -TF

Knowing the staffs capacity for work is critical to forecasting cost and schedule. We have a working example taking place at our house. In Colorado, the landscaping has river rock around the house to move the snow melt away from the foundation. Over time, dirt fills in between the rocks, weeds grow and it's an endless battle to pull weeds, spray Round Up, and generally keep it clean.

Taking all the rocks out, replacing the cloth barrier under the rocks with new weed proof barrier, cleaning the rock, and putting then back is a job to be done every 10 years or so. We've waited 15.

The neighborhood landscaping crew - high school boys - are doing the work this summer. They bid a fixed price for labor, plus materials. They've built a cleaver machine to get the rocks cleaned and ready for replacement, using a power washed and a screen.

Now the capacity problem. They assumed they could get all this done before summer was over and they have to start school. They started in the front, removing rocks, cleaning, re-laying barrier, and putting the rocks back. A few weeks into this job it was clear to me that they were not going to make it at the pace they were going. So I asked a few questions:

• Guys (2 highschoolers), from the work you've done to date, how many linear feet of rock replacement have you done per period of performance? That is, how much rock are you replacing per hour, per day, per week so far?
• Do you have the measurement the rock beds around house and around the lawn perimeter - lawns are expensive things in Colorado, so much of the back yard is in wild grasses that can live on 11" of rain a year. Are these adjusted for the wide of the beds, which varies from 12" to maybe 3'
• With these two numbers - your rate of work to date and the "to go" distance - when do you think you'll be finished? Is this date on or before the start of school or the first snow?

This is the capacity for work calculation. At X feet per day, and Y feet total, minus Z feet to date, what is the completion date?

Capacity for Work

This is what the agile folks call velocity. It is a semi-calibrated work performance number. The Earned Value folks calculate the To Complete Performance Index (TCPI). This tells us the calibrated performance in terms of CPI (Cost Performance Index) and SPI (Schedule Performance Index) we need to maintain to complete on time. Earned Schedule has its own version of a performance index.

Many failed projects in the IT world we work have no idea of their capacity for work. They work at the rate they work.

Hope is their current strategy - We hope to get done by the start of school

Hope is NOT a Strategy. Measurement of physical percent complete of the work performed on the day is was planned to be complete at the cost it was planned to be completes is the only way to forecast the future performance of the project.

If you don't know your capacity for work, you can't know when you will be done or how much it will cost. No matter what the schedule and budget plans says.