Throw away everything you know about how your current software process works. Seriously. Throw it all away and I promise you will be ok. Well, maybe.

Fifteen years ago a new way of building software was introduced to the world:

We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Sound familiar? Those were the founding principles of Agile.

What happened next? We took those principles and started adding process methodologies and ceremonies. We now call one of those processes methodologies scrum.

  1. Planning: Let's figure out what we need to build.
  2. Scrum: Let's add a daily meeting
  3. Sprint Review: At the end of the sprint lets demo our stuff
  4. Sprint Retro: Look back on the previous sprint, and challenge potentially broken processes.

If I was slinging code back in the 90's I would have been living the dream. During that time the field was not oversaturated with people that weren't actually the building the software. We had small teams getting stuff done.

Fast forward 15 years later and what does scrum life look like?

Well we first talk to stakeholders and document user stories.

We groom those user stories to add as little detail as possible without adding the how.

We then have planning poker sessions where we attach points (without knowing the how or who). Points? Yea points. Not hours, not days, lets use pointsFibonacci numbers. That really seems natural.

We then attempt to groom it. We add more details and potentially a better estimate. We declare the story ready to build and then pace it on the shelf of things that we might build some day.

We enter sprint planning where we then try to add tasks, hours, and assign out work. We really we don't remember anything from backlog grooming. We can't add tasks or hours without the "how". So lets go ahead and try to solve 2 weeks worth of work in 2 hours.

Great now we are done, lets see if it fits in our arbitrary 2 week sprint interval. But lets not look at the hours lets look at our velocity. How many points are we committing to?

Then we build finally!

Everything goes to plan (sarcasm).

Time runs out. The team demos semi-working software. I say semi because some of it has not been throughly tested, or might look great but is constructed haphazardly.

Stakeholders are impressed. When do we go live? Well....

Sprint is done lets do a a retrospective. Instead of honest and natural conversation let's play a game to try to make it fun.

Really? That's how we want to predictably build software? If we are lucky our process ensures 1 of the 4 founding principles: Working Software.

Now throw away everything you know about how your current software process works. Seriously. Throw it all away and I promise you will be ok.

Now what would you do?

  1. Discovery: Alright guys what is our budget, timeline, and critical stuff? Lets research a bit to figure out what we are getting into.

  2. Timelining & release planning: We have a rough idea of everything that needs to be built and the time we have to build it. How are we going to incrementally build this product? What are the "riskiest parts? What do we want to maximize? What are the nice-to-haves?

  3. Planning: Plan for the first milestone? Define the how. Make the decisions as a group now that will enable us to swarm? What will it look like, how & when will we test it? Do the technical design, decompose features into tasks. Identify dependancies between the team and tasks. Assign worst-case hours. Determine things that need approvals. What are our check points? When are we done?.

  4. Build: Iterate on all the features that are needed for the first milestone. Do the important stuff first, polish last. Keep an eye on budgets. If you start running over reach out for help and negotiate out the unimportant. Don't rush to stabilize, its natural for software to become unstable during a productive cycle. The goal is to maintain a healthy level of entropy that maximizes the development of features, but low enough that it doesn't slow or disrupt the team. Be proud of your work, and honest about shortcuts you had to take or challenges you faced.

  5. Done: If there is free time invest in the stuff you feel is important. Document, cleanup, write tests, polish, make anything better!

  6. Reflect: How did we do? Celebrate the victories & accomplishments. Challenge the failures. Take a look back at the plan. Where did we deviate from the plan? How was our technical design? What did we learn? How accurate were our estimates? Talk about them and most importantly learn from them.

  7. Repeat!

Develop common sense over building a process .

It boils down to teaching people the natural way of building software. Ironically, there is nothing natural about producing software. Murphy is lurking in the depths of any complex idea. Encourage teams to ask and understand why? Learn from your mistakes, but never repeat them. Develop principles. Principles empower people to think, they are the tools teams rely on to adapt to the changes or new challenges, and they reduce the need for process.

Fast, Good, and Cheap software is built by small teams chaperoned by common sense. If you do those things, your methodology doesn't mater.