Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/categories/6' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

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!

Project Management
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

Estimating on Agile Projects

Herding Cats - Glen Alleman - Fri, 05/27/2016 - 03:39

Here's a straightforward approach to estimating on agile projects. This is an example of the estimating profession found on many domains. 

Categories: Project Management

How to Make a Decision in the Presence of Uncertainty

Herding Cats - Glen Alleman - Wed, 05/25/2016 - 23:28

Uncertainty is all around us. In the project world, uncertanty comes in two forms:

  1. Aleatory Uncertainty - the naturally occurring variances due to the underlying statistical processes of the project. These can be schedule variances, cost variances, and technical variances - all driven by a stochastic process with a known or unknown statistical distribution. If you don't know what the distribution is, the Triangle Distribution is a good place to start. For example: The statistical processes of testing our code ranges from 2 to 4 days for a full cyber security scan. Planning on a specific duration has to consider this range and provide the needed margin. Aleatory uncertainty is irreducible. Only margin can protect the project from this uncertainty.
  2. Epistemic Uncertainty - the probability that something will happen in the future. The something we're interested in is usually unfavorable. For example: The probability that the server capacity we have selected will not meet the demands of the user when we go live. Epistemic uncertainty, being probabilistic, can be addressed with redundancy, extra capacity, experiments, surge capacity and other direction actions to buy down the risk that results from this uncertanty before the risk turns into an issue.

When we hear you can make decisions without estimates, this is physically not possible if you accept the fundamental principle that uncertanty is present on all projects. If there is no uncertanty - no aleatory or epistemic uncertainties - then there will be no probabilistic or statistical processes driving the project's outcomes. If that is the case, then decision have no probabilistic or statistical impact and whatever decision you make with the information you have is Deterministic.

So if you want to learn how and why estimating is needed to make decisions in the presence of uncertainty start here:

And then when you hear about a conjecture that decisions can be made without estimating you'll know better, and consider anyone making that conjecture as uninformed about how probabilistic and stochastic processes in the project world actually work - especially when spending other people's money.

 

Categories: Project Management

Successes and Failures are Illusions

NOOP.NL - Jurgen Appelo - Wed, 05/25/2016 - 09:19
Successes and Failures.jpg

In my talks around the world, I emphasize the need to run management experiments and I offer examples of interesting ideas that worked well for my team. Of course, with so many events per year, it was inevitable that someone would ask me, “What is your least successful experiment?”

I had to think about that for a moment and I had difficulty coming up with examples. That was strange, I thought. According to information theory, we learn most when roughly half of our experiments fail. When I’m able to name a good number of ideas that work, and I’m not able to list ideas that don’t work, does that mean that my learning process is suboptimal? That would be a reason for concern!

When I thought about it, I realized that, at least for me, success and failure are temporary statuses and I perceive them both with an optimistic mind. I have plenty of ideas that work for now, and I have a lot of ideas that don’t work yet. This means that, when you ask me about a successful experiment, I will happily share with you something that is successful now, knowing quite well that it may turn into a failure later. Likewise, when someone asks me about a failure, I have difficulty producing examples because I’m not considering the ideas that aren’t working yet as failures. They often just need more time, adaptation, and customization to make them work.

In other words, for my long-term optimistic brain, half of the experiments succeed and the other half will succeed later. I’m sure there are people with a negative mindset who would turn it all around: Half of the experiments fail and the other half will fail tomorrow. (My short-term pessimistic brain often works like that: “Nothing works, and even if something works, it breaks when I start using it.”)

Successes and failures are convenient illusions. They are judgement calls of the human mind, subjective evaluations of the consequences of our actions. Outcomes can be observed by anyone but successes and failures exist only in the eyes of the beholder.

Photo: (C) 2010 Paul Keller, Creative Commons 2.0

My new book Managing for Happiness is available from June 2016. PRE-ORDER NOW!

Managing for Happiness cover (front)

The post Successes and Failures are Illusions appeared first on NOOP.NL.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Tue, 05/24/2016 - 16:47

Wise men profit more from fools than fools from wise men; for the wise men shun the mistakes of fools, but fool do not imitate the success of the wise - Cato the Elder

Any conjecture not based on testable principles, independent of personal opinion or anecdotes cannot stand up to the questioning of the wise.

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter
Categories: Project Management

When is Agile Wrong for You?

People often ask me, “When is agile¬† right or not right for a project?” I’ve said before that if the team wants to go agile, that’s great. If the team doesn’t, don’t use agile.

That answer is insufficient. In addition to the team, we need management to not create a bad environment for agile. You might not have a great environment to start. But a bad environment? That’s a horror show.

I had a coaching conversation recently. My client¬†has a typical problem. He sees multiple ways to accomplish the work. He’s taking ideas from agile and lean, and smashing them together to create a project approach that works for them, at their company. It’s not quite agile. And, that’s the sticking point.

