One of the things I watch out for inside of a Scrum team is delamination. (Dela wha?) It is not a Scrum term. – Rather, as I often tell stories by analogy, it is a term I use to describe a behavior. The term ‘lamination’ comes to us from the Latin language. So it’s been around awhile. It is the method of making a material by using multiple layers, so that the resulting composite has much greater strength and is structurally more stable and sound. By using layering, we get something better. A laminate also usually bonds together through pressure and heat. The definition itself sounds like a team with cross-functional roles that is put through some rather challenging work. Delamination is when all this bonding starts to fall apart and the layers start to separate again and come apart in different directions. The team in essence diverges. Typically this is along the thin laminations, (or by analogy) the roles that the teams is comprised of. Are the developers ahead and working on different stories than the testers? Is half the team complaining at how slow the other half is? I try to discourage this in teams – as it is together, that we the TEAM will fail or succeed. What comes to mind is a list of things to look at when we might be facing some delamination. When we want to keep from pulling too far apart and stay together. Typically it can be the developers that are running a bit ahead, but not always.
Flip how we do the work.
- Many developers realize that a good practice is to do the unit tests. Many also have the tendency to put these last just to complete the ‘coverage’ as a cleanup thing to do. Do the unit tests first. Kent Beck had a great book – Test Driven Development: By Example in which he goes through explaining his thought process as he does the unit tests first. He explains the ‘why’. If the unit test is hard to write – he considers that the architecture itself might be too complex and much better off for being simplified so it is easier to test. For testers this often means NOT ever waiting until the development is done – But getting the tests done first and vetting those with the team so that we are all on the same page about what we need to deliver and how it will work.
- Some teams will do a whiteboard session in first days of a sprint where the devs and then the testers take turns walking through a deeper analysis of the work, where the risk is, where the verification points are. The roles overlay and vet the algorithms and the edge cases together. Maybe we set some plan for when tasks fit together during the sprint.
- Consider everyone on the team a software developer. We all have our specializations but no one should be left behind.
- What can we let go of? Are we really doing testing that is based on risk and impact? Is the process large, rigid and cumbersome? What if we are making ‘look and feel’ changes to a user facing document – do we really need to regression test the application that autogenerated it?
Teach me / Teach you
- What is covered by those unit tests? are we overlapping? is some of this testing redundant? or even unnecessary? Are we testing integration points, regression?
- Are you using Different Tools, environments? How did you do that?
- Increase the Skill sets on the team by teaching something that the team needs – maybe that is SQL or scripting, or whatever.
- Take an interest in what the developers/QA are doing.
Enable or help out, this is a team effort
- Help develop the functional test automation
- Make the daily stand up more of a problem solving plan for the team than an individual status. Focus on the tasks that need to get done and swarm on them. Help out the people that may have difficulty in asking for help, letting go or breaking it down.
- Make the application or service more testable.
- Look ahead and start grooming some of the stories that will hit the team. This is different than accepting more work – this can be vetting the acceptance criteria, the sequence, or the dependencies for the work so that the team can estimate these more easily.
- Bring in more organizational skill sets into the team. Ideally this work is potentially shippable – and will encompass everything it needs in order to get through the entire organization and into the customer’s hands. This might include a technical writer, a graphic artist, a system or security specialist. These roles may also benefit from continuous improvement or help us to integrate what we do to make this the Right software done the right way.
- Help another team. Is there someone else that is having a difficult sprint – ask around maybe at the Scrum of Scrums.
- Buy down and dig into getting some of your technical debt done. A refactor of some legacy code that is always brittle or tricky to make changes in will make future changes easier and less prone to mistakes.
- Address Bugs – typically, most of these are validations that require little time to verify AND make the product better. I shouldn’t need a test case to verify a spelling correction.
- Stabilize or improve a process. Perhaps this is something for continuous integration, admin of virtual machines, or the automated smoke test?
- Did you perform code reviews, pair program, help review test cases, or develop the artifacts necessary to train and educate others?
- Get in there and help test! – learn the tools and processes. Let’s all finish this before we grab another.
Remember, we are trying to become better ourselves at estimating what work the team can deliver and be completed at the end of a sprint. Also, I will say I have witnessed many GREAT teams pull together where it never felt like delamination was taking place. High performing teams are not just sitting idly around – but neither are they always leaving work half finished at the sprint boundaries. Sometimes is OK, and maybe it is ABSOLUTELY appropriate to get started on that last important piece of the feature or shippable increment. We just should make certain we can answer if the team is together on this. They’ll most assuredly be the stronger for it.