Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Project Management

Three Questions to Ask when Being Micromanaged

Mike Cohn's Blog - Tue, 02/14/2017 - 16:00

One of the foundational principles of agile and Scrum is a belief in the power of self-organizing teams. This makes a micromanaging boss, ScrumMaster or product owner a particularly difficult problem for agile teams.

I’ve found asking three questions helpful in dealing with micromanagers.

Who?

The first question is Who? Who is being micromanaged? If you are being micromanaged but the rest of the team is not, this tells you it is your own performance that someone is worried about. If so, you’ll need to improve your own performance and that stakeholder’s view of your performance.

But if your entire team is being micromanaged, the behavior is just part of who that stakeholder is.

To determine whether it’s just you or your entire team being micromanaged, spend a sprint or two noting what types of things draw the micromanager’s attention. Log all micromanaging activities so you can look back at the data and determine who is being micromanaged.

When?

A log of micromanagement activity will also help you answer the second question: When is the micromanaging occurring?

Does the stakeholder micromanage shortly before or after a meeting? For example, a product owner might leave their customer call every Tuesday feeling stressed and more inclined to micromanage. Or a Scrum Master might be prone to micromanage the day before the monthly meeting with the engineering VP.

Some people are more prone to micromanage at a specific time of day. A boss early in my career was particularly prone to micromanaging before his first cup of coffee.

Others may be more prone to micromanagement at specific times during an iteration. Perhaps the person you’re dealing with is most prone to micromanaging during the last few days of the iteration when he or she gets nervous about whether everything will get done. Again, log this type of information so you can later look for patterns.

I use a spreadsheet with the following columns:

Date: The actual date (e.g., March 8, 2017). This usually won’t help identify patterns but can be useful if you look back on the data and need to remember what might have been going on in the organization at the time.

Day of Week: Sometimes micromanaging occurs most frequently on certain days (e.g. Friday) so note the day of the week.

Day of the Sprint: To help see if micromanaging occurs most frequently at certain points within a sprint, note the number of days into the sprint when the micromanaging occurred. For example “Day 3” or perhaps “7 / 10” to indicate it occurred on day seven of a ten-day sprint.

Time: Note the time of day when the micromanaging occurred (e.g., 10:15 A.M.)

Who Was Being Micromanaged: Note whether it was you personally, the entire team, or perhaps a teammate being micromanaged.

What Was Being Micromanaged: Note the issue in this column.

Context: Note whether the micromanaging coincided with anything else occurring within the sprint, project or organization. Did it occur right before or after a meeting? Which meeting? What was occurring during the iteration overall?

Notes: Include anything additional worth remembering about the incident. You can see a sample in the following table.

 

Date

Day of
week

Day of
Sprint Time Micromanager Who? What? Context Notes March 8 Wed 6

10:30

Anne me Story about adding data sources    

Anne asked me for the 3rd time in two days how this was going.

March 8

Wed 6 2:15 Arie team Next week’s new client launch  

Arie emailed the full team to remind everyone how important the new client launch is

 

March 8
 

Thurs 6 9:28 Anne teammate  

Story about Salesforce integration

While en route to daily scrum, Anne asked me to tell Ashish

to see her sometime about the story he’s working on for her.  

Ashish has been providing her a daily update already as she requested.

 

Why?

After you’ve logged a couple of weeks of micromanaging activities, it’s time to ask the third question: Why is the micromanaging happening?

Scan your log looking for patterns. See if there are triggers that create the micromanagement. Perhaps your product owner micromanages you after her weekly meeting with her boss.

Perhaps your line manager is prone to micromanaging at the end of the month when he has to prepare a report for his boss.

Based on the patterns you see, try to identify conversations that may be worth having with whoever is micromanaging. You’re unlikely to get far by merely saying, “Please stop micromanaging.” Instead, talk to micromanagers in an attempt to learn what concerns them that they’re behaving as they are.

Once you’ve identified some of the triggers for micromanaging, it’s time to anticipate and eliminate those triggers.

Anticipate and Eliminate

If you can anticipate micromanaging behavior by noticing when it occurs, work to eliminate the trigger. Often you can do this by proactively providing information to the micromanager.

For example, if you know your product owner gets stressed and micromanages after a weekly meeting with her boss, schedule a meeting with your product owner ahead of that meeting. Be sure your product owner is well informed and prepared for her meeting.

Proactively provide information to stakeholders who are prone to micromanagement. Try to do it just in time so they have (and remember) the information in advance of whatever triggers them.

Avoid creating burdensome new processes for yourself. But you can assert control over a stakeholder (or boss) relationship by proactively providing information rather than waiting to be asked for it and then being forced to provide it on someone else’s schedule.

Some People Are Incurable

By following the advice here, you won’t always be able to eliminate micromanagement. Some stakeholders are incurable micromanagers. But the tips here will help you take greater control over most situations and generally make them more tolerable.

How Have You Handled a Micromanager?

What’s your worst story of being micromanaged? How did you handle the situation? Please leave your thoughts in the comments below.

 

Get Your Free Micromanagement Log

Start tracking to help eliminate micromanagement

Download Now!

Micromanagement Log cover