His management wants to “go agile.” They have no idea what that means.They think agile is a way to get more good stuff faster with less cost. It’s possible that with agile approaches, they can achieve that as a by-product. To be honest, any approach that stops people from waiting for phases to finish will help. That’s not necessarily agile.

The management team does know about one of the well-known approaches. They want everyone to go through that training. My client doesn’t think this will work. He has a number of concerns:

  • Management wants to control how people work at the project level. Management wants to define the iteration duration, what the standup questions will be, who will be on which team, and what the teams will do. (That’s enough right there, but there’s more. They are geographically dispersed across the globe. Going with an out-of-the-box solution does not make sense.)
  • Management wants to use team measurements for personal compensation. Specifically, they want to use personal velocity as a way to compensate people. (This is stupid, dangerous and wrong.)
  • Every manager my client has spoken with thinks that he or she does not need to change. Only the tech people need to change. (They could not be more mistaken.)

If you work in an agile organization, you know the problems with these assumptions.

Teams manage their own work: their intake is via the Product Owner. They decide how to work, flowing work through the team. Hopefully, the team focuses on their throughput, not who does what.

Remember,¬†Velocity is Not Acceleration. When managers abuse velocity and use it to measure the team members (not even the entire team!), they create schedule games and a toxic team environment. At best, a manager’s abuse of velocity leads to people taking shortcuts and incurring technical debt. At worse, it destroys teamwork.

Managers can create the environment in which people can succeed. Especially in agile and lean, managers do not have to “incent” people, or push people to do well. People will do a good job because they get feedback often and they want to. When managers attempt to manipulate an environment to deliver more with less work (what they think agile is), I’m not sure if anyone can succeed.

I asked my client if the managers understood what agile might mean for them, as managers. He was sure the managers had no idea.

I suggested that trying agile in this environment would give agile a bad name in the organization. I suggested these alternatives:

  • Ask about the three questions that might help the managers articulate their goals. See Define Your Agile Success.
  • Do a simulation with management to have them feel what agile is like.
  • Explain the system of agile and how the ideas that management have is not helpful.
  • Request a reasonable environment for a short-ish timebox (I was thinking about a month, maybe two months) to show management that their ideas are not the only ideas that could work. I suggested a number of measures my client could suggest to his management.

Don’t start agile in a toxic environment. It’s not worth it. Agile is wrong for you. Remember that Agile is Not a Silver Bullet and Agile is Not for Everyone.

Remember, agile is a cultural change, not merely a project management framework. Instead of agile, consider using all the ideas of agile to show steady progress and decide how to influence your managers.

Instead of agile, consider using all the ideas of agile ( for example, teamwork to deliver small chunks of value) to show steady progress and decide how to influence your managers. Don’t ask teams to be collaborative when management wants to stay command-and-control.

Categories: Project Management

When is Agile Wrong for You?

People often ask me, “When is agile¬† right or not right for a project?” I’ve said before that if the team wants to go agile, that’s great. If the team doesn’t, don’t use agile.

That answer is insufficient. In addition to the team, we need management to not create a bad environment for agile. You might not have a great environment to start. But a bad environment? That’s a horror show.

I had a coaching conversation recently. My client¬†has a typical problem. He sees multiple ways to accomplish the work. He’s taking ideas from agile and lean, and smashing them together to create a project approach that works for them, at their company. It’s not quite agile. And, that’s the sticking point.

His management wants to “go agile.” They have no idea what that means.They think agile is a way to get more good stuff faster with less cost. It’s possible that with agile approaches, they can achieve that as a by-product. To be honest, any approach that stops people from waiting for phases to finish will help. That’s not necessarily agile.

The management team does know about one of the well-known approaches. They want everyone to go through that training. My client doesn’t think this will work. He has a number of concerns:

  • Management wants to control how people work at the project level. Management wants to define the iteration duration, what the standup questions will be, who will be on which team, and what the teams will do. (That’s enough right there, but there’s more. They are geographically dispersed across the globe. Going with an out-of-the-box solution does not make sense.)
  • Management wants to use team measurements for personal compensation. Specifically, they want to use personal velocity as a way to compensate people. (This is stupid, dangerous and wrong.)
  • Every manager my client has spoken with thinks that he or she does not need to change. Only the tech people need to change. (They could not be more mistaken.)

If you work in an agile organization, you know the problems with these assumptions.

Teams manage their own work: their intake is via the Product Owner. They decide how to work, flowing work through the team. Hopefully, the team focuses on their throughput, not who does what.

Remember,¬†Velocity is Not Acceleration. When managers abuse velocity and use it to measure the team members (not even the entire team!), they create schedule games and a toxic team environment. At best, a manager’s abuse of velocity leads to people taking shortcuts and incurring technical debt. At worse, it destroys teamwork.

