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

See You Next Year!

NOOP.NL - Jurgen Appelo - Fri, 12/19/2014 - 13:13
trip

My book tour was crazy, exciting, ambitious, and exhausting.

The start of the tour now seems a long time ago, even though it was just six months. I had fun with 400 participants, had some great (and some not so great) travel experiences, and collected a good amount of fresh stories.

The post See You Next Year! appeared first on NOOP.NL.

Categories: Project Management

Closed Loop Control

Herding Cats - Glen Alleman - Fri, 12/19/2014 - 04:14

Writing software for money is a Closed Loop Control System.

Screen Shot 2014-12-18 at 6.16.44 PM

  • The Reference is our needed performance - cost, schedule, and techncial - to acheive the projects goals. These goals include providing the needed business value, at the needed cost, on the needed day. Since each of these is a random variable, we can't state  Exactly what they are, but we can make a statement about their range and the confidence that the will fall inside that range in order to meet the business goals
  • The System is the development process that takes money, time, and requirements and turns them into code.
  • The Sensor is the measurement system for the project. This starts with assessing the delivered code to assure it meets some intended capability, requirement, or business value. The target units of measure are defined before the work starts for any particular piece of code, so when that code is delivered we can know that it accomplished what we wanted it to do.
  • The Error Signal  comes from comparing the difference between the desired state - cost, schedule, technical, value, or any other measure - and the actual state. This error signal is then used to  adjust or take corrective action to put the system back in balance so it can achieve the desired outcome.

Without the Desired State, the Current State, the comparison of the two, the Error Signal, the project is running open loop. We'll arrive when we arrive at the rate of progress we are performing at, for the cost we are consuming. There is no information available to show what the needed performance of cost, schedule, or value production needs to be to arrive, on time, on budget, and on value (or near enough to call it close).

And when you hear about control systems and they don't follow the picture at the top, they're not Closed Loop. They may be Open Loop, but they are not Close Loop.

Control systems from Glen Alleman

 

Related articles Conveniently Unburdened by Evidence Risk Management is Project Management for Adults Three Increasingly Mature Views of Estimate Making in IT Projects Complex Project Management The Myth and Half-Truths of "Myths and Half-Truths"
Categories: Project Management

Manage Your Project Portfolio is Featured in Colombia’s Largest Business Newspaper

Andy Hunt, the Pragmatic Bookshelf publisher, just sent me an email telling me that Manage Your Project Portfolio is featured in La RepĂşblica, Columbia’s “first and most important business newspaper.” That’s because getabstract liked it!  

la_repĂşblica_20141204Okay, my book is below the fold. It’s in smaller print.

And, I have to say, I’m still pretty excited.

If your organization can’t decide which projects come first, second, third, whatever, or which features come first, second, third, whatever, you should get Manage Your Project Portfolio.

Categories: Project Management

The Myth and Half-Truths of "Myths and Half-Truths"

Herding Cats - Glen Alleman - Thu, 12/18/2014 - 05:51

I love it when there is a post about Myths and Half-Truths, that is itself full of Myths and Half Truths. Orginal text in Italics, the Myth Busted and Half Truth turned into actual Truth beow each

Myth: If your estimates are a range of dates, you are doing a good job managing expectations.

  • Only the earlier, lower, more magical numbers will be remembered. And those will be accepted as firm commitments.

If this is the case, the communication process is broken. It's not the fault of the estimate or the estimator that Dilbert style management is in place. If this condition persists, better look for work somewhere else, because there are much bigger systemic problems there.

  • The lower bound is usually set at "the earliest date the project can possibly be completed". In other words, there is absolutely no way the work can be completed any earlier, even by a day. What are the chances of hitting that exact date? Practice shows - close to nil. 

The lower bound, most likely, and upper bounds must have a confidence level. The early date with a 10% confidence says to the reader, there is no hope of making that. But the early alone gets stuck in the mind as a cofirmation bias.

Never ever communicate a date, a cost, a capability in the absence of the confidence level for that number.

Making the estimate and management expectations have no connection to each other. Poor estimates make it difficult to manage expectations, because receiving the estimates loose confidecen in the estimator when the estimates have no connection with the actual outcomes of the project.

Half-truth: You can control the quality of your estimate by putting more work into producing this estimate.

It's not the work that is needed, it's the proper work. Never confuse effort with results. Reference Class Forecasting, Parametric models, and similar estimating tools along with the knowledge of the unlying uncertaities of the processes, technology, and people connected with delivering the outcomes of their efforts.

  • By spending some time learning about the project, researching resources available, considering major and minor risks, one can produce a somewhat better estimate.
  • The above activities are only going to take the quality of the estimate so far.  Past a certain point, no matter how much effort goes into estimating a project, the quality of the estimate is not going to improve. Then the best bet is to simply start working on the project.

Of course this ignores the very notion of Subject Matter Expertise. Why are you asking someone who only knows one thing - a one trick pony to work on yu new project. This is naive hiring and management.

