Achieving Swarming In Agile Teams – Part Two

On May 23rd I gave a talk about Achieving Swarming In Agile Teams at Project Society Conference (PMI). Slides are available on SlideShare. And here is the full transcript, organized in three posts…

If you haven’t read previous part, here is a link to Part One.

Part Two

Scrum is the most popular Agile framework by far. It is a product development framework and one of it’s main points is that the whole team should be working on delivering the most important item at any given time. However, most of the companies find such behavior wasteful, and insist on whole team working on as many items as possible at once. This results in most of the items being worked on but not completely done until the end of the sprint. This leads team to having nothing (or very little) to show to the client and losing valuable feedback opportunity.

On the other hand, team completing most valuable item at a time, maximizes opportunity for the valuable feedback. They will have all the items they worked on, done (except maybe for the last one) and presentable to the client. To put it in one sentence – it is better to have 80% of the planned items completely done, than to have all of the items incomplete.

This leads us to the first swarming opportunity for a Scrum team – work collaboratively as a team on the most valuable item at a time and move on to the next one only upon completing the most valuable one.

You recognize this as a Scrum board. However, contrary to the popular belief, it does not have three well-known columns – “To Do”, “In Progress” and “Done”. It has FOUR columns. The leftmost column is equally important and represents Sprint Backlog. It holds all the items which represent WHAT should be done in order to satisfy client need (nowadays they are mostly called User Stories, often times wrongly interpreted). Team commits to working on those items, but does not work on items themselves directly. They create all the necessary task needed to make that WHAT item happen. The tasks they create are all the activities across all specialities within the team, e.g.:

  • all tasks for frontend developers
  • all backend tasks
  • all database tasks
  • everything needed for deployment
  • all testing tasks (identify and create test cases, write automated tests)
  • deployment tasks
  • design tasks
  • investigation tasks

All those tasks describe HOW are those WHAT items going to be built. And of course, team adds and removes them during the sprint if necessary.

This brings us to the second swarming opportunity for a Scrum team – swarm around tasks within specializations – pair developers, designers, testers and others within their respective specializations.

NOTE: There might not be specializations within the team (everybody has a complete skillset needed for the job), but particular tasks are related to particular specializations.

Scrum implementations often start with enthusiasts from a company reading a book or blog post(s) or even attending two-day certification training. There is a recurring pattern of starting implementation with using a three-column Scrum board (usually in Jira) – “To Do”, “In Progress” and “Done”. Sprint backlog is usually formed in “To Do” column, and almost as a rule, a single developer starts working on a single User Story (since User Stories are almost always used) and moves it to “In Progress” column. Once he is done with coding, someone from the team, usually a dedicated QA guy, takes the item to test the coded part. However, it is hard to represent it on the board, so usually, “QA” column is added. At that point “In Progress” column loses its meaning (since “QA” also means that work is in progress) and it is renamed to “Develop”.

This is a very common and very popular anti-pattern of Scrum implementation and leads to specializations being isolated within their respective silos with no collaboration between them. There are only handover points, at which only a fraction of information is shared.

Of course, once silos are formed, they keep being added, so quickly other columns or states are added to the process and a workflow with no collaboration and handoff culture is formed. The result is no-collaboration ineffective sequential process which has nothing to do with Scrum.

The simplicity of Scrum board, on the other hand, encourages, promotes and enhances collaboration which brings us to the third swarming opportunity for a Scrum team – work collaboratively across specializations on the same item.

What exactly does this mean? Take that sequential process that we had as an example. When developer starts working on an item from “To Do” column, he tries to identify all the necessary use cases and all the necessary paths he needs to implement. When he is done with coding, he hands his results over to a tester. She in turn tries to identify all the use cases and necessary test cases in order to verify whether or not is the implementation complete. Of course, since there is no collaboration, they will most likely come up with different sets and will have different expectations. This is a perfect setting for cat and mouse game in which tester ambushes developer waiting for his mistake. And of course, there will be such mistakes, since either the tester will try to verify something which was not implemented, or the developer will implement something that is not going to be verified. Either way, this will result in throwing the work back and forth, ultimately resulting in wasted effort, time and money. Not to mention frustration that it will cause as well.

Using the Scrum board, on the other hand, encourages developer and tester to work collaboratively from the beginning together on identifying the complete set of use cases and test cases. That way, developer will know what is expected to be build and what is going to be tested and the same goes for tester. This way, they are more likely to cover everything.

The beauty of this approach is that there is an opportunity to add another speciality to this exchange. If we add UX designer for example, she might understand that some of the steps that she initially envisioned are not necessary or that they are illogical. On the other hand, some new ones might be needed, so this is the perfect place to add them.

This results in quality being built in the product from the beginning. Not to mention that handover cost does not exist and that there are no unnecessary loops in the flow.

Continue to the third part – Kanban Example.

Here is another bonus video of one day in team engaging in mob programming (Woody Zuill video).