Managers can create the environment in which people can succeed. Especially in agile and lean, managers do not have to “incent” people, or push people to do well. People will do a good job because they get feedback often and they want to. When managers attempt to manipulate an environment to deliver more with less work (what they think agile is), I’m not sure if anyone can succeed.

I asked my client if the managers understood what agile might mean for them, as managers. He was sure the managers had no idea.

I suggested that trying agile in this environment would give agile a bad name in the organization. I suggested these alternatives:

  • Ask about the three questions that might help the managers articulate their goals. See Define Your Agile Success.
  • Do a simulation with management to have them feel what agile is like.
  • Explain the system of agile and how the ideas that management have is not helpful.
  • Request a reasonable environment for a short-ish timebox (I was thinking about a month, maybe two months) to show management that their ideas are not the only ideas that could work. I suggested a number of measures my client could suggest to his management.

Don’t start agile in a toxic environment. It’s not worth it. Agile is wrong for you. Remember that Agile is Not a Silver Bullet and Agile is Not for Everyone.

Remember, agile is a cultural change, not merely a project management framework. Instead of agile, consider using all the ideas of agile to show steady progress and decide how to influence your managers.

Instead of agile, consider using all the ideas of agile ( for example, teamwork to deliver small chunks of value) to show steady progress and decide how to influence your managers. Don’t ask teams to be collaborative when management wants to stay command-and-control.

Categories: Project Management

Book of the Month - IT Project Estimation: A Practical Guide to the Costing of Software

Herding Cats - Glen Alleman - Tue, 05/24/2016 - 04:42

IT Project EstimationEstimating is part of all decision making in the presence of uncertainty. Accuracy and precision are two primary attributes of all estimates.

We all know estimates are hard. But there are lots of hard things in the development of enterprise software. We wouldn't be whining about how hard it is to construct a good First Normal Form database schema, or bullet proof our cyber security front end from attack by the Chinese would we.

So why is estimating a topic that seems to be the whipping boy for software developers these days?

My first inclination is that estimating is not taught very well in the software arts. In engineering schools it is. Estimating is part of all engineering disciplines. One undergraduate and one graduate degree is in physics. Estimating is at the very heart of that discipline. A second graduate degree is in Systems Management - which is a combination of Systems Engineering and Managerial Finance - how to manage the technical processes of engineering programs with the principles of managerial finance, contract law, and probabilistic decision making.

This book comes with a spreadsheet for making the needed estimates to increase the probability of project success. It opens with an important quote that should be a poster on the wall of any shop spending other people's money

For which of you, intending to build a tower, sitteth not down first, and counteth the cost, whether he have sufficient to finish it? Lest haply, after he hath laid the foundation, and is not able to finish it, all the behold it begin to mock him, saying, This man began to build, and was not able to finish - Luke 14:28-30

 

Categories: Project Management

Thoughts on Suggestions That Violate Principles of Finance, Probability, and Statistics

Herding Cats - Glen Alleman - Mon, 05/23/2016 - 21:26

The on-going discussions that Decisions can be made in the absence of estimates reminds me of this concept.

 

The conjecture that we can manage in the presence of uncertanty without estimating the impacts of our decisions, willfully ignores uncertainties in the present and future that will impact our outcomes, the external governance frameworks of managerial finance, probability and statistics of the processes under management, and regular governance processes and the decision rights of those governance frameworks.

Those decision rights by the way belong to those paying, rarely to those spending. So the decision to estimate or not estimate rarely belongs to the developers spending the business's money.

When the claim that #Noestimates critics say we're simply not being Opened Minded those advocates  want us to accept that everything can be challenged, without any basis for that conjecture. If that were the case, those proforring #Noestimates fit right into those believing the pseudoscience of spending other people's money in the presence of uncertanty.

Thanks to Peter Kretzman for the link to the video.

Related articles Intentional Disregard for Good Engineering Practices? Calculating Value from Software Projects - Estimating is a Risk Reduction Process How to Estimate Any Software Problem Quote of the Day - All Things Project Are Probabilistic Probability and Statistics of Project Work How We Make Decisions is as Important as What We Decide. An Example of Complete Misunderstanding of Project Work Intellectual Honesty of Managing in the Presence of Uncertainty Some More Background on Probability, Needed for Estimating Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Quote of the Month May 2016

From the Editor of Methods & Tools - Mon, 05/23/2016 - 08:59
In other words, estimating is the key to unlocking the ability to commit. The ability to commit to near-term deliverables is the key to building a reliable, agile enterprise. So, there are good business reason why we need to take a harder look at this funny agile estimating thing. Source: Agile Software Requirements, Dean Leffingwell, […]

