All posts by heidi

Modern Agile Approach in Writing Dynamic Reteaming


My book Dynamic Reteaming: The Art and Wisdom of Changing Teams is coming along. It might be different than other books that you might have read so far because I am updating it every few days. In the writing of this book, I am attempting to demonstrate what it means to write a book from a Modern Agile approach (as invented by Joshua Kerievsky). Let me explain.

icon-deliver-value-continuously Deliver Value Continuously

You are reading a dynamic work in progress. In order to do this, I have had to exert a fair amount of courage as well as learning how to be comfortable shipping imperfection. I tend to be a perfectionist. I have hand drawn images in the book which are prototypes for final images to come some time later. I have notes to myself for thoughts to add later. I have reminders to add citations. I don’t think any of this gets in the way of the meaning of the book. The meat of the book are the ideas, and that is the value. Some of this other stuff is really logistical. It reminds me of when I taught English as a Second Language. There is a difference between communicating for meaning and communicating with “perfect grammar.” The idea is to communicate ideas, and not worry about using the ultimate syntactic structure. That’s hard when you’re learning a new language because we might get self-conscious and focused on perfection. I can relate to that.

The extreme learning here is that for years I have asked software engineers to ship imperfection. I am now feeling what that might feel like and it is empathy building. Moreover, I have the luxury of being my own product owner. Many developers do not get to go back and work on the areas of code that they have released do to changing business priorities. In an ideal world we would all be able to do this, but it’s not always the case. I am wondering if what I’m feeling relates at all to what it feels like to have your code, your features, your love go “out there” without the opportunity to revise or change it due to whatever constraints. I can feel more now that it wouldn’t always be easy.

Actually worse than this is when your product gets cancelled forever and you can no longer work on it. I had this experience at when we were building our marketplace for experts. I was on the web development team. We had so many hopes and dreams for future features. I created web flows with engineers for some of the new features. The marketplace product failed, and we were told that we can’t work on it anymore. I actually cried it hurt so much! As a junior person at the time I couldn’t comprehend the severity of the situation to the company’s survival. This was all pre-lean startup, pre-Steve Blank and so the concept of the pivot was unknown to me. Fortunately I was able to be part of the team that built GoToMyPC (predecessor to GoToMeeting and GoToWebinar), and now years later I have the perspective to understand the awesome strategic vision of our management team at that time. How we reteamed to build the initial version of GoToMyPC is in my book as one example of the Innovation by Isolation pattern.

To Deliver Value Continuously I’ve figured out a flow to get my words from Scrivener on the Mac, over to Leanpub. For those interested, it works like this. I have a Scrivener project going. Each chapter is an individual text file. The name of each of the files in scrivener equal to the names of the files in my Leanpub dropbox folder. I export the manuscript from Leanpub which copies over to a different dropbox folder. I copy and paste those files over to the appropriate Leanpub folder and list any new chapter additions in book.txt in the Leanpub folder. (Ideally this would go directly to the Leanpub folder but I haven’t done that yet). Then I go to Leanpub and generate a preview. That takes forever, but I wait. Then, I review the files in there and if they’re good to go I publish in Leanpub. I’m writing this here because I couldn’t find any help on how to do this on Leanpub, Scrivener nor Google. So maybe it’s helpful to someone out there.

icon-experiment-and-learn-rapidlyExperiment and Learn Rapidly

I’m looking for more feedback on my book so that I can iterate based on more authentic feedback from readers. If you are interested in being an active reader of my book, let me know and I’ll send you a coupon to get a free book. Contact me heidi dot helfand at gmail dot com. I’ll add you to a special community of active Dynamic Reteaming book participants.

Leanpub asks for a “percentage completed” number. That’s a bit challenging for me. The structure of this book is still changing at the macro level. Also, as I gather more and more data from interviews in which to derive the reteaming patterns, I’m learning. I’m experimenting with different organizational structures to the text. I’m not satisfied yet. As of the writing of this post I have 2 interviews out to be transcribed and 4 already transcribed to integrate into the text. I’m seeking out more companies to talk with who have stories to tell about how their teams have teamed and reteamed. Know of anyone? I’d love to hear from you.

icon-make-safety-a-prerequisite Make Safety a Prerequisite

I have interviewed countless people for countless hours to get real, world, industry stories about how their companies have teamed and reteamed. My first recording had sound issues. I learned the hard way that I should have tested the sound before doing an actual interview. It could have been worse – it was only one interview, and I was able to transcribe the data effectively but still as a perfectionist that troubles me.

I have been taking great care to get permission from people who are sharing stories in this book. I’ve also taken great care to hold anonymity of the participants sharing stories that for them might be uncomfortable. This also ties into *Making my Participants Awesome*.

