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

Quote of the Day

Herding Cats - Glen Alleman - Thu, 02/26/2015 - 20:08

Your breakdown is not my emergency

Categories: Project Management

The Blame Game

NOOP.NL - Jurgen Appelo - Wed, 02/25/2015 - 12:59
The Blame Game

“You did not receive your order? Well, I did all I could. But they aren’t doing their job properly.”

“They still haven’t paid your invoice? Strange. They told me last time it would be done.”

“The feature is still not working? I don’t understand. I did submit the service request for you.”

The post The Blame Game appeared first on NOOP.NL.

Categories: Project Management

Agile Misconceptions: Agile is Just a Project Management Framework

If you read least week’s post about agile misconceptions, There is One Right Approach, you will like this one. This week’s article is¬†Agile Misconceptions: Agile is Just a Project Management Framework.

If you would like more common-sense approaches to agile, sign up for the Influential Agile Leader. We’re leading it in San Francisco and London this year. We offer discounts for multiple people from your organization. Sign up now.

Categories: Project Management

Software Development Conferences Forecast February 2015

From the Editor of Methods & Tools - Tue, 02/24/2015 - 17:38
Here is a list of software development related conferences and events on Agile ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP) and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods & Tools software development magazine. QCon London, March 2-6 2015, London, UK Exclusive 50 pounds Method & Tools discount with promo code “softdevconf50″ Wearables TechCon, March 9-11 2015, Santa Clara, USA Use code WEARIT for a $200 conference discount off the 3-day ...

Risk Management is How Adults Manage Projects

Herding Cats - Glen Alleman - Tue, 02/24/2015 - 16:35

R-101 CrashA favorite blog is Critical Uncertainties where Matthew Squair writes about risk. Risk in broad terms. But risk in a narrow term is just as important and just as critical.

Thanks to Matthew for the picture to the left and the quote of Lord Thompson, before he boarded the airship headed to India. The R-101 is as safe as a house, except for the millionth chance.

In the software development business, risk results from uncertainty. Risk that we'll overrun our budget. Risk that we'll show up late. Risk that what we produce won't actually work. Risk that what we produce won't be what the customer thought they were getting.

Agile development is many times billed as a risk management process. Which is both correct and incorrect at the same time. A principle of Agile Software Development - and Agile is a software development method - focuses on mandatory production of outcomes in short periods of time. These outcomes - working software - can be assessed to be compliant with the customer needs. These short periods of time provide inch pebbles on the path to completion of the collection of needed capabilities. These frequent outcomes provide feedback needed to take corrective action when those outcomes aren't what the customer wanted. But this feedback is a lagging indicator. It's after the fact. Do the work, look at the results, adjust. The probabilistic future risk and it's probabilistic choices to take corrective action to reduce risk or margin to protect from a risk, are not a core competency of Agile. More is needed on top of the feedback process to protect future evens or variances from impacting the emergent outcomes from the agile development process.

CRMAgile is not a risk management processes per se. Agile doesn't address the core practices of Risk Management, shown to the left.

Agile does not identify risks upfront, analyze those identified risk, plan for their reduction in explicit ways, track them in risk burn down ways, control them in advance. Agile can respond to a risk when it is encountered. By that time the risk has turned into an Issue. Changes to the project can then be made to go a new direction, but only when the working software is present can that decision be made. 

Risks are probabilistic. These probabilistic risks come from one of two sources. There is a probability that an event will occur in the future that will unfavorably impact the outcomes of the project. These type of uncertainties come from the lack of knowledge. They are epistemic uncertainties. This missing knowledge can be bought. Agile can buy this knowledge by producing something that can be assessed. Money can be spent to develop an incremental outcome that can test an idea, an outcome, a capability to determine if it is what the customer wants. But doing this work requires time and money. So planning for this time and money has to be part of the development process.