Quote of the Day

Herding Cats - Glen Alleman - Mon, 05/23/2016 - 02:05

"It is the mark of an instructed mind to rest satisfied with the degree of precision that the nature of the subject admits, and not to seek exactness when only an approximation of the truth is possible." Aristotle 

 

Categories: Project Management

Discovery Projects Work for Agile Contracts

Marcus Blankenship and I wrote an article, Stay Agile with Discovery, to discuss how to help your clients see the benefits of working in an agile or more agile way.

We have seen too many clients want “agile” and not want all the responsibilities that being a Product Owner or customer involves. If your client asks you to be agile and then demands you estimate “everything” and provide a fixed cost, fixed scope “agile” contract, you don’t have to say, “NO.”

You can say, let’s try a discovery project so we (as the provider) can explore what it would take to do “everything.” As we finish this first discovery project, where we will provide working product, you can provide us feedback. Based on that feedback, we might do another discovery project. In fact, you can work in month-long (or two-week long) discovery projects all the way through. Your client can ask for changes that you incorporate into the next discovery.

That’s just one way to help people learn about collaboration and resilience over contracts and guarantees.

If you are a Product Owner or a person who represents the customer, you might like our Practical Product Owner workshop.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Thu, 05/19/2016 - 17:32

Do not deny the classical approach, simply as a reaction, or you will have created another pattern and trapped yourself there.
‚ÄĒ Bruce Lee

Any new innovative or revolutionary suggestion in the software development world, needs to be anchored on the established principles of how to manage the spend of other people's money. If it's your own money, spend as you please - no one cares.

But if you're spending other people's money to produce value in exchange for that money, those providing the money likely have a fiduciary obligation to know something to some level of confidence how much it will cost, when it will be done, and what they'll get for that that cost and time.

To suggest otherwise without a foundation of principles by which this new and innovative idea can be tested is selling snake oil to the uninformed. That approach has worked since the dawn of time - I have the solution to your unnamed ailment, just try this magic elixir and all will be better. 

Categories: Project Management

Velocity is Not Acceleration

I see a lot of confusion around velocity in new-to-agile teams.

Too many people treat velocity as an acceleration measurement. That is, they expect velocity to increase to some large number, as a stable state.

Velocity is a rate of change coupled with direction. When managers think they can measure a team with velocity, they confuse velocity with acceleration.

As I enter a highway, I have a higher rate of acceleration. As I continue to drive, I achieve a stable state: I get into a lane¬†and maintain a constant speed. (Well, with any luck.) I stay stable¬†with¬†respect to the road (my direction). My velocity stays the same—especially if I use my cruise control. With a reasonable velocity—that might change a little with traffic—I can get to my destination.

A note on direction: ¬†I live in the Boston area, where roads curve. North, South, East, and West are useful to other people. We have highways that literally point south that have a designation of “North.” They curve. I don’t find these directions useful. I am more likely to talk about the exit number on a highway or the gas station on a side road. Direction is as contextual as is velocity.

Direction for a project is much more about finishing features. How close to “done” are you? More on that below.

When managers try to use velocity as acceleration, they create schedule games. See Double Your Velocity. That often leads to people taking shortcuts and incurring technical debt.

What can you use instead of velocity? The feature burnup/burndown chart and the product backlog burnup chart.

Program.Feature.Chart_ This chart is an example of a feature burnup/burndown chart.

You chart the total number of features (the green line that wiggles at the top), the features complete (the burnup red line that continues to increase), and the features remaining (the burndown in blue, the line that proceeds down). I like this chart because you can see if things get a little “wonky” during the project.

If you add too many features faster than the team can finish features, you will have a large gap between the green and red lines. The blue line will go up. This chart shows you that. You can see how close to done you are for the project.

Product Backlog Burnup Chart (several iterations/milestones)

Product Backlog Burnup Chart (several iterations/milestones)

I also like the product backlog burnup chart. This shows how much progress a team (or teams) make on all the feature sets. (That helps people realize they should define feature sets. Feature sets help the team see where the product is headed.)

In this chart, the team works on feature set 1 (FS 1) and feature set 2 (FS 2). Those stories are more valuable than anything in feature set 3.

You can see that feature set 2 increased in the number of stories for the 5th milestone/iteration. That also helps people understand when they can expect the project to be done.

Measuring velocity¬†can help a team see what’s happening. See Value of Burndown and Burnup Charts.

However, velocity is for a team. Velocity helps a team see its context over some time period. They get to decide how to show it and what to do about it. If management wants to see progress, the team can measure the features complete, remaining, total chart and the product backlog burnup chart. (I would also measure cumulative flow to see how much work in progress the team has.)

Don’t measure velocity to see progress. ¬†That’s not the measurement you want or need.

Categories: Project Management

