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!
If this is how you see your management, your interaction with them, or how your firm works, then here's some advice
Here's what you do as soon as you have the chance.
If you don't Run Away, I guess you can sit around and grouse about how bad your management is, how to do your job without having to be accountable for how much money you are spending, or pretend that someone else, somewhere in the firm will figure how to estimate before you RUN AWAY.
But in the end if the Monte Python gang is the view of the world of your management, ask yourself if you've hitched up with the wrong crowd but don't know it yet.Related articles Quote of the Day - More Statistics for Decision Making Probabilistic Cost and Schedule Processes Danger Will Robinson How NOT to Estimate Anything Some more answers to the estimating questions Back To The Future Hume's Advice for Theoritical Business Process Advice How To and How Not To Make Credible Estimates of Cost and Schedule
Again and again researchers confirm that most people don‚Äôt like their jobs. About two-thirds of employees in the world are unhappy about their work, and they feel unengaged about their organizations.
Can we change this?
Can we do better?
Join me for a webinar on March 10, 2014 at 7pm Eastern. My topic is “Overcoming 7 Common Pitfalls of Transitioning to Agile in Software Engineering.” I’m speaking as part of the Graduate Professional Studies Spring 2014 Guest Speaker Series.
Now that I‚Äôve almost finished writing my third book I want to learn everything there is to know about publishing and marketing books. And more particularly, I want to know the answer to the question, ‚ÄúHow to Market a Self-Published Book?‚ÄĚ
The solution is very simple.
Woody asks some important questions that have straight foreword answers in the¬†software for money domain. These answers come for the business side of a software development organization. It's the business of software that needs estimates. Given a choice no developer really¬†wants to estimate her work. I never did, I just wanted to code. But once there is an understanding that my paycheck didn't come from the Bank of America, even thought that's what it said at the top (above TRW), then I slowly learned our customers paid of some value (in that first job a missile defense radar system) they needed to know how much it was going to cost to produce the needed capabilities.¬†
So here's some good questions that have answers from the point of view of those¬†paying for the cost to produce the software for the customer.
So some further questions?
Knowing what it costs to produce a specific value is a critical success factor in any business. Writing software for money is no different.Related articles Estimates and all that... Resources for Moving Beyond the "Estimating Fallacy" Danger Will Robinson Managing Risk and Uncertainty in Agile Why Estimating Is Mandatory It's an Estimating Problem not A Problem with Estimating The Value of Making An Estimate
The discussion (of sorts) on Twitter around "no estimates" - what ever that actually means, since there is no definitive description other than exploring¬†- brings me back to my core program management, project management, writing software for money, designing algorithms for identifying moving targets in radar systems, and other¬†software engineering experiences.
Let's start with a fundamental pricniple of all product or service development, either internal or external. While leading a couple hands full of project managers at a large Department of Energy environmental cleanup site, where software development was a critical success factor - and by the way we introduced eXtreme Programming into an ANSI validated Earned Value Management System - our external consulting firm gave us some good advice. We were bidding our technology and services at another DOE site, with similar cleanup problems. We were working on strategies, balanced scorecards, systems architectures, and the like.¬†
That's all nice boys and girls, but here's some fundamental advice - our customer has money and we want it. What's it gonna cost and when will you be done providing the capabilities to close this site?
That's it, that's the winning strategy. The customer has a need, we want to providea ¬†solution to it. How much will it cost and when will we have it. If we can answer those three questions - cost, schedule, delivered capabilities, with attached unassailable beneficial outcomes - we will win. This is a business strategy. All the Balanced Scorecard presentations, examples of past performance, deep references of success, are all for naught if the customer can't afford our solution. It comes down to this - and this is where I learned this from the Managing Partner of the Big 6 (at that time) consulting firm.
You can't know the value of something until you know its cost
That's a fundamental principle of all business transactions. Value is always exchanged for cost. We do this when we buy a Venti Nonfat Latte at Star Bucks. We do this when we pay the lawn care company to mow and trim weekly. We do this when we buy anything, including software or the services that produce the software.
This is an immutable principle of commerce
So when we hear, there are alternative ways of writing software for money that don't involves estimating the cost of doing that work, think again.¬†How did you get around the immutable principle of commerce? Now notice I used the word estimate in the same post as¬†know. Yes, estimating allows us to¬†know something to some level of confidence.¬†
I'll estimate that my 1 hour drive to work everyday, will be extended to 1 hour 20 minutes when the snow storm arrives tomorrow night.
I¬†know I'd better have margin in my drive schedule, if I want to attend the 8:30 stand up.¬†
I estimate that it will take 3 days to install and verify the database for the system, given the historical data from the last 3 times we did this.
This¬†knowledge¬† can then be used to plan the access to the server room, arrange for all the verification and validation data we'll need to certify the contents are¬†ready for use by the customer.¬†
We¬†estimate to a degree of confidence, things (time, cost, performance) we'll need to know about to do our job.
So How Can We Learn To Estimate?
Here's where we start. We start with what has taken place in the past.¬†We've never done this before you say. I'd suggest, working literally in the¬†rocket science world, there is very little in the commercial software world that hasn't been done by someone, somewhere in the past. You may not know these people, but it's been done. And more importantly it's the people issues that muck up the project most of the time, not the technical, unless of course it actually is rocket science, or stealth fighter science, or bioscience.¬†
So with the second best basis of estimate approach -¬†What is this like?¬†We've done similar things in the past, how is this problem like those solutions? Next comes the 10 questions approach. The¬†Planning Game. Then a parametric approach. Function Points, COCOMO, SEER, Price-S, SLIM, CoStar, and a long list of other¬†basis of estimate¬†tools, some free can guide you. So when you hear¬†software can't be estimated, change the phrase to¬†I don't know how to estimate software projects, but I can sure look into learning how.
Finally the least desirable way to estimate is to ask the expert. This only works if the expert has been calibrated with a reference class, has her¬†optimism bias in check, knows all about anchoring and adjustment, and has a track record for producing credible estimates. If not, you're going to be disappointed in the result.
But our management uses our estimates against us. Our management doesn't understand the notion of probability and statistics. Our management behaves like Dilbert's boss. This has nothing to do with the need to estimate the cost, schedule, and technical performance of the product and service needed by your customer. It has everyone to do with¬†managing up. And if that's not possible, producing a credible estimate with those risks baked in to protect yourself. And if that's not possible start looking for a better manager or even a better job because your company is going to be in the ditch before long.
So when we hear that¬†estimating is the smell of dysfunction -¬†without ever listing one single dyfunction - remember there are lots of dysfunctions in business. This is normal, because humans are involved. But that dysfunction is not¬†caused by the need to estimate. The need to estimate is a core business process. Doing bad estimates, doing estimates for the wrong reasons, doing estimates wrong - that's a dysfunction that is universal.
In the end you need to either nut up or shut up as Woody says. Yes, that Woody. Learn to estimate for all the right reasons, then when there is an opportunity to have an enlightened manager at your current firm or a new firm, you'll be prepared to contribute value to the business process in ways that benefit the top line.
Since that top line, minus the costs to produce the goods or services is the bottom line (in it's simplest¬†form) is what writing software for money is all about. Knowing the middle line -¬†costs of goods sold¬†(COGS) is critical to actually staying in business.Let's Stop Guessing and Learn How to Estimate Facts and Fallacies of Estimating Software Cost and Schedule
There are many things I do badly, or not at all. Exercise is one of them. And cooking. And dealing with badly formulated criticism. But there‚Äôs one thing I‚Äôve learned to do well in the last few years.
I can say ‚ÄúNo‚ÄĚ easily.
I am bombarded with requests every day. Which is awesome! I cherish all the attention people are willing to give me. But there‚Äôs only so much I can do, which means I have to make difficult choices. I‚Äôm sure you know the feeling!
The ideas below reflect the discussions we (Maaret Pyhaj√§rvi, Martin von Weissenberg, Vasco Duarte) have had while reflecting on our Visions for Agile Finland. We hope these ideas are discussed and developed within the Agile community in Finland, and end up in a set of actions for the Agile Finland Executive Committee 2014-2015. We also commit to present ourselves as candidates for the Agile Finland executive committee in the next Annual Fannual meeting and are open to you joining our group to be part of the next executive committee.
If you share our ideas, get in touch and join us for the Agile Finland board. If you don‚Äôt share our ideas, please join the debate! Publish your ideas, volunteer for the next Agile Finland board on your own or as part of our list. Our goal is to spark debate and ensure we will have a strong group of committed individuals to continue the work that we feel Agile Finland needs to complete.Read our ideas below, and let us know what you think. Community servicesAgile Finland needs to take a role in the progress of software industry in Finland. One way in which we can do that is by cooperating more closely with the companies that identify themselves as Agile companies, both consulting and product/service production.
We want Agile Finland to be a platform for all members of the Finnish Agile Community, be they individuals or other organizations (for profit or not). As an example of this cooperation, we want to establish a yearly market research process financed by Agile Finland that would deliver a yearly ‚Äústate of Agile in Finland report‚ÄĚ and distribute it to the companies in the Agile community as well as to the media and individual Agile Finland members. This report can include topics such as:
Over the past years, conferences (especially Scan Agile) have been a major funding component for Agile Finland. We want to propose some changes in this respect. We recognize that it is today unclear for Sponsors to know which events to participate in as sponsors. If you support Tampere Goes Agile does it make sense to support another major conference like Scan Agile? How about conferences that happen at similar times? Which one to choose?
We find these choices confuse sponsors and do not adequately serve our present Agile Finland members either. Therefore we propose a change in model for 2014-2015. We propose that companies interested in sponsoring Agile Finland be able to sponsor the whole year of events (several major events are held by Agile Finland every year) and be allowed to choose which ones they participate in. For example, if Company A purchases a yearly sponsorship from Agile Finland they could be features in Scan Agile, Tampere Goes Agile and local events that will happen during the year.
Alternatively, companies could still purchase sponsorship packages for specific events just like they did until now.
Additionally we want to propose a change in the Agile Finland bylaws to allow corporate membership. This membership would allow companies to have access to services such as market research, recruiting communication and other services that Agile Finland may want to develop in support of the Agile business community.Sponsoring local events
Agile Finland wants to support local Agile communities around Finland, therefore we will commit a minimum amount of money to self-organized community events. All that is needed is a request to the board and the funding will be approved provided we stay within the agreed limit. If you have an idea to support your local community we want to help you without a long wait for either practical or financial support. We want to help local communities get more active, and our support (advertising and financial support) will make it easier.Developing a future for the Finnish software industry
In 2014-2015 we want to start what we hope will become a trend for the future of our industry. We want to support events designed to support future professionals get familiar with what it means to work in a software organization. For that we will organize events with school-age children on topics such as what the ‚Äúmaker‚ÄĚ community already supports all over the world. Creating projects that young Agilists could work on, from concept to execution. But we will also try to grow partnerships with student organizations, universities and companies to have a mentorship program started to help integrate students in the software industry easily.Major events for 2014-2015
Events such as Turku Agile Day (which we want to support actively), Tampere Goes Agile and Scan Agile are events that attract a large audience and spreads knowledge and awareness of Agile within our community, but also helps establish strong links to other communities.
We want to continue to host and these events but also recognize that a voluntary-only approach has risks that must be tackled. We will consider how to support these events on a case-by-case basis and will work to make their organization a sustainable project that does not require heroic efforts from some of our members every year.
We recognize that each event has their own identity and we want to support that diversity.As first actions we will:
Do you want to help shape the next year for Agile Finland? Participate by sharing this blog, commenting or tweeting/blogging about the topic yourself! Be active, let's make Agile Finland even better!
There was a question posed on LinkedIn
How do you get Project Manager understand the importance of Earned Value Management?
It's been shown over and again when we make EV a compliance process and hold managers accountable for compliance it is a necessary condition for success, but far from sufficient.
Until EVM starts providing actionable information to the program management staff in the form of "leading indicators" it will always be one of those compliance processes. This information must reveal where in the program, technical and programmatic changes can be made, the ¬†testable outcomes of those changes on program performance, and the impacts on cost and schedule forecasts and the EAC against the BAC. Starting at the program level, but going down to the Control Account and Work Package.
In other words...
Nice data there in your Formats 1-5 and really nice IMS, what should I do next?
EV numbers themselves are lagging indicators, non-statistically adjusted, non risk adjusted, not connected to the effectiveness and performance measures of the project - unless enlightened users do so - and not connected to the needed capabilities of the customer as delivered by the program. There is no DID for the IMP, so Systems Engineering rarely flows down MOEs and MOPs - except where they do, because of the knowledge of the power of this approach.
Next is a real problem. 748-C has a loop hole big enough to fly a 787 through. In section 3.8 "Earned value is a direct measurement of the quantity of work accomplished. The quality and technical content of work performed is controlled by other processes." Measuring ¬†quantity is a construction centric view of producing value. Not a¬†value centric view. Our defense, space, biopharma, software intensive programs that apply EVM are not pouring concrete or welding pipe. (I used to work in that domain as a SW developers on piping design systems). If we see EV as measuring¬†quantity we ignore all the concerns Paul Solomon has brought forward, starting with the missing Technical Performance Measures for the product.
Sure we have¬†exit¬†criteria for the Work Packages. But these need to trace vertically through the IMP to the¬†Capability ¬† to accomplish the mission or provide a solution to the business need. In other ¬†do something with the resulting product or service. It has to be the right thing of course. But EV - as stated in 748 - only measures to quantity of¬†parts needed to delivery a capability, not the ability of the system to fulfill the needed capabilities. This by the way is essentially a Systems Engineering issue. With the missing IMP, most of the motivation for ¬†connecting the dots between EV and mission success is simply not there. It's back to the immutable principle
We don't know what done looks like in units of measure meaningful to the decision makers
"Earning value" means assessing the efficacy of the BCWS. This means assessing the Technical Performance Measures of the work be delivered. Many implementations assign TPMs and QBD's this work. But this is not called out in 748-C nor any formal EV guidance. It is called out in the DAG and the old SEMP DID. No SEMP DID is in place.¬†
So as EV practitioners we need to make the business case of EVM, not just the compliance case. When we add "leading indicators" that are statistically sound (Eric Druker has written about this as have others, including me), forecasting of EAC based on ARIMA processes rather than our linear, non-statistical, non risk adjusted CPI/SPI measures. As well those measure "roll up" the variances of all the past time series data, just like Darrell Huff tells us to do in "How To Lie With Statistics".¬†
All the data is available in the EV engine and in the CR at PARCA for DOD jobs. What's next is to start using EVM in the same way supply chain managers, quality control managers, systems engineers, and every design and manufacturing engineer does - compare statistically adjusted performance against the probabilistic plan to see leading indicators emerge of where we are going to go into the ditch in the future, show the PM, that corrective action "before the fact" rather than after.¬†
This will be a topic discussed at EVM World and ISCEA conferences coming soon.
Shim Marom provides thought provoking posts. The one on Estimates and Not Estimates was a perfect straight line requesting a response.
So some other thoughts:
If No Estimates is about making decisions, then No Estimates better come up with the cost of outcomes of having made that decision or that statement is completely bogus. Time to start looking for ¬†business value from our work efforts in building software for money. That means know the cost of our efforts to some degree of confidence before and during the project.¬†Knowing afterward is simple and worthless, that horse ran away and know we're saying how much it costs.Related articles It's an Estimating Problem not A Problem with Estimating How To Estimate, If You Really Want To Moving from "Why" to "What" Actions are Needed? Why Hasn't #NoEstimates Produced Actionable Outcomes Yet?
Project success is elusive in all business and technical domains, including software development, construction, new drug development, any project involving multiple participants, irregular funding, and emerging requirements and risks that haven't yet been identified and handled.
To increase the probability of project success we must start with principles and apply practices implemented by processes known to produce benefical outcomes. Without these principles the practices and processes have no home.
These principles provide the framework for practice and process. Let's establish them first:
Identify the Technical and Operational Capabilities
The capabilities needed for success of the project, mission, or business ¬†are defined by the customer. Through a strategy¬†development process or some other process that states why¬†these are needed in units of measure meanigful to the decision maker. These measures are stated as effectiveness and performance goals.
Construct the Sequence of Capabilities
The capabilities must be delivered in an order that maximizes business value, minimizes risk, and maximizes opportunities along the way to make improvements for the customer.
With the sequence of work in place, we can now look for risks to our success and opportunities for improvement. Risk is created by uncertainty. Uncertainty comes in two flavors:
With sequenced capabilities, risk handling plans, and opportunity plans we are now able determine the cost and schedule of the work needed to deliver the capabilities. This work starts with packages of work holding the budget for the work and describing the period of performance.¬† This result shows us the cost needed to produce each capability. This cost can be compared to the beneficial outcomes from the capability to confirm the business case or mission strategy if viable from a business point of view.
For each chunk of work in the plan to implement the needed capabilities we need some method to measure progress to our plan. These measures must be based on tangible evidence of physical percent complete. This can be done through three basic approaches.
Each of these assessments of progress to plan is based on a pre-defined unit of measure. This avoids the opinion of progress we often see on projects stuck at 80% to 90% complete. It also prevents measuring progress with the passage of time and consumption of money. Even the notion of¬†working software has to have a tangible measure of¬†working. Passing a test is fine. Is it the right test to confirm that a requirements is fulfilled to deliver a capability?¬†
Each capability of the insurance provider network ERP system above is developed in a planned sequence to provide value in support of a business strategy. This order includes minimizing risk and maximizing opportunities. Each point where capabilities join the business can put these to work in generating value.
We need to know what DONE looks like, how we‚Äôre going to arrive at DONE on-time, on-budget, with the planned capabilities, what resources, funding, and work sequences we need, what risk handling and opportunity management can be performed, and how we‚Äôre going to measure tangible physical percent complete along the way.
These Principles enable 5 Practices and 5 Process to be implemented to increase the probability of project success. The details of all these can be found in¬†Performance-Based Project Management(sm).Related articles The "Real" Root Cause of IT Project Failure Performance Based Management
I have a new column up on project management.com. It’s called Debugging Your Geographically Distributed Agile Team. (You have to register to read it. Registration is free.)
You can do agile with geographically distributed teams. You might not be able to do Scrum. You have other choices of approaches.
Helping a team form is tough. This article, which is true, shows how tough it can be.
Do you have similar experiences? Different experiences? Let me know. I’d love to hear from you.
When I utter a minor annoyance about Excel on Twitter, half a dozen people tell me I “should” use some spreadsheet software in the cloud, and never any Microsoft stuff.
When I vent my frustration about Spotify, there are bound to be some followers who tell me I “should” use Pandora, Google Play, or some other competitor.
When I tell people my Nexus phone has an issue, there are ALWAYS smug Apple fanboys telling me I “should” use the amazing Apple stuff, not a crappy Android phone.
All these people seem to make the assumption that I am either too ignorant or too lazy to pick the tool that’s best for me. Apparently, in their eyes, I haven’t yet figured out which is “the best choice”.
But I’m not stupid, and I’m not lazy.
It's not you money, behave apprioriately.
When asked to develop software in exchange for money - this is leaglly called¬†work for hire - we have an obligation to have some notion of the final cost. If not, we're likley working a¬†staff augmentation and not doing¬†work for hire. So let's assume we are on a WFH engagement. Knowing something about the final cost starts with estimating that cost. This estimate says its name - it's an estimate. It's not a firm price. It's not even a firm anything. It's an estimate.
This estimate can come in several forms
The answer to both of these approaches comes from making estimates. Estimates of cost and schedule. Estimates of capacity for work. The process for making these estimates is called ¬†Basis of Estimate and ¬†usually starts with an ¬†anchoring nbsp;process.¬†
By anchoring it means making the estimate from something that can be used as a reference. It's been done before, there is a model of what ¬†could ¬†be done. Some reference class. This anchoring process is then followed by an ¬†adjustment process. Adjustments can come in a short time, or over a longer time. But the anchoring and adjustment paradigm is well developed.
One research study has shown
One way to make judgments under uncertainty is to anchor on information that comes to mind and adjust until a plausible estimate is reached. This anchoring-and-adjustment heuristic is assumed to underlie many intuitive judgments, and insufficient adjustment is commonly invoked to explain judgmental biases. However, despite extensive research on anchoring effects, evidence for adjustment-based anchoring biases has only recently been provided, and the causes of insufficient adjustment remain unclear.¬†
Anchoring and adjustment is well studied in behaviour finance - why people make financiual decsisions that they do. Anchoring and adjustment is also well studied in estimating starting with Oil & Gas estimates of reserves to estimating public works projects. A complete litertaure search can be found from Google of course.
But estimates needed for making business and techncial decisions must take this research into consideration is they are to be successful. ¬†For cost and schedule estimates the best place to start is past performance. Here's an orginal drawing of Flybjerg's¬†Reference Class Forecasting process flow. Google will find you all his work as well. Many about infrastructure and some about IT.
When it is mentioned¬†we haven't done this before so we have no reference classes, we have to pause and think. Is this a trueGreen Field¬†project. Technology that has actually never beed done before is rare in the IT world. If this project is truly without precedent, it's likely an R&D project and need to be planned much differently.
So assuming this is not an R&D project, what can we do about creating estimates when we have little past performance? There are many tools available, some free, to start the estimating process. To produce an¬†anchor estimate, we can start to refine before the project starts, or even after the project starts.¬†
There are three types of activities that paerticipate in the estimating process
So when we hear¬†estimating is the smell of dysfunction and no dysfunctions are listed let alone any credible and¬†in use estimating processes, it's time to question the wisdom is assuming estimates are the problems with software projects.
So let's invert the conversation for a moment.
In the end it's the business that needs the estimates of the developers have decided they are not useful. It's not the developers money - if it is no one cares how they spend it. The business has a obligation to the shareholders, investors, the funding agency, to have some understanding of what the cost for the products or services will be when they are done.Related articles How To and How Not To Make Credible Estimates of Cost and Schedule Facts and Fallacies of Estimating Software Cost and Schedule It's an Estimating Problem not A Problem with Estimating 8 Reasons Why Estimates Are Too Low The Value of Making An Estimate
Last year I was in a discussion with the CEO and a dozen top managers of a mobile apps developer in Shanghai, China. The company was very successful and was trying to be more agile, but also struggling with their rapid growth at the same time. The managers told me their interpretation of being agile was to deliver new software faster to their customers.
Now that we know our positive inquiry into an organization is best initiated with powerful questions, it is useful to learn a bit more about developing and catalyzing our dialogues. A great analogy for storytelling in working environments is Improvisational Theatre (or Improv for short). It is a form of theatre where little or nothing is planned ahead, and every performer on stage works with whatever is created at the moment.
The AMACOM Book¬†Performance-Based Project Management has a blog post from the publisher.
Knowing that we should inquire into an organization in a positive way (see my post about Appreciative Inquiry), it is useful to know what kind of questions we should ask. To learn more about this we can turn our attention to the concept of Powerful Questions.
A powerful question stimulates curiosity and reflection in a conversation, it leads the participants toward creativity, energy, and forward movement, it helps to channel attention and focus, and it has a tendency to invite further questions. My own very first powerful question, satisfying all these criteria, would be, ‚ÄúHow can we make our questions more powerful?‚ÄĚ
It's always good to have a Plan B. And all Scrum teams do--it's called an abnormal termination.
An abnormal termination is essentially blowing up the sprint and starting a new sprint instead. An abnormal termination is most frequently the result of a dramatic shift in business priorities--something previously considered important is no longer important, or something even more important is discovered.
But an abnormal termination can often be called if the team gets partway into a sprint and discovers that the work is going to take much longer than they'd anticipated in sprint planning. Sometimes a few days of experience with a new technology or in an old part of the code reveals that implementing something will take a lot more effort than previously thought--so much more, in fact, that the product owner may not want the functionality at its new cost.
A question I've skirted around in writing the preceding is: Who decides if an abnormal termination should be invoked?
To me the answer is very clear, but there is a lot of debate about this among Scrum trainers. My opinion is that the product owner makes the call. However, many people say it should be the ScrumMaster. Let's look very practically at why it cannot be the ScrumMaster who makes the decision.
Suppose a ScrumMaster and product owner are at odds over abnormally terminating, with the ScrumMaster in favor of it. If we decide that ScrumMasters are the ones empowered to make the decision, this sprint will be abnormally terminated. The first thing a team does after any abnormal termination is plan a new sprint.
The planning meeting for the new sprint will begin--as all sprint planning meetings do--by asking the product owner what should be worked on. And the product owner will reply, "Exactly what you were working on 10 minutes ago, before the ScrumMaster called for an abnormal termination."
And there's the problem: A Scrum team works on what the product owner wants. If a Scrum rule gives the ScrumMaster the right to abnormally terminate, a product owner who disagrees with that decision can nullify the abnormal termination by having the team work in the "new" sprint on exactly what they were working on in the abnormally terminated sprint.
So giving authority over the decision to abnormally terminate to ScrumMasters doesn't work. I completely understand the appeal. It makes absolute sense until thinking through the implications, and then we realize it can't work. The decision to abnormally terminate must be given to product owners.
In wrapping up, though, I want to point out that authority over this decision is a bit theoretical. In practice, I've never seen a situation where a product owner, ScrumMaster, and team disagreed over abnormally terminating. Sure, it might take some argument and discussion to create consensus, but I've never seen a situation where the product owner, ScrumMaster, and team cannot come to agreement and need a dispute resolved by an authoritarian decision-maker.