There are statistical variances in the project that will impact outcomes as well. We can't buy down these processes. They are Aleatory. They are Irreducible. The only solution for aleatory uncertainties - irreducible uncertainties - is margin. Cost margin. Schedule margin. Technical margin. 

To determine these margins we need several things:

  • A model of the underlying statistical processes that produce the irreducible uncertainties - the naturally occurring variances. These models can come from past performance -¬†we've done this many times and the most likely value is X, with the least value being X-15% and the highest value being X+25%.¬†
  • A parametric model where the observed past values are scaled to match the current model.

In either case - and other modeling approaches - this type of risk analysis produces probabilistic ranges of values that might occur. Rather than a probability of occurrence - which is an event.

Since both reducible and irreducible risks result from the underlying uncertainties requires us to estimate both the probabilities for event based outcomes and estimates for the range of possibilities from aleatory risks.

So when we revisit the title of the this post Risk Management is How Adults Manage Projects - Tim Lister, we see that Estimating are required to manage risk, since risk is always in the future, driven by underlying statistical process, emergent (event based and reducible) or natural variable process (probability distributions, and irreducible).  

Related articles Agile Software Development in the DOD Start with Problem, Than Suggest The Solution I Think You'll Find It's a Bit More Complicated Than That Estimating is Risk Management Software Engineering is a Verb Here, There Be Dragons We Suck At Estimating Quote of the Day
Categories: Project Management

The Difference Between a Story and a Task

Mike Cohn's Blog - Tue, 02/24/2015 - 16:00

What’s the difference between a user story and a task?

Well that’s an easy question, I thought, the first time it was asked of me in a Certified ScrumMaster class. “The difference is …,” I began to reply and realized it wasn’t actually such an easy difference after all.

I’d been using the two terms, “user story” and “task” in my classes for years, and they seemed pretty distinct in my head. User stories were on the product backlog and tasks were identified during sprint planning and became part of the sprint backlog.

That was fine but wasn’t very helpful—it was like saying “salt is what goes in a salt shaker and pepper is what goes in a pepper grinder.” Sure, stories go on the product backlog and tasks go on a sprint backlog. But what is the essential difference between the two?

I paused for a second the first time I was asked that question, and realized I did know what the difference was. A story is something that is generally worked on by more than one person, and a task is generally worked on by just one person.

Let’s see if that works …

A user story is typically functionality that will be visible to end users. Developing it will usually involve a programmer and tester, perhaps a user interface designer or analyst, perhaps a database designer, or others.

It would be very rare for a user story to be fully developed by a single person. (And when that did happen, the person would be filling multiple of those roles.)

A task, on the other hand, is typically something like code this, design that, create test data for such-and-such, automate that, and so on. These tend to be things done by one person.

You could argue that some of them are or should be done via pairing, but I think that’s just a nuance to my distinction between user story and task. Pairing is really two brains sharing a single pair of hands while doing one type of work. That’s still different from the multiple types of work that occur on a typical story.

I have, however, used a couple of wiggly terms like saying tasks are typically done by one person. Here’s why I wiggled: Some tasks are meetings—for example, have a design review between three team members—and I will still consider that a task rather than a user story.

So, perhaps the better distinction is that stories contain multiple types of work (e.g., programming, testing, database design, user interface design, analysis, etc.) while tasks are restricted to a single type of work.

I Think You'll Find It's a Bit More Complicated Than That

Herding Cats - Glen Alleman - Mon, 02/23/2015 - 19:35

When we encounter simple answers to complex problems, we need to not only be skeptical, we need to think twice about the credibility of the person posing the solution. A recent example is:

The cost of software is not directly proportional to the value it produces. Knowing cost is potentially useless information.

The first sentence is likely the case. Value of any one feature or capability is not necessary related to it's cost. Since cost in software development is nearly 100% correlated with the cost of the labor needed to produce the feature.