This would be like hiring a commercial builder with little or no understanding of modern energy efficient building, solar power and heating, thermal windows, and high efficiency HVAC systems and asked him to build a LEADS Compliant office building.

Why would you do that? Why would you hire software developers that had little understanding of where technology is going? Don’t they read, attend conferences, and look at the literature to see what’s coming up? 

Myth: People can learn to estimate better, as they gain experience.

People can learn to estimates as they gain skill, knowledge, and experience. All three ae needed. Experience alone is necessary but far from sufficient. Experience doing it wrong doesn't lead to improvement, only confirm that bad estimates are the outcome. There are a nearly endless supply of books, papers, and articles on how to properly estimate. Read, take a course, talk to experts, listen, and you'll be able to determine where you are going wrong. Then your experience  is will of value, beyond confirming you know how to do it wrong.

  • It is possible to get better at estimating – if one keeps estimating the same task, which becomes known and familiar with experience. This is hardly ever the case in software development. Every project is different, most teams are brand new, and technology is moving along fast enough.

That's not the way to improve anyting in the software development world. If you wrote code for a single function over and over again, you'd be a one-trick-pony. 

The notion of projects are always new, is better said projects are new to me. Fix that by finding someone who knows what the new problem is about and hire them to help you. Like the builder above dobn't embark on a project where you don't have some knowledge of what to do, how to do it, what prolems will be encountered and what their solutions are. That's a great way to waste your customers money and join a Dath March project.

    • Do not expect to produce a better estimate for your next project than you did for your last one.

Did you not keep a record of what you did last time. Were you paying attention to what happened? No wonder your outcomes are the same.

    • By the same token, do not expect a worse estimate. The quality of the estimate is going to be low, and it is going to be random.

As Inigo Montoya says: You keep using that word. I do not think it means what you think it means.All estimates are random variables. These random variables come from an underlying statistcial process - a Reference Class - of uncertainty about or work. Some are reducible some are irreducible. Making decisons in the presence of this uncertainty is called risk management. And as Tim Lister says Risk Management is how Adults Manage Projects.

Half-truth: it is possible to control the schedule by giving up quality.

The trade offs between cost, schedule, and performance - quality is a performance measure in our Software Intensive Systems domain, along with many other ...ilities. So certainly the schedule can be controlled by trading off quality. 

  • Only for short-term, throw-away temporary projects.

This is not a Myth, it's all too common. I'm currently the Director of Program Governance, where this decision was made lomg ago and we're still paying the price for that decision.

  • For most projects, aiming for lower quality has a negative effect on the schedule.

 

Related articles How Think Like a Rocket Scientist - Irreducible Complexity Complex Project Management Risk Management is Project Management for Adults
Categories: Project Management

5 Reasons Product Owners Should Let Teams Work Out of Order

Mike Cohn's Blog - Tue, 12/16/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

A product owner hands 10 story cards to the team. The team reads them and hands the fifth and sixth cards back to the product owner. By the end of the sprint, the team delivers the functionality described on cards 1, 2, 3, 4, and 7. But the team has not touched the work of cards 5 and 6.

And I say this is OK.

Standard agile advice is that a team should work on product backlog items in the order prescribed by the product owner. And although this is somewhat reasonable advice, I want to argue that good agile teams violate that guideline all the time.

There are many good reasons for a team to work out of order. Let’s consider just a few, and consider it sufficient evidence that teams should be allowed to work out of order.

1. Synergies

There are often synergies between items near the top of a product backlog—while a team is working on item No. 3, they should be allowed to work on No. 6. If two items are in the same part of the system and can be done faster together than separately, this is usually a good tradeoff for a product owner to allow.

2. Dependencies

A team may agree that No. 4 is more important than No. 5 and No. 6 on the product backlog. Unfortunately, No. 4 can’t be done until No. 7 has been implemented. Finding a dependency like this is usually enough to justify a team working a bit out of the product owner’s prioritized sequence.

3. Skillset Availability

A team might love to work on the product owner’s fourth top priority, but the right person for the job is unavailable. Sure, this can be a sign that additional cross-training is needed on that team to address this problem – but, that is often more of a long-term solution. And, in the short term, the right thing to do might simply be to work a bit out of order on something that doesn’t require the in-demand skillset.

4. It’s More Exciting

OK, this one may stir up some controversy. I’m not saying the team can do 1, 2, 3, 4, and then number 600. But, in my example of 1, 2, 3, 4 and 7, choosing to work on something because it’s more exciting to the team is OK.

On some projects, teams occasionally hit a streak of product backlog items that are, shall we say, less than exciting. Letting the team slide slightly ahead sometimes just to have some variety in what they’re doing can be good for the morale of the team. And that will be good for product owners.

Bonus Reason 4a: It’s More Exciting to Stakeholders

While on the subject of things being more exciting, I’m going to say it is also acceptable for a team to work out of order if the item will be more exciting to stakeholders.

It can sometimes be a challenge to get the right people to attend sprint reviews. It gets especially tough after a team runs a few boring ones in a row. Sometimes this happens because of the nature of the high-priority work—it’s stuff that isn’t really visible or is esoteric perhaps to stakeholders.