Writing Workshop Starts on August 24, 2016

I had a great time with my previous version of the Non-Fiction Writing Workshop: Write Non-Fiction to Enhance Your Business and Reputation. I am offering it again, starting this August 24.

I added another week, so you have the chance to practice more. I am also offering a personal accountability option. If you want, you can track your writing (words or minutes) in a group spreadsheet.

If you want to improve your non-fiction, start with your non-fiction writing, or nudge yourself to writing that book, please join me in the workshop. I’d love to work with you.

Categories: Project Management

Podcast About Agile and Lean Program Management with Ryan Ripley

Ryan Ripley and I spoke on his Agile for Humans Podcast, Agile Program Management with Johanna Rothman.

 Scaling Collaboration Across the OrganizationWe had a blast. We spoke all about Agile and Lean Program Management: Scaling Collaboration Across the Organization, estimation, value, and much more. I hope you listen.

Categories: Project Management

Lean Funding

NOOP.NL - Jurgen Appelo - Tue, 05/17/2016 - 17:02
lean-funding

The traditional way that we fund startups is broken.

I know what I’m talking about. My own startup failed in the early 2000s, though it was just a minor failure. I blew away “only” 1 million euros of investors’ money on a business model that never really worked. When the dot-com bubble burst, my startup’s demise was nothing more than a dog’s fart in an imploding galaxy.

With perfect hindsight, I know what we did wrong. Our business model was unsustainable, but we had no talent for switching to another. We could have benefitted from the Lean Startup method: iterate with small production cycles, validate with paying customers, and pivot when things don’t work. We might have changed direction faster. But I think the Lean Startup approach only addresses half of the challenges of entrepreneurs. The other half could be dealt with using Lean Funding.

Less Prediction

When bootstrapping (self-funding) and crowdsourcing are not valid options, entrepreneurs usually turn to angel investors for seed capital. To obtain this capital, entrepreneurs engage in an elaborate courtship ritual with potential investors. In return for the investment, the angel investor gets equity ownership. The great challenge is: how much capital for how much equity?

Because there is often no inventory and there are hardly any sales, it is common to guess potential sales of the new company so that investors can calculate the current “value” of the business. Here, the entrepreneurs have reason the exaggerate the potential of their fledgling business to epic proportions, drawing hockey stick diagrams of fabulous “projected revenues” that are even larger than their egos.

I did that too, many years ago. I even won a business plan contest with it. With traditional seed investments, optimistically “predicting” the future is rewarded because if you’re not a naive optimist, you won’t get any money. Now I realize that my business plan and its impressive diagrams should have been classified as a work of fantasy, with lovingly crafted fantasy art.

As we have learned in the Agile community, there is little value in trying to predict the future. Startups should learn to embrace change instead of following a plan.

Less Negotiation

The mating ritual of entrepreneurs and investors is interesting to watch, but I consider it a complete waste of everyone’s time. Elevator pitches, business plans, six months of networking and negotiating… Yes, entrepreneurs should spend their time selling, but to customers not to investors. However, because a “seed round” is only done once or twice, there is a lot at stake. And both parties waste a significant amount of time finding the “right” balance of capital and equity.

I remember having endless discussions with my investors, trying to convince them that, no really, my ideas were thoughts of pure gold, and they just needed to sign on the dotted line.

The whole process is suspiciously similar to getting agreement over a requirements study with a large customer. Because both parties want to go through this ordeal only once, it only makes the process more complicated and more agonizing. After the signature on the deal, there is no way back!

The Agile Manifesto teaches us that customer collaboration is more important than contract negotiation. Every minute you spend talking with investors about imagined customers is one minute not spent collaborating with real clients.

Less Documentation

I still have the legal documents of my failed startup, with all its impressive signatures. These papers not only cost me a lot of time and effort to obtain, but they were also expensive to produce. My God! The legal fees that financial and legal “experts” charged me were insane. And did they deliver any value? Not really. The papers went into a drawer, and they never came out. If I had used that money to get ourselves a room full of massage chairs, it wouldn’t have made any practical difference to our performance. Except, my startup would have collapsed more comfortably.

It would have been nice if we had a product that was being used, and paid for, by a customer. After all, as agilists, we have learned that working products are more important than comprehensive documentation. I’m not saying that you can simply run a business without any documents. But the effort and costs that went into producing legalese could have been better spent on finding customers first.

Less Capital

The more you have, the less it’s worth. When you only have a small amount of money to pay your bills, that money will be worth a lot to you. But when you have so much money that it doesn’t even fit on one bank account in one country, you’re probably not using it with care.

I remember spending a ridiculous amount of our startup capital on some overpriced professional bookkeeping software because I felt the need to plan ahead. My diagrams in the business plan said that we would be making a huge amount of money from customers in a few years, and I had just received several tons of capital from my investors. So, why not purchase the Ferrari of bookkeeping programs? At least nobody could say that I lacked the will to invest in the future.

