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!
Software Development Blogs: Programming, Software Testing, Agile Project Management
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!
The new Management 3.0 #Workout book is already available in PDF, Kindle and ePUB versions. And in just a few weeks, readers will be able to get the Premium Print Edition as well. Nearly 500 pages of high-quality, full-color paper, with great design, awesome photos, crisp illustrations, and concrete practices. It will be the most colorful and practical management book ever published!
Hugh McCleod's art for Zappo's provides the foundation for trust in that environment
If I'm the head of HR, I'm responsible for filling the desks at my company with amazing employees.¬†I can hold people to all the right standards. But ultimately I can't control what they do.¬†This is why hiring for culture works.¬†What Zappos does is radical because it trusts.¬†It says "Go do the best job you can do for the customer, without policy".¬†And leaves employees to come up with human solutions.¬†Something it turns out they're quite good at, if given the chance.
Now let's take another domain, one I'm very famailar with - fault tolerant process control systems. Software and support hardware applied to emergency shutdown of exothermic chemical reactors - those that make the unleaded gasoline for our cars, nuclear reactors and conventional fired power generation, gas turbine controls, and other¬†must work properly machines. And a similar domain of DO-178c flight control systems, which must equally work without fail and provide all the needed capabilities on day one.
At Zappos, the HR Diector describes a work environment where employess are free to do the best job they can for the customer. In the domains above, employees also work to do the best job for the customer they can, but flight safety, live safety, equipment safety are also part of that¬†best job. In other domains we work, doing the best job for the customer means processing with extremely low error rates, transactions for 100's of millions of dollars of value in the enterprise IT paradigm. Medical insurance provider services, HHS enrollment, enterprise IT in a variety of domains.
Zappo's can recover from an error, other domains can't. Nonrecoverable errors mean serious loss of revenue, or even loss of live. In the other domains, failure is similar consequences. I come from those domains, they inform my view of the software development world - where software¬†fail safe and¬†fault tolerance is¬†the basis of business success.
So when we hear about the freedom to fail early and fail often in the absence of a domain or context, care is needed. Without a¬†domain and context, it is difficult to assess the credibility of any concept, let alone one that is untested outside of personal ancedote. It comes down to Trust alone or¬†Trust But Verify.¬†I could also guarantee that Zappos has some of the¬†verify¬†process. It is doubtful employees are left to do anything they wish for their customer. The simple reason there is a business governance process at any firm, no matter the size. Behaviour, even¬†full trust behavior fits inside that governance process.
All the rhetoric around any idea needs actionable outcomes that can be tested in the market place, beyond¬†the personal anecdotes of self-selected conversations.
Some readers told me they have used Moving Motivators during job interviews.
Some readers told me they used Delegation Boards on management teams.
Some readers told me they adopted Merit Money to get rid of bonuses.
I just visited REA Group in Melbourne, Australia, where they use lots of Management 3.0 practices, and have great experiences to share.
Last week, one conference attendee told me my presentation at Agile Tour Toulouse was perfect.
It was very kind, but I didn‚Äôt believe her.
In five years, I have spoken at almost 100 conferences and joined a similar number of community and company events. Thanks to the many discussions I had with event organizers, I think I now understand how to be a more valuable speaker.
Sometimes, you just need to get on with the work. You need to give yourself some breathing room so you can think for a while. Here are some tips that will help you tackle the day-to-day management work:
Okay, there are your five tips. Happy management.
Just a quick note today to let you know that the Call for Sessions for ScanAgile, the Agile Finland annual conference is open for submissions.
You can read the whole call for sessions here. You will find the submission form in that page as well.
For me the most interesting tracks are:
The Agile Finland Community is very active and has a long history of agile adoption and promotion. They have some of the most advanced practitioners in the world, so I am really looking forward to see who the Scan Agile team chooses for the 2015 lineup of the conference!
There are two primary ways for planning a sprint: velocity-driven sprint planning and commitment-driven sprint planning. In last week’s post, I described velocity-driven planning; so in this week’s, we turn our attention to commitment-driven sprint planning.
A commitment-driven sprint planning meeting involves the product owner, ScrumMaster and all development team members. The product owner brings the top-priority product backlog items into the meeting and describes them to the team, usually starting with an overview of the set of high-priority items.Select an Item
Following that, team members select a first item to bring into the sprint. This will almost always be the product owner’s top-priority item, but it is possible that the product owner’s top priority has too many open issues.
Ideally, a team should be able to still bring that item into the sprint and resolve the issues early enough in the sprint to complete the item. But, it’s possible that there are so many issues, that the issues are so significant, or that resolving the issues would take so much time (for example, the need to convene a meeting with 25 user representatives) that the product owner’s top priority is skipped.Tasks and Hours
Having selected a high-priority item, team members discuss the work involved, and identify the tasks that will be necessary to deliver the product backlog item. Either concurrent with identifying the tasks or immediately after they finish doing so, team members roughly estimate the number of hours each task will take.
Do not ask or expect a team to think of every task that will be done during the sprint. Not only is that impossible, it is also unnecessary.
Teams should think of enough of the tasks that they feel they have thought through the work—but it is important to realize that thinking through the work is the real goal of this meeting. Identifying tasks and hours is secondary.Asking for Commitment
After they’ve identified tasks and roughly estimated the hours for that one product backlog item, the team members ask themselves, “Can we commit to this?”
I find it very important that the team members ask this collectively of themselves rather than having a ScrumMaster ask, “Can you commit to this?” When team members ask, “Can we commit?” they are committing to each other rather than to the ScrumMaster.
I don’t know about you, but my early, pre-Scrum career is littered with broken “commitments” to bosses who asked if I could deliver something while making it clear my answer better be yes.
The ScrumMaster isn’t a boss and shouldn’t create that type of feeling among team members, but the person is called “master” – and it’s better not to risk being perceived as a boss insisting on a commitment.
Coach a team to ask, “Can we commit?” and it’s clear that they are committing to one another, which will likely be a stronger commitment.
Further, by having the team ask themselves, “Can we commit?” it is clear that the answer should be, “Yes we can” or “No we can’t.” When a ScrumMaster asks, “Can you commit?” some team members will properly answer with “we” but others will answer with “I.”
Scrum demands a full-team commitment: If you’re behind, I’ll help, and I know you’ll do the same for me. It’s not “these are my tasks” and “those are yours.”Repeat with More Stories
If the team agrees they can commit to a product backlog item, they select another item and repeat the process. And so it goes—tasks, hours and commitment—until someone says they cannot commit to the selected product backlog item.
If not, perhaps that story can be put back on the product backlog but a smaller item can be brought in, or an item that needs less of the skills possessed by the person who could not commit.No Role for Points or Velocity?
You may have noticed that in the process so far, there has been no role for story points or velocity. Although I still recommend that product backlog items be given quick, high-level estimates in story points, neither story points nor velocity play a role in commitment-driven sprint planning as described so far.
They do, however, play an important role in the final step of a sprint planning meeting.Sanity Checking the Commitment
Once team members have filled their available time in the sprint, the ScrumMaster can look at the selected product backlog items, sum the story points assigned to each, and share that sum with the team. Team members can then compare it to the average or recent velocity.
Suppose a team with an average velocity of 20 conducts a commitment-driven sprint planning meeting and selects 19 points of work. They’ve done this without knowing the story point values on any of the selected product backlog items.
When their ScrumMaster tells them they’ve just selected 19 points of work and have an average velocity of 19, that team should feel very confident they’ve selected an appropriate amount of work for the sprint.
Suppose instead, though, that the ScrumMaster for this team announces they’ve selected only 11 points of work. They might in that case ask themselves why they were making the work so hard during sprint planning as compared to when they’d earlier estimated the same items in story points.
For example, this may reveal that during sprint planning they’d identified work they’d earlier not thought about, or perhaps had explicitly assumed would not be part of a given story. Or they may discover that the story really is harder than they’d thought when assigning points to it.
Either way, knowing they’d selected 11 yet averaged 20 will help the team know they’ve selected an appropriate amount of work or perhaps make a change to bring more.
Similarly, if the ScrumMaster announces that the team has selected 30 points, 10 more than their average velocity, the team may wonder what they are forgetting to consider. “Why,” they would discuss, “does this work seem so much easier after sprint planning than it did while estimating story points?”
So: story points and velocity do not play a role during the main portion of a commitment-driven sprint planning meeting. But they play the vital role of acting as a sanity check and confirmation of the plan.It’s a Commitment, Not a Guarantee
It is important that the team’s commitment not be viewed as a guarantee. As Clint Eastwood said in one of his movies, “If you want a guarantee, buy a toaster.”
The team’s commitment is to do its best. I’d like to see them make their commitment perhaps 80 percent of the time. It should be something they take seriously and should make most of that time. That’s needed for the business to gain confidence in what a team says it can deliver.
However, finishing everything they say they will 100 percent of the time should not be the goal. A team forced to finish everything every time will do so—but by reducing what they commit to.
I originally named this approach commitment-driven sprint planning in my Agile Estimating and Planning book; others have taken to calling this “capacity-based planning.” I’m beginning to like the latter term better because of how easily a team’s commitment can be forced into being a guarantee.
The question asked by #NoEstimates is in the form of a statement.¬†
On the surface this statement sounds interesting until the second sentence. The MicroEconomics of writing software for money is based on estimating future outcomes thaty result from current day decisions. But let's pretend for a moment that Micro Econ is beyond consideration, this is never true, but let's pretend.
The next approach is to construct a small decision tree that can invert the question. Forget the exploring, since all business effort is a¬†zero sum game, in that someone has to pay for everything we do. Exploring, coding, testing, installing training, even operating.
¬†So let's start down the flow chart.
Is It Your Money?
In the crass world of capitalism, money talks, BS walks. While this may be abhorrent to some, it's the way the world works, and unless you've got your own bank, you're going to likely have to use other peoples money to produce software - ¬†either for yourself or for someone else. Self-funded start up? No problem, but even the best known names in software today went on to raise more money to move the firm forward. Then¬†self-funded became venture funded, private equity funded, and then publicly funded.
If you're writing software for money, and it's not your money, those providing the money have - or should have if they're savvy investors - a vested interest in knowing how much will this cost. As well when will it be done and most importantly, what will be delivered during the work effort and at the end.¬†
This requires estimating
Is There A Governance Policy Where You Work?
Governance of software development, either internal projects, external projects, or product development is a subset of corporate governance.¬†
If you work at a place that has no corporate governance, then estimating is probably a waste.
If however, you work somewhere that does have a corporate governance process - no matter how simple - and this is likely the case when there is a non-trival amount of money at risk, then someone, somewhere in the building has an interest in knowing how much things will cost before you spend the money to do them or buy them.¬†
This requres estimating
What's the Value at Risk for Your Project?
If the value at risk for a project is low - that is if you spend all the money and consume all the time and produce nothing and the management of your firm writes that off as a loss without much concern, then estimating probably doesn't add much value.
But if those providing you the money have an expectation that something of value will be returned and that something is needed for the business, then writing off the time and cost is not likely to be seen as favorable to you the provider.¬†
We trusted you because you said "trust me" and you didn't show up on or before the planned time, at or below the planned budget, with the needed capabilities - and you didn't want to estimate those up front and keep us informed about your new and updated Estimate To Complete and Estimate At Complete so we could take corrective actions to help you out - then we're going to suggest you look for work somewhere else.
On low value projects estimating the probability of success, the probability of the cost of that success, the probability of completion date of that success is not likely of much value.
But using the Value At Risk paradigm - risk of loss of a specific asset (in this case the value produced by the project) is¬†defined as a threshold loss value, such that the probability that the loss on the value from the project over the given time horizon exceeds some value.
As an aside the notion of¬†slicing does not reduce the Value at Risk. Slicing is a estimating¬†normalization¬†process where the exposure to risk is reduced to same sized¬†chucks. But the natural and event based variability of the work is still present in the chunks, and the probability of impacting the outcome of the project due to changes in demand, productivity, defects, rework, unfavorable and even un anticipated interactions between the produced chuncks needs to be accounted for in some estimating process. aAs well¬†the sunk cost of¬†breaking down the work into same sized chunks needs to be accounted.
In our space and defense world, there is the 44 Day Rule, where¬†chunks of work are broken down into 44 days (2 financial months) with tangible deliverables. The agile community would consider this to long, but they don't work on National Asset billion dollar software intensive programs, so ignore that for the moment.
So yes, slicing is a good project management process. But using the definition of No Estimates in the opening, slicing is Estimating and done in every credible project management process, usually through the Work Breakdown Structure guide.
The Five Immutable Principles of Project Success
To increase the probability of project success, five immutable principles must be in place and have credible answers to their question. Each requires some form of an estimate, since the outcomes from these principles is in the future. No amount of¬†slicing and dicing is going to produce a non-statistical or non-probabilistic outcome. All slicing does - as mentioned before - is reduce the variance of the work demand, not the work productivity, the variance in that work productivity process, the rework due to defects, or any unidentified dependencies between those work products that will create uncertainty and therefore create risk to showing up on time, on budget, and on specification.
The Devil Made Me Do It
Those of us seeking an evidence based discussion about the issues around estimating - and there are an endless supply of real issues with real solutions - have pushed back on using Dilbert cartons. But I just couldn't resist today carton.
When we need to make a decision between options - Microeconomics and¬†opportunity costs¬†- about some outcome in the future, we need an estimate of the cost and benefit of that choice. To suggest that decisions can be made without estimates has little merit in the real world of spending other peoples money.No Estimates Needs to Come In Contact With Those Providing the Money
The first is the self-selection problem of statistics. This is the Standish problem. Send out a survey, tally the results from those that were returned. Don't publish how many surveys went out and how many came back.
These are both members of the¬†cherry picking process. The result is lots of exchanges of questions to the original conjecture that have not basis in evidence for the conjecture.
When you encounter such a conjecture, apply the Sagan's¬†BS detection kit
When there is push back from hard questions, you'll know those making the claims have no evidence and are essentially BS'ing their constituents.
There is this notion in some circles that trust trumps all business management processes.
"–Ē–ĺ–≤–Ķ—Ä—Ź–Ļ, –Ĺ–ĺ –Ņ—Ä–ĺ–≤–Ķ—Ä—Ź–Ļ, –õ—É—á—ą–Ķ –Ņ–Ķ—Ä–Ķ–Ī–ī–Ķ—ā—Ć, —á–Ķ–ľ –Ĺ–Ķ–ī–ĺ–Ī–ī–Ķ—ā—Ć"
Who's butchered translation is Trust but Verify, don't rely on chance.
President Regan used that proverb reflected back to the Russian in the SALT I treaty. So what does it mean¬†trust that people can think for themselves and decide if it applies to them ...¬†that not making estimates of the cost, performance and schedule for the project are needed?
The first question is - what's the value at risk? Trust alone is likely possible in low value at risk. In that case the impact of not showing up on or before the needed time, at or below the needed cost, and with ot without all the needed capabilities for the¬†mission or business case fulfillment has much less impact and therefore is acceptable.
Trust but Verify
6 week DB update with 3 developers
18 month ERP integration with 87 developers whose performance is reported to the BoD on a quarterly basis
Water filter install in kitchen using the local handyman
Water filter install in kitchen with wife testing to see if it does what it said in the brochure
Install the finch feeder on the pole attached to the back deck in front of the kitchen window over looking the golf course.
Design and build the 1,200 square foot deck attached to the second floor on the back of the house using the architects plans and schedule the county for the inspection certificate so it can be used last summer.
Arrange for a ride in a glider at the county airport sometime Saturday afternoon
Plan departure from DIA and check for departure delay of SWA flight DEN to DCA.
In the first instances (left column)¬†trust us, we'll be done in the 6 week window probably means that team doesn't need to do much estimating other than the agree among themselves that the¬†Promise made to the manager has a good chance of coming true.
The second (right column) $178M ERP integration project in a publicly traded firm, filing their 10K and subject to FASB 86, and having¬†promised the shareholders, insured, and the provider network that the new system will remove all the grief of the several dozen legacy apps will be¬†made all better -¬†on or before¬† the Go Live date announced at the Board Meeting and in the Press has a good chance of coming true.¬†
To assess that chance, more that¬†Trust¬†is needed. Evidence of the probability of completing¬†on or before¬†the go live date and¬†at or below the target budget is needed. That probability is developed with an estimating process and updated on a periodic basis - in this case every month, with a mid-month assessment of the month end's reportable data.¬†
So next time you hear...
...think of the¬†Value at Risk, the fiduciary responsibility to those funding your work, to ask and produce an answer to the question of¬†how much, when, and what will be delivered. And even possibly the compliance responsibility - SOX, CMS, FAR/DFARS, ITIL - for¬†knowing to some degree of confidence the Estimate To Complete¬†and the¬†Estimate at Complete for your project. Writing 6 week warehouse apps, probably not much value. Spending 100's of millions of stock holders money and¬†betting the company likely knowing something like those numbers is needed.
Trust Alone is Open Loop Trust but Verify is Closed Loop
Control systems from Glen Alleman ¬† Without knowing the¬†Value At Risk it's difficult if not impossible to have a conversation about applying any method of managing the spend of other peoples money. Here's a clip from another book that needs to be on the shelf of anyone accoutable for spending money in the presence of a governance process. Practical Spread Sheet Risk Modeling. Don't do risk management of other peoples money? Then you don't need this book or similar ones, and likley don't need to estimate the impact of decisions made using other peoples money. Just keep going, your customer will tell you when to stop. ¬†
1024 - 2014
Thanks to Mr. Honner, a mathematics teacher in at Brooklyn Technical High School. If you like mathematics and appreciate the contribution a good teacher can make to mathematically understanding which is woefully lacking in our project management domain, sign up to get his blog posts.
The #NoEstimates movement appears to be based on a 27 year old report‚Ä† that provides examples of FORTRAN and PASCAL programs as the basis on which estimates is done.¬†
A lot has happend since 1987. For a short crtiique on the Software Crisis report - which is referenced in the #NoEstimates argument, see "There is No Software Engineering Crisis."
1000's of research and practicum books and papers on how to estimate software projects have be published. Maybe it's time to catch up with the 21st Century approach of estimating the time, cost, and capabilities needed to deliver value for those paying for our work. These approaches¬†answer the mail in the 1987 report, along with the much referenced¬†NATO Software Crisis report published in 1986.
While estimates have always been needed to make decisions in the paradigm of Microeconomics of software development, the techniques, tools, and data have improved dramatically in the last 27 years. Let's acknowldge that and start taking advantage of the efforts to improve our lot in life of being good stewards of other peoples money. And when we hear #Noestimates can be used to forecast completion times and costs at the end, test that idea with activities in the Baloney Claims check list.
‚Ä†¬†#NoEstimates is an approach to software development that arose from the observation that large amounts of time were spent over the years in estimating and improving those estimates, but we see no value from that investment. Indeed, according to scholars Conte, Dunmore and Shens¬†¬†a good estimate is one that is within 25% of the actual cost, 75% of the time. in¬†http://www.mystes.fi/agile2014/
As a small aside, that's not what the statement actually says in the context of statistical estimating. It says there is a 75% confidence that there will be on overage of 25% which needs to be covered with management reserve for 25% to protect the budget. Since all project work is probabilistic, uncertainty is both naturally occurring and event based. Event based uncertainty can be reduced by spending money. This is a core concept of Agile development. Do small things to discover what will and won't work. Naturally occurring uncertainty, can only be handled with¬†margin. In this statement - remember it's 27 years old - there is a likelihood that a 25% management reserve will be needed 25% of the time there is a project estimate produced. If you know that ahead of time, it's won't be a disappointment when it occurs 25% of the time.
This is standard¬†best management practice in mature organizations. In some domains, it's mandatory to have Management Reserve built from Monte Carlo Simulations using Reference Classes of past performance.Related articles How to Estimate Software Development Software Requirements Are Vague How Not To Make Decisions Using Bad Estimates #NoEstimates? #NoProjects? #NoManagers? #NoJustNo
Ascertaining of the success and applicability of any claims made that are outside the accepted practices of business, engineering, or governance processes require careful testing of ideas through tangible evidence they are actually going to do what it is conjectured they're suppose to do.
The structure of this checklist is taken directly from¬†Scientific American's¬†essay on scientific baloney, but sure feels right for many of the¬†outrageous¬†claims found in today's software development community about approaches to estimating the cost, schedule, and likely outcomes.
How reliable is the¬†
source of the claim?
Self-pronounced experts often appear credible at first glance, but when examined more closely, the facts and figures they cite are distorted, taken out of context, long out of date, mathematically wrong, missing critical domain and context basis, or occasionally even fabricated.
In many instances the data used to support the claims are weak or poorly formed. Relying on surveys of friends or hearsay, small population samples, classroom experiments, or worse anecdotal evidence where the expert extends personal experience to a larger population.
Does this source often make similar claims?
Self pronounced experts have a habit of going well beyond the facts and generalizing their claims to a larger population of problems or domains. Many proponents of ideas make claims that cannot be substantiated within a testable framework. This is the nature of¬†early development ¬†in the engineering world. Of course, some great thinkers do frequently go beyond the data in their creative speculations.
But when those creative thinkers are used to support the new claims it's more suspect the hard work of testing the claim outside of personal experience hasn't been performed.¬†
They said agile wouldn't work, so my conjecture is getting the same criticism and I'll be considered just like those guys when I'm proven right.
Have the claims been verified by another source?
Typically self pronounced experts make statements that are unverified or verified only by a source within their own private circle, or who's conclusions are based primarily on anecdotal information.
We must ask, who is checking the claims, and even who is checking the checkers? Outside verification is crucial to good business decisions as it is crucial to good methodology development.
How does the claim fit with what we
know about how the world works?¬†
Any specific claim must be placed into a larger context to see how it fits. When people claim that a specific method, approach, or technique results in significant benefits, dramatic changes in an outcome, etc. they are usually not presenting the specific context for the application of their idea.
Such a claim is typically not supported by quantitative statistics as well. There may be qualitative data, but this is likely to be biased by the experimental method as well as the underlying population of the sample statistics.
In most cases to date, the sample size is minuscule compared to that needed to draw correlations and causation's to the conjectured outcomes.
Has anyone gone out
of the way to disprove the claim, or has only supportive evidence
This is the confirmation bias, or the tendency to seek confirmatory evidence and to reject or ignore dis‚Äďconfirmatory evidence. The confirmation bias is powerful, pervasive and almost impossible to avoid.
It is why the methods that emphasize checking and rechecking, verification and replication, and especially attempts to falsify a claim, are critical.
When self-selected communities see external criticism as ¬†harassment or¬†you're simply not getting it, or ¬†those people are just like talking to a box of rocks, the confirmation bias is in full force.
Does the preponderance of evidence point to the claimant's conclusion or to a different one?
Evidence is the basis of all confirmation processes. The problem is having evidence alone is necessary but not sufficient. The evidence must somehow be "predicted" by the process, fit the process model, or somehow participate in the process in a supportive manner.
Is the claimant employing the
accepted rules of reason and tools of research, or have
these been abandoned in favor of others that lead to the desired conclusion?¬†
Unique and innovative ways of conducting research, process data, and "conjecturing" about the results are not statistically sound. In almost every discipline there are accepted mechanisms for conducting research. One of the first courses taken in graduate school is¬†quantitative methods ¬†for experiments. This course sets the ground rules for conducting research in the field.
Is the claimant providing an explanation for the observed phenomena or merely denying the existing explanation?¬†
This is a classic debate strategy‚ÄĒcriticize your opponent and never affirm what you believe to avoid criticism.
Show us your data, is that starting point for engaging in a conversation about a speculative idea.
If the claimant proffers a new explanation, does it account for as many phenomena as the old explanation did?¬†
This concept is usually lost on "innovative" claims. The need to explain previous results is mandatory. Without this bridge to past results, a new suggested approach has no foundation for acceptance.
Do the claimant's personal beliefs and biases drive the conclusions, or vice versa?
All claimants hold social, political and ideological beliefs that could potentially slant their interpretations of the data, but how do those biases and beliefs affect their research in practice?
Usually during some peer-review system, such biases and beliefs are rooted out, or the paper or book is rejected.
In the absence of peer review - self publishing is popular these days - there is no external assessment of the ideas and therefore the author reinforces of the confirmation bias.
¬†So the next time you hear a suggestion that appears to violate a principles of ¬†business, economics, or even physics, think of these questions. So let's move to the #NoEstimates suggestion that we can make decisions in the absence of estimate, that is we can make decisions about a future outcome in absence of estimating the cost to acheive that outcome and the impact of that outcome.
The core question is¬†how can this conjecture be tested beyond the personal anecdotes of those proffering the notion that decisions can be made in the absence of estimates? Certainly those making the claim have no interest in performing that test. It's incumbant on those attempting to apply the notion to first test if for validity, applicability, and simple credibility.¬†
A final recommendation is Ken Schwaber's talk and slides¬†to think about¬†evidence based¬†discussions around improving the business of software development. And the book he gave away at the end of the talk¬†Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based ManagementRelated articles Falsifiability and Junk Science
If a man will begin with certainties, he shall end in doubts, but if he will be content to begin with doubts, he shall end in certainties. - Francis Bacon
Everything in project work is¬†uncertainty. Estimating is required to discover the extent of the range of these uncertainties, the impacts of the uncertainties on cost, schedule, and the performance of the products or services.
To suggest decisions can be made in the presence of these uncertainties without knowledge of the future outcomes and the cost of achieving these outcomes, or deciding between alternatives with future outcomes ignores completely the notion of uncertainty and microeconomics of decision making in the presence of these uncertainties.
Long ago, I was a project manager and senior engineer for a company undergoing a Change Transformation. You know the kind, where the culture changes, along with the process. The senior managers had bought into the changes. The middle managers were muddling through, implementing the changes as best they could.
Us project managers and the technical staff, we were the ones doing the bulk of the changes. The changes weren’t as significant as an agile transformation, but they were big.
One day, the Big Bosses, the CEO and the VP Engineering spoke at an all-hands meeting. “You are empowered,” they said. No, they didn’t say it as a duet. They each said it separately. They had choreographed speeches, with great slide shows, eight by ten color glossies, and pictures. They had a vision. They just knew what the future would hold.
I managed to keep my big mouth shut.
The company was not doing well. We had too many managers for not enough engineers or contracts. If you could count, you could see that.
I was traveling back and forth to a client in the midwest. At one point, the company owed me four weeks of travel expenses. I quietly explained that no, I was not going to book any more airline travel or hotel nights until I was paid in full for my previous travel.
“I’m empowered. I can refuse to get on a plane.”
That did not go over well with anyone except my boss, who was in hysterics. He thought it was quite funny. My boss agreed I should be reimbursed before I racked up more charges.
Somehow, they did manage to reimburse me. I explained that from now on, I was not going to float the company more than a week’s worth of expenses. If they wanted me to travel, I expected to be reimbursed within a week of travel. I got my expenses in the following Monday. They could reimburse me four days later, on Friday.
“But that’s too fast for us,” explained one of the people in Accounting.
“Then I don’t have to travel every other week,” I explained. “You see, I’m empowered. I’ll travel after I get the money for the previous trip. I won’t make a new reservation until I receive all the money I spent for all my previous trips. It’s fine with me. You’ll just have to decide how important this project is. It’s okay.”
The VP came to me and tried to talk me out of it. I didn’t budge. (Imagine that!) I told him that I didn’t need to float the company money. I was empowered.
“Do you like that word?”
“Sure I do.”
“Do you feel empowered?”
“Not at all. I have no power at all, except over my actions. I have plenty of power over what I choose to do. I am exercising that power. I realized that during your dog and pony show.
“You’re not changing our culture. You’re making it more difficult for me to do my job. That’s fine. I’m explaining how I will work.”
The company didn’t get a contract it had expected. It had a layoff. Guess who got laid off? Yes, I did. It was a good thing. I got a better job for more money. And, I didn’t have to travel every other week.
Change can be great for an organization. But telling people the culture is one thing and then living up to that thing can be difficult. That’s why this month’s management myth is Myth 34: You‚Äôre Empowered Because I Say You Are.
I picked on empowerment. I could have chosen “open door.” Or “employees are our greatest asset.” (Just read that sentence. Asset???)
How you talk about culture says a lot about what the culture is. Remember, culture is how you treat people, what you reward, and what is okay to talk about.