In those cases, it can be wise to add a bit of sex appeal to the next sprint review by making sure the team works on something stakeholders will find interesting and worth attending the meeting for.

5. Size

In case the first four (plus) items haven’t convinced you, I’ve saved for last the item that proves every team occasionally works out of product owner order: A team may skip item 5 on the product backlog because it’s too big. So they grab the next one that fits.

If a team were not to do this, they would grab items 1, 2, 3, and 4 and stop, perhaps leaving a significant portion of the sprint unfilled. Of course, the team could look for a way to perhaps do a portion of item 5 before jumping down to grab number 7. But sometimes that won’t be practical, which means the team will at least occasionally work out of order.

Product Owners Aren’t Perfect

A perfect product owner would know everything above. The perfect product owner would know that the team’s DBA will be full from tasks from the first four product backlog items, and so wouldn’t put a database-intensive task fifth. The perfect product owner would know that items 2 and 5 both affect the same Java class, and would naturally prioritize them together.

But most product owners have a hard time being perfect. A better solution is for them to put the product backlog in a pretty good prioritized order, and then leave room for fine tuning from the team.

Team Competition is Not Friendly

I once worked in an organization where the senior managers thought they should motivate us, the team members. They decided to have a team competition, complete with prizes.

I was working on a difficult software problem with a colleague on another team. We both needed to jointly design our pieces of the product to make the entire product work.

After management announced the competition, he didn’t want to work with me. Why? There was prize money, worth hundreds of dollars to each person. He had a mortgage and three kids. That money made a big difference to him. I was still single. I would have stuck that money into either my savings or retirement fund, after buying something nice for myself.

Management motivated us, alright. But not to collaborate. They motivated us to stop working together. They motivated us to compete.

Our progress stopped.

My boss wanted to know what happened. I explained. I couldn’t fault my colleague. He wanted the money. It made a big difference for him. I would have appreciated the money, but not nearly as much as he would have. (Later, when I was paying for childcare, I understood how much of a difference that money made.)

I then had this conversation with my boss, ranting and raving the entire time:

“Look, do you want the best product or the best competition?”

“What?”

“You can’t have both. You can have a great product or you can have a great competition. Choose. Because once you put money on the table, where only one team gets the money, we won’t collaborate anymore.”

My boss got that “aha” look on his face. “Hold that thought,” he said.

The next day, management changed the competition. Now, it was about the teams who worked together to create the best product, not the one team who had the best idea. Still not so good, because all the teams on the program needed to collaborate. But better.

When I had my one-on-one with my boss, I explained that all the teams needed to collaborate. Were they really going to pay everyone a bonus?

My boss paled. They had not thought this through. “I’d better make sure we have the funds, right?”

People don’t work just for money. You need to pay people a reasonable salary. Remember what Dan Pink says in Drive: The Surprising Truth About What Motivates Us. People work for autonomy, mastery, and purpose. If you exchange the social contract of working for autonomy, mastery, and purpose for money, you’d better pay enough money. You also better repeat that money the next time. And, the next time. And, the next time.

That’s the topic of this month’s management myth: Management Myth 35: Friendly Competition Is Constructive.

Software product development is a team activity, full of learning. As soon as you make it a competition, you lose on the teamwork. You lose the learning. Nobody wins. There is no such thing as “friendly” competition.

Instead, if you go for collaboration, you can win.

Read Management Myth 35: Friendly Competition Is Constructive.

Categories: Project Management

Here’s My Management 3.0 Story. What’s Yours?

NOOP.NL - Jurgen Appelo - Thu, 12/11/2014 - 21:28
Delegation Levels

After 4 years of working by myself, I am now the proud manager of a team of seven great people. Two months ago, I had already extended my one-person company Happy Melly One by adding Lisette Sutherland (general management) and Sergey Kotlov (software development). In the last couple of weeks, I asked Lisette and Sergey to conduct job interviews with people around the world for the roles of Internet marketing, content writing, web development, and video editing.

The post Here’s My Management 3.0 Story. What’s Yours? appeared first on NOOP.NL.

Categories: Project Management

Conveniently Unburdened by Evidence

Herding Cats - Glen Alleman - Wed, 12/10/2014 - 17:32

Conveniently Unburdened by Evidence - Kate Beckett to Richard Castle

When we hear a conjecture about a topic that skips over principles of business, the economics of decision making, or the mathematics of probabilistic and statistical modeling, listen to what Kate said to Richard. 

Putting This Skepticism To Work

There are three concerns for every project manager and those funding the work of the project †

  1. Schedule - Will the project go over schedule? All projects are probabilistic endeavors. Uncertainty abounds. Both reducible uncertainty and irreducible uncertainty. Work can address the reducible uncertainty. Buying down the risk associated with this reducible uncertainty. Irreducible uncertainty can only be addressed with margin. Schedule margin, cost margin, technical margin. 

  2. Cost - Will the project overrun its budget? Cost margin is needed to protect the project from an over budget condition. This is called Management Reserve. But MR can only do some much the estimate of the cost, the management of the work to that estimate is also needed. With a credible estimate, MR and Contingency are still needed to avoid going over budget.

  3. Performance - Will the deliverables  satisfy the goal(s) of the project? The technical performance of the deliverables is founded on the Measures of Effectiveness and Measures of Performance of the capabilities provided by the projects. Capabilities Based Planning is the foundation of defining what DONE looks like in units of measure meaningful to the decision makers.

