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!
Everyone is entitled to his own opinion, but not his own facts.‚ÄĒ Daniel Patrick Moynihan
When engaging in exchanges about complex topics like cost, schedule, and technical performance management, I always get a smile when someone says¬†oh that problem can be solved with this simple approach. Or¬†I bet that organization has no motivation what so every to solve the problem.¬†
Then the next quote is applicable...
For every complex problem there is an answer that is clear, simple, and wrong. ‚ÄĒ H. L. Mencken
Solving complex problems is hard, stating there are simple solutions without having worked on complex problems is easy.Related articles Complex Problems Require Better Solutions The Three Elements of Project Work and Their Estimates The Power of Misattributed and Misquoted Quotes Is There Such a Thing As Making Decisions Without Knowing the Cost?
As far as the laws of mathematics refer to reality, they are not certain, as far as they are certain, they do not refer to reality.
‚ÄĒ Albert Einstein Sherwin, Ronald Paul (2014-08-17). In The Tao of Systems Engineering: An Engineer's Survival Guide (pp. 195-197). Ronald Paul Sherwin. Kindle Edition.
When ever you hear that we can't predict the future. Think again. We can always predict the future. The level of confidence of that future is what is in question.
When you hear estimating is¬†guessing. Think again. That person doesn't understand probability and statistics. When you hear we don't need to predict to make decisions, that person has very little at risk from that decision, since making decisions in the absence of knowing the possible loss ignores the principles of microeconomics of everyday life.
When ever you hear we don't need to estimate the outcomes of our decisions. Think again. We don't need to estimate those outcomes only if they are of low enough value that we don't care about the consequences of not knowing to some level of confidence what happens as a result of our decision. We're willing to wright off our loss if we're wrong.
When we hear any conjecture that involves mathematics that does not address the foundation of the mathematical principles of that discussion, remember Einstein, and also remember how to apply that advice in the specific domain and context of the question guided by Deming.
Management is Prediction¬†
Since management is prediction, knowing how to make predictions using statistical methods to produce a confidence interval about the probabilistic outcomes of those business decisions is part of management. When we want a sit at the table where management decisions are being made, knowing this and being able to add value to the decision process is the price of entry to that room. Otherwise we're labor sitting outside the room waiting for the decisions to be made.¬†
I came across a nice blog post from DelancyPlace about the navigation powers of birds.¬†
This bird was taken from Wale's to Venice Italy and released and found it's way home in 14 days. 930 miles, over mountains .
To be able to find their way home from an unfamiliar place, birds must carry a figurative map and compass in their brains.
The map tells them where they are, and the compass tells them which direction to fly, even when they are released with no frame of reference to their home loft.
Projects Are Not Birds
As project managers, what's our map and compass? How can we navigate from the start of the project to the end, even though we haven't been on this path before.¬†
How can we find our way Home?
We have a map. It starts with a Capabilities Based Plan. The CBP states what¬†Done looks like in units of measure meaningful to the decision makers. These units of measure are¬†Measures of Effectiveness and¬†Measures of Performance.
Measures of Effectiveness - are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions.
These measures speak to our¬†home and the attributes of the home. The¬†map that gets us ti home is the Integrated Master Plan. This shows the increasing maturity of the deliverables that implement the Measures of Performance and those Performance items that enable the project to produce the needed capabilities that are effectively accomplish the mission or fulfill the business need.¬†
This looks like a¬†map¬†for the increasing value delivery for an insurance company. The map shows the path or actually paths to¬†home. Home is the ability to generate value from the exchange of money to develop the software.Golden Ratio Managing In The Presence Uncertainty Impact Mapping and Integrated Master Planning We Can Know the Business Value of What We Build All Project Work is Probabilistic Work 5 Questions That Need Answers for Project Success
"All the mathematical sciences are founded on relations between physical laws and laws of numbers, so that the aim of exact science is to reduce the problems of nature to the determination of quantities by operations with numbers."
‚ÄĒ James Clerk Maxwell, On Faraday's Lines of Force, 1856
Along with the quote of Daniel Boorstin's,¬†The greatest¬†obstacle to discovery is not ignorance ‚Äď it is the illusion of knowledge. Boorstin was the Librarian of Congress. One of his other quotes was once the subtitle of this blog¬†I Write to Discover What I Think.
And here's what I think about the predictive nature of managing projects. If we don't know how to estimate the impacts of our decisions on the future outcomes of those decisions, we have the illusion of knowledge, when in fact we have no knowledge.
There is a popular myth, that estimating the future outcomes of our present day decisions is somehow voodoo, guessing, making things up, and having our management treat them as commitments. It's clear we didn't pay attention in the probability and statistics class. Or worse yet, we have intentionally ignored what we did learn in that probability and statistics class. Thinking naively or with intent ignoring the probabilistic nature of all project work.
All variables in project work are random variables. These variables are almost always coupled to each other in some way, usually a non-linear way. Fix one variable, the other two are free to be variable. Fix two variables, the third variable is free. Fix all three, they still vary. This is the primary reason¬†margin is needed for project to have a credible chance of showing up on time, on budget, and on value. These variances are¬†Irreducible, meaning they will vary no matter what you do. Fixing Budget, only fixes the amount of money you've allocated to the project. It doesn't fix the cost to produce the value from the project, nor the time to produce that value.
So Why Do¬†We Estimate?
When ever possible we should use evidence in making decisions about project variables. Observing the behaviour of the variables in an attempt to see what they are doing, where they are going, what the next outcome might be.¬†
This is the basis of the OODA Loop. Boyd was an Air Force fighter pilot, and like Jeff Sutherland of agile fame, understood that¬†emerging situations are the norm in the skies of Vietnam, just like they are on projects.
The OODA loop is often popularized as four elements going around in a circle. The picture is the only diagram Boyd ever drew. Boyd's OODA Loop describes the details. The title of the chart above comes from one of our briefings for¬†Managing in the Presence of Uncertainty.¬†But the domain OODA is applicable is not restricted to DOD acquisition, but is applicable in any domain where money, time, and performance are¬†at risk.
Just to push a little harder, when you hear about Clausewitz and Tzu from agile coders, remember Boyd's comments when he spoke in public
‚ÄúDon‚Äôt be a member of Clausewitz‚Äôs school because a lot has happened since 1832,‚ÄĚ he would warn his audiences, ‚Äúand don‚Äôt be a member of Sun Tzu‚Äôs school because an awful lot has happened since 400 BC.‚ÄĚ
So just like those reference to 1968 reference to the¬†Software Crisis - a lot has happened since then.
So Here's a Simple Fact
Also often ignored by some wanting us to learn to decide without knowing the impacts of those decisions.
People learn better when they predict
Making an estimate about the future ‚ÄĒ predicting¬†on outcome or impact ‚ÄĒ forces us to think ahead about those very outcomes. Making an estimate causes us to examine more deeply the system we are observing and our engagement with that system and our reactions to the system. It causes us to question our understanding of the system as it is now ‚ÄĒ in ¬†its current state ‚ÄĒ and what we would like it to be in its future state. As well, by making estimating about future outcomes, we can learn more about our understanding of the management beliefs we hold as we examine the results of our predictions.
So like Deming tells us ...
Management is Prediction
Not making prediction's about the impact of our decisions, the processes affected by those decisions, like - cost, schedule, and technical performance - shown in the three legged picture above, ignores the principles of Deming. And when we do that, ...
... we're not managing how we spend other peoples money.
The only way this notion can't be called¬†bad management is if the amount of money at risk is low enough that those providing the money don't care if we waste it or not.Related articles Making Estimates For Your Project Require Discipline, Skill, and Experience Why We Must Learn to Estimate The OODA Loop - Insight into Strategic Thinking An Agile Estimating Story Averages Without Variances are Meaningless - Or Worse Misleading Four Critical Elements of Project Success The Value of Information What does a "broken OODA loop" look like? How To Create Confusion About Root Causes
In our domain there are three common root causes for program difficulties when the program overruns it's budget, shows up late, or the delivered product doesn't work as required
When I read about decision making processes like ...
I'm struck by the 3rd statement. Knowing something about the cost of a decision, the outcome of an investment, the risks, scope impact, progress reporting of future values requires you make estimates. Since all project variables are random variables that interact in random ways - technically non-stationary stochastic processes - knowing about the impacts from deciding anything using these variables means estimating the three core variables of all projects, shown below.
When I hear the suggestion that decisions can be made in the absence of those estimates, think of the Ostrich, ask the following:
If there ways to decide these things without estimates, let's hear them. Each of the three variables and each of their drivers is a random variable whose value is not know in the present, but can only be knowing with an estimate of it's future possible values.Resources for Moving Beyond the "Estimating Fallacy" Making Estimates For Your Project Require Discipline, Skill, and Experience Four Critical Elements of Project Success First Comes Theory, Then Comes Practice How to Deal With Complexity In Software Projects? Statistical Process Control The Basis of All Modern Control Systems Let's Stop Guessing and Learn How to Estimate The Value of Information Why is Statistical Thinking Hard?
Developers: We're spending money, consuming resources, producing outputs that the customer likes.¬†
Project Manager: I was more interested in what's our performance against¬†our planned spend, planned resource consumption, and planned outputs of value to the customer?¬†
Developers:¬†What do you mean, we didn't estimate any of that, we're managing this project with #NoEstimates. You know that new alternative to estimates for making decisions in software development. That is ways to make decisions with "No Estimates." of the impacts on the future of those estimates or of our work on the future cost, schedule, or technical performance. You know where we can use¬†Decision making frameworks for projects that do not require estimates, or apply¬†Investment models for software projects that do not require estimates, and have our project management methods for risk management, scope management, progress reporting, not require any of those annoying estimates. 'Cause we kinda suck at them anyway, so we just decided instead of learning how to estimate, we'll just not estimate and get back to coding.
Project Manager:¬†Oh, you mean that approach of managing other peoples money that violates the principles of software microeconomics with Open Loop Control - where¬†our organization can make business decisions on the allocation of our limited resources, without examining how those decisions effect the supply and demand of our resources. You do know about those resources? Like money, people, and time?
Developers: Yea, we don't need any that mumbo jumbo microeconomics that we all learned in school, since we didn't pay attention in that boring the statistics and probability class that tried to teach us that all variables on a project are actually random variables and we should to know something about their behaviour in the future if we're going have a hope in hell of ever managing this project in the presence of uncertainty about those values.
Project Manager: What's that smell?¬†Maybe we'd better start rearranging the deck chairs on our ship here real soon, cause I smell an Iceberg getting closer.
No project can be managed to successful closure in the absence of steering targets defined at periodic intervals for the expenditure of cost, schedule, and technical performance. Knowing what those steering targets should be requires estimating their values, then measures the actual values to develop the needed steering signal - the variance between plan and actual.
The only way out of the need to estimate those intermediate steering targets is to¬†straight line the budget, schedule, and needed technical performance - from start to end, then measure the actual performance.¬†
Like the intended route of the Titanic, our project does not proceed in a straight line, so that idea is a non-starter. And like the Titanic, our project cannot confuse the intended speed with the actual speed, just like we can't confuse the budget - the total planned crossing time - with the actual cost - the actual total crossing time.
Without those pesky intermediate targets to steer toward - those targets created by estimating the¬†needed cost, needed scheduled arrival date, and, needed capabilities on the needed date¬†for the needed cost. We're managing the project Open Loop, driving in a straight line. Never knowing what will pop up in front of our path.¬†
Say good bye to Kate Leonardo, you're gonna get wet.
‚Ä† Full attribution for the inspiration for this post comes from the very useful blog by Gene HughsonRelated articles Staying on Plan Means Closed Loop Control How Not To Make Decisions Using Bad Estimates Control Systems - Their Misuse and Abuse More Than Target Needed To Steer Toward Project Success Why Project Management is a Control System
The term¬†Systems Thinking is many times used in vague and unspecified ways to mean¬†think about the system and all will emerge in a way needed to produce value.¬†
Systems Thinking¬†is a term toosed around many times with little regard for what it actually means and its relationship to¬†Systems Engineering and¬†Engineered Systems.
But systems thinking is much more than that.¬†Systems thinking provides a rigorous way of integrating¬†people, purpose, process and performance and: ‚Ä†
‚Ä† ¬†"How Systems Thinking Contributes to Systems Engineering," INCOSEUK, Z7, Issue 1.0, March 2010.Related articles A Breathtaking Paper Positive Deviance
In the absence of a control system that provides feedback to the progress to plan, the project is just wandering around looking for what¬†Done looks like. The notion of emergent requirements is fine. The notion of emergent¬†capabilities is not.
If we don't know what capabilities are needed to fulfill the business plan or fulfill the mission need, then we're on a¬†Death March project. We don't know what value is being produced, when we will be done, or how much this will cost when we're done.
This is the role of the project control system. Without a control system there is no way to use feedback to¬†steer the project toward success.
Control systems from Glen Alleman So when we hear we can make decisions wihout estimating the impact of those decisions on the furture outcomes of the project, we'll know to call BS. First not knowing this impact on the decision making process violates the principle of Microeconomics and second there is no way to close the loop to generate a variance signal needed to¬†steer the project to success. Related articles Staying on Plan Means Closed Loop Control Concept of Operations First, then Capabilities, then Requirements Delivering Needed Capabilities What Do We Mean When We Say "Agile Community?" More Than Target Needed To Steer Toward Project Success Getting to done!
A Guiding Principle defines the key criteria for making decisions about the application of a project's Practices and Processes. The Principles provide the project with the foundation to test the practices and processes in pursuit of the project's goals in the most timely and cost-effective way while still meeting essential requirements of business outcomes or mission accomplishment.
In the absence of Principles, the Practices and Processes - while possible the rights one - have no way of being tested to assure they are producing actionable information for the management of the project.¬†
The common lament of¬†we could be spending time and effort doing something more useful, ignores the fact that those ¬†useful things need to be guided by a higher structure - a holistic structure - of exchanging cost for value. The questions should be¬†are the practices and processes we are applying to this project the proper ones to maximize the efficacy of our funding?
These five principles are the foundation of project success. Success means - in the simplist terms - On Time, On Cost, On Value. Time and Cost are easily defined, Value needs another layer for it to be connected with Time and Budget.
What is Strategy
One approach for Value to to connect the outcomes of the project with the¬†Strategy for the business or the mission.¬†Strategy is creating fit among a company‚Äôs activities. The success of a strategy depends on doing many things well ‚Äď not just a few. The things that are done well must operate within a close nit system. If there is no fit among the activities - in this post, the project management activities - there is no distinctive strategy and little to sustain the project management practices and processes. Project Management then reverts to the simpler task of overseeing independent functions. When this occurs operational effectiveness determines the relative performance of the project management activities and the results of the project itself.¬†
Improving operational effectiveness is a necessary part of management, but it is not strategy. In confusing the two, managers will be unintentionally backed into a way of thinking about competition that drives the business support processes (IT) away from the strategic support and toward the tactical improvement of operational effectiveness.
The concept of fit among functions is one of the oldest ideas in strategy. Gradually, it has been supplanted with new concepts of core competencies, critical resources and key success factors. Fit is far more critical to the success of the project management System.¬†Strategic fit among the project management Practices and Processes and the business processes in which the project is deployed is fundamental not only to competitive advantage but also to the sustainability of that advantage.¬†
This is the fundation of success for¬†Project Based Organizations
The mechnism for creating this¬†Fit is the Programmatic Architecture of the project. This architecture is the same term used for technical architecture. It is the¬†form of the project, in the same way it is the¬†form¬†of the product or service.
The Five Principles That Establish Programmatic Architecture
These Five Principles and their Practices are...
Principles and Practices of Performance-Based Project Management¬ģ from Glen Alleman Related articles What Is Strategy? Elements of Project Success Why Project Management is a Control System Creating Effective Mission Statements That Have Meaning and Function Performance Based Management Principles First, Then Practice Moving EVM from Reporting and Compliance to Managing for Success Project Maxims How To Make Decisions
SEI is focused on helping the DOD improve the development of software.
Here are Pod Casts of the Principles of Agile Development of software in the DOD
Awhile back I posted about Don't Do Stupid Things On Purpose (DDSTOP). This caused some comments about this being a very¬†Theory-X management approach. The notion of Don't Do Stupid Things on Purpose comes from observinig people DSTOP with other peoples money.
Many might say, people have to experiment, try thing out, test the waters. Yes this is true, but who pays for that testing, trying, experimenting? Is there budget for that in the project plan? May be that this is actually an experimental project and the whole point of the project is to¬†do stupid things on purpose to see what happens.¬†
I wonder if the experimental work being paid for by the customer were worded like that if it would sound so clever?
Here's some clarity and a few examples of DSTOP in recent years.
So is it Theory X to ask those working on the project and managing the project to stop and think about what they are doing, what decisions are being made - and assess the impact of those decisions? Or should those entrusted with the customers money just go¬†exploring, trying out ideas with the hope that something innovative will come out of it?
When we're assumed to be the stewards of other people's money, they should expect us to behave as those stewards. This means we make decision about the use of that time and treasure is ways that are informed by our experience, skills, and governance model. Doing otherwise means we're not the right people to be spending our customers money, or our customer has a lot of money to spend on us to become the right people they should have hired to spend their money.Related articles In Earned Value, Money Spent is Not a Measure of Progress! What Do We Mean When We Say "Agile Community?"
For most projects showing up on or near the planned need date, at or near the planned cost, and more or less with the planned capabilities is a good measure of success. Delivering capabilities late and over budget is usually not acceptable to those paying for our work.
So how do we do this? Simple actually.
We start with a Plan. Here's the approach to Planning and the resulting Plan.
The Plan tells us when we need the capabilities to produce the needed business value or accomplish the mission. The Plan is a strategy. This strategy¬†involves setting goals, determining actions to achieve the goals, and mobilizing resources to execute the actions. The strategy describes how the ends (goals) will be achieved by the means (resources) in units of measure meanigful to the decision makers.
Strategy creates fit among a firms activities. For Enterprise IT, this fit is defined by the relationships between the needed capabilities delivered by the project. The success of a strategy depends on doing many things well ‚ÄĒ not just a few.
The things that are done well must operate within a close nit system. If there is no fit among the activities, there is no distinctive strategy and little to sustain the strategic deployment process. Management then reverts to the simpler task of overseeing independent functions.
When this occurs operational effectiveness determines the relative performance of the organization. ["What is Strategy,‚ÄĚ M. E. Porter, Harvard Business Review, Volume 74, Number 6, pp. 61‚Äď78.]
As successful Plan describes the order of delivery of value in exchange for cost, the inter-dependencies between these¬†value producing items, and the synergistic outcomes from these¬†value producing¬†items working together to meet the strategy.
With the Plan in hand, we can ask and answer the following questions:
This Post Answers the Last Question
The example below is from our cycling group. The principles are the same for projects. We have a desired outcome in terms of date, cost, and technical performance. These desired outcomes have some end goal. A budget, a¬†go live¬†date, a set of features or capabilities needed to fulfill the business case.¬†
Along the way we need to take corrective actions when we see we are falling behind.¬†
How did we know we were falling behind? Because we have a desired performance at points along the way, that we compare our actual performance to. The difference between our actual performance and the desired performance, creates an "error signal" we can use to make adjustments.
Out thermostat does this, our speed control on our car does this, the Close Loop Control systems used for managing our project does this. So replaces the cycling example with writing software for money. The Peleton for the desired performance of our work. In the presentation below, ignore the guy in the Yellow Jersey at the end. Turns out he's a Dopper and an all around bad person to his fellow riders and fans.
The simple problem of schedule performance indices from Glen Alleman So let's look at a project example using the analogy of our cycling group, ignoring Lance.
This example can be related to a project.¬†
This is Close Loop Control
You're cruise control does this about every 10 milliseconds. You Nest thermostat does this slower, but still less than a minute. To know how often you need to sample your progress against plan, answer this question
How long are you willing to wait before you find out you're late? Sample at ¬Ĺ that time.
This is called the Nyquist Rate, one of the starting point for all the process control software I wrote in my youner days for flying and swimming machines. But it's a good question to ask on all projects as well.Related articles Is There Such a Thing As Making Decisions Without Knowing the Cost? Time to Revisit The Risk Discussion Can Enterprise Agile Be Bottom Up? Process Improvement In A Complex World Why Project Management is a Control System If you want to pretent you're a Pro, then starting acting like one Control Systems - Their Misuse and Abuse Seven Immutable Activities of Project Success More Than Target Needed To Steer Toward Project Success
"You cannot have an execution culture without robust dialog - one that brings reality to the surface through openness, candor, and informality.
This is called "truth over harmony"
in¬†Execution: The Discipline of Getting Things Done, Larry Bossidy and Ram CharanRelated articles Practices without Principles Does Not Scale The Need for Strategy How to Manage in the Presence of Uncertainty
There is a suggestion that only the final target of a project's performance is needed to steer toward success. This target can be budget, a finish date, the number of stories or story points in an agile software project. With the target and the measure of performance to date, collected from the measures at each sample point, there is still a missing piece needed to guide the project.
With the target and the samples, no error signal is available to make intermediate corrections to arrive¬†on target.¬†With the target alone, any variances in cost, schedule, or techncial performance can only be discovered when the project arrives at the end. With the target alone, this is an Open Loop control system.
Control systems from Glen Alleman Pages 27 and 28 show the difference between Open Loop control and Closed Loop control of a notional software development project using stories as the unit of measure. In the figure below (page 27), the cummulative performance of stories is collected from the individual performance of stories over the projects duration. The target stories - ¬†or budget, or some other measure - is the¬†final target. But along the way, there is no measure of¬†are we going to make it at this rate?¬† An Open Loop Control System
Irreducible Uncertainty can only be¬†handled with Margin. Cost margin, schedule margin, technical margin. This is the type of margin you use when you drive to work. The GPS Navigation system says it 23 ninutes to the office. It's NEVER 23 minutes to the office. Something always interferes with our¬†progress.
Reducible Uncertainty is handled in two way. Spending money to¬†buydown the risk that results from this uncertainty. Management Reserve (budget reserve and schedule contingency) to be used whenm soemthnig goes wrong to pay for the fix when the uncertainty turns into reality.
The next figure (page 28) shows how to manage in the presence of these ¬†uncertainties, by measuring actual performance against the¬†desired performance at each step along the way.
In this figure, we measure at each¬†assessment point the progress of the project against the¬†desired progress - the¬†planned progress,¬†the¬†needed progress. This planned, desired, or needed progress is developed by looking at the future effort, duration, risk, uncertainty - the stochastic processes that drive the project - and determining¬†what should be the progress at this point in time to reach our target on or before the need date, at or below the needed cost, and with the needed confidence that the technical capabilities can be delivered along the way? ¬†This is closed loop control.
The planned performance, the needed performance, the desired performance is developed early in the project. Maybe on day one, more likely after actual performance has been assessed to¬†calibrate future performance. This is called¬†Reference Class Forecasting. With this information¬†estimates of the needed performance can then be used to establish¬†steering targets along the way to completing the project. These intermediate references - or steering - points provide feedback along the way toward the goal. They provide the¬†error signal needed to keep the project on track. They are the basis of Closed Loop control.¬†
In the US, many highways have¬†rumble strips cut into the asphalt¬†to¬†signal that you are nearing the edge of the road on the right. They make a loud noise that tells you -¬†hey get back in the lane, otherwise you're going to end up in the ditch.
This is the purpose of the intermediate¬†steering targets for the project. When the variance between planned and actual exceeds a defined threshold, this says¬†hey, you're not going to make it to the end on time, on budget, or with your needed capabilities if you keep going like this.
Kent Beck's quote is...
Optimism is the disease of software development. Feedback is the cure.
This feedback must have a reference to compare against if it is to be of any value in¬†steering the project to a successful completion. Knowing it's going to be late, over budget, and doesn't work when we arrive at late, over budget, and not working is of little help to the passengers of the project.Related articles Indicators of project performance provide us with "Steering Inputs" Seven Immutable Activities of Project Success Why Project Management is a Control System The Use and Misuse of Little's Law and Central Limit Theorem in Agile Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Slicing Work Into Small Pieces How To Assure Your Project Will Fail Control Systems - Their Misuse and Abuse Getting to done!
Strategy without tactics is the slowest route to victory
Tactics without strategy is the noise before defeat.
‚ÄĒ Sun Tzu
Every time you hear about some conjectured great new idea on how to solve a vexing problem, ask what's the actual problem to be solved, what's the root cause of that problem, what domain is this problem found in and what domain is this problem already solved in, and finally ask¬†what's your strategy for assuring that your solution will actually result in a solution that doesn't break something else, violate a business principle, and create an obligation that you didn't think of because you were too busy admiring your cleaver idea?
The notion of self-directed development teams has a range of applicable domains. Much of the rancor around agile development these days is about how to apply the core principles of agile software development. Do we need estimates? What's the role of business process in the development life cycle? How are capabilities and requirements elicited? Who has what decision rights for what decisions? How can we made these decisions and what information is needed in order to make the decisions?
Guy Strelitz's post has got me thinking about the spectrum of the world called¬†agile. Here's my take on his diagram. Working in a domain where we're spending other people's money, lots of other people's money, the¬†Winging it approach is simply not accepted. The Kanban approach doesn't either because the inter-dependencies between the backlog items it tight, so picking the next thing off the blog log based on business value may not be possible, since some pre-condition may need to be fulfilled before a higher value item can be started. Softwarr development is not production in our domain. Kanban is a production flow management system, no matter how twisted the logic of the Kanban software advocates make it out to be.
Scrum is a powerful approach to emergent requirements. With those requirements anchored to¬†Needed Capabilities.¬†Capabilities that all have to be in place for the system to be called ready for¬†Go Live. Some more formality is needed as governance and regulatory paradigms are encountered.
Finally we arrive at the Enterprise model of software development. The firm depends on the software system for revenue. PayPal depends on the system for revenue, but not in the way an insurance company does. Or a gas pipeline process control system does.¬†
But at the same time, agile can contribute to not only increasing the probability of project success, but also deal with the emerging requirements traceable to the need capabilities.
Process is King
So not to the point. In that agile enterprise paradigm, the mission critical aspects of the software system demand assuance that the released software is not only¬†Fit for Purpose and it is¬†Fit for Use.¬†That is, the software does what it is supposed to do, in a way it is supposed to work.¬†
One of the critically important process of any enterprise software system is the Change Control (CC) and Release Management (RM) process. The software system is a corporate asset and must be treated as such. This asset is carried on the General Ledger as an asset. A capital investment, governed by the rules of accounting for capital assets. That's essentially the definition of¬†enterprise.¬†
In this enterprise paradigm, the control of these assets starts with CC and RM. Here's a high level flow of how this corporate asset is managed. In this example development occurs in the lower left. The CC and RM process is post development. This development business rhythm can be weekly, monthly, possibly even daily. But once the software is ready for release to production, this is a possible process.¬†
The key here is¬†separation of concerns. The developers of enterprise software our not the approvers of the release of that software, nor are they the involved in the QA, UAT, and Performance Assessment of that software.
So this is the separation from the activities on the left of the top diagram to those on the right. When some suggests a new idea, or has read a book about a new idea and wants to discuss it - ask where on the spectrum of the top diagram they work, where they think their idea would fit in.
In the End
Without first starting with a domain, context, framing assumptions around governance, established decision rights any suggested process has no home for being tested against reality.Related articles Performance Based Management Agile Project Management Kanban is the New Scrum Can Enterprise Agile Be Bottom Up? Agile Paradigm The Myth of Incremental Development
No data hath meaning apart from their context. ~unknownRelated articles How to Forecast the Future Failure is NOT an Option!
A point of view can be a dangerous luxury when substituted for insight and¬†understanding.
In a recent Skype conversation around agile, estimating, Little's Law and the #NoEstimate hashtag, the term¬†agile community was used. My first reaction was¬†whose agile community? The community of sole contributors? The community of $1B weapons systems and all in between?
My thoughts go back to the presentation below. There is a spectrum of project management processes built around agile. My experience starts with 5. Literally 5, since I have time in that aircraft. My software development management experience goes all the way to the end. And aircraft experience to 25.
Paradigm of agile project management from Glen Alleman So when I hear¬†the agile community which one is it? The recent Agile Conference looks like it was attended by¬†sole contributors or¬†small team members. But there are other agile communities where I work
And guideance for deploying agile
So Now Back To The Core Issues
If you're a sole contributor and have a customer sitting near by, estimating you cost, schedule, and technology outcomes is likely of little value. If you're in the other end, say the flight avionics systems for the 777, then the level of rigor, formality, reporting is different. Both use agile. Not all in the same way, but both write code using the principles of agile development
No credble management process would or should object to these principles and practices. Do to so means Doing Stupid Things on Purpose.¬†So many of the motivators for not doing something are actually bad management.¬†Let's not estimate, because estimates are misused is my favorite DDSTOP example.
Here's an example of how to¬†connect the dots between these principles and practices in a more formal business management process - in this case Earned Value Management.¬†
Ev+agile=success (final v2) from Glen Alleman
So when we hear the agile community and those representing the¬†agile community which community is that?¬†
There is a crass American term used in our domain.
When you see dysfunction, see something you don't understand, or see something that is counter to your paradigm - Follow the Money.
This is the basis of microeconomics of writing software for money. What is considered a waste or even¬†evil in one domain is a critical success factor in another domain.
Ask some simple questions to establish this domain:
In The End
Can we have any meanigful disucssion about any topic in the absence of a domain and context? Especially when that topic is driven by Value at Risk, Governance, and business processes?
I'd say it is incumbent on those making a suggestion for example
To show in what domain this statement is applicable, how we would recognize its applicability outside the the domain of those making the suggestion, how we could test the suggestion to see if it is applicable, and most important what are the conditions that allow the suggestion to work in those domains?¬†