But certainly the cost of developing all the capabilities and the cost of individual capabilities when their interactions are considered must be related to their value or the principles of Microeconomics of Software Development would not longer be in place.

Microeconomics is a branch of economics that studies the behavior of individuals and small impacting organizations in making decisions on the allocation of limited resources. Those limited resources include (but are not limited to) Time and Money.

So without knowing the cost or time it takes to produce an outcome, the simple decision making processes of spending other peoples money based on the Return on that Investment gets a divide by zero error

ROI = (Value - Cost) / Cost

Since all elements of a project are driven by statistical processes, the outcomes are always probabilistic. The delivered capabilities are what the customer bought. Cost and Schedule are needed to produce those capabilities. The success of the project in providing the needed capabilities depends on knowing the Key Performance Parameters, the Measures of Effectiveness, the Measures of Performance, and the Technical Performance Measures of those capabilities and the technical and operational requirements that implement them.

The cost and schedule to fulfill all these probabilistic outcomes is itself probabilistic. It is literally impossible to determine these outcomes in a deterministic manner when each is a statistical process without estimating. The Cost and Schedule elements are also probabilistic, further requiring estimates.


The notion that you can determine the Value of something without knowing its Cost is actually nonsense. Anyone suggesting that is the case has little understanding of business, microeconomics of software development or how the world or business treats expenditures of other peoples money.

Here's some background to help in that understanding:

And for any suggestion that cost is not important in determining value please read

51lMOhz7RdLBetween this last book and the books above and all the papers, articles, and training provided about how to manage other people's money when producing value from software systems, you'll hopefully come to realize those notions that we don't need to know the cost, can't know the cost, and poor at making estimates, and should simply start coding and see what comes out are not only seriously misinformed, but misinformed with intentional ignorance.

If your project is not using other peoples money, if your project has low value at risk, if your project is of low importance to those paying, then maybe, just maybe they don't really care how much you spend, when you'll be done, or what will result. But that doesn't sound very fulfilling where I live.

Related articles Start with Problem, Than Suggest The Solution Estimating is Risk Management Software Engineering is a Verb
Categories: Project Management

Agile Software Development in the DOD

Herding Cats - Glen Alleman - Sun, 02/22/2015 - 00:59

I spoke at a workshop this week at The Nexus of Agile Software Development and Earned Value Management,¬†OUSD(AT&L)/PARCA, February 19 ‚Äď 20, 2015 Institute for Defense Analysis, Alexandria, VA.

This meeting was attended by government and industry representatives to share ideas of how to integrate Agile Software Development on Earned Value Management programs. EVM programs start with awards greater than $20M, so these are non-trivial efforts. The presentations will be available soon,. and I'll update this post when they're posted on the PARCA site.

In the mean time there is existing guidance for starting this process. But first here's a collection from SEI on the topic.

  • First Principle¬†- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.‚ÄĚ
  • Second Principle¬†- Welcome changing requirements, even late in development
  • Third Principle¬†- Delivering working software frequently‚ÄĚ
  • Fourth Principle¬†- Business people and developers must work together daily throughout the project.
  • Fifth Principle¬†- Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
  • Sixth Principle¬†- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
  • Seventh Principle¬†- Working software is the primary measure of progress
  • Eighth Principle¬†- Sustainable development pace.

As well here's some background

The notion of agile in large complex programs has come to the forefront of defense acquisition with Better Buying Power and Achieving Better Buying Power for Software Acquisitions

Related articles Real Life Sources of Empirical Data for Project Estimates We Suck At Estimating Software Engineering is a Verb Building A Credible Measurement Baseline
Categories: Project Management

Please Help Me Title Essays on Estimation

I have finished the content for Essays on Estimation. But, I need a new title. The book is more than loosely coupled essays. It reads like a real book, with progression and everything.