At the start and up until the end of a project, the answer to each of these questions is knowable to some degree of confidence - less in the beginning and more as the project progresses. A yes answer to any or all of the questions is taken to be an undesirable outcome. These are business questions as well as technical questions. But it is the business that is most interested in the answers and the confidence level of the answer - a simple Yes or No is not sufficient. Yes, we have an 80% confidence of completing on or before the need date. 

In The End

To provide answers to these questions before arriving at the end of the project, we need estimates. So when we answer Yes to the question - which is unavoidable - we don't to proceed in the absence of corrective actions to increase the probability of a desirable outcome. At the beginning of the project that confidence is low, since project evolve. To provide credible answers about the confidence of arriving on time, on budget, with the needed capabilities, we must estimate not only the cost, schedule, and outcomes, but estimate the impact of our corrective actions.

If we fail to do this, if by lack of knowledge or experience or with intentional ignorance of the probabilistic process of all projects, we've set the foundation of failure. The approach of making decisions in the absence of estimating the cost or that decision and the resulting impact of that decision, ignore  - with intent - the principles of Microeconomics of decision making. Ignoring the opportunity cost of the decision. This opportunity cost must be estimated, since it will occur in the future and is usually beyond our ability to measure directly.

Ignoring opportunity cost and ignoring estimating the future is called Open Loop Control. To increase the probability of project success we need to apply the principles of Closed Loop Control. And when we manage projects with Open Loop processes, those providing us the money to produce value will be disappointed.

Control systems from Glen Alleman

† Quantitative Risk Analysis for Project Management A Critical Review, Lionel Galway, WR-112-RC, February 2004

Related articles Software Estimating for Non Trival Projects Mike Cohn's Agile Quotes Show Me Your Math Estimating Guidance Complex Project Management
Categories: Project Management

Software Development Linkopedia December 2014

From the Editor of Methods & Tools - Wed, 12/10/2014 - 15:37
Here is our monthly selection of interesting knowledge material on programming, software testing and project management.  This month you will find some interesting information and opinions about slow programming, technical career paths, Agile QA, Scrum backlog refinement meetings, being a better test manager, java BDD, mixing Waterfall and Agile, the TDD cycle and dealing with bad Java code. Blog: The Case for Slow Programming Blog: Coding, Fast and Slow: Developers and the Psychology of Overconfidence Blog: Climbing off the CTO ladder Blog: What Does QA Do on the First Day of a Sprint? Blog: Stop ...

How Think Like a Rocket Scientist - Irreducible Complexity

Herding Cats - Glen Alleman - Wed, 12/10/2014 - 15:00

Orion launched today and recovery after two orbits. The test of the launch system, Pad Abort system, and Heat Shield were the main purposes of the flight.

I worked the proposal - after coming off the winning proposal for Hubble Robotic Service Mission. The Crew Exploration Vehicle was the original name of the flight vehicle. The Integrated Master Plan and Integrated Master Schedule described the increasing maturity of the deliverables for the space craft and it's flight support systems. After the contract win, I moved to the flight avionics firm and defined the IMP/IMS and project performance management processes for that major subcontractor. When you get to minute 21:17, Tracking Data Relay Satellite is mentioned. I worked that project as a new graduate student many decades ago.

Starting back on TDRSS, agile - meaning emerging requirements, test driven development, direct customer feedback on short iterations - and the development process were deployed with rolling waves, 44 day rule Work Packages, and emergent technical requirements derived from Mission Capabilities. 

Here's the long version of the launch to orbit. 

 

After two orbits, Orion came home. The double boom is the sonic boom. Tests of the heat shield will confirm if it functioned properly.

 

Recently a statement was made about agile and complexity and it was conjectured if the project is too complex for a physical board - a place to put the stickies for the stories - then we've missed opportunities to simplify. Possibly not realizing that complexity, as well as complex system, are the norm in many domains and complexity management processes using tools - rather than manual means - is also the norm. 

If your Agile planning needs are too complex for a physical board, you've probably missed opportunities to simplify / improve.

When I suggested that agile and agile tools are used to deal with complex problem in these environments, without the need to reduce that complexity, there was a conversation of sorts that suggested...

I'd be surprised to hear Orion was using a COTS Agile project management tool in a significant way

Some Necessary Complexity

On Hubble mission, there is a Service Mission Assurance Process that reveals some of the complexity of the System of Systems found in space flight. The Interface Control processes for example for the payload on STS 125.

HST ICD

External knowledge of what tools were used, what processes were applied, how the flight avionics software for Orion was converted from the 777 suite to the spacecraft suite, tested, altered to user needs, simulated, emulated, verified and validated on rolling waves, on 44 day iteration cycles could have only been obtained if you were actually in the building in the vendors shop.

