Finished draft for my first free eBook: 12 Things to Shorten Your Lead Time

Update: Released the final version.

Yesterday night I've finished the first draft of my first eBook (hurray!). The book is about reducing the lead time of your software development. "12 Things to Shorten Your Lead Time" helps with concrete actions you can take to shorten the time it takes from the first idea to the idea generating money on your website. The BETA early access version is free and available for download here. Go download it and give me feedback in the comments below or via email.

Writing the book was a lot of fun, I've learned a lot - about cadence and a steady pace when writing. The design is a first draft also, what do you think of it? For various reasons I used Word instead of Pages and it worked suprisingly good. I would wish for Keynote to be able to flow text boxes from page to page so I could use it for eBook writing. I had the feeling a blog post would be to long for the topic, so I decided to try an eBook. Good idea? The title is also a work in progress, I'm not really satisfied yet. Enjoy it.

Update: Cover inspired ;-) by some great presentations by Joe Walker

Why the Toyota Product Development System is a thing of the past

This post tries to explain why website/app development is Production and should use the Toyota Production System (TPS) and why classic software application development is product development and can use the Toyota Product Development System (TPDS).

Overloading QA
Creative Commons License photo credit: drewgstephens

Recently there has been a conundrum in parts of the agile and lean community: Obviously the Toyota Product Development System (TPDS) and software development uses a waterfall (or similar spiral) process:

What might surprise some, was that they were using a waterfall model (in Ishii-san's own words - in reality I think it was more like the spiral model). In spite of that, I had a feeling afterwards that I had just talked to perhaps the most skilled software development managers I have ever met! Does that sound like a paradox? I do not think so.

Toyota today looks so much like a religion that people are willing to suddenly proclaim "waterfall" is a good thing if it's done by Toyota:

I once said to myself that I did not want to waste my time as a developer on non-agile projects. In the Toyota case, I would certainly make an exception "Toyota is using waterfall!"

Or even, from Mary Poppendieck,

When you are dealing with embedded software in production hardware, a 3 month waterfall is really fast.

And as Sean tries to explain in his comment on another post:

If the projects that Toyota is working on span only a couple of weeks, then waterfall is probably going to work fine. They'll only develop requirements for a few weeks worth of work, and their in-process code inventory will still be pretty small.

So why should we use TPS and lean in software development, when Toyota does Waterfall and TPDS? We're confused. But remain calm. There is no conundrum. If you have clear requirements, a limited project, a fixed feature set and a fixed deadline, use waterfall. This is what Toyota probably experiences. Most people in the agile community will tell you it's only best to use agile and go lean when you have unclear or changing requirements, changing feature priorities and work in a flow model instead of a project.

After reading the Toyota Way book, and twittering about TPS, I got the following reply:

@flowchainsensei: "Might like to take a look at TPDS too (more direct relevance to software development) Kennedy, Ward, etc."

So TPS/lean isn't for software development? After some more thinking, whether software development is more like Toyota Product Development (TPDS) or more like production (TPS), I had an insight. For your web app development there are 2 phases:

Phase 1: Version 1.0 done with product development (PD)
Phase 2: After that companies shift to a production (P) model

Note: You should keep the PD phase as short as possible.

Websites and web applications are different than your usual software application development. Website/app development has many more direct stakeholders: Reporting, Controlling, Marketing, Sales, Product Development, Customer Support, Backend Services and more. Contrary to classic software apps, they all have direct involvement into features. In webSite/app development, those stakeholders write their own (!) stories and directly contribute features. On the other hand in software app development, features are mainly developed by a product development department with indirect input from other deparments.

Therefore software app development is much more product development (PD) heavy, while website/app development is much more production (P) heavy. With more direct involvement, smaller stories and changing requirements, more and more development will move into production style in the future.

The same will happen inside Toyota. My prediction: Over time at Toyota TPDS and TPS will merge, when every car is build-to-order, with it's own design, with custom colors, each with a one-in-a-kind motor etc.

This is what Scrum tries to accomplish, merging production and product development. An enviroment in which web companies are already. Each story to be developed is the same - consisting of web forms, services, database code, reporting etc., but at the same time every story is different. Think of stories as being all the same, e.g. web-service-db stories, but highly customized and build-to-order for each customer (marketing, product development, sales). Then it becomes clear that development in web companies is production, not product development.

This merging is also the area where Scrum struggles: How to put design, architecture work, technical debt etc into development, and Scrum still hasn't settled for the one best practice.

Hope this helps clear up the "Conundrum", which isn't one.

Micro Book Review: Agile Retrospectives, making good teams great

Title: Agile Retrospectives, making good teams great
Author: Esther Derby / Diana Larsen
Pages: 165

What the book is about
The book is about leading retrospectives. Retrospectives came into fashion with agile software development, especially Scrum has retrospectives every sprint. The beginning of the book motivates retrospectives, explains them, shows how to lead them and establishes the concept of phases: set the stage, gather data, generate insights, decide what to do, close the retrospective. The second part explains detailed several activities you can use in each phase. A description is structured like the famous design pattern book: Purpose, Time needed, Description, Steps, Materials and Preperation and Examples.

What I've learned from the book

  • Retrospectives have several phases: set the stage, gather data, generate insights, decide what to do, close the retrospective
  • There are many activities for retrospectives, you should change activities from time to time
  • Use an activity like"appraisals" for closing a retrospective

Should you buy this book?
Yes, highly recommended

Who should buy the book

  • Every ScrumMaster or Iteration Manager
  • Everyone who leads retrospectives

Notes
Book bought by myself due to a mentioning on Twitter.

I've chosen the micro review format because it lends itself to be used as a future micro format and I like short reviews myself. You can read the table of contents elsewhere, I don't like it when reviews iterate the content.