I have a number of ideas. They are (in no particular order):

  1. Predicting the Unpredictable: Essays on Estimating Project Costs and Dates
  2. Essays on Estimation: Pragmatic Approaches for Estimating Cost and Schedule
  3. How Much Will This Project Cost or When Will it be Done? Essays on Estimation
  4. Essays on Estimation: How to Predict When Your Project Will be Done
  5. Pragmatic Estimation: How to Create and Update Schedule or Cost Estimates
  6. Practical Approaches to Estimation: Create and Update Your Prediction Without Losing Your Hair
  7. Essays on Estimation: Practical Approaches for Schedule and Cost Estimates

Do you like any of these ideas? Have a better idea? I would like a title that explains what’s in the book.

I numbered these so you could respond easily in the comments with the number, if you like. Or, you can type out the entire title or a new title. I am open to ideas.

Thank you in advance.

Categories: Project Management

How to Write a Book… with Feedback and Options

NOOP.NL - Jurgen Appelo - Wed, 02/18/2015 - 20:41

As the author of a book, you make decisions all the time. Do you write about principles or about practices? Do you use the words he and she or the more neutral they? Do you use chapter numbers or not? Do you make your own illustrations, or do you hire someone else? Do you insert jokes, or is your bookkeeper funnier than you are?

If you want a good book, you need to make good decisions. The problem is, you often have too little information to know what the good decisions are. There are two ways of dealing with that.

The post How to Write a Book… with Feedback and Options appeared first on NOOP.NL.

Categories: Project Management


Herding Cats - Glen Alleman - Wed, 02/18/2015 - 06:11

Systems ThinkingMany in the Agile community like to use words like Self Organizing, Emergent, Complexity, and Complex Adaptive Systems, without actual being able to do the mathematics behind these concepts. They've turned the words into platitudes. This is the definition of popularization - a core idea from science and mathematics (physics many times) without the math. 

These popularizations, spawned a small industry of using the words in ways no longer connected with the actual mathematical model of self organizations, complexity, complex adaptive systems, and emergence of the underlying simplicity into a complex outcome.

There is a pop-psychology approach to core mathematics and the physics of complex systems as well.

Self Organization requires several conditions for it to be in place and be observed

  • A High Degree of Structure
  • The capacity for coordinated action
  • A mechanism for system-wide feedback and amplification
  • Some means to transform a small event into a larger driving force for the system to¬†organize itself into a coherent system

The key is coordination across boundaries and the capacity for action. This implies - quite explicitly - a deterministic response to external stimulus. The self-organization properties require structured communication channels to be in place for the systems to posses this property.

So next time you hear self organizing teams are the best ask to see what structures are in place to provide the channels for coordinated actions. What mechanisms are being used for system-wide feedback within that highly structured process framework, and what are the means of transforms small - potentially very small stimuli - into the collective actions of the whole? 

In the broader sense, these concepts all live in a world governed in a deterministic manner through...

  • Feedback - the return of a portion the output of a process or system to the input. These means modeling the transform function - usually G(S), where S is the system dynamic model, and G is the transform function. Both can be represented by non-linear differential equations
  • System Dynamics is the next level of modeling for the¬†structured, coordinated, system-wide feedback and amplification¬†(both positive and negative).
    • This involves¬†state-space¬†modeling or¬†phase space) where an abstract space - a mathematical model of in which all possible states of a system - are represented, with each possible state of the system corresponding to one unique point in the state space. Dimensions of state space represent all relevant parameters of the system. For example state space of mechanical systems has six dimensions and consists of all possible values of position and momentum variables.
    • The Trajectory of the system¬†describing the sequence of system states as they evolve.
    • A fixed point¬†in the state space where the system is in equilibrium and does not change. In complex projects and systems they represent, this is the¬†steering signal needed to compare the feedback to so corrective actions can be taken by the system to maintain equilibrium and run off the cliff.
    • The¬†Attractor¬†is a part of the state space where some trajectories end.
  • The actual dynamics of the system - where the¬†set of functions that encode the movement of the system from one point in the state space to another. This is the foundation of the mechanism for feedback and structuring of the disconnected components of the system. These dynamics are many times modeled with sets of differential equations containing the¬†rules for the interactions.¬†