But there are other surprises in the business of space flight. A few good places to start include:

Beyond the outsiders comments of surprise inside space and defense firms, agile tools from Rally, VersionOne, and JIRA are used in a wide variety of domains from embedded systems to intelligence systems, where the requirements don't come from the users, they come from the enemy. Here's an example of agile in the INTEL business.

Maybe those  surprised by the many different applications of the principles of agile - developed long before the Agile Manifesto - missed those processes in Building O6, Sepulveda Blvd, Redondo Beach, circa 1978.

Screen Shot 2014-12-05 at 8.12.48 PM

In The End

There are numerous approaches to applying agile development in a wide variety of domains. I work in a domain where Systems Engineering and Earned Value Management is the starting point and Agile is used to develop code guided by EAI-748-C and DID 81861.

In these environments, development of software is incremental and iterative, with emerging requirements, with stable capabilities. These programs are complex and tools are the basis of success for managing all the moving parts of the program. Rarely is everyone in the same room, since these are System of Systems programs. As well Integration and Test are done by external sources - V&V for flight safety. So many of the processes found in small commercial projects are not applicable to programs in our domain.

To suggest there is but one way to reduce complexity by putting all the stories on cards on the wall is a bit naive in the absence of establishing the external needs of the project first, then deciding what processes to apply.

Some background on applying agile in the DOD can be found at:

Domain first, Context second, Only then Process

Related articles Systems Engineering in the Enterprise IT Domain Estimating Guidance Software Estimating for Non Trival Projects Improving DOE Project Performance Using the DOD Integrated Master Plan
Categories: Project Management

When Should You Move from Iterations to Flow?

I’m writing part of the program management book, talking about how you need to keep everything small to maintain momentum. Sometimes, to keep your work small, teams move from iterations to flow.

Here are times when you might consider moving from iteration to flow:

  • The Product Owner wants to change the order of features in the iteration for business reasons, and you are already working in one- or two-week iterations. Yes, you have that much change.
  • You feel as if you have a death march agile project. You lurch from one iteration to the next, always cramming too much into an iteration. You could use more teams working on your backlog.
  • You are working on too many projects in one iteration. No one is managing the project portfolio.

This came home to me when I was coaching a program manager working on a geographically distributed program in 2009. One of the feature teams was responsible for the database that “fed” all the other feature teams. They had their own features, but the access and what the database could do was centralized in one database team. That team tried to work in iterations. They had small, one- or two-day stories. They did a great job meeting their iteration commitments. And, they always felt as if they were behind.

Why? Because they had requests backed up. The rank of the requests into that team changed faster than the iteration duration.

When they changed to flow, they were able to respond to requests for the different reports, access, whatever the database needed to do much faster. They were no longer a bottleneck on the program. Of course, they used continuous integration for each feature. Every day, or every other day, they updated the access into the database, or what the database was capable of doing.

The entire program regained momentum.

kanban.iterationThis is a simplified board. I’m sure your board will look different.

When you work in flow, you have a board with a fixed set of Ready items (the team’s backlog), and the team always works on the top-ranked item first. Depending on the work in progress limits, the team might take more than one item off the Ready column at a time.

The Product Owner has the capability to change any of the items in the Ready column at any time. If the item is large, the team will spend more time working on that item. It is in the Product Owner’s and the team’s interest to learn how to make small stories. That way, work moves across the board fast.

If you use a board something like this, combined with an agile roadmap, the team still has the big picture of what the product looks like. Many of us like to know what the big picture is. And, we see from the board, what we are working on in the small. However, we don’t need to do iteration planning. We take the next item off the top of the Ready list.

There is no One Right Answer as to whether you should move from iteration to flow. It depends on your circumstances. Your Product Owner needs to write stories that are small enough that the team can complete them and move on to another story. Agile is about the ability to change, right? If the team is stuck on a too-large story, it’s just as bad as being stuck in an iteration, waiting for the iteration to end.

However, if you discover, especially if you are a feature team working in a program, that you need to change what you do, or the order of what you do more often than your iterations allow, consider moving to flow. You may decide that iterations are too confining for what you need.

Categories: Project Management

Quote of the Month December 2014

From the Editor of Methods & Tools - Tue, 12/09/2014 - 18:23
Stories shouldn’t be small because they need to fit into an iteration, but because the world shouldn’t end just because a story turns out to be wrong. Stories are based on assumptions about business value, and those assumptions might turn out to be right or wrong.The key questions for story sizing shouldn’t be about the iteration length, but about how much business stakeholders want to invest in learning whether a proposed change will actually give them what they assumed. Source: Fifty Quick Ideas to Improve your User Stories, Gojko Adzic and ...

Risk Management is Project Management for Adults

Herding Cats - Glen Alleman - Tue, 12/09/2014 - 16:49

