Worst thing the team can build is a great solution looking for a problem to solve. Does it works? Yeah! And who are we going to sell it to? … (awkward silence) … (more silence) … Eeeeerrrr.
Then, you need to work on things that provide value to customers.
Lowdermilk and Rich proposed some tools:
“How might we [fill the gaps]?: start stating a problem based on what the customer can’t do (yet) and should be able to do (once we fix the problem).
“What else?”: based on feedback from the previous question, search deeper to uncover new problems or to divide the problem into smaller ones.
Generate ideas: once the team feels comfortable understanding the problem, it can start generating ideas.
Once the team has identified problems (whether top-down or bottom-up) and generated ideas (on a “How might we?” basis), they need to sort them out.
Essentially, you organize your ideas into a 2×2 matrix, comparing the impact on customers with the effort for the team. In terms of direct impact on customers, the ideas that have a higher impact are projects that the team believes will improve customer value, satisfaction, desirability, or usefulness.
When you make a first-guess estimation, you are using your crystal ball to see the future.
Once you start working into the problem, getting deeper into it, it’s possible to find that the whole task was easier than expected. But it’s not likely.
Usual thing is, in fact, that once you start analysing, you’ll find it harder than you thought. If you inspect a drop of water under the microscope you’ll discover a lot more complexity than you found at first glance.
Besides, if you failed on the good side estimating one task that you estimated for 2 hours, you’ll save at most 2 hours. But if you failed on the bad side, this task could take you 4 hours, 4 days, 4 weeks, 4ever… The advancement is limited, but the delay could be infinite.
McConell’s representation of the Cone of Uncertainty (via Construx.com)
I never liked McConell’s representation of the Cone of Uncertainty. Since both curves (best-case and worst-case) are symmetric, the sensible difference in ACTUAL AMMOUNT OF TIME to completion is not perceived but for the trained eye.
A one-hundred-hour estimation in the initial concept could become a 25 hour (best-case x0,25) execution or a 400 hours one (worst case x4).
The ratio is symmetric (I estimated in 100 hours and it could be 4 times more or 4 times less than that). But the difference in effort is brutal.
Best case: 100 hours turned into 25 hours. You saved the company 3 weeks of work.
Worst case: 100 hours turned into 400 hours. Bang! Your one-month project is actually a four-month effort!
I usually try with this representation so Business and customers really understand that uncertainty is not a zero-sum game.
If things result better than expected, we will have a small gain. But if risks finally hit, if doubts are always solved for the “let’s do more to avoid discussing today” instead of “review the scope to keep dates, cost and quality fixed” then things are going to take A LOT MORE to be made. What a x2 vs /2 estimation means is that you can have up to 50 hours saved in your 100-hour project but you would need to pay for 100 extra hours if things delay.
That’s why worst time to do promises on how much is going to cost the project is during conceptualization stage. This is no time to promise, but to analyse, investigate and accept trade-offs to reduce uncertainty.
That’s why methodologies like Scrum delay “commitment” until requirements are frozen. And that’s why they ask for the smallest chunk of work. And that’s why they fixed deadline.
Related: The Cone of Uncertainty (Construx.com): The variability in these factors contributes variability to project estimates — an accurate estimate of a variable phenomenon must include the variability in the phenomenon itself. As these sources of variabiility are further investigated and pinned down, the variability in the project diminishes, and so the variability in the project estimatescan also diminish.
Related: A matter of time. Estimation and uncertainty: You don’t really know. It could REALLY take you ANY AMOUNT OF TIME. From literally zero minutes, if you start working remote from home, to several hours if you’ve moved to a big, crowded city or to a nice house at the outskirts.
Related: Cone of Uncertainty (Agile in a nutshell): The Cone of Uncertainty described by Steve McConnel, shows what any experienced software professional knows. Which is at the beginning of any project we don’t know exactly how long a project is going to take.
He has a vision. A clear goal. And some clues on what needs to be done and when.
He knows what the future looks like, although he doesn’t need to know how to reach there.
So The Visionary arranges a team that can fulfill the vision. He transmits the vision to the team. And he puts on his best work so the team can fulfill the vision.
He is Ethan Hunt recruiting teammembers for his Mission Impossible force.
Ethan Hunt is a Visionary enrolling the right people in the right way for the success of the mission
Second type. The Frontiersman. The Expert.
He knows the landscape. He’s walk this same walk before. He has frequently travelled through roads similar to this one.
So a team that need guidance hires The Expert for guiding them through this road. The Expert doesn’t need to agree on The Vision, but knows how to get there. And he puts on his best work so the team can fulfill The Vision.
The Expert is Chris Adams recruiting seven magnificent mercenaries to fight against Caldera’s gang.
Chris Adams is the Expert, hired by the villagers to lead them to reach their goal
Both The Expert and The Visionary will put all their best effort and knowledge. to help the team. In the long run, The Visionary will turn an expert, and The Expert could become a Visionary. But better not confusing them in the first place.
Serving on a doubles match, in a losing effort. After a 0-6 first set, we almost came back on a 5-7 second set
You are going to fail: The only player not losing is the player not playing. Learn from failure.
Plan/Do/Check/Act: visualize the point before playing. Then play it. Then ask yourself what happened. Finally, adjust accordingly. Playing tennis you apply PDCA every minute so you end up being quite good at it.
Learn from failure but don’t let it be an anchor: best way to improve is asking, what can I improve? But once you have an answer, stick to it and forget about the failure.
Resilience: The one who gets the point is the one passing the ball over the net one more time. Be more patient than faster. Do more push than rush.
Long-term strategy. You don’t need to win every point. Trying to win the next point at all costs is usually not the best strategy. Do one step at a time, think mid-term.
Long-term strategy: A point is a point. But they don’t mean the same. Be aware of it. The most valuable point is the last one. And only until you start the next match.
Focusing on next steps: learn from the past, but think only about the next point. Slow down. Breath. Think positive. Focus.
You should play AND train: You improve by playing, you improve by trainning. But combining both will give your game a boost! You learn how to work by working. But if you refuse to train, to learn, to read, to experiment on your own time with your own resources and projects, your progress is going to be much slower than it should.
Enjoy the pressure: you can’t play if you are not willing to deal with pressure, uncertainty and exhaustion. You wont endure If you don’t learn how to enjoy while suffering.
Last but most important. First step to succeeding in a game is being aware that you are playing one. And in the end, it’s just a game.
Second, we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on.
The lead times for their tasks had been shortened, and the throughput of their system was higher than ever before. So did it really matter whether people were fully utilized?
Stop Starting, Start Finishing, Arne Roock
If you need to be able to react to change, you should allow create slack time for your team.
“It’s better that people wait for work than the other way around”, he thought […] The team members used their slack time to help their colleagues and to think about general system improvements”.
Stop Starting, Start Finishing, Arne Roock
Focusing on finishing each task as soon as possible (and not sooner) is crucial.
Stop looking on how much busy you are. Start focusing on how much work you get done.
Related:
Redefining productivity (Seth). The new high productivity calculation, though, is very different: Decide what you’re going to do next, and then do it. […] Innovation drives the connection economy, not low cost.
The Goal: to sum it up. Having inventory is bad. It’s not an asset, but a liability. Until the very moment you manage to turn it into money. Having lots of inventory makes it harder to uncover problems.
Great bosses will want you to work less. And all of this leave great bosses with the only strategy able to let them increase productivity. […] More work done in the same time.
First. Applying the Prime Directive by default usually pays.
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
Not only for your retros but for every interaction. For every piece of work.
Second. As a manager, as a leader, as a boss or simply as someone accountable for something, applying Leffert’s Law is also handy.
The Lefferts law of management: It is your fault. As a person with more power than the people who work for you, there are probably a dozen excuses in any situation for why things are not going well: don’t use them.
Don’t use it as a way to avoid root-cause analysis. But as a first step to keep the team in motion and to start looking for continuous improvement and for a better outcome.
Third. Finally, assume goodwill. Because, yeah, you guessed it, it usually pays.
In just about every industry (except electronic money transfer, apparently), assuming goodwill is not only more productive, it’s also likely to be an accurate forecast. Trust pays.
My new rule of thumb is to always assume goodwill and ignore any perceived sarcasm. Call it a Type II sarcasm-detection error. It’s hard to imagine a situation where sarcasm is the most effective way to make your point.
What a powerful combination! Trust your team and your customers. Be as accountable as possible. Leave behind all feelings that prevent good communication from happening. And then, take advantage of this lever to show up and keep doing your best work.
Agile hype has turned “waterfall” into a synonim for “worst practice”
It’s not.
“You should never be religious about methods of any kind. The only sane way to work is to let the project define the plan. Only a fool chooses tools before studying the job to be done.”
Berkun, A year without pants
Let me tell you a story.
…
Still there? Ok! Thanks. Let’s begin.
It was the end of the century. Like 1998 or something. I was trying to get my degree in Software Engineering. I was enrolled in Project Management 101. For the course you must form an ensemble with other four fellow students to create a windows (3.11!!) desktop application. But making a great application was not going to give you an “A”.
Things were so different at the End of The Century
What was important was how you managed the creation of the application. Your team should do it using a structured methodology.
Guess what was the methodology?
It was Iterative Waterfall. Requirements, analysis, design, coding, testing, release. And some feedback loops between each stage and the previous one.
Guess what? It was marvellous. And it worked.
The professor told us to take it as a real opportunity for learning by doing, since “perhaps it’s the last time you are going to work on a project with a requirements document or a testing strategy“.
You know what? He was somehow right.
Back in the Old Days, working with no clear requirements statement could be common practice in some markets and some companies. Start coding just having a vague set of wishes mentioned by some salespeople while having a coffee was not rare. Testing manually on an ad hoc basis by the same person doing the coding was quite normal in many environments too.
So what? You ask. Well, my point is that Waterfall gave you a structured approach to build software. And it works. Sometimes.
Waterfall, in its many flavours, is as every framework, ruleset, procedure and methodology a tool. Just a tool.
Know it, learn it, master it, and then you would be able to apply it when you need it. When it fits best.
Related: I would build a bridge with Agile: You need detailed planning for building a bridge, right? Right? RIIIIIGHT?No. Not right. I would build a bridge using Agile techniques. Sometimes.
Games have traditionally been competitive. Ancient olympics were war in disguise. Throwing weapons. Jumping over fences. Wrestling. New olympics get their original spirit from them. Modern pentathlon consisted of the five skills needed to be a good officer, that is, riding a horse, shooting a gun, fighting with a sword, swimming and running.
People can only be social friends if they don’t try to upstage or outsmart one another. Indeed, the classical art of conversation is to avoid any imbalance[…] You’d rather have dinner with your friends than with your professor, unless of course your professor understands “the art” of conversation
Skin in the Game (Nicholas Taleb)
Games have been traditionally competitive. Conversation has not.
Conversation is one hundred per cent cooperative. If the other person is not willing to do it, there is a zero per cent chance of a good conversation to happen.
What if next time you enter a negotiation meeting, you do it as if you were starting a conversation instead of doing it as if it is a competition?
Related: Cooperative Jenga: With Cooperative-Jenga you get longer games, cooperation and team building and a way of working based on sustainability and on helping others.
Related: Management lessons from Gears of War 2 (Scott Berkun): Like real life projects, where you can can only survive by working together, the HORDE mode is based on co-operation. You can’t get very far without working as a team.
.jpg)
