The high cost of overhead when working in parallel


Photo by SanyamStudios

Astonishingly most companies I know work projects in parallel. This seems a good idea, because no stakeholder has to wait before his projects starts. All are a little busy.

As I’ve written in my free eBook 12 Things You can do to Shorten Your Lead Time, working in parallel is a terrible idea. It increases time to market substantially, sometime by several hundred percent. Working on one project after another – as proposed by Lean with its work in progress limits (WIP) – reduces time to market. Project managers will not attribute long time to market to developers not working, but to the bottleneck which is a low number of developers.

But there is something else to working in parallel. It produces a high overhead. Take a look at the figure:

Assume we have five projects going on. Each project has a biweekly or weekly status meeting. Then there will be 5 status meetings each week, and due to the longer project life time of parallel projects, we get 100 status meetings (20 weeks a 5 meetings). When work is done in serial, we have one status meeting a week (one project) for 5 months equalling 20 status meetings. Working in parallel has 5 times the overhead.

This multiplies. All stakeholders ask about the status of each project. In serial mode, when a project is not started, they won’t ask about the status. After it’s finished they will neither asked – obviously – about its status.

Projects must be tracked much longer, more documents are produced and must be tracked. All those status messages aggregate, flow upwards toward upper management, clog thinking and time. All those status messages flow to all stakeholders. Each increment per status update is small, much smaller than when working in serial mode.

I hope this gave you the same insights as it gave me. Start working in serial. There might be resistance, but in the long run people will see effects.

5 Practices Better to Change in Your Scrum Implementation


Photo by royskeane

Scrum saw a big increase in adoption last year. Everyone who is doing Scrum, does it differently as Scrum is a framework, not a process. One needs to inspect and adapt, mostly through retrospectives and daily improvements. I’ve been an agile proponent since learning about XP in the 90s and had the chance to learn something about Scrum in the last years and positions.

It is hard to determine if someone is really doing Scrum, the famous Nokia test helps as a Litmus test. Jeff Sutherland writes:

In 2005, Certified Scrum Trainer Bas Vodde was coaching teams at Nokia Networks in Finland and developed the first Nokia test focused on Agile practices. He had hundreds of teams and wanted a simple way to determine if each team was doing the basics.

I’m certain Scrum needs to adapt. As I’m head of development at a startup, and a ScrumMaster, I had some canditates for a Java job and they’ve asked me about Scrum. I’ve told them we aren’t doing Scrum by the book. They’ve been suprised and thought we do Scrum-Butt:

Scrumbutt is a word for the organisations saying or at least thinking that they are using Scrum, but the fact is that they are only using parts of the method. It is when a user of Scrum is saying: “YES! We use SCRUM, BUT we have these deviations in our method…”

But there are two sides beside Scrum. Doing not enough Scrum – ScrumButt. And learning from Scrum and going beyond – especially more lean. I think we are more lean and beyond basic Scrum. How did I adapt Scrum?

1. No Review Meetings

Scrum has a review meeting at the end of each sprint to present the work done to all interested parties.

What we do: We have no review meetings. Reviews with customers/product owner are done right after a story is completed together with the developers.

Pro: Con:
  • Completed stories can go faster into testing
  • Completed stories can be deployed faster and go live earlier
  • It’s harder for other stakeholders to see the stories
  • It’s harder for the team to promote it’s work

2. No estimation of hours

Scrum estimates the hours remaining on each task card for each story. Those estimates are updated each daily scrum and drawn on a burndown chart.

What we do: We do not estimate hours.

Pro: Con:
  • Less work to do, so less time wasted on something which is – often – not needed, less waste
  • Updates of hours are done by one developer and therefor are more inaccurate
  • Harder to see if the time remaining in a sprint matches the work remaining
  • Developers are not bound by their hour estimates and tasks may take longer

3. No hour burn down chart

In Scrum remaining work in hours is drawn on a burn down chart.

What we do: We draw two graphs, story points remaining and tasks remaining

Pro: Con:
  • Less waste, as it’s easier to count SP and tasks than hours
  • Graph of tasks remaining shows if the sprint goal can be reached or if the team is behind
  • Story points remaining show that a team finishes stories too late in the sprint
  • Harder to see if the time remaining in a sprint matches the work remaining

4. We do not use Velocity for Sprint Planning

In Scrum some teams use the past velocity for planning the number of stories for the sprint.

What we do: We pull stories from the backlog. After each story was discussed during planning, the ScrumMaster asks the team if they can do this story in the next sprint. Go on until they say no.

Pro: Con:
  • Developers are not fixed on a number and therefor are more likely to improve
  • Velocity should increase in teams, if retrospektives are effective. So why focus exclusivly on past performance?
  • Because they are more aggressive with what they can do, developers may overestimate their abilities

5. We split the backlog into stories that are in planning and those that are ready for development

Scrum has a product backlog with stories and most of the time estimations. They are ordered top to bottom according to business value.

What we do: We add (at least) one more state. All stories which are ready for development are put in a “Ready” queue.

Pro: Con:
  • The team sees which stories are ready for development
  • The company sees if the ready queue is too large or grows too fast
  • More work for the ProductOwner, possible additional waste

I hope one or two things on the list get you thinking about your Scrum implementation and helps you to smooth your process and increase customer satisfication. What changes to Scrum have you applied? I would be interested to hear, please leave a comment.

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.