In a recent presentation, Tim speaks further about managing in the presence of uncertainty and the application of agile in software development. Plans NEVER go right, planning in presence of uncertainty, requires - DEMANDS actually - estimating risk, uncertainties, unknowns - on the project. When we hear about making decisions in the absence of estimating the probability of the drivers, impacts, and outcomes. As he says This is a crock just as the making decisions in the absence of estimating is a crock. Ignoring the probabilistic behaviour of impacts from the future - microeconomics - is as Tim suggests childish behaviour.

Screen Shot 2014-12-08 at 8.35.51 PM

Managing in the Presence of Uncertainty

Here's an extract from a much larger briefing on managing complex, software intensive systems, in our domain - Enterprise IT. The critical issue here is uncertainty is always present. Failure to recognize this, failure to deal with it, failure to make decisions based on the underlying statistical and probabilistic aspects of this uncertainty is as Tim suggest childish.

If we're looking where we need estimates, look here potential - potential being something that might occur in the future. Potential cost, potential schedule, potential event. 

Screen Shot 2014-12-09 at 8.36.26 AM

 

Effective risk management - and therefore effective project management and effective value delivery - requires navigating through this causal chain, assessing the current potential for loss, and implementing strategies for minimizing the potential for loss. The next section builds on the concepts in this section by examining two fundamental approaches for analyzing risk.

Managing in the presence of uncertainty from Glen Alleman

So when we hear...

Decisions can be made in the absence of estimates. Ask how, ask to be shown the tangible evidence, ask for the mechanics this can be possible.

Related articles Show Me Your Math Estimating Guidance Software Estimating for Non Trival Projects
Categories: Project Management

Who Picks the Sprint Length on a Scrum Team?

Mike Cohn's Blog - Tue, 12/09/2014 - 15:00

An important consideration for every Scrum team is how long its sprints should be. Choose a length that’s too long, and it will be hard to keep change out of the sprint. Choose a length that’s too short, and a team may struggle with completing significant work within the sprint or weaken their definition of done to do so.

But who is it that gets to select a team’s sprint length?

Of course, the answer is the whole team – that collective of ScrumMaster plus product owner plus team members such as programmers, testers, designers, DBAs, analysts and so on.

But what if that broad set of individuals cannot agree? Do they argue endlessly, perhaps sticking with their waterfall or ad hoc process until consensus finally emerges?

No. The ScrumMaster is ultimately the one who gets to choose a team’s sprint length.

A good ScrumMaster will do everything possible to arrive at a consensus. But, when the ScrumMaster exhausts his or her collaborative, facilitative skills without arriving at a consensus, the good ScrumMaster makes the decision.

This should not happen often. I hope most ScrumMasters never need to say, “I’ve listened to everyone, but here’s what we’re doing.” But since the ScrumMaster can be considered a team’s process owner, the ultimate decision does belong to the ScrumMaster.

Let’s consider one example from my past.

In this case, I was consulting to a team doing four-week sprints. They were struggling to pull the right amount of work into their sprints. For the six months before I’d met them, team members were consistently dropping about a third of the work each sprint.

They were a good team doing high-quality work. They simply didn’t know how much of it they could do in four weeks. Their optimism was getting the better of them, and they were consistently overcommitting.

I asked the team to think about how they’d like to solve the problem and tell me their suggestions the next day. I was thrilled the next day when they announced that they should clearly change the length of their sprints. “Yes,” I told them, “Definitely.”

They were relieved that I agreed with them and said so: “Wow! We didn’t think you’d let us go to six-week sprints!”

I had to inform them that while I agreed with changing sprint length, the better solution would be to go to shorter rather than longer sprints.

We ended with me—as a consulting ScrumMaster—setting a two-week length.

Why did I do this?

The team was already pulling too much work into a four-week sprint. They were, in fact, probably pulling six weeks of work into each four-week sprint. But, if they had gone to a six-week sprint, they probably would have pulled eight or nine weeks of work into those!

This team needed more chances to learn how much work fit into a sprint (of any length). As their ScrumMaster—especially coming to the team as a consultant—I could see that more easily than they could.

I want to end by repeating my caution that this is not something that should happen very often. I can count on one hand the number of times when I’ve flat-out chosen a length for the team after failing to gain consensus.

I’ll stand by the value of having done so in each case. But I only did so after significant effort to gain consensus. Overriding team members on something as important as sprint length should be done with great caution. But, it’s a process issue and, therefore, in the domain of the ScrumMaster.

What about you? Were there times when your team couldn’t agree on a sprint length? How did you resolve it?

Three Increasingly Mature Views of Estimate Making in IT Projects - Update

Herding Cats - Glen Alleman - Mon, 12/08/2014 - 19:02

There remains serious misunderstandings of how, why, when, and for what purpose estimates of cost, schedule and delivered capabilities are made in the development of software systems using other peoples money.

There are three distinct approaches to the problem:

The first paper shows the self-selected projects and how they have completed - for the most part - lonfer the ideal initial estimates. These estimates are not calibrated, meaning they are not assessed for credibility, error bands, or confidence. The paper mentions the the solid line, initial versus actual is the ideal line where actuals meet estimated value. In any stochastic estimating process, it will be unlikely ant estimate will result in a match with the actual for the very simple reason that the work processes are random and when the estimates don't contain the probabilistic confidence intervals, the actual MUST be different that the estimate.