The complex part of complex systems is the subtle - and poorly understood without the mathematics - property, that a deterministic system can have emergent and very different outcomes from the sensitivities of the starting conditions.

The double pendulum is a nice example. The equations of the Double Pendulum are a classic two year physics student problem. My introduction to FORTRAN 77 was to code the solution to the Double Pendulum problem in the Dynamics course.

Or maybe that person is just fond of using words they don't actually know the meaning of - at the mathematical level. As a classic example self organizing is defined (first used by William Rose Ashby in 1948) as the ability of the system to autonomously (without being guided or managed by an outside source)  increase its complexity. So when we hear self-organizing is good, the system we're applying it too is getting MORE complex without any external guidance. Wonder if that's what we actually wanted.

Using that word

Categories: Project Management

Software Development Linkopedia February 2015

From the Editor of Methods & Tools - Tue, 02/17/2015 - 16:09
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 software and system modeling, programmer psychology, managing priorities, improving software architecture, technical user stories, free tools for Scrum, coding culture and integrating UX in Agile approaches. Web site: Fundamental Modeling Concepts The Fundamental Modeling Concepts (FMC) primarily provide a framework for the comprehensive description of software-intensive systems. Blog: The Ten Commandments of Egoless Programming Blog: WIP and Priorities: Hw to Get Fast and Focused! Blog: Sacrificial Architecture Blog: ...

Multiple Levels of Done

Mike Cohn's Blog - Tue, 02/17/2015 - 16: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.

Having a “definition of done” has become a near-standard thing for Scrum teams. The definition of done (often called a “DoD”) establishes what must be true of each product backlog item for that item to be done.

A typical DoD would be something similar to:

  • The code is well written. (That is, we’re happy with it and don’t feel like it immediately needs to be rewritten.)
  • The code is checked in. (Kind of an “of course” statement, but still worth calling out.)
  • The code was either pair programmed or peer reviewed.
  • The code comes with tests at all appropriate levels. (That is, unit, service and user interface.)
  • The feature the code implements has been documented in any end-user documentation such as manuals or help systems.

Many teams will improve their Definition of Done over time. For example, a team using the example above might not be able to do so much automated testing when first starting out. But, hopefully, they would add that to their definition of done over time.

All this is sufficient for the vast majority of teams. But I’ve worked on a few projects whose teams benefitted from having multiple definitions of done. A team takes a product backlog item to definition of done Level 1 in a first sprint, to definition of done Level 2 in a subsequent sprint, and so on.

I am most definitely not saying they code something in a first sprint and test it in a second sprint. “Done” still means tested, but it may mean tested to different—but appropriate—levels. Let’s look an example.

An Example from a Game Studio

One thing I’ve really enjoyed in working with game studios is that they understand that not all work will make it into the finished game. Sometimes, for example, a game team experiments with a new character trying to make the character fun. If they can’t, the character isn’t added to the game.

So it would be extremely wasteful for a game team to have a definition of done requiring all art to be perfect, all audio be recorded, and refresh rates be high when they are merely trying to decide if a new character is fun. The team should do just enough to answer that question.

In a number of game studios, this has led to a four-level definition of done:

Done, Level 1 (D1) means the new feature works and decisions can be made. For animation, this was often “the character is animated in a white room.” It’s “shippable” to friendly users (often internal) who can comment on whether the new functionality meets its objective.

D2: The thing is integrated into the game and users can play it / interact with it.

D3: The feature is truly shippable. It’s good enough to include in a major public release. The team may not want to release it yet—they may first want to improve the frame rate, add some polygons, brighten colors, and so on. But the feature could be shipped with this feature in this state if necessary.

