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.

Development Dream Teams

Over the years I’ve build some teams. The size and composition most often was determined by the company I was working for. This meant the team was developer only, at least some teams were cross-functional. I wished to have the freedom to create an optimal development team, a dream team.

In modern teams everyone should be able to do everything – this avoids bottlenecks or single point of failures and distributes the burden of some tasks. But there are limits. Skills are not easily found combined in one person:

  • Test Know How
  • UX/Design CSS
  • Programming
  • Product Development / Management

So a cross functional team needs to include:

  1. Product manager / PO for product development, wire frames, business analyist, business cases
  2. UX/HTML designer for usabilty, design and hardcore CSS problems, developers can’t solve
  3. 5-7 Developers for programming, backend, frontend, CSS/HTML, development, unit testing
  4. QA/tester: works with PM to determine acceptance tests, writes automatic acceptance tests, exploratory testing, helps developers with their tests, keeps the testing focus
  5. Optional, but helpful: Operations guy for the sub system. This role can be temporary

Why strive for a cross functional team? When a team is not cross functional, there is a lot of communcation overhead and lots of filled queues. With no product manager as part of the team, there are vertical silos and handoffs. Repsonsibility is split and in the case of trouble, finger-pointing starts.

And Jon Moore blogs in “Scrum thoughts: cross-functional teams”:

As a developer, this was great. We had instant access to team members from the other disciplines, able to brainstorm about how a feature should work and getting questions answered quickly. There was a very real team vibe, very exciting. […] The six weeks that we operated like this were really fun!

With cross functional teams, communication is easier, missunderstandings seldom. Colocation is a must and leads to much higher productivity. With one team there is only one responsibility. The team is tasked with a user story and the whole team is responsible for delivery.

Scrum strives for cross functional teams, the biggest hurdle for Scrum Masters on that road are political struggles and thinking in kingdoms.In Scrum, product owners (PO) and developers are considered one team, which is often not colocated. They belong to different departments with different goals. Therefor a ScrumMaster constantly needs to tell them they are one team. One real team makes Scrum easier and more successful. Companies should organize teams not at department boundaries, but value streams.

Team size

Team size is another paramter. From my experience, the team should be smaller than 10 people, team communication and managment gets more difficult when you approach the threshold of 10 people. Pete Abilla writes about the size of the famous 2-Pizza Teams at Amazon:

[…] Amazon’s 2-Pizza Team, which is defined as the following: a team where the team size is no larger than 2 pizzas can feed. Amazon realized early on that in order to cut software development time, the solution was *NOT* to put more people on the project.

The number of developers matters most, as it influences the number of the other team players. If the number is small, there might not be a good ratio to testers, designers and product managers. If the number of developers is larger, this is better, because it creates more throughput according to queuing theory. More throughput means shorter cycle time. Too many developers on the other hand lead to communication overhead and get ineffective says Jens:

Intra-project communication becomes more and more challenging with increasing team sizes. When team size increase so does the number of different communication channels. Every team member can communicate with every other team member. Mathematically it looks like this:
number of communication channels = n(n-1)/2, n=team size

While Jeff Sutherland goes farther and generally attributes lower productivity to large team sizes:

There is plenty of data to show that team sizes over 7 result in significantly lower productivity. Any team over 7 in size should be split up into multiple SCRUMs.

Conclusion

My dream team is a cross functional, cross department development team with less than 10 people. What would be your dream team?

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.