I’ve Had Enough

NOOP.NL - Jurgen Appelo - Mon, 02/13/2017 - 18:50

I can’t take it anymore.

I’ve had enough of people asking me how they can improve their team, while none of the team members are willing to run any experiments and learn from their failures.

I’ve had enough of organizations that want to scale with agile, while the change programs that managers roll out are still mainly about cutting costs and optimizing profits.

I’ve had enough of politicians promising change and making things better, while the policies of their parties are all about scaremongering and protectionism.

I firmly believe that most people are good. They usually mean well. But more often than not, group performance is abysmal. Progress stalls because teams, organizations, and political parties lack a systemic approach to purposeful evolution. I fear that, in most cases, the whole is less than the sum of the parts. In other words, great people, terrible systems.

Can we help improve those groups?

I’m sure we can. But history proves that writing books, running workshops, and organizing conferences are not enough to achieve sustainable improvement. And despite their heroic efforts, coaches and consultants often see their hard-earned results evaporate after yet another idiotic organizational system failure.

I am convinced that the solution is staring us straight in the eyes. The very reason that teams, organizations, and political systems perform badly is that the world is changing faster and faster. Have you ever seen the adoption rates of smartphones, social networks, or streaming media? Did you see how fast people are learning to use wearables and robots?

Anyone who claims that “people resist change” is just flaunting his or her incompetence.

They key to improving collaboration and performance across teams, organizations and other groups is understanding how some human behaviors are adopted at a rate that is similar to a global epidemic. If you have a good idea, and people aren’t picking it up, it doesn’t mean that they resist the change. It also doesn’t mean that your idea is wrong. It just means that there is no platform enabling the idea to go viral.

I’ve had enough of good people wasting their time in bad teams and organizations. I’ve had enough of fantastic books, workshops, conferences, coaches, and consultants achieving only temporary performance fixes. We need a platform that allows good ideas to spread across teams and organizations at Internet-speed. And like the adoption rates of new technologies, we need that platform to make any behavioral changes sustainable.

I want the whole to be more than the sum of the parts. There should be a platform that helps people grow awesome systems.

Do you want to build that platform with me?

JOIN ME

The post I’ve Had Enough appeared first on NOOP.NL.

Categories: Project Management

Why I Use a Paper Kanban Board

My most recent post about how to Visualize Your Work So You Can Say No showing a couple of different kanbans was quite popular. Several people ask me how I use my personal kanban.

I use paper. Here’s why I don’t use a tool:

  • I am too likely to put too much into a tool. I put all this week’s work, next week’s work, next month’s and next year’s work, even though I’m not going to think about anything that far out. Paper helps me contain my To Do list.
  • When I collaborate with others, they want to break down the stories (large as they may be) into tasks. No!! I can’t take tasks. I need to see the value. See my post about From Tasks to Stories with Value.
  • I change my board, depending on what’s going on. I often have a week-based kanban because I retrospect at the end of the week. I often—not always—have a “today” column.

This is what my board looks like this week. it might look like this for a while because I’m trying to finish a book. (I have several more books planned, so yes, I will have a bunch of work “in progress” for the next several months/rest of the year.)

I have several chapters in This Week. I have two chapters in “Today:” That helps me focus on the work I want to finish this week and today.¬†As a technical editor for agileconnection.com and as a shepherd for XP 2017, I have work in “Waiting to Discuss.” I¬†will discuss other people’s writing.

Earlier this week, I had interactions with a potential client, so that work is now in Waiting for Feedback. Sometimes, I have book chapters there, if I need to discuss what the heck goes in there and doesn’t go in a chapter.

I haven’t finished much yet this week. I am quite close on two chapters, which I expect to finish today. My acceptance criteria is ready for my editor to read. I do not expect them to be done as in publishable. I’ll do that after I receive editorial feedback.

Could I do this on an electronic board? Of course.

However, I limit my WIP by staying with paper. I can’t add any more to the paper.

Should I have WIP limits? Maybe. If I worked on a project, I would definitely have WIP limits. However, the fact that I use paper limits what I can add to my board. If I notice I have work building up in any of the Waiting columns, I can ask myself: What can I do to move those puppies to Done before I take something off the Today or To Do columns?