D4: The feature is tuned, polished, and everyone loves it. There’s nothing the team would change. A typical public release will include a mix of D4 and D3 items. There will always be areas the team wants to go back to and further improve. But, time intrudes and they ship the product. So D3 is totally shippable. You’re not embarrassed by D3 and only your hardest core users will notice the ways it could be better. D4 rocks.

Are Multiple Definitions of Done Right for You?

Very likely not. Most teams do quite well with a single definition of done. But the ideas above extend beyond just game development. I’ve used the same approach in a variety of other application domains, notably hardware development. In that case, the teams involved were developing dozens of new gadgets for an integrated suite of home automation products.

They used these definitions:

D1: The new hardware works on a test bench in the office.

D2: The new hardware is integrated with the other products in the suite.

D3: The new hardware is installed and running in at least one model house used for this type of beta testing.

D4: The product is fully ready for sale (e.g., it meets all requirements for UL approval).

Within this company, there were dozens of components in development at all times, and some components could be found at each level of doneness. For example, a product to raise and lower window shades could be in testing at the model home, while a newer component to open and close doors had just been started and was only working on a test bench of one developer.

Most projects will never need this. If you do think it’s appropriate for you, before trying it, really be sure you’re not using the technique as an excuse to skip things like testing.

Each level should exist as a way of making decisions about the product. A good test of that is to see if some features are dropped at each level. It is a good sign, for example, that sometimes a feature reaches a certain doneness level, and the product owner decides the feature is no longer wanted due to perhaps its cost or delivery time.

Agile Misconceptions: There Is One Right Approach

I have an article up on called Common Misconceptions about Agile: There Is Only One Approach.

If you read my Design Your Agile Project series, you know I am a fan of determining what approach works when for your organization or project.

Please leave comments over there. Thanks!

Two notes:

  1. If you would like to write an article for, I’m the technical editor. Send me your article and we can go from there.
  2. If you would like more common-sense approaches to agile, sign up for the Influential Agile Leader. We’re leading it in San Francisco and London this year. Early bird pricing ends soon.
Categories: Project Management

Early Bird Ends Soon for Influential Agile Leader

If you are a leader for your agile efforts in your organization, you need to consider participating in The Influential Agile Leader. If you are working on how to transition to agile, how to talk about agile, how to help your peers, managers, or teams, you want to participate.

Gil Broza and I designed it to be experiential and interactive. We’re leading the workshop in San Francisco, Mar 31-Apr 1. We’ll be in London April 14-15.

The early bird pricing ends Feb 20.

People who participate see great results, especially when they bring peers/managers from their organization. Sign up now.

Categories: Project Management

Real Life Sources of Empirical Data for Project Estimates

Herding Cats - Glen Alleman - Fri, 02/13/2015 - 19:39

In the #NoEstimates conversation, the term empirical data is used as a substitute for Not Estimating. This notion of No Estimates - that is making decisions (about the future) with No Estimates, is oxymoronic since gathering data and making decisions about the future from empirical data is actually estimating.

But that aside for the moment, the examples in the No Estimates community of empirical data are woefully inadequate for any credible decision making. Using 22 ¬†or so data samples with a ¬Ī30 variance to forecast future outcomes when spending other peoples money doesn't pass the¬†smell test where I work.¬†

Here's some sources of actual data for IT projects that can be used to build Reference Class that have better statistics.

The current issue of ORMS Today has resources as well ORMS can be obtained for free. There are several professional societies that provide guidance for estimating

Are two I participate in.

As well I have a colleague, Mario Vanhoucke, who speaks at our Earned Value Management conferences, whose graduate studies do research on project performance management. A recent paper, "Construction and Evaluation of Frameworks for Real Life Project Database," is a good source of how to apply empirical data to making estimates of outcomes in the future. Mario teaches Economics and Business Administration, at Ghent University and is a founder of OR-AS. 

