Learn the Secrets of Collaboration…From Your Kids
One of the simulations I like to facilitate during training sessions is a simple penny flipping exercise learned from Mishkin Berteig to show how the team approach can lead to substantial improvement and productivity gains.
The idea is simple, have the attendees work in a serial process where they have to pass the penny from person to person. The goal is to get the pennies facing heads up in ‘the product environment’ (which is a piece of paper) at the end of the chain. The second part has the same goal, but the teams can accomplish it however they want. I usually repeat the second part a couple of times to prove the meaning behind the exercise. I’ll add a post with the mechanics on this game later.
Anyway, last night my 2 kids and I were playing dominos which always results in a living room disaster since we have a few hundred of the them. 20 minutes for me to set them up, 10 seconds for them to knock them down. When it was time to clean up I simply stated the goal. ”Ok guys, time to put all the dominos away in the clear bin“. Just like a high-performing Scrum team, we started singing the Wonder Pets Teamwork song (what’s gunna work? TEAMWORK!) and each “team member” started cleaning up.
My 4 year old son started picking up the dominos nearest to him, same for me and my 3 year old daughter. The bucket was pretty much centralized between the 3 of us. After we had cleaned up the dominos closet to us, my son immediately took the bin, moved it to the next ‘batch of mess’ and we proceeded to start with whatever dominos were nearest to us. My daughter had walked towards the pile my son started with so she quickly self-adjusted and started on another pile.
I was stunned. The collaboration was completely instinctive and there was very little, if any, discussion. We all knew what the goal was and we all chipped in. Once there were only a handful of dominos left, all 3 of us focused on that so no one was idle until there were less than 3 dominos left.
Sounds silly, I know, but the Agile principles were were much apparent to me during this clean-up session:
- all team members understood the goal
- team members self-organized
- team members adjusted based on work remaining
- team members started with highest priority items (as in, we all started with the pile in front of us)
- we had fun while working! (For those who don’t have kids, trying to convince a 3 and 4 year old to clean-up is not really that easy most of the time!)
I often get complaints in training sessions about the simplicity of the exercise and that moving pennies is different than real-world work. I agree, it is but applying the one-team, shared goal value is more important. Once folks buy into the team system, the rest of the work falls into line much easier.
Waterfalling your Iterations: Not the way to handle re-work
Ah, good old re-work. The thorn in the side of Scrum teams, the impossible mountain to climb for development teams. Re-work is un-avoidable. When people see working software, they get new ideas and might want some changes. Here are some thoughts for handling re-work based on a few scenarios that popped up at work this week.
If We Knew Earlier, We Coulda Did Something About it
Situation: During our iteration demos the team I’m working with found that they had improvements and suggestions now that they could ‘step back’ and see their work. Other folks who we invite to the demo would have some small ideas or our Product Owner would have some suggestions that were nit-picky, but nonetheless would be better for the user.
Problem: Waiting too long to get feedback.
Solution: I’m happy the team came to this conclusion themselves in the retrospective. One of the team members posed the question that why don’t we show our product owner immediately when we complete the story and not wait for the demo? Side note: I’ve mentioned this to them a few times, but it was great to see them take a problem and apply the learnings on their own.
Splitting the Iteration into Work and Re-work Phases
Scenario: There is too much re-work at the end of the iteration so we are going to take our 1 week iterations and shorten them to 3 days so we have 2 days to do re-work.
Problem: too much WIP and lack of communication between team and product owner. (In this scenario the product owner isn’t available full-time to the team and the proxy he assigned can’t always make a decision). There are a few other things happening here as well. The work this team does is non-software and they rely frequently on interacting with people in other departments. They’ll start something, get blocked and move on to something else therefore creating a great deal of waste.
Solution: The team has been struggling with this for a few iterations, I’m not working with them but did have a chat with their Scrum Master since he felt it was a failure on his part. Not so at all. I told him maybe trying to hammer Scrum into their work-style wasn’t the best thing to do. Perhaps a Kanban system would be more effective for them. We talked about what that meant and they’re not ready for that so instead they’ll try communicating with the product owner more often and help the PO understand he needs to be available for the team to fulfill their commitments.
Agile/Waterfall Hybrids is What we Did!
This one came up in a training session I was doing. One of the attendees said mixing waterfall and Agile can work because in his experience there was no way to handle re-work in Agile. The solution to this is similar to the first scenario I discussed at the start of this post.
The root of this problem is not getting feedback early enough or the lack of daily communication between the Product Owner and the Team that is required when using an Agile process. A deeper problem was the apparent separation between programmers and testers on the team he was talking about. I wasn’t able to deep-dive into the scenario since it was in the middle of class but I offered some suggestions about why it might be happening.
All of these examples, in my opinion, are some of the main reasons why companies fail with Agile. They interpret “Agile” to mean flexible and let’s just change the rules to make it work for us. While Scrum is a simple, adaptable framework, the fundamentals shouldn’t be changed to accommodate a broken process. This type of dysfunction can lead to mis-trust between the Team and the business and also cause a rift between programmers and testers as they will start to ‘fall back’ into a waterfall mentality.
It’s important that the Scrum Master or Coach help the teams struggling with this to understand what the real underlying issue is and to work through it.
If What You are Doing Works, Does the Label Really Matter?
Recently I had a brief messenger chat with a former co-worker that they determined they were actually using Scrum-ban instead of Kanban. The timing of this chat coincided when I seemed to be coming across a multitude of discussions about what is or is not in Scrum, what is or is not Kanban and so on.
My initial response was “is what you are doing working?“. Her response was, “yes“.
My response, of course, then was “so why does it matter?”
I do understand the desire to have these processes defined but I’ve never much been a fan of labeling. Being “Agile” isn’t about using Scrum, Kanban, Lean or any other tool/process, it’s about being dedicated to empirical processes that work within the context. I also understand the dangers of ”Agile” being tarnished by misused practices but by and large solving problems and rejecting the status quo are what really matters at the end of the day.
As an example, a few months ago a team member who was recently kicked off the team BY the team, decided it was worth his time to prove a point by finding a page in Ken Schwaber’s book that mentions it’s not a rule for the team to stand-up at the daily scrum. My reply was pretty simple in the sense that I never said it was a rule. I explained to the team why it’s a good idea to stand-up and the team decided they wanted to sit, so they now sit. (results of our daily ‘sitdown’ here).
Is sitting at the stand-up a Scrum smell? Probably. I don’t care though. The team gets more value out of sitting.
Before I knew what “Agile” was, common sense would dictate that if something isn’t working, find a better way of doing it by trying something new. I believe that’s much more valuable than worrying about what label you put on it.