You can find similar stories of well-funded startups about overpriced tools, outrageous perks for workers, lavishly decorated offices, and other non-value adding expenses. Startups with an abundance of cash often lack an abundance of restraint and foresight.

As agilists, we know that individuals and interactions beat processes and tools. If I had not received such a large amount of capital, I would not have been able to waste it on useless tools and perks. Instead, I might have invested more time in networking with friends and partners who could help keep the business afloat at a minimum of expenses.

Lean Startup + Lean Funding

A friend asked me recently to invest in his startup. I like his business idea, and I think he is someone who could make it a success, with a bit of help. However, now that I was suddenly asked to sit on the other side of the negotiation table, I wanted to think more deeply about my own (bad) experiences with funding and how the problems that I described above might be addressed with a more Agile and Lean mindset.

Less prediction, less negotiation, less documentation and less capital. That is what many entrepreneurs should strive for, in my opinion. The Lean Startup method, useful as it is, doesn’t deal with these issues. It offers an approach to creating products and services that work, with a clear focus on getting money from customers. But it offers no suggestions on funding the business, by receiving money from investors.

So, let’s solve that problem! Here’s what I have come up with.

Valuation

There are several ways of assigning a value to a business. You can calculate assets minus liabilities, and add some goodwill on top, but this won’t get you very far with a startup which doesn’t have any of that. The only “assets” of startups are the founders themselves, which is exactly what many angel investors value most when they offer an entrepreneur seed capital: they believe in the person. I admit, I could be quite charming 17 years ago.

Another way of calculating a value is by taking the revenue of the business and multiplying it by an industry-dependent number. For example, an accountancy firm may be worth its annual income times 100% but a pharmacy may be worth its revenue times 25%. These are just rules of thumb, of course, but it’s better than nothing. The startup we want to invest in probably has little or no revenue, but that doesn’t matter. We know in which sector it operates, and there should be revenues soon enough. The entrepreneur will make sure of that. (Keep reading!)

The third way is to base a startup’s valuation on future earnings. The Discounted Cash Flow method is the most famous example of that. But, as a true agilist, I refuse to go there. What the company may or may not earn in the future is interesting for futurists and fantasists, not for a lean investor.

Conclusion: with a startup we can only base valuation on the worth of the entrepreneur and the sales he can generate. We can make a simple funding formula for this. For example, Value = 100K * Founder + 100% * Annual Revenue. In other words, the value of the startup is 100,000 euros for each founder, plus any revenue earned in the last twelve months.

Iteration

With a traditional seed capital approach, the valuation and funding process easily takes months. But when something is hard to do, agile thinking suggests that we should do it as often as possible, in small iterations, which forces us to keep things simple. Well now, we have a formula, which means we can apply it anytime we want, for as long as it works!

For example, on January 1, the entrepreneur doesn’t have anything, except for his smart brains, and therefore his business is worth 100K. But if he works hard on validating his business model in the first three months, maybe he can send a couple of invoices worth 5K in Q1. This means that annual revenue (last 12 months) is 5K on April 1, and the value of his startup has grown from 100K to 105K.

Maybe by the end of the year, the entrepreneur will have earned 40K, and his startup will be worth 140K. Obviously, when he wants the value of the business to increase further, he will have to sell more in Q1 of next year than he did in Q1 of this year.

Investment

Now comes the interesting part: at any time during the year, the entrepreneur can ask for investment. The amount of capital that he asks for will (if the investor agrees) be traded against equity in the startup using the valuation at that moment.

For example, in January, the entrepreneur asks for a 10K investment, just to get started with the business, purchase some essentials, and pay the fees of one or two part-time workers. A 10K investment in a 100K startup means the investor gets a 10% stake in the company at that time. Three months later, the entrepreneur asks for another 10K. However, now the value of the business is 105K. Therefore, a 10K investment results in an additional stake of 9.52% in the company. The price of equity has climbed a little because the entrepreneur made a little bit of money.

By generating revenue, the entrepreneur will be able to trade away less of his business to the investor. A year later, at a valuation of 140K, an additional 10K will be traded against 7.14% of the company. With 200K in annual revenues (a valuation of 300K), a 10K investment would be worth just 3.33%.

With this investment approach, the incentives for the entrepreneur are in the right place: He should validate his business model as soon as he can, with paying customers, because actual revenue will drive the price of the shares up. He will be giving away less for more. He should also ask for as little money as possible, just enough to survive in the next few months. Because asking for too much means trading away equity at a price that is steadily climbing. As long as the business is growing, it is best to postpone each trade.

Divestment

The reverse is also possible: the entrepreneur can give money back to the investor!

