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!
There's a meme going around in some parts of¬†agile that management is inhumane. This is an extreme view of course, likely informed by anecdotal experience with Bad Management, or worse lack of actual management experience.
Managing in the presence of Agile is not the same as managing in traditional domains. The platitude is Stewardship, but that has little actionable outcomes needed to move the work efforts along toward getting value delivered to customers in exchange for money and time.
One view of¬†management in Agile can be informed by Governance of the work efforts. Here's a version of Governance, from "Agile Governance Theory: conceptual development,‚ÄĚ Alexandre J. H. de O. Luna, Philippe Kruchten , and Hermano Moura.
¬†Related articles Agile Software Development in the DOD Deadlines Always Matter Risk Management is How Adults Manage Projects Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
It is common to use the phrase¬†
If we feel pain X. Let's explore solutions? & possibly "Solutions A & B might be a starting point?"
This approach seeks a solution to the¬†symptom not a solution to the¬†problem
This is the false notion used by #NoEstimates advocates, with the conjecture that¬†estimates are the smell of dysfunction. Without stating what the¬†dysfunction is, then¬†makes the statement that Not Estimating will fix it. So in the end nothing is fixed, the dysfunction is not identified, the Root Cause is not identified, and therefore is it not possible to claim Not Estimating will fix anything, for the simple fact that the problem has not been defined. It's a solution - at doubtful solution - looking for an undefined problem to solve. A lose-lose situation.¬†
So don't fall for the¬†fallacy of the smell and most of all don't fall for the fallacy,¬†we're just exploring and I have no recommended solutions.
The only way to provide an effective solution to any problem, is to determine the Root Cause to that problem and confirm that the proposed solution will in fact prevent the problem from recurring. If you want to learn how to do this - and not follow the naive 5 Whys - read this. Then if you're working in a domain that does Root Cause analysis buy the Reality Charting tool. It's saved us from catastrophe several times.¬†
¬†Related articles The Dysfunctional Approach to Using "5 Whys" Are Estimates Really The Smell of Dysfunction? Root Cause of Project Failure Turning Editorials into Root Cause Analysis Estimating and Making Decisions in Presence of Uncertainty The False Notion of "we haven't seen this before" When the Solution to Bad Management is a Bad Solution
The Project Breathalyzer provides question for the Program Manager to assess of the project is¬†fit to be on the road. If the Program Manager cannot answer these questions about the current status, or answers in the¬†negative , then the project is subject to a critical review.
This concept comes from the Software Program Managers Network, and the work of Norm Brown in 1997. The SPMN was a non profit organization, with funding canceled in 1002. but is now¬†for Profit.¬†The questions can from the Airlie Software Council of experts after the failure of the Airane¬†5 launch vehicle failure¬†attributed to a Software Design Flaw.
¬†Related articles Failure is not an Option Fit for Purpose, Fit for Use Assessing Value Produced By Investments
This year in June, publisher John Wiley & Sons will release Managing for Happiness, the updated version of my very successful #Workout book. To celebrate this, I have a special offer for event organizers in the USA and Canada.
For an appearance at any event (either public or in-company) during my book tour, I offer 100 copies of my new book for free, and for anything above that number, I offer a 50% discount from the catalog price (USD 35). This only applies to events taking place during my book tour in North America from June 30 to August 31.
You can see my public fees here: http://jurgenappelo.com/fees/
For private/in-company events, I request flexibility of the event date. My itinerary will be very complicated. I aim to maximize the number of people I can meet in the same region and time span, and at the same time I must minimize the time wasted on travel.
I'm coming to Austin!
I've wanted to offer training courses in Austin for a while, and the time is right. I'll be there for a Certified Scrum Master course on October 3-4, 2016. The course will be at the Doubletree Northwest Austin Arboretum.
We've got an early bird discount running. Register by September 5 and save $100.
Groups of three or more can also save $100 per person. Groups of 10 or more save $200 per person.
The last time I was in Austin, I was walking around downtown and stopped in a little bar because I liked the band I could hear as I walked by.
I sat down, and by the second song, I realized that blues legend Pinetop Perkins was sitting in on piano with the band. He was in his 90s by then and was still amazing to see.
Seeing Pinetop Perkins perform, meeting him and getting his autograph was an amazing experience.
I hope to have just as much fun in Austin this October. And I hope you'll join me for my first public Certified Scrum Master class there.Where to Next?
I’m looking to add another city or two into my usual rotation. If you have a suggestion, please let me know in the comments below or by emailing us.
A burst of Tweets¬†of¬†No Estimates fixes these problems came across Twitter this morning. I won't repeat who they are attributed to, to protect the guilty. But here's a core concept that is totally missing from not only the No Estimates conjecture, but from most every discussion, where a solution is proposed before the problem has been defined. Let's start with Dean Gano's introduction to Apollo Root Cause Analysis, which is a George Bernard Shaw quote so fitting to the discussion of ignoring the root cause and going straight for a solution to the symptom - in many cases an¬†Unnamed symptom.
Ignorance is a most wonderful thing.
It facilitates magic.
It allows the masses to be led.
It provides answers when there are none.
It allows happiness in the presence of danger.
All this while, the pursuit of knowledge can only destroy the illusion.
Is it any wonder mankind chooses ignorance?
~ George Bernard Shaw
So until the symptom is named - and¬†the smell of¬†dysfunction¬†is not a symptom. Until the search for the root cause of the symptom, and applying the 5 whys to an unnamed symptom is applied properly, the root cause will be undetermined. Without discovering the¬†root cause, there will be no¬†chance that any suggested processes, method, or change in behaviors will have any impact on the symptom - named or unnamed.
To see how the statement Estimating is the smell of Dysfunction is seriously flawed and the¬†approach of asking 5 Whys equally flawed, please read¬†RealityCharting¬ģ Seven¬†Steps¬†to Effective¬†Problem-Solving and¬†Strategies¬†for Personal Success, Dean L. Gano
The Seven Steps are:
When one or all of these steps are missing, anyone conjecturing their solution - or worse conjecturing¬†we're just exploring for the solution - that conjectured solution is NOT a solution, it's just unsubstantiated conjecture.¬†
One of my favorite quotes when hearing unsubstantiated claims is this:
How many legs does a dog have if you call the tail a leg? Four. Calling a tail a leg¬†doesn't make it a leg - Abraham Lincoln
Calling estimating the smell of¬†Dysfunction¬†doesn't make estimating the smell of dysfunction. You've only identified an unsubstantiated symptom. Until you¬†have found the cause and certainly can't suggest Not estimating is the corrective action.
When we have willful ignorance of the Microeconomics of decision making, managerial finance as a governance process for managing other people's money, denial that the uncertainties of projects - aleatory and epistemic uncertainty - can¬†be addressed without estimates of the impact of those uncertainties. Then we are no better than the people mentioned in George Bernard Shaw's quote above. And we are doomed to repeating the symptoms that result from ignoring these principles of¬†managing in the presence of uncertainty.¬†
¬†Related articles The Dysfunctional Approach to Using "5 Whys" Carl Sagan's BS Detector Myth's Abound Making Conjectures Without Testable Outcomes Are Estimates Really The Smell of Dysfunction? Architecture -Center ERP Systems in the Manufacturing Domain The Fallacy of the Planning Fallacy IT Risk Management
There a popular notions in the agile development world that authors like Hayek and Taleb speak to how software development works. Let's look at one example. You¬†Can‚Äôt Understand Agile Without Understanding Hayek. Let's look at Hayek's paper. "The Use of Knowledge in Society," F. A. Hayek,¬†The American Economic Review, Vol. 35, No. 4, September 1945, pp. 519-530.
Let's look at the thesis of Hayek in light of software development and the decisions that must be made when spending other people's money in the presence of uncertainty. Below is from the paper, but download the paper and read the whole thesis. Hayek was a social scientist. He was not a program manager of engineered to order software intensive system of systems. His ideas have not held up well. Hayek and Modern Macroeconomics. So I'd suggest not spending your customers money before doing some more research.
What is the problem we wish to solve when we try to construct a¬†rational economic order?¬†
On certain familiar assumptions the answer is simple enough. If we¬†possess all the relevant information, if we can start out from a given¬†system of preferences and if we command complete knowledge of¬†available means, the problem which remains is purely one of logic.¬†That is, the answer to the question of what is the best use of the¬†available means is implicit in our assumptions. The conditions which¬†the solution of this optimum problem must satisfy have been fully¬†worked out and can be stated best in mathematical form: put at their¬†briefest, they are that the marginal rates of substitution between any¬†two commodities or factors must be the same in all their different uses.
This, however, is emphatically not the economic problem which¬†society faces. And the economic calculus which we have developed to¬†solve this logical problem, though an important step toward the solution¬†of the economic problem of society, does not yet provide an¬†answer to it. The reason for this is that the "data" from which the¬†economic calculus starts are never for the whole society "given" to a¬†single mind which could work out the implications, and can never be¬†so given.
The peculiar character of the problem of a rational economic order¬†is determined precisely by the fact that the knowledge of the circumstances¬†of which we must make use never exists in concentrated or¬†integrated form, but solely as the dispersed bits of incomplete and¬†frequently contradictory knowledge which all the separate individuals¬†possess. The economic problem of society is thus not merely a problem¬†of how to allocate "given" resources-if "given" is taken to mean¬†given to a single mind which deliberately solves the problem set by¬†these "data." It is rather a problem of how to secure the best use of¬†resources known to any of the members of society, for ends whose¬†relative importance only these individuals know. Or, to put it briefly,¬†it is a problem of the utilization of knowledge not given to anyone¬†in its totality.
First some questions:
Is there vague and unfolding knowledge, driven by externalities, of what the project should be accomplishing, with uncertain and variable funding? With members of the project team having differing views of the outcomes from those paying for the project?
If so, the project has already failed, the members of the project team are on a death march (Yourdan) and should start looking for work elsewhere, before it gets canceled.
So like the¬†other misrepresentations of seminal works, the agile community adopts this¬†attractive ideas with little or no consideration or understanding of their principles. And most of all it those principles are applicable to software development or if those principles are even applicable in today's understanding of who the world works. Macroeconomics is the¬†dismal science - treat it as such when developing software.
So whenever there is some conjecture that someone outside the software development domain¬†has a principle that can be applied to Agile, test that idea first before spending any time and money acting on it. Especially if that time and money is not yours.Related articles IT Risk Management Risk Management is How Adults Manage Projects Risk Management is How Adults Manage Projects Qualitative Risk Management and Quantitative Risk Management Domain and Context Are King, Then Comes Process and Experience Two Books in the Spectrum of Software Development What is a Team? Five Estimating Pathologies and Their Corrective Actions How Think Like a Rocket Scientist - Irreducible Complexity Why Guessing is not Estimating and Estimating is not Guessing
The end of an agile sprint or iteration should be a relatively lightweight occasion. After all, it’s something that will be done at least once a month, and often much more frequently than that. So, it’s important that we don’t burden a team with any more process ceremony than necessary. Often a very simple sprint review is all that is needed.A Sprint Summary Document
Sometimes, though, as a ScrumMaster, I like to produce a sprint summary document. This short document contains very brief details of what work was done during the sprint, when the sprint was, who was on the team, any key decisions that were made during the sprint, and perhaps a few important metrics.Audience
There are two target audiences for a sprint summary document. The first is any interested outsiders. This could include the VP of development, executives, stakeholders, department management, other teams and so on.
The second audience is future versions of the agile team itself. I’ve been in many situations where a team wanted to look back in time. A sprint summary can provide that view. Let me provide an example.
This one team was feeling depressed about how few automated tests they were writing. In the prior sprint, they’d added only about 200 total automated tests, which they knew was too low for what their system needed.
Because their ScrumMaster had been producing sprint summary documents, I retrieved a summary from six months earlier.
I shared with the team that they had once been struggling to write even one or two automated tests per sprint. (They were refactoring code so that it could support automated testing and were learning the concepts and tools.)
By sharing this information with the team from their sprint summary, I helped them realize how far they had come. Yes, they still had a long way to go, but they had already started moving the mountain, and momentum was now on their side.
Without a sprint summary document to provide exact facts, I would have had to rely on memory or had to piece things together by digging through the source code repository.Content
While the specific contents of a sprint summary document are entirely up to you, there are a few things I’ve found to be helpful. These include ...Context
Simply list the start and end date of the sprint and the number of working days in the sprint. I also list the people who were on the team, how many days each was expected to be available and the approximate number of days each was actually available.
The number of days a team member worked may differ from the planned days available because of illness or because the person was pulled onto another project mid-sprint, for example.Metrics
Include any metrics here that are important to the ScrumMaster, stakeholders or the team. Keep it simple. I tend to include a graph or table of the velocity of the last 10 or so sprints (whatever horizon seems reasonable for your team). If you’re using burndown charts, include those.
You might also consider including things like the number of defects found or fixed, the number of automated tests added, code coverage, the number of builds deployed and so on.
If you are building the software for a client and need to report on cost, include things like billable hours and cost in this section.
But keep it simple.Contents and Assessment
In this section, include a list of each product backlog item the team planned to do. Indicate whether the item was finished or not. And if the team estimates product backlog items (for example, in story points), include the size of the story.
Also include any additional notes from the sprint review on relevant decisions.
Finally, consider including a list of actions decided as a result of the sprint retrospective. This is entirely optional and be sure the team is OK including this. They may or may not be, depending on the audience for the sprint summary document.Keep The Effort Short
Once you’ve produced an initial sprint summary document, you should find creating a new one for each sprint quite simple. My guideline is that it should not take more than 15 minutes per sprint to produce. If you keep the metrics section simple, this is quite feasible.
I’ve included a sample sprint summary document you can use to get started.What Are You Tracking?
In the comments below, please share your thoughts. What do you think of the things I like to track? What do you track already? Or what will you begin tracking now after reading this?
There was a Twitter post mentioning Russell Ackoff YouTube about¬†systems.
A system is never the sum of its parts, it's the product of their interactions.
This is a good start,¬†but it needs to produce¬†actionable outcomes, not just principles, but practices and processes. How do you define, design, represent, assess, analyze, and manage these interactions. The notion that systems are somehow unmanageable is fine in some domains. Finance, social, political. But in technical systems -¬†engineered¬†technical systems - the system has to work when commanded to do so.¬†Much of Ackoff's principles are the basis of practices and processes that assure this happens.¬†
I come to this¬†systems domain from the Software Intensive System of Systems paradigm. This is where systems are designed, tested, verified, operated, maintained, enhanced, repaired, and replaced with other system. The¬†touchy feely view of systems does not belong here. This is the domain of Systems Engineering, that many times is based on the principles of Ackoff and others like him.
When I hear about complex software systems and how difficult they are, and how undesirable they are, and all the other¬†urban¬†legends¬†about complexity, complex, complicated and chaos, I get a smile. This is the world we work in. And the world where most people are users of those¬†systems. Here's a start in learning how to manage in the presence of these systems.
Ask anyone mentioning complex, complexity, complicated, and chaos if they have a background in Systems Engineering? No, walk away, they don't know what they're talking about.Related articles The Use, Misuse, and Abuse of Complexity and Complex Technical Performance Measures Agile as a Systems Engineering Paradigm Systems Thinking, System Engineering, and Systems Management Can Enterprise Agile Be Bottom Up? Estimating Guidance Systems Thinking and Capabilities Based Planning What Can Lean Learn From Systems Engineering? Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management
The conjecture that we can make decisions in the presence of uncertainty without estimating the impacts of those decisions is without any principles that can be tested beyond personal anecdotes of¬†I know people who spend other peoples money without providing estimates
Here's some reading to help understand why its bunk and how to learn to estimate in the presence of uncertainty in order to make better decisions.
This list¬†starts with¬†the earliest posts, beginning¬†in 2009.¬†
So when you hear about all the posts about #NoEstimates, take a look here to see if those posts provide any actionable outcomes that can be put to the test on actual projects - other than¬†Slicing.¬†