As well, no root cause for the unfavorable performance of the actuals compared to the initial estimates is provided. This is a core failure to understand the process of estimating, rot cause analysis, and the discovery of the corrective actions needed to improve both the estimating processes as well as project performance management.

This fundamental failure is not limited to the self-selected set of projects in the paper. This failure mode can be found a wide variety of project domains in and out of the software business.

The second paper speaks the the major flaws Standish Report - meaningless figures. self-selected samples, perverted accuracy, unrealistic rates and misleading definitions. The paper states the root causes and suggested corrective actions.

The third paper shows how to quantify IT forecasts (estimates of future outcomes) in a mathematically sound manner.

All five papers are useful in the right context. Little re-introduces Boehm's cone of uncertainty, assessment of Standish shows the traps that can be easily fallen into when good statistical practices are not followed, the third provides the mathematical foundation for restoring those sound practices, and the RAND report shows the mechanics of the corrective actions to restore credibility in software estimating.

A risk based view of the estimating problem developed for the recent successful launch and recovery of Orion, then called Crew Exploration Vehicle.

Probabilistic Schedule and Cost Analysis from Glen Alleman Related articles Software Estimating for Non Trival Projects
Categories: Project Management

Building Software Before Requirement Are Stable??

Herding Cats - Glen Alleman - Fri, 12/05/2014 - 14:47

There is a popular notion that requirements stability is difficult to acheive, because customers don't know what they want. Ignoring for the moment that requirements instability is the root cause of Death March project and let's pretend requirements stability is in fact hard to come by.

If you a project without requirements stability, the architecture of the underlying systems become paramount, since the components of the system are guaranteed to change.

What is software architecture?

Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.

This means that the underlying architecture must

  • Be based on a reference design, so the structure has alreay been shown to work
  • The transaction model must be separated from the data model and the display model
  • There must be strict, some would say ruthless, separation of concerns, for example

Screen Shot 2014-12-04 at 10.11.02 PM

  • Data warehouse paradigm, where the data for the transactions and the resulting display and interaction is completely isolated
  • A federated architecture, where systems are integrated through a data bus or some other form os isolation
  • The referential integrity of the data must be ruthlessly maintained and enforced

With these the result of low requirements fidelity is the ball of mud or shanty town architecture. The Ball or Mud paradigm is 

A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.

This means there is 

  • Throw away code - we'll fix this now and worry about the outcomes later
  • Piecemeal code that is installed to fix the current problems, only to create future problems.
  • Keep it working - we're on a deadline, we need to get this fixed and move on.

And of course the biggest lie of all for any non-trivial system

Our architecture emerges as the requirements become known

This approach is the basis of Shanty Town or Ball of Mud architecture of the modern hacked together systems we've all come in contact with.

Related articles Software Estimating for Non Trival Projects
Categories: Project Management

Is Programming the Same as Software Engineering?

Herding Cats - Glen Alleman - Thu, 12/04/2014 - 16:50

Jenkins-cover-6-26-2014When we hear I'm a developer is that the same as I'm a Software Engineer. What does it mean to be a software engineering versus a developer of sofwtare? Peter Denning's review of he book A Whole New Engineer in the December edition of Communications of the ACM speaks to this question.

There are several important ideas here. One example in the review was from a 1980s in a study at the research institute at NASA-Ames Research Center where computer scientists were brought together with NASA scientists on big problems in space and aeronautics. Our scientists pioneered in applying supercomputers instead of wind tunnels to the design of full aircraft, conducting science operations from great distances over a network, and studying neural networks that could automate tasks that depend on human memory and experience. But there was a breakdown: our NASA customers frequently complained that our engineers and scientists failed to make their deliverables. 

This was a major issue, since the research funding for the institute came mainly from our individual contracts with NASA managers. Failure to make deliverables was a recipe for non-renewal and loss of jobs. NASA managers said, “your work is of no value to us without the deliverables we agreed to,” and our scientists responded, “sorry, we can’t schedule breakthroughs.” This disconnect seemed to be rooted in the gap between what engineering and science schools teach and the realities of customer expectations in the workplace.

This extract from the review brings up a smaller issue. The notion that we can't possibly estimate when we'll be done or what it wil cost. And the popular notion that...

Estimates are difficult. When requirements are vague — and it seems that they always are — then the best conceivable estimates would also be very vague. Accurate estimation becomes essentially impossible. Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before.