icon-make-people-awesome Make People Awesome

I have been very fortunate to be involved in the Modern Agile community and to have the support of people like Joshua Kerievsky who has been an incredible thought partner for many of these ideas, especially the concept of what patterns are and how to write them up, as well as the whole Modern Agile topic that he started.

Michael Kelley Harris has been such a thoughtful friend actually bringing me recording devices to try out in the early days of this project so that I could solve and make better recordings.

Vasco Duarte told me how to record Skype interviews. And I’ve discovered along the way that Zoom video recording also works well.

I’ve got a flow to a transcription company to get my interviews transcribed and it only takes a few days.

Friend have introduced me to people to interview. Participants have contributed valuable hours of time to be interviewed. It means so much to me.

I have been able to introduce participants to each other who are experiencing similar reteaming patterns in their companies. As a connector that gives me a lot of satisfaction.

Dynamic Reteaming is Inevitable, You Might as Well Get Good At It

People come and go from teams. Sometimes people embrace this, and some avoid it at all costs. There are risks to avoiding changes in our teams related to the development of knowledge silos, competition between teams, and lack of learning to name a few.

So where did the notion of “keep teams the same” come from? Maybe it’s related to the Tuckman model. Back in 1965, and later with an addition in 1977, Bruce Tuckman came up with his highly quoted “stages of group development”.

The stages include Forming, Storming, Norming, Performing and Adjourning. His primary dataset was from a review of the literature from training and therapy groups . . not software teams. Despite all that, his model is still one of the most widely quoted in organizational development literature. (Bonebright, 2010[1]). Even today, there is still nonetheless something very compelling about this model even to people in the software industry. It’s a catchy model.

Maybe it has to do with the relatively intuitive nature of some of the phases. The first phase of his model, Forming, and the last one, Adjourning seem straightforward enough. When new people come together to make up a team with a common goal, you could call it “Forming”. When the team dissolves for whatever reason you could say it has “Adjourned” or as some say “Mourned” to keep the rhyming scheme going. At times though we may be glad that a team has dissolved due to toxic team behavior, and so “mourned” might not quite capture the meaning.

Tuckman’s Model is a linear model that implies that you get together as a team, you keep it the same, and you go through Storming and Norming once, and thereafter you are Performing. I guess that’s not surprising. After all, the era in which Tuckman came up with that model was the same one in which the Waterfall model for software development emerged – another linear model. Linearity was hot.

The linearity of this model is problematic though, especially when thinking about the notion of conflict. It would be ideal if a team could get together, work out all their issues, and then get on with Performing.

If Storming means having conflict, that unfortunately is not a thing that happens only once on teams and then goes away. I’ve been with plenty of product development teams for the last 17 years that have had conflicts and who have “stormed” regularly. Conflict is a natural, reoccurrence when groups of people are together. People can get good at conflict. When armed with the right syntax, at least you have a shot at being more of a skillful communicator. We can train people in how to have “crucial conversations” and to talk about things that are on their minds. If Conway’s law has any truth to it, wouldn’t you want your software built via healthy, productive conversation as opposed to the opposite?

As an ORSC-trained[2] coach, one of the things I do with teams is proactively work out with them how they want to “be with each other” when they are in conflict. We can design and share personal preferences for dealing with conflict when our teams get together initially and when they reteam. It’s quite useful. For instance, you might find out that your team member would like you to ask them to go for a walk outside if you have an issue with them and want to talk about it. You might learn that when another team member is upset, their face turns red and they like to have some space away from other people before invited to a discussion to talk about what happened. You might learn that when Joe has code on his screen, and there is the “Garfield cat” stuffed animal next to his monitor it means that he’d prefer that you didn’t interrupt him.

Moreover, conflict, and dealing with it in a healthy way is also required in the creative process when working out solutions to problems during team discussions. Sam Kaner calls this type of conflict “the groan zone” in his book on facilitation[3] – when people come together to devise unique solutions, they first have divergent thinking, and work out their issues or conflict in “the groan zone”, before converging on their solution. In product development we are devising unique solutions over and over again as we build. Again, Tuckman’s linear model applied to teams is insufficient here.

[Conflict reoccurs in product development- It’s normal.]

In product development we live through cross-functional discussions that have varying lengths – sometimes annoying, sometimes not. When anyone complains about “design by committee” they are likely miffed about going into the “groan zone” as shown above. We want our teams to have healthy disagreements. Having divergent views is necessary to get us to awesome solutions. If everyone’s agreeing with everything everyone is saying on your teams, you might want to look into that.