For example, suppose that the business is suddenly taking off in the second year. Annual revenue turns out to be 100K, which is more than double the amount of income in the first year. The entrepreneur now has a choice: keep investing in the business in the same way? Maybe ask a bank or a venture capitalist to scale things up? Or just grow the business naturally with cash from customers?

Either way, the entrepreneur can try to buy back his shares from the first investor. But the investment formula still applies, which means the entrepreneur has to pay a much higher price for the equity than the price at which he sold it. If the investor agrees to sell, he will have made a nice return on investment. It will all depend on the situation and plans of the investor and the entrepreneur in the future. Maybe they decide to choose the long road and aim for an IPO. Maybe some other opportunities come up, such as an acquisition by a larger firm. Right now, they don’t know, so it’s better to keep all options open, including divestment.

Formalization

Investments and shares in the company can change hands at any time, but that doesn’t mean that you need to formalize everything with legal documents in those early stages. Nobody cares about legal documents, except the overpaid experts who make them. Between an early investor and an entrepreneur, a simple I.O.U. with a signature should suffice. If they don’t trust each other, they shouldn’t be collaborating anyway. Formalization of ownership status can be done later, or at longer intervals.

Lean Funding

I am going to start experimenting with Lean Funding. Diversifying your investments is always a good idea, is what the experts say. Investing everything I have in my own business is therefore not a wise approach. It’s better to let some of my money work for friends and partners who have good ideas and a talent to realize their dreams.

But I will not be interested in plans and projections for the future. Entrepreneurs can share their fantasy stories with their spouses and children, but I will want to see actual achievements regarding sales. I want to invest in startups that generate revenues, not forecasts.

I will also not waste much time on negotiations. We will use a funding formula that will be more or less the same for different entrepreneurs. And once we’ve agreed on the formula, we use it for all further investments or divestments. No startup will waste its time on my negotiation table. I want to see them sell great stuff to clients, not to me.

We will waste none of the money I invest on legal experts and documents. Of course, we will sign a simple one-page I.O.U. that should even hold up in court. But capital should be used to create working products and services, not comprehensive documentation.

Last but not least, I will invest as little as I can get away with to keep the startup alive. Lean Funding should be like a life support system for newborn businesses when their caretaker(s) lack sufficient funds. But I’m not going to bathe the newborn in champagne and dress it in robes of silk and silver. One pair of shorts will be enough.

Lean Funding is a perfect companion for Lean Startups. It allows entrepreneurs to focus on individuals and interactions, customer collaboration, working products, and responding to change. While the Lean Startup approach guides the development of products and services, Lean Funding takes care of the capital needed to make them.

At least, that’s my hypothesis.

Let’s start the experiment!

(c) 2011 Images Money, Creative Commons 2.0

My new book Managing for Happiness is available from June 2016. PRE-ORDER NOW!

Managing for Happiness cover (front)

The post Lean Funding appeared first on NOOP.NL.

Categories: Project Management

Don’t Estimate the Sprint Backlog Using Task Points

Mike Cohn's Blog - Tue, 05/17/2016 - 15:00

Back when I was writing Agile Estimating and Planning (the 2005 book, but now it’s also a video course), I had already been studying and experimenting with estimating approaches for five years. By conducting experiments with various teams, especially those that worked directly for me, I felt I had learned enough to write that book.

But there was quite a bit I didn’t know (there still is, of course!), and so I sought out teams that were estimating or planning their projects in ways that differed from the advice I was giving. A few of these teams were using task points to estimate their sprint backlog items in conjunction with story points for the product backlog items.

This was intriguing. By then, I had already become a proponent of story points--I’ve since become even much more of a proponent because of the advantages that story points offer. But I couldn’t see why a team would use task points. However, because I was such a fan of story points, I had to learn more about teams using task points.

To do that, I talked a couple of the teams using task points into letting me visit them so I could see what they were doing and learn more about it.

What I learned confirmed my suspicion that teams should not estimate sprint backlog tasks in task points.

The Main Benefit of Story Points

The main benefit of story points is that they allow individuals with different skills, experience levels and backgrounds to agree on a relative estimate for work.

As a silly example, suppose that an octopus and I each estimate the effort to wash my car.

The octopus has four times as many arms as I do. So, presumably, the octopus can wash my car four times faster than I can. (I told you it was a silly example. Go with it for a minute.)

But the octopus will also be four times faster than me at washing any car. So, the octopus and I can agree that perhaps my two-seat car can be estimated at five story points and a second, larger car can be estimated as 10 story points.

So, then, story points allow the octopus and I to agree on a number of story points, even though the octopus is presumably much faster than I am at washing cars.

Task Points

What I learned from the teams I visited was that a task point was nearly identical to a story point. All the teams I interviewed, though (or have talked to subsequently), wanted to use a more granular unit than their story points.