The rest of the book review speaks to the new engineer gap and how it is being closed, with these principles (I've included the one most interesting to me personally)

  • Become competent at engineering practices and technologies.
  • Learn to be a designer—someone who can propose combinations of existing components and technologies to take care of real concerns.
Related articles Assessing Value Produced By Investments Software Estimating for Non Trival Projects
Categories: Project Management

Integrated Master Plan and Department of Energy Program Management

Herding Cats - Glen Alleman - Wed, 12/03/2014 - 16:05

Working in Phoenix this week on a Program Management Office deployment for a government agency providing public health services. We're installing processes and training staff on the notion of Measures of Success (a term I had not heard before), that have close resemblance to the Integrated Master Plan (IMP).

Here's a paper given at the Energy Facilities Contractors Organization (EFCOG) on a similar topic.

There are several critical points here:

  • If we don't know what capabilities the project is supposed to produce and what the Measures of Effectiveness and Measures of Performance are for those capabilities, it's going to be hard to know what done looks like.
  • If we don't know what Done looks like, someone is going to have to pay to find out. That cost has to be absorbed somewhere, many times the project itself.
  • When we hear...

Estimates are difficult. When requirements are vague — and it seems that they always are — then the best conceivable estimates would also be very vague. Accurate estimation becomes essentially impossible. Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before.

This is going to turn out to be true. The project is going to spend money on discovering the requirements that delivery the capabilities. This is the case sometimes, but that cost needs to be accounted for in the business case. 

The last sentence above is actually not the case, expect where the development team has no experience in the business or technical domain. And in that case, why did you hire people to spend your money when they've never done this kind of work before?

  • So in the end, define the capabilities, hire people who know something about what you want done, make sure their Past Performance assures they have a grasp on the problem, and fund the project with enough budget to discover the requirements that deliver the needed capabilities.
Related articles Assessing Value Produced By Investments Systems Engineering in the Enterprise IT Domain
Categories: Project Management

Who Removes Your Obstacles?

In self-organizing teams, teams remove their own obstacles. It’s a good idea. It can be difficult in practice.

In Scrum, the Scrum Master is supposed to facilitate removing the team’s obstacles that the team can’t remove. It’s a good idea. It can be difficult in practice.

And, what if you aren’t doing Scrum, or you’re transitioning to agile and you don’t yet have a self-organizing team? Maybe you have an agile project manager. Maybe you have a team facilitator. Not every team needs a titled manager-type, you know. (Even I don’t think that, and I come from project management.)

Maybe the team bumps up against an obstacle they can’t remove, even if they try. Why? Because the obstacles the team can’t remove tend to fall in these categories:

  • Cross-functional problems across several teams or across the organization
  • Problems up the hierarchy in the organization
  • Problems that occur both places, as in over there in another department and higher up in the hierarchy

Oh boy. Someone who either used to be technical or used to be a first-line manager is supposed to talk to a VP of Support or Sales or the CIO or the CTO or “the Founder of the Company” and ask for help removing an impediment. Unless the entire organization is already agile, can you see that this is a problem or a potential problem?

Chances are good that during an organization’s transition to agile, the team’s facilitator (regardless of the title) will need help from a more senior manager to remove obstacles. Not for the team. For the rest of the organization.

Now, I would love it if the person who is supposed to remove obstacles was that designated facilitator (Scrum Master, agile project manager, whomever). And, that designated facilitator had the personal power to do it all by him or herself. But, I’m a realist. In my clients, that doesn’t happen without management support.

Is it a problem if a manager removes obstacles?

I don’t think so, as long as the manager supports the team, and doesn’t prevent the team from solving its own problems.

Here are examples I would expect the team to solve on its own:

  • Not finishing stories inside an iteration because there is too much work in progress or each person take his or her own story. This is a problem the team can manage by reviewing the board, or by pairing or swarming. The team has many options for solving this problem.
  • Too much work in progress. Again, the team can often manage this problem. The first step is to see it.
  • Not getting to “done” on stories. The first steps are to make the stories smaller, to make sure you have acceptance criteria, to work with the product owner on making stories smaller, those kinds of things. Maybe the first step is to make sure you have integrated testers into your team. But that might require managers to help.
  • Having trouble deciding what team norms are and the resulting issues from that.

Here are obstacles mid-level managers or more senior managers might help with:

  • Creating cross-functional teams, not silo’d teams. I keep seeing “developer” teams and “tester” teams being told “Go Agile!” No, agile is a cross-functional team where you have all the roles you need on one team to accomplish the work. This misconception is often a management misconception.
  • Which project is #1 (managing the project portfolio). If the team has a ton of interruptions or a demand for multitasking because management can’t decide which project is #1, I would expect some manager to take this obstacle on and resolve it. The pressures for multitasking or interruptions often arise from outside the team.
  • How the organization rewards people. At some point, agile bumps up against the culture of individual rewards. Managers might be the ones who need to manage HR.
  • When the product owner goes missing, or the team has no product owner. The team is now missing a key piece to their success and what makes agile work. Very few teams can demand a product owner, especially if they are new to agile.

This is a form of management as servant leadership, where the manager serves the team.

Do you see how certain problems are inside-the-team problems and the team can solve them? Other problems are not inside-the-team problems, and are part of the organization’s system. The organization needs to decide, “How committed to agile are we?” and address these issues.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Tue, 12/02/2014 - 15:02

Plans are only good intentions unless they immediately degenerate into hard work. - Peter F. Drucker

Categories: Project Management