Sprint to Survive

Until successful? {
? Monday?   - feedback from sales
  Tuesday ? - re-prioritize
  Wednesday - develop the code
  Thursday ?- develop the code
  Friday? ? - build the next iteration of product
}
        

These product iterations were built on 3-? inch floppy disks and shipped to sales and customers on a weekly basis.

35 years ago building enterprise products for Fortune 500 companies our start up company practiced this process.? Without knowing it we were doing 1 week sprints. That start-up is now the second largest software company in Europe and famous worldwide. This grounding in an iterative process has stayed with me throughout my career.?

Cool new names - same fundamentals

Iterative development now has many cool names in the software industry.??

Agile, Kanban, Extreme! etc.? Cool names with ardent supporters for each.? Though in my experience most teams are not religious in following the strict rules of any and implement some kind of iterative development.? Iterative development is my preferred name for the process. In 35+ years of software development I have always used some kind of iterative development. Though it has never been exactly the same in any instance. It has to be adjusted for factors such as age of product, type of product, team size, team motivations etc.

Why does it work? There are several fundamentals to the? iterative processes.

Communication

????90% of software engineers are INTJs.? Introverts tend to communicate less than others. We have all seen the three rope swing analogy of software development.? I have lost count of how many times I have heard “this is not what I was expecting” from customers, product managers and even other engineers.

Flexibility, or is it agility ??

??The expectation should be that plans are going to change.? If you're still on plan after 6 months you might want to check your plan because the world has changed around you..

Goals

??Short term goals that, ideally, deliver some kind of product value. The magic of iterations is they provide small goals that are set by the engineers themselves.? Rather than some lofty goal set by a manager who is not close enough to understand the reality.? They also deliver some amount of concrete product value, even if it is just insight into what doesn’t work.

“We don’t do sprints”

I worked with an engineering team once that was adamant that they did not do sprints. They had a bad name for some reason and I was not even allowed to use the word.? So I implemented monthly demos where we also set the goal for the following month.

In this scenario were two main teams with a large pond in between, the Atlantic.? The two teams were just not aligned or on the same page about core aspects of the project or strategy and had not been for months, possibly years before I joined the org. ? The very first monthly demo was like magic as it cut through a huge amount of miss-communication. With one team finally understanding what the other team was trying to achieve.

Show and tell not demos

If I could only pick one aspect of iterative development it would be “end of sprint demos”

Though I try to avoid the word demo as it set the wrong expectation with the team. Everyone should show what they did and tell us about it.? No Powerpoints or prior prep needed.? It does not have to be polished or complete. It's better if it is not. Maybe it's the unit tests you built this week.?

• Show and tell is better than any status report or written weekly update for getting an accurate understanding of the project status
• Engineers get to show their work to other engineers, and learn from each other.
• Normally quiet engineers will talk about their work and show what they have achieved.
• Product manager and customers get early understanding of what is being built and can steer the direction early according to customer expectations and product needs
• The level of engineering effort and complexity can been appreciated by the whole team and managers
• The sessions provide short term goals for engineers that are set by engineers and therefore achievable
• They can provide insight into unexpected problems. Maybe the development machines are not powerful enough e.g.
• Managers get clues into who might be struggling and need help
• Everyone communicates!
• Everyone see the progress

Side note the worst mistake you, in any position, can make is to assume your manager knows what you are doing in any level of detail at all. They don’t they are largely in the dark and too busy “keeping plates spinning” elsewhere. I should know I was a manager for more years than I care to remember and went out of my way to understand my engineers and their work.? I never appreciated the details without "show and tell". And I also fell foul of not keeping my manager informed on my efforts.? "Show and tell" solves this problem for engineers.

Big bang theory

“Let's just rewrite this from the ground up now we understand things better”. ? I have watched many big projects fail by being too ambitious and not iterative.

Rewrites are a classic.?

Some recent examples I have observed from other teams include

• A redesign of a web UI project that took 25-30 engineers. The project was 9 months before it faced the customer. It was never able to even match the performance in terms of revenue conversion that the existing UI achieved.? After about a year the entire project was scrapped
• A rebuild of the entire web application using the latest technologies. This was sold by engineering to management as absolutely needed for scale.? The engineers estimates were 1 year - 18 months tops to complete. Though it would take a large percentage of the engineers to contribute.? My estimate, watching from the outside, was 5 years. 6 years later the goal posts were changed so they could call it complete. Software development is notoriously non-deterministic and trying to estimate even 6 month’s effort accurately. can be folly. This project was great for the engineering careers.? In the meantime the company struggled to align with customer needs. The product never scaled and all this engineering effort could have been focused on meeting the customer need.

In contrast, one very successful company that I worked for set expectations that everyone would provide some impact on the business on a 6 monthly basis. They were rewarded on impact.? This led to projects, even large ones, to be broken down into smaller iterations and streams that would each contribute independently to the business.? This way there was continuous upside to the business even if some aspects of the project did not come to fruition.

Notice that with this approach management is much less likely to simply abandon a project after multiple man years of development. Which is not untypical in a big bang scenario where all that leadership can see are the costs.

Shoot for the moon

You can’t iterate in a vacuum, you have to have a goal to aim at. My analogy is the 1960s moon landing.? “Put a man on the moon and bring him back safely before the end of the decade”

That was the goal.? Very clear and measurable. This was broken down early into a series of stages e.g..

• Get a man in space
• Orbit the planet
• Do a space walk
• Orbit the moon
• Make a landing
• Bring the astronaut back to Earth

I know this is not a complete list though what it shows are shorter term goals that have to be reached before moving on to the next.? Note this is not the same as waterfall development

Within each goal there are multiple substreams

• The space suits
• The space food
• The computers
• The fuel
• The mathematics
• Etc etc

Each of which iterated towards their own goals.

If it can work for the moon landing it can work for your project too.? Plan your destination and broadly the steps to get there.? Now iterate.? Don’t expect a straight line more a zig zag towards the goal.? To torture my moon analogy further by the time you have got off the ground the moon will have moved.? Unlike the moon your goal is likely less predictable so you need to be agile.

Iterations for Product Managers

When working with product managers I have always looked for ways to push back on complex ideas in favor of a series of iterations.

?An example from my web days was a PM who wanted us to build a feature for higher paying customers.? They would follow a link from an existing page to a series of new pages that were backed with specialized data.? This data required DB design and approaches for batch updates and handling stale data. It was 6 month work for a couple of engineers minimum.

We encouraged the PM to first test out the link.? Would visitors to the first page actually follow the link?? If not, the rest was academic, and an expensive waste of engineering effort.

Conclusion

Don’t do one large project, find multiple short iterations and learn something at every step.

?To use a sailing analogy, it is safer to keep the shoreline insight or you can quickly lose your way.