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 you're like me, you're late in starting your shopping this year, whether it's for Hanukkah, Christmas, Festivus or some other holiday.
To help you out, I want to share a few thoughts on the best gifts for the ScrumMaster in your life. Here are the top ten gifts for the ScrumMaster in your life.A Bullhorn
All good ScrumMasters struggle at times to get their message across. Perhaps it's because we too often try the subtle approach. Perhaps it's time for something different.Patience
For when the bullhorn doesn't work after all. If you know where you buy additional patience, let me know. Mine is always in short supply.A "We'll Try It For Two Sprints" Gift Certificate
Gift certificates always make great presents. I guarantee your ScrumMaster would love a handmade note from the whole team saying, "We'll try whatever you want for two sprints." What a wonderful way to demonstrate your commitment.Cologne
In case your ScrumMaster has been too busy to notice, there is now a cologne just for ScrumMasters.Socks
Judging by the frequency with which my family gives me socks, these are a tremendous gift.A Great Book
Admit it, you make life hard on your ScrumMaster. Your ScrumMaster could use help and advice in figuring out how to help you be the best team you can be. There's nothing like a great book to help. Fortunately my publisher has all the books in their Signature Series on sale for half off. That includes the ones I've edited as well as those by Martin Fowler and Kent Beck. Check out all the great books on sale but only through 14 December.A Video Course
Well, if there's anything better than a book, it's a video course. I know your ScrumMaster would love my online Agile Estimating and Planning video course.Index Cards
Honestly, can any ScrumMaster really have too many index cards? Splurge and get your ScrumMaster some monogrammed cards or the desk box to hold all their cards. I like the cards and boxes from Levenger.An Atomic Clock
What better way to be sure the daily scrum never takes more than fifteen minutes?Thank Them
Many ScrumMasters have taken on the role and given up part of all of their time as programmers, testers, analysts or whatever got them into this industry in the first place. And they're happy to do it if it helps the team. But there are times when being a ScrumMaster can be a thankless job at times. So thank your ScrumMaster just for doing the job.
I had a great conversation last week with someone taking a leadership course. (Not one of my courses. His instructor wouldn’t talk to him!! He’d seen one of my posts and emailed me. Of course I talked with him.)
He was confused by the word “Handoff.” He thought it meant that people hadn’t done their job and other people had to cover for them.
Sometimes that happens. But more often, handoffs occur when you bring people together in a complex project or program, and they deliver their parts to make it a whole.
Here’s the analogy I created for him during our conversation. Imagine you’re a chef at a famous restaurant, creating a great dining experience for your customers. You have the meat chef, the potato chef, the vegetable chef, the sauce chef, and you, the lead chef, all bringing the dinner together for the customer’s delight.
Not all meals need a lead chef, but sometimes they do. In this example, they do. Why? Because my colleague has a new team of volunteers who don’t know how to perform their tasks. He is the master chef. He’s not command and control. But he needs to show them the first few times how to put everything together. Does this sound like some new-to-agile teams, working with a coach, to you? The coach isn’t a master chef. The coach is a facilitator. It’s a little different. Okay, back to our example.
My colleague, in his role as master chef, asks each chef to handoff their parts to the plate. (Integration to the software people.) As master chef, he would do the clean-around-the-outside-of-the-plate thing that master chefs do, add a sprig of herbs, handoff the plate to the server and now the plate goes to the diner for a delightful culinary experience.
As the people in the kitchen evolve, they don’t need the master chef to supervise them, do they? No, they become a self-organizing team who can do this by themselves. But, they still have handoffs, because the meat chef still focuses on meat, and the potato chef still focuses on potatoes, etc.
In kitchens, chefs are trained to be generalizing specialists. In software, we aren’t always trained. But we can learn, if we want. We can pay attention to the handoffs.
In an agile team, especially with continuous integration, we don’t notice handoffs. Continuous integration makes handoffs trivial. If we work together to achieve a feature, as in swarming or mob-programming, we don’t even have handoffs.
In a non-agile or when you don’t have software, we want to know when the handoffs occur, so the team can synchronize around them. In a geographically distributed team, we want to highlight the handoffs, so we know what to expect and when.
Handoffs aren’t bad. It’s how we manage them that can make them good or bad.
When something hurts, do it every day. The pain will turn into joy.
Thereâ€™s a well-known argument in favor of continuous delivery in the Agile community:
When software deployment is painful, learn to do it every day.
When an activity is unpleasant, uncomfortable, or just unbelievably boring, humans have a strong tendency to do it less often
It has been suggested that context is somehow irrelevant. This notion seems to start around the criticism of theÂ MoSCoW requirements method where requirements that implement the needed capabilities of a system are categorized.
MoSCoW means: (how it got the moniker I have no idea) and is a well developed method of eliciting requirements in a paradigm where the customer has some notion of what done looks like. If this is not the case, no method will help and the norms of project management are no longer effective - it's aÂ ChaosÂ mode. So in fact MoSCoW has no value and the suggestion may be true - in Chaos we don't need requirements elicitation methods.
But let's assume we're not in chaos and we actually would like to know something about what Done looks like, how much it might cost to get to done, how long it might take, and what of value will be produced when we reach done.Â
But for projects operating in the other three uncertainty modes - variaton, foreseen uncertainty, andÂ unforeseen uncertainty,Â the first question is actually theÂ inverse question ...
Why would we NOT prioritize the requirements using this or a similar mechanism?
Let's look at some content in the notion that prioritizing requierements should be ignored.Â A requirementsÂ Trade Space is mandatory on any non-trivial project for some very simple reasons:
Below is an example (at the end) of a program that has a minimum set ofÂ capabilities fulfilled by the requirements, where the Program Manager and the Customer managed the success withÂ ruthless adherence to a schedule and the needed capabilities.
This example might serve as a paradigm for otherÂ mission critical projects.Â
Now the question isÂ can this paradigm orÂ context be applicable to small group, agile software projects? Turns out Star Dust had small team software intensive software components. As Shim saysÂ think about it.
Focus on the nine I's (v9) from Glen Alleman Related articles What's Missing from Project Management in IT Agile Paradigm A Common Myth in Software Development They Never Saw It Coming
I donâ€™t work remotely because Iâ€™m not away from anything where Iâ€™m supposed to be.
My flight to Hamburg was canceled two times, and thus Iâ€™m spending a day at Vienna airport reading articles, answering emails, sending invoices, and writing a blog post. And I started reading the book Why Managing Sucks and How to Fix ItÂ (Thompson, Ressler)
Are you transitioning to agile? Is it going well?
If it your transition is going well, excellent. I’m happy for you. But if you are like many of the leaders across the organization I’ve met, you have plenty of problems. Sometimes you have a problem as this colleague said,
Right now we’re really struggling with Portfolio Management that is relevant to our business.Â We can’t prioritize because we can’t define projects in a way that resonates with the business.
Resonating with the business is an issue of influence. How influential are you? Would you like to succeed in managing the project portfolio? Or, in getting the testers/QA involved at the beginning in a real cross-functional team? Or, helping people realize that fast failing is good? Are you ready to prepare to become more influential?
Join Gil Broza and me at The Influential Agile Leader in Toronto, April 8-9, 2014. If you’re in Europe, we’ll be in Edinburgh, Scotland, May 22-23, 2014.
We’ll experience and practice authentic approaches to influence and coaching.Â (Of course this is experiential. What did you expect?) Where is your sphere of influence? How do you expand it? How do you influence within it? You’ll have a chance to practice with yourÂ peers in real situations.
We’ll help you learn how to coach up, sideways, and down. Up is especially critical. For example, you might have to explain options in different ways when you coach up. Again, you’ll practice, using real-life situations.
There’s much more that we can offer. You, the participants select the rest of the program. We will deliver, experientially, what you want at the time. We are prepared. We’ve done our work. You will drive the rest of the event.
All the details are at the Influential Agile Leader.
Please join us. Early bird registration ends Dec 31.
Sign up now. You won’t regret it.
There’s nothing wrong with a bit of self-promotion
Proper Preparation Prevents Poor Performance
This simple phrase describes the core behavior of all project related work. For any platitude to survive contact with reality, it must beÂ true,Â actionable, andÂ applicableÂ in your own domain.Â
The notion that â€śemergenceâ€ť is the driver for the participants in a project requires careful consideration. The technical or business requirements of the outcomes of the project are always â€śemergentâ€ť in some form. To be otherwise would require a preset group of activities, materials, technology, and personnel.
Failing to understand the subtleties of the continuous emergence of requirements, that enable the capabilities to be delivered, Â means failing to understand any project requires planning to deal with these emerging requirements. This emergence also pertains to the tools and processes used to manage and deliver the project. emergence is applicable to all elements.
Preparing for Emergence is a critical success factor in project work. Proper preparation is the foundation of programmatic and technical risk management. This means asking and answering the â€śif â€“ thanâ€ť question, rather than the â€śwhat â€“ ifâ€ť question.
Managing in the presence of emergence requiresÂ directed decision making. Just letting things happen disconnects the outcomes of the project from the neeed capabilities produced by the project. These capabilities are theÂ immutable part of the business process. They can only change, when the strategy for the success of the business enabled by the project changes. To do otherwise, would be to disconnect between the investment in the project and the value produced by the project.
â€śIf â€“ Thanâ€ť means knowing what can go wrong and how to respond to the following:
IfÂ personal development never happens as planned, why bother?
There are many things wrong with performance appraisals, but one aspect that many authors and experts seem to overlook is the insane idea of â€śmeasuring progress against a goalâ€ť.
Iâ€™ve been part of this nonsense myself.
We asked our employees (many years ago) to create Personal Development Plans, and craft personal goals that they would try to achieve before the end of the year
Â Plans are nothing, Planning is Everything
The notion that plans are nothing but planning is everything is a common mis-applied quote. The clip art Â and content extracted from the current edition of Defense Acquisition Journal, November-December, 2013.
The ever-quotable Dwight D. Eisenhower, speaking to a group of industry executives who could be mobilized for war at a momentâ€™s notice, was echoing an old adageÂ about warfare: â€śNo battle plan survives first contact with the enemy.â€ť
Eisenhowerâ€™s message, like the man himself, was straightforward: â€śThe reason it is so important to plan [is] to keep yourselves steeped in the character of the problem that you may one day be called upon to solveâ€”or to help to solve.â€ť He was reminding them that warfare is inherently fluid, and that the only way to adjust to quickly changing circumstances is to have planned for such contingencies in advance.
For our project management domain, Plans are considered Strategies for the successful delievry of the project's capabilities. But this strategy is actually a hypothesis and this needs continualÂ testing. The best way of course if testing the hypothesis is working product at periodic points in the project. Some would say this test should be every few weeks. This of course - as always - is domain dependent. But at a minimum every month.
In our Earned Value Management domain, the montly Contract Performance Report (CPR), requires an assessment of physical percent complete to calculate the BCWP (Budgeted Cost of Work Performed). Â The planned cost of producing this value is BCWS (Budgeted Cost of Work Scheduled).
BCWP = BCWS xÂ Physical Percent Complete
On the planned day for the planned cost. Don't show up on the planned day for the planned cost and the planned physical percent complete? You can't be on schedule and on budget.
Now Add Technical Performance Measures and Quantified Backup Data
The determination ofÂ Physical Percent Complete starts with Quantifiable Backup Data. Percent complete is never aÂ guess or anÂ opinion. Tangible evidence is needed. But tangible evidence against the planned percent complete, on the day we planned to be that percent complete. This is nearly identical to Agile's approach to delivering working software at the end of an iteration. Not quite, since agile allows you to drop planned deliverables without an penalty to the current performance measure. ThisÂ mortgaging the future by pushing undelivered features into the future would not be counted as complete in Earned Value.
We hear all the time, pithy statements about teams, teaming, team building, enabling team that provide innovation, and most everyÂ soft skill ever thought of, applied to managing projects. At the project below, where I was one of many program managers, we came to realize one fundamental truth about teams -Â
If you have a team who is your opponent?
Having played team sports at the High School, College, and competitive adult level, our teams always played against an opposing team. Much of the team building platitudes seem to ignore that teams are formed to play Â other teams, score points, win games, overcome obstacles, and participate in competition.
Who is theÂ other team if we're on a project team?
See if the notions below resonant when you hear short, cleaver words about the role of teams on projects?
Making the impossible possible from Glen Alleman Related articles Agile Requires Discipline, In Fact Successful Projects Require Discipline Trust 5 Benefits Team-building Consultants Can Offer Your Business Competency Model For Project Managers
Four hours of driving seems like a colossal waste of time.
Last night I drove from Vienna (Austria) to Zagreb (Croatia). It wasnâ€™t cheap. Apart from the cost of the rental car, the gas/petrol, the toll road, the Slovenian vignette (15 euros?! Geez, itâ€™s a crime!), and the parking fee, it cost me 4 hours of driving
The first question isÂ who pays for people learning from their mistakes? Then the next question -Â with these mistakes, did the project advance in ways it would not have before we made the mistake?Â
And did the money we spent learning from our mistake "earn its value?"Â Or put in another wayÂ was there a better use of the money to advance our learning other than building something that we considered a mistake?
There are other questions as well.Â Why didn't we know this was going to be a mistake before we started? OrÂ could we have known this before we discovered it failed? Or even better,Â was the failure we just experienced knowable at all?
This knowability question is the key to all project planning processes. If something is not knowable, then we could not have known, so we only discover our mistake after the fact. If it was knowable and we choose not to address it - ignore the potential problem - then we'll overrun our plan for no good reason other than we choose to ignore the knowable facts.
We may have a knowable issue, but can't afford toÂ learn (pay money to learn), but that's different.
These questions and others need to be asked and answered before we can make any assessment ifÂ learning from our mistakes is a good idea. The alternative toÂ learning from our mistakes is toÂ do the job right the first time.
This of course is overstating the solution and somewhat silly, but it brings out a critical concept that must be addressed in any credible management process of spending other peoples money...
Who pays for the development team to discover their mistakes, if these mistakes could be avoided?
Once we have the answer to that question, we now have some decisions to make.
This is all fancy words forÂ someone has to pay for us to learn what we don't currently know. And we need to make the cost of this learning visible as soon as possible if we're going to be good stweards of other peoples money.
So What's the Point?
The notion ofÂ Hiring smart people is pointless if they aren't allowed to make any mistakesÂ ignores the managerial finance obligation to determine who pays for these mistakes, is the budget for making these mistakes in the baseline authorization, and if not, are we going to overrun our planned cost for the project and dilute the Return on Investment calculationÂ that we sold to the owner of the project?
We seem to forget that writing software for money, means spending other peoples money for the expected amount of money (within the variance bounds) and showing up on or before some expected time (within the varaince bounds), with more or less the expected capabilities.Â
This is aÂ Prime Directive (to borrow a phrase) for all projects. It's very doubtful the owner of the money says to usÂ hey boys and girls, go out there and experiment around to figure out what will work and what won't work without actually budgeting for thatÂ experimenting work.
When there is explicit budget toÂ experiment that's calledÂ explicit work for discovering what we dont' know, that is needed before we can proceed. We'd find that budgeted work in our plan for the project. No problem, all part of the normal project management process.
But the notion ofÂ Hiring smart people is pointless if they aren't allowed to make any mistakesÂ needs to addressÂ Who, What, When, Where, Why, andÂ How this discovery process is going to get paid for FIRST, then we can startÂ failing on purpose to make the follow on work better.
But let's start with a fundamental principle of all business, not matter the domain. If we expect to generate revenue or produce some measurable value from our work efforts, we need to measure those beneficial outcomes in some agreed upon units.Â
Dollars is one unit of measures common in the business world. If we work are aÂ for profit company, it is likely the managers of the business use that unit when they discuss project work. If we work for the government, budget is used many times in place of cost, but cost - in dollars - is still in the equation. If we work for a non-profit or a not-for-profit budget and cost are half the equation. Intangible benefits the other half.Â
But it is unlikely any place we work, there is not some discussion of cost, budget, or expenses. So no matter what our personal opinion creating estimates of our work effort are, we can't escape the fundamentals of business.Â
We need to know the cost of something before we can assign a value
Let's look at some deepÂ truths about estimating
So The Big Question?
These issues are not unique to software development. They are found in every project domain. Public works, bio-pharma, energy, government contracting.Â
Estimating is hard, it's important, and needs to be addressed in much more detail, before being dismissed as simply something management wants.
When we estimate a software project we make certain assumptions about what work and how that work will be completed. We need to do that in order to sequence the work, handle the dependencies, assign the work to the right people, etc. Estimation is a process of planning, and as such it requires us to make commitments. Those commitments reduce our options, because we immediately eliminate possible implementation strategies.
Let's look at an example. I want to implement a IT-request queue in my organization. Something that allows us to manage the requests from employees in a way that none is lost and the employee can easily get information on how the item is proceeding through it's life-cycle. A project is started. How to plan this project?
One of the key benefits of using #NoEstimates as a planning approach is that we create more Options, making our projects more valuable and more flexible.
In the #NoEstimates approach we release a partial set of functionality (value) earlier. We may find that for the time being that functionality is enough and may decide not to release any further functionality (an option). Or we may find something we did not know before, and change the project (another option). While in the Estimated approach we will make commitments in terms of time, people and resource allocation that are going to be harder to change later (reducing options), and may commit more money to the problem than we actually need (less options still).With the #NoEstimates approach we don't commit to requirements that we are not going to immediately work on
Note also that with the #NoEstimates approach we don't commit to requirements that we are not going to immediately work on. The reason is simple: requirements have a "best before" date and expire. We should not commit to requirements too far into the future - but that we will tackle in another post.
Have you applied this planning heuristic in your projects? What were the benefits, and obstacles you faced when using it?Photo credit: psiaki @ flickr
The recent post about the 5 Ways To Rethink Software Projects has elicited a response from the author stating I was being unfair to his thesis that in the end - Number 5 - we didn't need to make estimates. Of course without any domain or business processes governing the expenditure of other peoples money, it's hard to tell where the proposed ideas would fit it.
Going back to basics with the clip below, I'm reminded we seem to have lost all visibility to why estimating is needed in the first place. The clip below is from a 1970 Naval Post Graduate School (NPS) thesis about the troubles with estimating. Many of the problems are still in place today. So you may say we haven't move beyond the orginal problem. But that would be too simple. The papers below, including this 1970 thesis shows how far we have come.
I'd conjecture to move beyond twitter exchanges and interviews of personal anecdotes we need to test the notion of how to improve estimates in the market place. Anecdotes are fine, if derived from actual hands-on experience in a domain or similar domain. The bottom's up discussion many times ignores governance and simple business processes and is stuck on theÂ you're not listening to my great ideaÂ that XP was in early on. As Carl Sagan suggests
"Extraordinary claims require extraordinary evidence."Â CarlÂ Sagan
TheÂ systems referenced below are not in the domain of the CIO magazine article. But the principles for forecasting the cost of a project before - or near the start - work is still an important part of Project Governance.Â Â The notion of project governance seems to have been skipped over when we look at the problems of estimating. From the management of the ACA web site, to large ERP systems, to major weapons, to major science projects - managing the project with the paradigm ofÂ governance is actually harder than it looks. It is hard because theÂ value at risk is more important than the interests of the individual. The subordination of self interest some times is more difficult than seeing the bigger picture of managing other peoples money.
So we can choose to explore how to improve our estimating capabilities or we can seek out ways to avoid estimating all the together. But in the end, those with the money likely want us to learn to be better estimators. We should ask them, before assuming they want us to stop estimating the cost of work - #5 in the list of ways.
That's the message here. If you have a customer who will pr ovide you with funding in the absence of knowing - in some way, with some confidence - how much it will cost in the end, I'd suggest you proceed and hope for the best.
There is a common idea found in some software places, especially one that start with the notion that we don't want to do estimating, or estimating is not needed when spending other peoples money, that estimating is hard, is the same a guessing, and produces results not valuable or not needed by the customers.
Let's start with a paradigm. If you choose to not estimate because you don't want to learn, well not much to do about that. But let's read what Barry has to say.Â
There is no good way to perform a software cost-benefit analysis, break-even analysis, or make-or-buy analysis without some reasonably accurate method of estimating software costs and their sensitivity to various product, project, and environmental factors.
Professional organizations for cost estimating
Ignoring for the moment the problems with the logic of ignoring the needs of those providing us money, here's some places to start in the domain where estimating is the basis of good project management
There are many more approaches. Google will get you them all. But in the end you actually have to want to learn how to do software estimating. If you start with the notion that estimates are either not needed, serve no purpose, or you simply have heard this from a source that has no connection to your domain, nor wants to - then you'll probably want to ask a few more questions:
So when you hear someone suggest we needÂ question everything then question the questioner if he has any experience at all spending other peoples money on a project where theÂ value at risk is substantial to the point if the project fails he'll ge fired.
No? not working in that domain -Â manifestly important and nearly impossible - according to Edwin Land, then that advice about estimating may be a bit too narrowly focused, limited in domain for your need. You get to decide.
But if you do maybe these will help as well
It's not clear how this notion came about, since I haven't talked directly with those making statement like that. I'll have to estimate myself why this might be true.
One reason might be they haven't been exposed to the statistical processes used to make estimates in a variety of domains, not just project management. When we encounter the need for estimates, we need to come in contact with probability and statistics. All processes on projects are statistical in nature. This produces uncertainty and uncertainty results in probabilistic outcomes.Â
Estimating means searching in this probabilistic "space" for a number that isÂ close enoughÂ to answer a question.Â How many people are in line for movie tickets inside? Should I buy my tickets at the kiosk outside? Or maybe, how long will it take me to drive from my office to the airport parking garage for my flight on Wednesday morning? These are not exact numbers, these ae quick estimates. The answer to the first question can be made with a quick look inside the theater. The second comes from the experience of driving to the airport several times a month over the past 20 years. One is informed by observeation of the current situation, one informed by past experience under a variety of situations.
Let's start with a simple definition of an estimate - it is an approximation of some value for some purpose, even if the data is incomplete, uncertain, or even unstable. Typically the estimate is derived from a statistical source of data - either observed or referenced in some way.
Making Simple Estimates
When we don't have the exact answer of some value, we can make an estimate of that value. The result is a number and a confidence on that value. Say we need an estimate of how long it will take to drive to the airport. It's 52 miles. Some on surface streets, some on open 2 lane roads, some on freeways. Knowing the speed limit for each of these segments can get us an approximate time portal-to-portal. We can improve the estimate, knowing the weather conditions and the traffic flow on the surface streets.Â
Let's look at five easy steps for making estimates (abstracted fromÂ The "Mother of All Guesses" -Â A User-Friendly Guide to Statistical Estimation,Â by Francois Melese and David RoseÂ COPYRIGHT ARMED FORCES COMPTROLLER, 1998)
Making Estimates for Project Work
With the steps above we can start to make estimates of our project work.Â
But first let's kill some myths used to not to make estimates.
We've heard them all and more. There is an endless list of reasons for not doing most anything on a project, but that doesn't remove our obligation to be stewards of other people's money we are spending with expectation (estimate) of some value in return.
Let's start with a core principle of all project work, and possibly a principle of all life's work when we encounter money.Â
We can't determine what something is worth until we know what it costs.
This is a crass capitalist point of view I know. But we live in a crass capitalist society andÂ them's the rules. Don't like the rules, it might be better to look somewhere else for work other than spending other peoples money without knowing how much it will cost in the end and when we'll be done.
We all know and maybe even experience a Dilbert's paradigm when it comes to projects. But that doesn't make it right. We hear this some times from management. But we also hear it as an excuse for not making estimates from those who should be looking after the cost needed to compute theÂ Return on Investment.
A Few More Myths
Below are some links to other Blogs on this topic, explore, think about our role in managing other peoples money.Related articles How To Estimate Almost Any Software Deliverable Measurement of Uncertainty Credible Estimating Processes Everything is a Random Variable Estimating Accuracy