All of this is to say, using empirical data is necessary but not sufficient. Especially when the data being used if too small a sample size, statistically unstable, or at a minimum statistical broad variances. To be sufficient, we need a few more things:

  • The correlations between the data samples as the evolve in time. This is¬†Time Series Analysis.
  • sample sizes sufficient to draw variances assessment of the future outcomes.
  • A broader Reference Class basis, than just the small number of samples in the current work stream. These small samples can be useful IF the future work represents the same class of work. This would imply the project itself is straightforward, has little emergent risk (reducible or irreducible), and we're confident not much is going to change. Without those assumption the statistics from those 20 or so samples should not be used.

What's Next?

Starting with empirical samples to make estimates of future outcomes is call Estimating. Labeling it as No Estimates seems a bit odd at best. 

With the basic understanding the empirical data is needed for any credible estimating process, look further into the principles and practices of probabilistic estimating for project work. 

This, hopefully, will result in an understanding of sample size calculations to determine the confidence in the forecast as a start. 

Related articles What does it mean when we say 80% confidence in a number? Intellectual Honesty of Managing in the Presence of Uncertainty Bayesian Statistics and Project Work The Actual Science in Management Science A Theory of Speculation
Categories: Project Management

How to Create a Book’s Front and Back Matter

NOOP.NL - Jurgen Appelo - Thu, 02/12/2015 - 22:37

So, your book has a great title, a nice cover, good content, and proper design? What about the front and back matter? The what? The front matter and the back matter! That’s all the extra stuff at the beginning and at the end of your book that sits between the cover and the chapters. Oh that, I’ll do all that stuff the day before I publish the book. *EEEEE* Wrong!!

A book is only good when it’s good from start to finish. It starts with the cover and it ends with the backside (or the final page in case of an eBook).

The post How to Create a Book’s Front and Back Matter appeared first on NOOP.NL.

Categories: Project Management

Intellectual Honesty of Managing in the Presence of Uncertainty

Herding Cats - Glen Alleman - Thu, 02/12/2015 - 17:11

There was a post yesterday where the phrase embrace the intellectual  honesty of uncertainty and a picture of Dice. I interpreted - possibly wrongly - that picture meant uncertainty is the same as tossing dice and gambling with your project. 

While uncertainty is certainly part of project management, it's not gambling, it's not guessing. It's probability and statistics.

So when someone suggests that tossing dice is the same as embracing uncertainty ask a few questions:
  • Do you have a model of the underlying uncertainties of your project. The reducible and irreducible uncertainties?
  • Do you have reference classes for the past performance of the work you are planning to perform?
  • Do you have mitigation plans for the reducible uncertainties?
  • Do you have margin for the irreducible uncertainties?

Of the answer to these is NO, then you are in fact tossing the dice for your project's success.

Related articles Software Engineering is a Verb All The World's A Random Process We Suck At Estimating
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Wed, 02/11/2015 - 17:13

Our mathematical models are far from complete, but they provide us with schemes that model reality with great precision - a precision enormously exceeding that of any description that is free of mathematics - Roger Penrose - "What is Reality, New Scientist, 2006

Any suggestion that all models are wrong, some models are useful, from a person who does not have George Box's book on the shelf and can point to the page that quote is on, or who has not read Penrose, is speaking about which he is uninformed. Do not listen.

Related articles The Actual Science in Management Science Bayesian Statistics and Project Work We Suck At Estimating
Categories: Project Management

Posted: Creating an Environment of Leadership

My most recent Pragmatic Manager , Creating an Environment of Leadership is up.

If you like these tips and the ones in Discovering Your Leadership, check out the Influential Agile Leader.

Gil Broza and I are offering the Influential Agile Leader twice this year: once in San Francisco, and once in London. The early bird deadline for registration is Feb 15.

If you are trying to transition to agile and you’re having more challenges than you expected, you owe it to yourself to participate.

If you have questions, contact me. I’m happy to answer them.

Categories: Project Management