I’ve been using personal kanban inside one-week iterations since I read Benson’s and Barry’s book, Personal Kanban.¬†(See my book review,¬†Book Review: Personal Kanban: Mapping Work | Navigating Life.

I recommend it for a job search. (See Manage Your Job Search and  Personal Kanban for Your Job Hunt.

You should use whatever you want as a tool. Me, I’m sticking with paper for now. I don’t measure my cycle time or lead time, which are good reasons to use an electronic board. I also don’t measure my cumulative flow, which is another reason to use a board.

I do recommend that until you know what your flow is, you use paper. And, if you realize you need to change your flow, return to paper until you really understand your flow. You don’t need a gazillion columns, which is easy to do in a tool. Use the fewest number of columns that help you achieve control over your work nad provide you the information you need.

Question for you: Do you want to see a parking lot board? I have images of these in Manage Your Project Portfolio, but you might want to see my parking lot board. Let me know.

Categories: Project Management

Visualize Your Work So You Can Say No

Most people I know—even the people supposedly using agile—have too much work to do. You have project work. You have support work, formal for customer support or sales, and informal for your colleagues. You have reports to write or file, time cards to fill out, or other periodic events.

You need a way to say no to more work.

I wrote an article for Better Software, which is now online. See Saying No to More Work. (You need to register for the site to see the article. No charge for registration.)

One person wanted to see the kanban boards I referred to in the article. I am happy to show them to you here.

These are two potential kanban boards. The one on the left is the basic personal kanban board. Note that there are no WIP (Work in Progress) limits (yet) on this board. I would add WIP limits. Especially if I wanted to convince my manager I was doing too much work.

On the right,  you can see a disaster of a personal kanban board. There are many items To Do, three in Progress and a total of six stuck in various Waiting states. Yes, I had a board that looked like this many years ago. Then, I made a picture on a piece of paper and explained to my boss I was just one person. What did he want me to do and not do?

Now, given what I know, I would add WIP limits to each column.

If you want to see the project portfolio images for how I start at the organization level: the calendar view and kanban view, see¬†Manage Your Project Portfolio at the Prags. At the end of the blurb, there’s a link to the quick start guide, which has just two of the images in the book. (I included many possible ways to visualize the project portfolio in this edition of the book.)

Here’s the key idea: Don’t take on more work than you can complete in a reasonable amount of time. Don’t multitask. Instead, see what your work is and how you might discuss it with your manager.

Categories: Project Management

Quote of the Month February 2017

From the Editor of Methods & Tools - Thu, 02/09/2017 - 16:40
One of the most important expectations to set early on is about involvement in the process. Many project stakeholders accustomed to traditional-style development view their role in a software development project as akin to dropping a car off for service: You tell someone what you need done and come back at appointed time to pick […]

From Tasks to Stories with Value

I’m almost at the end of the January Practical Product Owner workshop. One of the participants has a problem I’ve seen before. They have a backlog of work, and it’s all tasks. Not a story in sight.

I understand how that happens. Here are some ways I’ve seen the tasks-not-stories problem occur:

  • The technical people see the work they want to accomplish. They create a list of tasks to get there: design database, create infrastructure, fix these typos in the UI, and more.
  • Or, someone (such as an architect) is in charge of breaking down work, not team members. That person creates tasks.
  • Marketing or sales (or someone not in the product development team) says something like this: “I want a drop-down menu,” or a radio button or another¬†report. They don’t remember to explain who the value is for, or why they want that value. Pretty soon, the idea of value is gone altogether, and only tasks remain.
  • Teams start to create stories, and the stories are so large, they create tasks to cover the stories. Pretty soon, they stop creating stories at all. They only create tasks.

Here’s a gotcha: When teams measure story points as opposed to features, they often feel pressure from management to do more points. (See Who’s Playing Agile Schedule Games?)

Your customers don’t buy points. They buy completed features.

Something clicked for the participant last week. He saw the feature chart, which explains how scope expands during the project and what the team(s) delivers.

This chart shows the features complete, added, and remaining to do. Because it measures features—what customers buy and use—there’s no confusion about work done or not done. Plenty of work might be done. But, if the work doesn’t add to a feature, the work is inventory (or possibly waste).

Here’s one value of this chart: Until tasks add up to features, you don’t count them.

My participant couldn’t articulate the problems before. The chart helped him see and discuss:

  • Tasks—by themselves—might not add up to a feature. He wants features.
  • When he counts features, he can describe what’s in a feature set—a collection of features that you might call an epic or a theme.
  • He can explain why he wants just this small feature, and not necessarily all of a feature set for now.

The chart helped him see how to separate stories and count them. He is moving from tasks and technical stories to features, real user stories.

I use this chart with cumulative flow diagrams and the product backlog burnup chart to see where our work is and how much progress we make over time for a given feature set.

I recommend you build and count features (stories). The smaller you can make a story, the faster you can get feedback and see the value in it.

If you’re interested in this workshop, I have just announced the May 2017 dates. See Practical Product Owner Workshop: Deliver What Your Customers Value and Need.

Categories: Project Management

Influential Agile Leader, May 9-10, 2017

Is your agile transition proceeding well? Or, is it stuck in places? Maybe the teams aren‚Äôt improving. Maybe no one knows “how to get it all done.” Maybe you’re tired and don‚Äôt know how you‚Äôll find the energy to continue. Or, ¬†you can’t understand how to engage your management or their management in creating an agile culture?

You are the kind of person who would benefit from the Influential Agile Leader event in Toronto, May 9-10, 2017.

Gil Broza and I co-facilitate. It’s experiential, so you learn by doing. You practice your coaching and influence in the mornings. You’ll have a chance to map your organizational dynamics to see where to put your energy. You’ll split into smaller sessions in the afternoon, focusing on your specific business challenges.

If you would like to bring your agile transition to the next level, or, at the very least, unstick it, please join us.

We sold out of super early bird registration. Our early bird registration is still a steal.

If you have questions, please post a comment or email me. Hope to work with you at The Influential Agile Leader.

(See the servant leadership tag for the Pragmatic Manager  and the leadership tag on this blog to see relevant articles I’ve written before.)

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Sat, 02/04/2017 - 23:14

Every systematic development of any subject ought to begin with a definition, so that everyone may understand what the discussion is about.
Marcus Tullius Cicero (196BC ‚Äí 16BC), De Officiis, Book 1, Moral Goodness

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter
Categories: Project Management

Cone of Uncertainty - Part Cinq (Updated)

Herding Cats - Glen Alleman - Sat, 02/04/2017 - 16:41

The notion¬†of the Cone of Uncertainty has been around for awhile. Barry Boehm's work in ‚ÄúSoftware Engineering Economics‚ÄĚ. Prentice-Hall, 1981. ¬†The poster below is from Steve McConnell's site and makes several things clear.

  • The Cone is a project management framework describing the uncertainty aspects of estimates (cost and schedule) and other project attributes (cost, schedule, and technical performance parameters). Estimates of cost, schedule, technical¬†performance on the left side of the cone have a lower probability of being precise and accurate than estimates on the right side of the cone. This is due to many reasons. One is levels of uncertainty¬†early in the project. Aleatory and Epistemic uncertainties, which create the risk to the success of the project. Other uncertainties that create risk include:
    • Unrealistic performance expectation with missing Measures of Effectiveness and Measures of Performance
    • Inadequate assessment of risks and unmitigated exposure to these risks with proper handling plans.
    • Unanticipated technical issues with alternative plans and solutions to maintain effectiveness
  • Since all project work contains uncertainty, reducing this uncertainty¬†- which reduces risk - is the role of the project team and their management. Either the team itself, the Project or Program Manager, or on larger programs the Risk Management owner.¬†

Here's a simple definition of the Cone of Uncertainty: 

The Cone of Uncertainty describes the evolution of the measure of uncertainty during a project. For project success, uncertainty not only must decrease over time, but must also diminishe its impact on the project's outcome. This is done by active risk management, through probabalistic decision-making. At the beginning of a project, there is usually little known about the product or work results. Estimates are needed but are subject to large level of uncertainty. As more research and development is done, more information is learned about the project, and the uncertainty then decreases, reaching 0% when all risk has been mitigated or transferred. This usually happens by the end of the project.

So the question is? - How much variance reduction needs to take place in the project attributes (risk, effectiveness, performance, cost, schedule - shown below) at what points in time, to increase the probability of project success? This is the basis of Closed Loop Project Control  Estimates of the needed reduction of uncertanty, estimates of the possisble reduction of uncertainty, and estimates of the effectiveness of these reduction efforts are the basis of the Close Loop Project Control System.

This is the paradigm of the Cone of Uncertainty - it's a planned development compliance engineering tool, not an after the fact data collection tool

The Cone is NOT the result of the project's past performance. The Cone IS the Planned boundaries (upper and lower limits) of the needed reduction in uncertainty (or other performance metrics) as the project proceeds. When actual measures of cost, schedule, and technical performance are outside the planned cone of uncertainty, corrective actions must be taken to move those uncertanties inside the cone, if the project is going to meet it's cost, schedule, and technical performance goals. 

If your project's uncertanties are outside the Planned boundaries at the time when they should be inside those boundaries, then you are reducing the proabbility of project success

The Measures that are modeled in the Cone of Uncertainty are the Quantitative basis of a control process that establishes the goal for the performance measures. Capturing the actual performance, comparing it to the planned performance, and compliance with the upper and lower control limits provides guidance for making adjustments to maintain the variables perform inside their acceptable limits.

The Benefits of the Use of the Cone of Uncertainty 

The planned value, the upper and lower control limits, the measures of actual values form a Close Loop Control System - a measurement based feedback process to improve the effectiveness and efficiency of the project management processes by [1]

  • Analyzing trends that help focus on problem areas at the earliest point in time - when the¬†variable under control starts misbehaving, intervention can be taken. No need to wait till the end to find out¬†you're not going to make it.
  • Providing early insight into error-prone products that can then be corrected earlier and thereby at lower cost - when the trends are headed to the UCL and LCL, intervention can take place.
  • Avoiding or minimizing cost overruns and schedule slips by detecting them early - by observing trends to breaches of the UCL and LCL.
    enough in the project to implement corrective actions
  • Performing better technical planning, and making adjustments to resources based on discrepancies between planned and actual progress.

Screen Shot 2017-01-12 at 3.48.34 PM

A critical success factor for all project work is Risk Management. And risk management includes the management of all kinds of risks. Risks from all kinds of sources of uncertainty, including technical risk, cost risk, schedule, management risk. Each of these uncertainties and the risks they produce can take on a range of values described by probability and statistical distribution functions. Knowing what ranges are possible and knowing what ranges are acceptable is a critical project success factor.

We need to know the Upper Control Limits (UCL) and Lower Control Limit (LCL) of the ranges of all the variables that will impact the success of our project. We need to know these ranges as a function of time With this paradigm we have logically connected project management processes with Control System processesIf the variances, created by uncertainty going outside the UCL and LCL. Here's a work in progress paper "Is there an underlying Theory of Project Management," that addresses some of the issues with control of project activities.

Here are some examples of Planned variances and managing of the actual variances to make sure the project stays on plan.

A product weight as a function of the programs increasing maturity. In this case, the projected base weight is planned and the planned weights of each of the major subsystems are laid out as a function of time. Tolerance bands for the project base weight provide management with actionable information about the progression of the program. If the vehicle gets overweight, money and time are needed to correct the undesirable variance. This is a closed loop control system for managing the program with a Technical Performance Measure (TPM). There can be cost and schedule performance measures as well.

Screen Shot 2017-01-13 at 4.23.56 PM

Below is another example of a Weight reduction attribute that has error bands. In this example (an actual vehicle like the example above) the weight must be reduced as the program proceeds left to right. We have a target weight at Test Readiness Review of 23KG. A 25KG vehicle was sold in the proposal, and we need a target weight that has a safety margin, so 23KG is our target.

As the program proceeds, there are UCL and LCL bands that follow the planned weight.  The Orange dots are the actual weights from a variety of sources - a Design Model (3D Catia CAD system), a detailed design model, a bench scale model that can be measured, a non-flying prototype, and then the 1st Flight Article). As the program progresses each of the weight measurements for each of the models through to a final article is compared to the planned weight. We need to keep these values inside the error bands of NEEDED weight reduction if we are to stay on plan.

This is the critical concept in successful project management

We must have a Plan for the critical attributes - Mission Effectiveness, Technical Performance, Key Performance Parameters - for the items. If these are not compliant, the project is bcome subject to one of the Root Causes of program performance shortfall. We must have a burndown or burnup plan for producing the end item deliverables for the program that match those parameters over the course of the program. Of course, we have a wide range of possible outcomes for each item in the beginning. And as the program proceeds the variances measures on those items move toward compliance of the target number in this case Weight.

Screen Shot 2017-01-13 at 4.21.56 PM

Here's another example of the Cone of Uncertainty, in this case, the uncertainty is the temperature of an oven being designed by an engineering team. The UCL and LCL are defined BEFORE the project starts. These are used to inform the designer of the progress of the project as it proceeds. Staying inside the control limits is the Planned progress path to the final goal - in this case, temperature.

The Cone of Uncertanty, is the signaling boundaries of the Closed Loop Control system used to manage the project to success

Screen Shot 2017-01-13 at 4.38.04 PM

It turns out the cone can also be a flat range with Upper and Lower Control Limits of the variable that is being developed - a design to variable - in this example a Measure of Performance. In this case, a Measure of Performance that needs to stay within the Upper and Lower limits as the project progresses through its gates. If this variable is out of bounds the project will have to pay in some way to get it back to Green.

A Measure of Performance characterizes physical or functional attributes relating to the system operation, measured or estimated under specific conditions. Measures of Performance are (1) Attributes that assure the system has the capability and capacity to perform and (2) Assessment of the system to assure it meets design requirements to satisfy the Measures of Effectiveness, (3) Corrective actions to return the actual performance to the planned performance when that actual performance goes outside the Upper and Lower control limits. Again this is simple statistical process control, using feedback to take corrective actions to control future outcomes - feedforward.  In the probabilistic and statistical program management paradigm, feedforward control using past performance, with future models (Monte Carlo model of future behaviors) to determine what corrective actions are needed to Keep The Program Green.

Screen Shot 2017-01-15 at 7.37.49 PM

Another cone style is the cone of confidence in a delivery date. This Actual case it's a Low Earth Orbit Vehicle Launch date. In this case, as the program moves from left to right, we need to assure that the Launch Date moves from a low confidence Date to a date that has a chance of being correct. The BLUE bars are the probabilistic ranges of the current estimate date. As the program moves forward those ranges must be reduced if we're going to show up as needed. The Planned date and a date with a margin are the build to dates. As the program moves the confidence of the date must increase and move toward the need date.

  • The probabilistic completion times change as the program matures.
  • The efforts that produce these improvements must be defined and managed.
  • The¬†error bands of the assessment points must include the¬†risk mitigation activities as well.
  • The¬†planned activities show how the¬†error band narrows over time:
    • This is the basis of a¬†risk tolerant plan.
    • The probabilistic interval become more reliable as the risk mitigation and the maturity assessment add confidence to the planned¬†launch date.

Just a reminder again - the Cone of Uncertainty is a DESIRED path, NOT the result of an unmanaged project outcome.

Risk Management, as shown below, is how Adults Manage Projects

Screen Shot 2017-01-13 at 7.09.21 AM

Wrap Up On the Misunderstanding of the Purpose and Value of the Cone of Uncertainty

When you hear... 

I have data that shows that uncertainty (or any other needed attribute) doesn't reduce and therefore the COU is a FAKE ... OR ... I see data on my projects where the variance is getting worse as we move forward, instead of narrowing as the Planned COU tells us it should be to meet our goals ...

...then that project is out of control,  starting with a missing steering target that means it's Open Loop Control and will be late, over budget, and likely not perform to the needed effectiveness and performance parameters. And when you see these out of control situations, go find the Root Cause and generate the Corrective Act. 

This data is an observation of a project not being managed as Tim Lister suggests - Risk Management is How Adults Manage Projects. 

And if these observations are taking place without corrective actions of the Root Causes of the performance shortfall, the management is behaving badly. Their just observers of the train wreck that is going to happen real soon.

The Engineering Reason for the Cone of Uncertainty Model and the Value it Provides the Designing Makers

The Cone of Uncertainty is NOT an output from the project's behaviour, by then that's too late.
The Cone of Uncertanty is a Steering Target Input to the Management Framework for increasing the probability of the project's success.
This is the Programmatic Management of the project in support of the Technical Management of the project. The processes is an engineering discipline. Systems Engineering, Risk Engineering, Safety and Mission Assurance Engineering, are typical roles where we work.
To suggest otherwise is to invert the paradigm and removes any value from the post-facto observations of the project's performance. At that point it's Too Late, the Horse has left and there's no getting him back.
Defining the planned and needed variance levels at planned points in the project is the basis of the closed loop control system needed increase the probability of success.
When variances outside the planned variance appear, the Root Cause of those must be found and corrective action take.

Here's an example from a Galorath presentation, using the framework of the Cone of Uncertainty, and the actual project cones of how to put this all together. Repeating again, the Cone of Uncertainty is the framework for the 

planned reduction of the uncertainty in critical performance measures of the project.

If your project is not reducing the uncertainty as planned for these critical performance measures - cost, schedule, and technical performance - then it's headed for trouble and you may not even know it.

Screen Shot 2017-01-22 at 12.23.32 PM

Resources

[1] Systems Engineering Measurement Primer, INCOSE

[2] System Analysis, Design, and Development Concepts, Principles, and Practices, Charles Wasson, John Wiley & Sons

[3] SMC Systems Engineering Primer & Handbook: Concept, Processes, and Techniques, Space & Missle Systems Center, U.S. Air Force

[4] Defense Acquisition Guide, Chapter 4, Systems Engineering, 15 May 2013.

[5] Program Managers Tool Kit, 16th Edition, Defense Acquisition University.

[6] "Open Loop / Close Loop Project Controls"

[7] "Reducing Estimation Uncertainty with Continuous Assessment: Tracking the 'Cone of Uncertainty',"¬†Pongtip Aroonvatanaporn, Chatchai Sinthop, Barry Boehm.¬†ASE‚Äô10, September 20‚Äď24, 2010, Antwerp, Belgium.¬†

[8]¬†Boehm, B. ‚ÄúSoftware Engineering Economics‚ÄĚ. Prentice-Hall, 1981.

[9] Boehm, B., Abts, C., Brown, A. W., Chulani, S., Clark, B. K., Horowitz, E., Madachy, R., Reifer, D. J., and Steece, B. Software Cost Estimation with COCOMO II, Prentice-Hall,
2000.
[10] Boehm, B., Egyed, A., Port, D., Shah, A., Kwan, J., and Madachy, R. "Using the WinWin Spiral Model: A Case Study," IEEE Computer, Volume 31, Number 7, July 1998, pp.  33-44 

[11] Cohn, M. Agile Estimating and Planning, Prentice-Hall, 2005

[12] DeMarco, T. Controlling Software Projects: Management, Measurement, and Estimation, Yourdon Press, 1982.

[13] Fleming, Q. W. and Koppelman, J. M. Earned Value Project Management, 2nd edition, Project Management Institute, 2000

[14] Galorath, D. and Evans, M. Software Sizing, Estimation, and Risk Management, Auer-bach, 2006

[15]Jorgensen, M. and Boehm, B. ‚ÄúSoftware Development Effort Estimation: Formal Models or Expert Judgment?‚ÄĚ IEEE Software, March-April 2009, pp. 14-19

[16] Jorgensen, M. and Shepperd, M. ‚ÄúA Systematic Review of Software Development Cost Estimation Studies,‚ÄĚ IEEE Trans. Software Eng., vol. 33, no. 1, 2007, pp. 33-53

[17] Krebs, W., Kroll, P., and Richard, E. Un-assessments ‚Äďreflections by the team, for the team. Agile 2008 Conference

[18] McConnell, S. Software Project Survival Guide, Microsoft Press, 1998

[19] Nguyen, V., Deeds-Rubin, S., Tan, T., and Boehm, B. "A SLOC Counting Standard," COCOMO II Forum 2007

[20] Putnam L. and Fitzsimmons, A. ‚ÄúEstimating Software Costs, Parts 1,2 and 3,‚ÄĚ Datamation, September through December 1979

[21] Stutzke, R. D. Estimating Software-Intensive Systems, Pearson Education, Inc, 2005. 

Related articles

Complex, Complexity, Complicated Economics of Software Development Herding Cats: Economics of Software Development Estimating Probabilistic Outcomes? Of Course We Can! I Think You'll Find It's a Bit More Complicated Than That Risk Management is How Adults Manage Projects

 

Categories: Project Management

What Agile Managers Do: Podcast

I had a conversation with Amitai Schleier last year. I told him how much I enjoyed Agile in 3 Minutes (the podcast). I learned something from each podcast.

He invited me to contribute one. Naturally, I chose management. My podcast, 34: Manage is up. If you like the podcast, you should check out the book, too. See

If you like the podcast, you should check out the book, too. See Agile in Three Minutes. In three minutes, I explain what agile managers do.

Teams can be agile, up to a point. If the managers are not ready to nurture the agile culture, agile won’t work. (See¬†When is Agile Wrong for You?)

I hope you enjoy it the podcast and the book.

Categories: Project Management

The Sweet Software Architecture Spot

From the Editor of Methods & Tools - Wed, 02/01/2017 - 08:54
Software developers keep looking to CQRS as a software architecture to boost performance. But the more I work with companies the more I discover there’s a sweet spot where Theory of Constraints, Kanban, CQRS, Domain-Driven Design, EventStorming and UX blend together to solve ‘the really real problems’. Once you’re there, a land of opportunities ready […]

An Agenda for the Sprint Review

Mike Cohn's Blog - Tue, 01/31/2017 - 16:00

The most discernible activity during a sprint review is a demonstration of the functionality built during the sprint. But, a good sprint review includes more than just a demo. Let’s take a look at an agenda for the review.

Welcome Participants & Set the Stage for the Sprint Review

The product owner starts by welcoming everyone to the sprint review. This can be as simple as saying, “Thank you for being here.”

If participants are unfamiliar with one another, the product owner may have attendees briefly introduce themselves. Introductions are generally a good idea at the start of a new product development initiative. The product owner knows that Joe from Marketing is Joe from Marketing but team members may not.

Introductions are also helpful if it is common for an occasional new participant to attend sprint reviews. Perhaps Joe from Marketing will only attend two reviews following the sprints in which the team worked on marketing-related features.

Introductions should be kept extremely short. “Hi, I’m Mike and I’m a developer. I’ve been working on the shopping cart features,” is plenty. In some cases, “I’m Mike and I’m a developer,” would be enough. But once a team reaches a certain size, it can be helpful for stakeholders to hear a few words to let them know who has been doing what.

After an initial welcome by the product owner and any needed introductions, the product owner can share any ground rules or expectations for the sprint review. For example, some product owners find it necessary to state the need to keep the meeting civil. If someone doesn’t like how a feature was implemented it’s fine to say so, but don’t call the implementation “stupid” or so on. Yes, we all should know things like this anyway, but sometimes people need to be reminded.

Depending on the number of attendees and many other factors, a product owner might also state that while she is looking for feedback on what was built, the sprint review itself will not be the time to redesign features.

With the welcome message, introductions, and ground rules out of the way, it’s time to move onto the next item on the agenda.

State What Will (and Will Not) Be Demonstrated

At this point, many teams dive right in and start demonstrating. Instead, I recommend the product owner present a very brief overview of what will be demonstrated and what will not be.

To avoid a product owner just reading a list of items that participants won’t be able to follow, display something on the monitor or projector being used. Or have printed copies available for those who want one.

I like to prepare this as a Word document and email it to likely review participants at the end of the day before the review. This allows people a chance to see what will be demonstrated. Each person can then intelligently decide whether to attend or not based on what will be shown.

The following table shows the information I like to include for each product backlog item. I recommend putting this list in the order in which items will be demonstrated, although you can change that on the fly as needed during the meeting.

 

Description                                               SIZE    STATUS                                                 DEMO      As a user, I .... 5 Finished

Yes

As a user, I .... 3

Finished but there’s more we could add to the such-and-such part of this.

Yes As a user, I .... 5 We started but there were too many open issues No Bug fix: Update the copyright notice on the About screen 0 Finished No ADDED: As a … 3 We brought this item in when we dropped the item above. Yes

 

The table starts with a description of the item. Put the user story or other description here. Next include the size of the item, usually this will be in story points. Then list the status of the item. Mostly this is whether the item was finished or not, but include anything else that is important to note. Finally, include a column indicating whether the item will be demonstrated or not.

You may wonder why we’d ever have items that the team would not demonstrate. I’ve provided a couple of examples in the sample table. Obviously, the item that was planned into the sprint but dropped cannot be demonstrated. I’ve also shown a simple bug fix that updates one character on one screen--it is not scheduled for demonstration either.

It’s quite possible that one or more participants might ask to see an item that you had not planned to show. When that happens, go ahead and demonstrate the item along with all others. You’re not trying to avoid showing something, you’re just trying to be respectful of people’s time by not showing them things that don’t really need feedback.

Notice in the sample above, I indicated that one product backlog item was added during the sprint. I think it’s a good idea to indicate items added during the sprint so they can be distinguished from those that were planned into the sprint. If adding items happens frequently, consider adding an initial column and putting P (for Planned) or A (for Added) in it.  

You might also want to consider a column at the far right that can be used to indicate whether each item is accepted by the review participants or ready to release or such. Do this if those types of decisions are formally made as part of a sprint review.

Avoid spending too much time on this part of the agenda. The goal here is not to get feedback on the items or to talk about why a planned item was only partially implemented. This is merely a table of contents into the rest of the meeting. After the product owner has presented this list, move onto the main part of the sprint review: the demo itself.

Demo New Functionality

This is the heart of the sprint review. And if you’re already doing sprint reviews, it’s quite possible this is the only part of the agenda you’re doing.

During this portion of the review, proceed down the list of items you’ve previously shown meeting participants. Keep in mind that the purpose of the sprint review is to solicit feedback.

There is no hard rule about who gives the demo. In some cases, a product owner will operate the keyboard. I’d recommend doing that in a review with particularly challenging stakeholders. Other times, though, team members will demonstrate the specific product backlog items they worked on. Just about any approach works fine. So experiment to find the one that works best for your team.

Discuss Key Occurrences

After all completed product backlog items have been demonstrated, discuss key events or problems that occurred during the sprint.

This discussion could be facilitated by either the product owner or Scrum Master. I’ve found both approaches to work equally well. I do, however, have a slight bias toward having the Scrum Master conduct this part of the meeting.

Up until now, in most sprint reviews the product owner will have done a lot more talking than the Scrum Master. So I find it a good balance to have the Scrum Master facilitate this agenda item. Plus, this is often more a discussion of the process than strictly the product, and so it falls a bit more in the domain of the Scrum Master.

Present Upcoming Product Backlog Items

The final item on a sprint review agenda should be a discussion of the next work on the product backlog. Because the purpose of the sprint review is to acquire feedback on the work of the current sprint, this will often influence what will be worked on in subsequent sprints.

If, for example, participants in the review liked the look of the new screens, the product owner may want to accelerate moving other parts of the product to the new design. Or, if participants didn’t like how a feature was implemented, perhaps the next sprint should be spent fixing issues with it instead of moving onto the next items, as might have happened without a sprint review.

The product owner starts this discussion by presenting the next set of potential items from the product backlog. The product owner might say something like, “On the screen, you’ll see what I thought would be our next ten things to work on, but I want to insert such-and-such that came up today. I’ll add that probably as item three.”

The product owner then solicits comments from participants about the proposed next set of items. I do not, however, recommend that the product owner make any prioritization decisions during the sprint review based on these comments. The reasons for this are many. The product owner may need time to think about what was said in the review. Or the product owner may want to get estimates from the team about changes that were requested in the review. And so on. Instead, the product owner solicits opinions during the sprint review and then makes decisions after the meeting.

Conclude the Meeting

Simply wrap up by thanking everyone for participating. Consider thanking the team in whole for the work of the sprint. Consider occasionally praising a team member or two who performed exceptionally well during the sprint. Remind everyone when and where the next review will be held.

After the Sprint Review

Although not part of the agenda for the actual review, someone should enter any new product backlog items into whatever tool the team is using (or post them on the wall if using physical cards).

How Do You Conduct Reviews?

Please let me know how you do your sprint reviews. Do you include anything I didn’t mention? Do you skip some of these steps? Please share your thoughts in the comments below.

 

 

Get Your Free Sprint Review Agenda Poster

First Name

Email Address

ScrumMaster Interview Questions cover

Software Development Conferences Forecast January 2017

From the Editor of Methods & Tools - Mon, 01/30/2017 - 15:14
Here is a list of software development related conferences and events on Agile project management ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP), DevOps and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods […]

