It isn’t the fast that eats the slow, it’s the correctly funded and managed that eat the incorrectly managed and funded.


It isn’t the fast that eats the slow, it’s the correctly funded and managed that eat the incorrectly managed and funded.

Years ago there was a book by Jason Jennings and Laurence Haughton called It’s Not the Big That Eat the Small…It’s the Fast That Eat the Slow: How to Use Speed as a Competitive Tool in Business. Though the book was good, it failed several points, at in my not so humble of an opinion was not a failure of the authors.

  • Just because you read the title, doesn’t mean you understand the point of the book.
  • Pushing faster does not remove the need to pay for enough staff to do the work, or trim the features.
  • Pushing faster does not remove the need to understand status and product issues, such as using the product, and how does it work. The person who is at the top of the push must be as much a stakeholder with this knowledge at the person pushing on the frontlines of development.
    • This means that they must understand the realities impact from their decisions.
    • No means no, I don’t mean from the person pushing, but from the people doing the work. Find out why they have that claim. Sometimes it is because they don’t understand, mostly because the person pushing doesn’t understand.
  • No arbitrary estimations.
    • Arbitrary estimations from someone not doing the work means that they are making massive assumptions. These assumptions usually fail.
    • People doing the estimation who are working on the product may have more information, but that doesn’t mean that they actually know what they are going to do, until they actually have to work on it.
  • Some estimations must be done.
    • I really hope you are reading this and not claiming the TL;DR rule.
    • Sprint, or feature estimation are realistic, and can be used to help provide a two week estimation.
    • A collection of two week estimations can be used for getting a general velocity. With this general velocity, you can get an idea of how long before the project is ready to go live.
  • Over documentation is as poisonous as under documentation
    • The hands on builders are generally the worst documenters, don’t ask them to create the core documentation.
    • Product owners are horrible code documenters. Have them document the features, and the user experience.
    • Good enough can be good enough, if it answers the following
      • Who is the user, or who will receive this.
      • What will it be used for.
      • When will is be used. This is both time and scenario.
      • How will it be used. This is normally the user experience.
      • Most importantly: Why will this be used. What problem are you trying to solve.
  • Just because you have a vision, doesn’t mean that it is shared with everyone else. Stakeholders must stay invested throughout the project, so that they can be part of the solution, and not the guy on delivery who says that this is broken, and claims the product isn’t useable.
    • Without participation by the stakeholders, the stakeholders are as much at fault for a failure as the people doing the work.
    • With participation by the stakeholders, they get to participate in keeping the product on the right track.
  • More bodies does not equal more productivity. When you add bodies, you are adding management, and communication overhead. When you add bodies, you are adding on-boarding time. That time hits the whole team, not just the new people.
  • Not adding more bodies does equal not more productivity. The real solution is, if you want more speed, assume that you will have a marked slowdown, and a re-escalation of speed, as the team gets back into the groove.
  • Just because it is said, doesn’t mean it is done. If you don’t actually track your discussions, and requests, they you will make wrong assumptions.

Summary: Good Management, Reasonable Expectations, Competent Participation, and Expending the right investment on the development team will ultimately help you achieve the goal of being faster, so that you can eat the bigger fish.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.