For example, a team that finished 10 story points per sprint might complete 80 task points per sprint.

Teams simply wanted a smaller, more granular unit to better track progress on things. It would be equivalent to a car’s speedometer reporting speed in light years per hour. That would make it very hard for me to know if I’m exceeding the speed limit.

Introducing a more granular unit was a good idea for many teams. After all, it’s really hard to gauge daily progress using story points for a team that finishes seven story points in two weeks, for example. For many points, story points are simply too large to be useful for this.

But We Already Have More a More Granular Unit

However, a more granular unit already exists. And it’s one that every team member is already familiar with: hours.

When I looked at teams estimating in task points, I could not find an advantage over simply estimating sprint backlog tasks in hours.

There’s a fundamental difference between product backlog items (most commonly, user stories) and sprint backlog tasks: a typical product backlog item will be worked on by three to five people, perhaps a programmer or two, a tester, and maybe a designer, architect, analyst or technical writer and so on. A task on the sprint backlog will usually be worked on by one person.

This fundamental difference means it is not vital for everyone on the team to agree on a task estimate as they should on a product backlog item estimate. Everyone on the team has the right to have input on a task estimate, but those who will do the work should ultimately be the ones who establish the estimate.

If there’s only one person who is likely to do a specific task, put that person’s estimate on the task. If two or three people might do the task, use a consensus estimate among those individuals or use the estimate of the person most likely to do the work.

If, during the sprint, the work is reallocated to someone else, the worst that will happen is that estimates will swap between tasks. A speedy team member picks up the work of a slower team member and changes an estimate from eight to four, and vice versa.

Why Not Task Points

This leaves task points without a compelling advantage over hours. Yet task points have all the drawbacks of story points:

  • A foreign concept to many team members
  • The need to establish baseline values against which relative estimating can begin
  • A concern that estimates drift over time in comparison to the original relative values
My Advice

I finished my foray into learning about task points unconvinced of their value. I continue to advocate commitment-driven sprint planning as it’s commonly known. But perhaps capacity-driven sprint planning is a better name. I find it to have significant advantages over velocity-driven sprint planning.

Commitment- or capacity-driven sprint planning in hours works best for most teams. Some teams follow that general process, but throw away the estimates, using them only as a tool during the meeting to figure out what to bring into the sprint.

Other teams don’t estimate sprint backlog tasks at all in any unit. Either of these approaches works well once a team has some experience with the approach.

I’m glad I undertook my project to learn more about task points and the teams using them.

In learning about alternative approaches to estimating, I’m always disappointed when a new approach doesn’t turn out to be better than an existing one. But, many don’t.

Yet, it’s by looking at as many options as possible that we find the continuous improvements every agilist seeks.

What Do You Think?

Have you used task points? Did you find advantages to them that I’ve overlooked? Please share your thoughts in the comments below.

Software Development Linkopedia May 2016

From the Editor of Methods & Tools - Tue, 05/17/2016 - 13:44
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about software engineering myths, programming career, fixing things, optimization projects, mobile testing, minimum viable products, scaling Agile, lean business analysis and javaScript testing at Facebook. Blog: Exploding SoftwareEngineering Myths Blog: Single […]

New Practical Product Ownership Workshop Dates

I just posted the dates for the next Practical Product Ownership workshop: Deliver What Your Customers Need. It starts Aug 23, 2016.

You need this workshop if:

  • You are having trouble doing everything in your PO role, you might be trying to do too much. See Product Manager, Product Owner, Business Analyst?
  • You are having trouble deciding how to organize your backlog, roadmap, and everything.
  • How to value the items you do organize. We discuss Cost of Delay and seven other possibilities to rank the items.
  • How to help people articulate the problems they want the team to solve, not the solutions.
  • And much, much more.

We meet twice a week for six weeks. Our first meeting is a 90-minute teaching call, where I teach and you ask questions. We meet later that week for a 60-minute coaching call, where you bring your problems, concerns, and challenges.

I estimate you will have about 60-90 minutes of homework every week. Any other questions? Email me.

Categories: Project Management

Learning Through Research

Herding Cats - Glen Alleman - Sun, 05/15/2016 - 16:30

A primary learning process is research. This process is part of all science, engineering, management processes. Here's a starting point for learning how to estimate in the presence of uncertainty on agile projects.

This is the start of a literature search. Anyone making suggestions about making decisions in the presence uncertainty on agile project can start here for establishing the basis of any arguments of how and why that suggestion (conjecture possibly) is based on some set of principles. Not just anecdotal opinion.

Evm+agile estimating from Glen Alleman Related articles Debunking Failure is not an Option Project Risk Management, PMBOK, DoD PMBOK and Edmund Conrow's Book
Categories: Project Management