Quote of the Day

Herding Cats - Glen Alleman - Sun, 01/29/2017 - 18:43

Jerry, just remember, it's not a lie if you believe it - George Costanza

 

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Sat, 01/28/2017 - 18:12

The measure of who we are is how we react to something that doesn't go our way -  Gregg Popovich, Head coach of the San Antonio Spurs

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Fri, 01/27/2017 - 17:40

Never let the tool control the hand that uses it -  Lt Gen Hans H. Driessnack (ret), in Advanced Project Management, Best Practices on Implementation, page 40, Harold Kerzner, 2004

Categories: Project Management

Thinking About PMO Productivity

In Manage Your Project Portfolio, I’m agnostic about who manages the project portfolio. I prefer that the managers responsible for the strategy make the project portfolio decisions. And, I recognize that the PMO often makes those decisions.

I am doing a series of webinars with TransparentChoice. The first one is live. See¬†How many ‚Äúpoints‚ÄĚ does your PMO score?¬†We spoke about how you might know if you need a project portfolio and the major measure of successful decisions:

It doesn’t matter how many projects you start. It matters how many you finish.

Hope you enjoy it!

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Thu, 01/26/2017 - 04:49

Screen Shot 2017-01-25 at 8.43.09 PM

In a time of universal deceit - telling the truth is a revolutionary act.
War is peace. Freedom is slavery. Ignorance is strength.

Political language... is designed to make lies sound truthful and murder respectable, and to give an appearance of solidity to pure wind. 
If liberty means anything at all, it means the right to tell people what they do not want to hear.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Wed, 01/25/2017 - 03:06

On a long enough timeline the survival rate of everyone drops to zero

Categories: Project Management

Software Development Linkopedia January 2017

From the Editor of Methods & Tools - Tue, 01/24/2017 - 07:54
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about Test-Driven Development (TDD), big meetings, product ownership, UX stories, cognitive bias, ScrumMaster job description, test management in JIRA, #NoProjects, team performance and software testing culture. Blog: TDD and the “6 […]