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!
Without a desired delivery date, target budget, and expectedÂ capabilities, a control system is of little interest to thoseÂ providing the money at business level.Â There is no way to assure those needs â€“ date, budget, capabilities â€“ canÂ be met with the current capacity for work, efficacy of that work process,Â or budget absorption of that work.Â
With a need date, target budget, and expected capabilityÂ outcome, a control system is the basis of increasing theÂ probability of success.Â These targets are the baseline to steer toward.Â Without a steering target the management of the project is Open Loop.Â There are two types of control systems
AnÂ Open Loop Control control systemÂ is a non-feedback system, whereÂ the output â€“ the desired state â€“ has no influence or effectÂ on the control action of the input signal.Â In an Open-Loop control system the output â€“ the desiredÂ stateâ€“ is neither measured nor â€śfed backâ€ť for comparisonÂ with the input. Â An Open-Loop system is expected to faithfully follow itsÂ input command or set point regardless of the final result.Â An Open-Loop system has no knowledge of the outputÂ condition â€“ the difference between desired state and actualÂ state â€“ so cannot self-correct any errors it could makeÂ when the preset value drifts, even if this results in largeÂ deviations from the preset value.
An Closed-loop Control System, is a feedback control systemÂ which uses the concept of an open loop system as its forwardÂ path but has one or more feedback loops between its outputÂ and its input.Â In Closed Loop control, there is aÂ â€śfeedback,â€ť signal that means some portion of the outputÂ is returned â€śbackâ€ť to the input to form part of the systemsÂ excitation.
Closed-loop systems are designed to automatically achieve andÂ maintain the desired output condition by comparing it with theÂ actual condition. Closed Loop control systems doÂ this by generating an error signal which is theÂ difference between the output and the reference input.Â A â€śclosed-loop systemâ€ť is a fully automatic control system inÂ which its control action being dependent on the output in someÂ way.
Key Differences Between OpenÂ Loop and ClosedÂ Loop control
Open Loop Control
Closed Loop Control
Using Closed Loop Control for a Project
Using these measures to calculate the variance between planned and actual. Take management action to adjust the productivity, the end date, the budget â€“ using all variables produce a new Estimate To Complete to manage toward.
This is a closed loop control system
The Microeconomics of Decision in Closed Loop Control
Microeconomics is the study of how people make decisions in resource-limited situation on a person scale. It deals with decision that individual and organizations make on such issues as how much insurance to buy, which word processor to buy, what prices to change for pro ducts and services, which path to take in a project. Throughput the project lifecycle, these decision making opportunities. Each decision impacts the future behavior of the project and is informed by past performance and the probabilistic and statistical processes of the underlying project activities. To make an informed decision about the project, estimates are made using this information.
Microeconomics applied to projects is a well understood and broadly applied discipline in cost account and business strategy and execution. Decision making based on alternatives, their assessed value and forecast cost. Both these values are probabilistic. Microeconomics is the basis of Real Options and other statistical decision making. Without this paradigm decision are made not knowing the future impact of those decisions, their cost, schedule, or technical impacts. This is counter to good business practices in any domain.
Let's Look At An Open Loop Control System
This is all fine and dandy. But where are we going? What's the probability we will arrive at our desired destination if we knew what that destination was? Do we have what we need to reach that desired destination if we knew what it was? In Open Loop Control these questions have no answers.
Let's Look at a Closed Loop Control System
We want to manage our projects with Closed Loop Control SystemsRelated articles Who's Budget is it Anyway? Your Project Needs a Budget and Other Things The Actual Science in Management Science Control Systems - Their Misuse and Abuse Building a Credible Performance Measurement Baseline Open Loop Thinking v. Close Loop Thinking
Estimating in the presence of uncertainty is a critical success factor for all project work. Uncertainty prevails on all projects, no matter the domain, development process, or governance method.
Uncertainty from underlying statistical variances. Uncertainty from probabilistic events.
Here's an approach to estimating the cost and schedule impacts from those uncertainties.
Forecasting cost and schedule performance from Glen Alleman
ÂRelated articles Intellectual Honesty of Managing in the Presence of Uncertainty Essential Reading List for Managing Other People's Money
Risk Management is How Adults Manage Projects - Tim Lister
Tim's quote offends some people. Here's a collection of his presentations. But this not really the point of this blog. I'm working two programs where Agile (Scrum and SAFe) is integrated into the Earned Value Management System, complaint with EIA-748-C and the guidelines for deploying, using, and reporting progress to plan with that system. This integration is directed by FAR 34.2 and DFARS 234.2 on Software Intensive System of Systems programs.
These programs are similar to Enterprise IT programs, they have mission critical outcomes, they are expensive, they have high risk, they are not simple structure - by definition, and they have deadlines and budget goals set of the enterprise for maintenanceÂ of corporate performance.
Outside ofÂ theÂ programs we work, weÂ encounter much confusion around risk management, theÂ source of risk, and the separation of the effective and non-effective process of managing risk in the presence of uncertainty.Â Let's start with a framework for making decisions in the presence of uncertainty. This briefing has been shown before here, many times. But it can't be shown too many times, because there is much misinformation about how to manage in the presence of uncertainty. This briefing is part of a much large set of charts developed over several years for an Office of Secretary of DefenseÂ for Acquisition, Technology and Logistics. These are the people that buy things for the warfighter and those who support them.
It may not appear to be applicable inÂ all domains, but I'd strongly suggest it is. Because uncertainty is present on all projects. And the risk this uncertainty creates is present on all projects. Uncertainty and the resulting risk cannot be avoided itÂ can only be managed.
When we hear Agile is Risk Management it's not true. Agile Software Development in the form of Scrum, XP, DSDM, Crystal, and now evenÂ Agile Prince2 is just that - a Software Development Method using the principles of agile.
In some domains by the way a few of those principles are violations of governance of other people's money. Many business people have day jobs and aren't going to be available on demand to work with the developers. Â standards - DODAF, ToGAF, 1553 Bus, ISO 12207 etc. define architectural processes.
But that aside for now, Agile provides information for risk management through frequent feedback and adaptability. But Agile is NOT risk management for a Â simple reason ...Â Â
Agile does not model the uncertainties that underly all project work. Â
Agile has no notion ofÂ margin. Agile has an informal notion ofÂ riskÂ reductionÂ of Reducible RisksÂ (Epistemic uncertainties if you read the briefing). But thoseÂ irreducibleÂ uncertaintiesÂ (Aleatory) are not addressed by Agile. Research shows the irreducible uncertainties are theÂ killer problems on all project work. These come from the natural variances of humans, processes, and machines.
Agile in the form of methods has no process model for addressing the reducible and irreducible uncertainties other than to provide data on performance to date to make decisions about mitigations, margin, and management reserve needed toÂ MANAGE Risk in the presence of uncertainty.Â
And of course the final tagÂ line
To Manage Risk in theÂ presenceÂ ofÂ uncertaintyÂ we must Estimate not only theÂ probabilityÂ ofÂ occurrenceÂ of an Event based risk, but also EstimateÂ theÂ statisticalÂ processes ofÂ naturallyÂ occurringÂ variancesÂ and thenÂ estimateÂ theÂ impactÂ of thoseÂ uncertaintiesÂ creatingÂ risk, Estimate the costÂ andÂ scheduleÂ toÂ mitigate thoseÂ risk, and finally Estimate the residualÂ uncertaintyÂ afterÂ mitigation.
Yes,Â Risk Management is How Adults Manage Projects and of course Estimating is how Adults Manage Projects
ÂRelated articles Agile Software Development in the DOD Risk Management is How Adults Manage Projects What Do We Mean When We Say "Agile Community?" IT Risk Management
The Scrum sprint cycle calls for a team to do a retrospective at the end of each sprint. Yet in almost every Certified Scrum Master course I teach, I'm asked if teams really need to do a retrospective every sprint.
Usually the logic of the questioner is along the lines of:
So, in this blog post, I want to briefly counter each of those arguments and say why you should still do a retrospective every sprint. Then, I'll end the post by saying maybe--just maybe--you don't really need to do a retrospective every sprint after all. (Did I surprise you with that? Read on ...)The Team Is Too Good for Retrospectives
Your team is not too good that it cannot get better. I’ve worked with teams that have been doing Scrum for over 10 years, doing retrospectives every two weeks, and they can still identify ways to improve. It is highly unlikely that your team is so good there are no further improvements either to be identified or worth making.Retrospectives Are Too Boring
No one said a retrospective should be as exciting as the latest Hollywood blockbuster. But there are things you can to do to liven them up.
For example, mix things up by asking a ScrumMaster from another team to facilitate your retrospective. The change in style can help. (Be sure to return the favor.) Change the venue, possibly holding a retrospective outdoors, even while walking.
Try a totally different format for the meeting. For example, many teams fall into a habit of always looking for new practices to adopt. Dedicate your next retrospectives entirely to discussing what should be dropped from the team’s process. (And, no, “dropping retrospectives” is not allowed.)
Geoff Watts and Paul Goddard offer ten different formats for retrospectives in their video course on retrospectives. Watch it and try some your team hasn’t tried. There are plenty of ways to prevent a retrospective from being boring.The Team Is Too Busy for Retrospectives
A team that says it is too busy to dedicate time to getting better is taking a very shortsighted view of the future.
In his Seven Habits of Highly Effective People, Stephen Covey used the analogy of a woodcutter cutting a tree for days with a saw. Eventually the saw becomes dull. But with a short-term attitude, the woodcutter will never stop to sharpen the saw.
A Scrum team with a similarly short-term view will never take thirty minutes out of its schedule to look for improvements. Instead they’ll put too much value on the little bit of code that could have been developed during those 30 minutes.The Team Doesn't Like Retrospectives
This is somewhat a variation on retrospectives being boring. I’ve listed it separately because it does go beyond retrospectives being boring or becoming mundane to some team members. Some team members just flat out don’t like them.
And for those team members, that may just be too bad because everyone on the team is expected to be a professional. And professionals do all parts of their jobs, not just the parts they want to do.
As soon as I finish writing this post, I need to rewrite it to make it better. That isn’t as fun. Then I need to proofread it. That’s not fun at all. Then I have someone else read it. And then I have to accept or reject edits to it. That’s not fun at all.
Not every part of our job gets to be fun. If some team members don’t like retrospectives, but if retrospectives are helping the team find ways to improve, the team should be doing them.When It's OK Not to Do a Retrospective Every Sprint
But I also said I’d let you know when it’s OK not to do a retrospective every sprint. So, when is that?
If your team:
… and if they work in short sprints, I'll say it's OK for the team do retrospectives less frequently.
Here's why. The general Scrum rule is to run sprints of four weeks or less. So a team that truly wanted out of retrospectives could just adopt a four-week sprint.
Consider a team that has chosen one-week sprints for a variety of good reasons. But this team so detests retrospectives that they switch to a four-week sprint just to conduct retrospectives less frequently.
This would be a bad change, unless the change is appropriate for reasons other than just a desire to do retrospectives less frequently.
And so, a good ScrumMaster should really encourage the team to do retrospectives every sprint, arguing against the four objections covered above. But the ScrumMaster should be open in some rare cases to a team doing a retrospective perhaps every other sprint when using one- or two-week sprints.
I want to be clear that I always try to talk a team out of this. I always try to convince teams to do retrospectives every sprint. But if a team really has achieved a very, very high level of performance and is doing short sprints (usually one week), I am willing to acquiesce to their arguments.
I'll then have them do a retrospective every other sprint. And for most teams, that is more frequent than teams doing four-week retrospectives.Come Back Next Week for My Favorite Way to Run a Retrospective
Be sure to come back next week. There are many ways to conduct a retrospective, but next week I’ll share my favorite way.What Do You Think?
Let me know what you think in the comments below. Do you ever skip retrospectives? Under what circumstances do you think it’s OK (if ever)?
A colleague asked me for some tips about writing. With hundreds of articles, blog posts, and 10 books, I know what works for me. I suspect some of these ideas will work for you, too.Tip 1: Â Write every day.
Write for 15 minutes every day. This practice exercises your writing muscles. For me, itâ€™s a little different than all the email I writeTip 2: Think about the stories you want to tell in an article.
People love stories. If you include a story, they will identify with it and love your work. That’s because they can identify with the situation, regardless if they agree with you.
You might not like my story approach. Think about what you like to read. What pulls you in? Write like that (not the same words, the same approach).Tip 3: Writing is not editing.
For me, writing is about 3 parts:
When I write (down), I donâ€™t edit. I spew words on the page. Itâ€™s almost a game: how fast can I write? I write about 750-1000 words an hour. Thatâ€™s pretty darn close to an entire article. (1000 words) After Iâ€™m done with the writing-down, I can edit.ÂTip 4: People will disagree with you
When you write non-fiction, people will disagree with you. (Heck, they probably disagree with fiction, too!) Thatâ€™s fine. Itâ€™s their loss if they disregard your ideas. Everyone has their own experience. If you tell stories/provide tips/write from your experience, you are authentic. You also build your self-confidence. The writing is easier over time.
If you would like to practice your writing, I have an online workshop starting in March. SeeÂ http://www.jrothman.com/syllabus/2015/12/writing-workshop-1-write-non-fiction-to-enhance-your-business-and-reputation/. You willÂ write at least one article during the workshop.Â
Great equations change the way we perceive the world. They reorchestrate the world - transforming and reintegrating our perception by redefining what belongs together with what. Light and waves. Energy and mass. probability and position. And they do so in a way that often seems unexpected and even strange.
- Robert P. Crease,Â The GreatestÂ EquationsÂ Ever, Physics Web 2004, inÂ The Mathematics Devotional: Celebrating theÂ WisdomÂ and Beauty of Mathematics, CliffordÂ A. Pickover
I'm working two programs where Earned Value Management, through FAR 34.2 and DFARS 234.2 are applicable. These programs are also Software Intensive Systems applying Agile development processes. Capabilities Based Planning is defined as ...
A method involvingÂ the functional analysis of operational requirements. Capabilities are identified based on the tasks requiredâ€¦ Once the required capability inventory is defined, the most cost effective and efficient options to satisfy the requirements are sought. Capabilities Based Planning is planning, under uncertainty, to provide capabilities suitable for a wide range of modern-day challenges and circumstances while working within an economic framework that necessitates choice.
In tradition Agile (I know agilest will be wincing) the development of requirements is emergent. On Sofware Intensive System of Systems in the domain where FAR / DFARS are applicable, we have deadlines and mandatory Capabilities for the outcomes of the work effort. The systemÂ must perform in specific ways on specific dates for specific costs.
This specificity of capabilities, cost, and delivery dates is no different than onÂ Enterprise IT projects
WhenÂ applying Agile Development has to address how do we bound the program in aÂ contract vehicle? The Agile Manifesto ofÂ CustomerÂ CollaborationÂ OverÂ ContractÂ NegotiationÂ is fine exceptÂ when dealing with a sovereign. So here's how its done.
Capabilities Based Planning
The needed Capabilities are on contract. The technical and operational requirements needed to provide those capabilities can be emergent and are suitable to agile development methods.
Here's some posts from the past about Capabilities Based Planning
And of course ...
To make decisions about the analysis of alternatives usingÂ Capabilities Based Planning, estimates must be made of the outcomes for each choice in the list of alternatives. Without estimates, there can be no Analysis of Alternatives to determine which capabilities are best suited to meet the mission need or fulfill the business case. There can be no credible decisions in the presence of uncertainty without estimates.Related articles How Think Like a Rocket Scientist - Irreducible Complexity What Do We Mean When We Say "Agile Community?" Can Enterprise Agile Be Bottom Up? Seven Principles of Agile Software Development in the US DOD Two Books in the Spectrum of Software Development There is No Such Thing as Free Empirical Data Used to Estimate Future Performance Agile Software Development in the DOD Thinking, Talking, Doing on the Road to Improvement
I want to make sure I’m doing the best job I can addressing your needs and writing about the topics you’re interested in. And that means I need to know more about you. And so I’ve created a short survey.
I’d really appreciate it if you’d take a few minutes to fill out the survey. By doing so, you’ll help me provide you with the best content I can.
There are only 10 questions, so you can finish in just a couple minutes and the results are completely anonymous.
Thanks in advance for your help.
I have several public workshops this year.
I’m offering the Influential Agile Leader with Gil Broza April 6-7, 2016 in Boston and May 4-5, 2016 London. If you have not read some of my writing about leadership, take a look at these previous newsletters:
Early bird registration for Influential Agile Leader ends Feb 29, 2016.
Super early bird registration ends January 15, 2016.
I hope you decide to join me and we can learn together.
There is no problem so complicated that you can't make it worse - a common phrase in the astronuaghtÂ business
The impression that "our problems are different," is a common disease that afflicts management to work over. They are different, to be sure, but the principles that will help improve the quality of product and service are universal in nature - W. Edwards Deming
So when we hear some new and controversial conjecture is the solution to the smell ofÂ dysfunction, ask for tangible, testable, verifiable evidence that this new approach is not a solution looking for a problem to solve.Â
A lot of traditionally managed projects begin with a Software Requirements Specification (SRS). Then sometime during the project, a decision is made to adopt an agile approach. And so a natural question is whether the SRS can serve as the newly agile project's product backlog. Some teams contemplate going so far as rewriting the SRS into a product backlog with user stories. Let's consider whether that's necessary.
But before taking up this question, I want to clarify what I mean by a Software Requirements Specification or SRS. I find this type of document to vary tremendously from company to company. In general, though, what I'm referring to is the typical document full of "The system shall ..." type statements.
But you can imagine any sort of traditional requirements document and my advice should still apply. This is especially the case for any document with numbered and nested requirements statements, regardless of whether each statement is really written as "the system shall ..."Some Drawbacks to Using the SRS as a Product Backlog
On an agile product, the product backlog serves two purposes:
That is, the product backlog tells a team what needs to be done and can be used as a planning tool for sequencing the work. In contrast, a traditional SRS addresses only the issue of what is to be done on the project.
There is no attempt with an SRS to write requirements that can be implemented within a sprint or that are prioritized. Writing independent requirements is a minor goal at best, as shown by the hierarchical organization of most SRS documents, with their enumerated requirements such as 1.0, 1.1, 1.1.1, and so on.
These are not problems when an SRS is evaluated purely as a requirements document. But when the items within an SRS will also be used as product backlog items and prioritized, it creates problems.
With an SRS, it is often impossible for a team to develop requirement 1.1.1 without concurrently developing 1.1.2 and 1.1.5. These dependencies make it not as easy as picking a story at a time from a well-crafted product backlog.
Prioritizing sub-items on an SRS is also difficult, as is identifying a subset of features that creates a minimum viable product.
A Software Requirements Specification is good at being a requirements specification. It’s good at saying what a system or product is to do. (Of course, it misses out on all the agile aspects of emergent requirements, collaboration, discovery, and so on. I’m assuming these will still happen.)
But an SRS is not good for planning, prioritizing and scheduling work. A product backlog is used for both of these purposes on an agile project.My Advice
In general, I do not recommend taking the time to rewrite a perfectly fine SRS. Rewriting the SRS into user stories and a nice product backlog could address the problems I’ve outlined. But, it is not usually worth the time required to rewrite an SRS into user stories.
Someone would have to spend time doing this, and usually that person could spend their time more profitably. I would be especially reluctant to rewrite an SRS if other teammates would be stalled in starting their own work while waiting for the rewritten product backlog.
A ScrumMaster or someone on the team will have to find ways of tracking progress against the SRS and making sure requirements within it don’t fall through the cracks. Usually enlisting help from QA in validating that everything in an SRS is done or listed in the product backlog is a smart move.
One additional important strategy would be educating those involved in creating SRS documents to consider doing so in a more agile-friendly manner for future projects. If you can do this, you’ll help your next project avoid the challenges created by a mismatch between agile and starting with an SRS document.What Do You Think?
Please join the discussion and share your thoughts and experiences below. Have you worked on an agile project that started with a traditional SRS? How did it go? Would it have been different if the SRS had been rewritten as a more agile product backlog?