The fact is, it takes time to hear each other out, to listen to different perspectives, and to come to a resolution and agreement on how to proceed. And, someone needs to forward the action/deepen the learning[4] on the discussion to get things to closure. That takes skill and practice as you want to be inclusive, and enable “all voices to be heard[5].” The caveat here is that you can’t have discussions go on forever. Otherwise things can feel unproductive and that is essentially demotivating. Experienced coaches who are skilled in facilitation are helpful here. Moreover, great coaches can train anyone to move along discussions like these in a respectful way. Then the coaches can fade out and help out elsewhere in the organization.

Back to Tuckman’s Model, how do you define Performing? Is it just getting the work done? Is it watching people like a hawk? Or is there something else? What does high performance look like? Can you see or feel it? Maybe the energy is visibly high…or maybe the team is quietly cranking out incredible software to your customers regularly. Measuring performance is of interest to many, and there are many different approaches to that.

Some people might try to measure performance with an abstract level of reports and metrics like velocity – which can be easily gamed, and can lead to energy-sucking accounting work and nagging ScrumMasters. Few people want to enter in “hours remaining on work” on a daily basis to compose burndown charts. It’s a total drag. Trust me, I did it 9 years ago – it was a rookie mistake. Others go with a Modern Agile[6] approach of Delivering Value Continuously to customers. Software in the hands of delighted customers, and delivered frequently speaks volumes about productivity, doesn’t it? See

Research at Google as part of the Project Aristotle[7] study claims that, among other things, the highest performing teams have large amounts of psychological safety. That’s when team members feel free to express themselves without fear or scrutiny. They can essentially be comfortable contributors without concern. Working on team relationships, team gel and the like is an area we will be hearing more and more about in the coming years thanks to this study. It’s about time we took more of a Humanistic stance on software development as opposed to a Mechanistic stance that is ridden with time tracking and the like. Put your software developers under scrutiny and you’re guaranteed to “dim the light” of their inherent “Geek Joy,” according to Michael “Gee Paw” Hill. Back in May at Agile and Beyond in Detroit he told me, “The fundamental fabric of geek-centric work is we don’t have to motivate them, we have to not demotivate them.” Put your geeks under a microscope won’t get you geek joy. It will get your geeks to leave for better working conditions.

Despite all that, if we keep our teams together for too long, you can have other problems. Few people know that there is a missing phase in Tuckman’s model. It’s the phase called Stagnating. It’s when you keep your teams together for too long. Since the team composition does not change, there is less new information in the system. There is less learning because of that. I didn’t make that up. It emerged in a qualitative case study[8] that I conducted at my former company AppFolio, Inc., which I presented at Agile, 2016. Here are a couple of the quotes from the participants which inspired my Stagnating addition to Tuckman’s model:

“You just get different perspectives working with new people…unless you actively have a source of new input to your team, like you’re reading books together or something, it’s going to stagnate over time…” -Bryce, PhD, Senior Software Engineer

“If the team stays stagnant, the abilities you have stay stagnant. We have people on the global engineering team for a reason. They’re good at different things. They’re good team members. And so mixing it up all the time is important.” Comron, Principal Software Engineer

Teams that are together forever could also have very low energy. Simply put, people might just be sick of working with each other. The work itself could also be stale or uncompelling. Maybe the people are just “going through the motions” of their work. They feel disengaged from their day to day experiences but still come into work each day “looking the part”.

Keeping those people together on a team or in the company for that matter is doing a disservice to the humans present. It’s sad. Who wants to work with those people? Who wants to work with that team? That’s when we need to take a critical look at dogmatic suggestions about team stability, which can be easily misinterpreted as “keep teams the same.” Too much of the same might not be such a good thing.

So how do you know when you should reteam? Good coaches can keep the pulse on team health in your organization. They can coach teams as units or systems to understand the collective sentiment. They can also coach individuals one on one in order to “take temperatures” and see how people are doing. Managers can do that too. The important thing here is to design how you want any coaching to be in your organization. This is a deliberate discussion so that you do not have conflicts of interest or issues with confidentiality.

“Reteaming is inevitable, you might as well get used to it” is what my friend, coach Nayan Hajratwala said to me. And it’s true. People will come and go from your organization. You will team and reteam across time whether it’s your choice or not. If you’re on a team, you can decide to speak up and seek fulfilling team situations that get you excited to come to work every day. Just like for teams, coaching helps with this.

If you’d like to read more, please check out my book Dynamic Reteaming: The Art and Wisdom of Changing Teams.

[2] See
[4] This is a concept from co-active coaching which is the coaching philosophy that I am trained in.
[5] This is a concept from organizational relationship systems coaching which is another coaching philosophy I am trained in.
[6] See