I was catching up on some blog posts over the weekend, and two by Stephen Forte caught my eye. He wrote about his initial experience with Agile methodologies, and how he started breaking all the rules.
That made me start thinking about our own process, and how it has changed over the past several years. We don’t strictly follow any process brand, but we work hard to develop the best software we can as fast as we can. We work they way we do because of our team. We have the luxury of a wicked smart team, and a team that knows how much we respect them. I can distill our ongoing process changes down to three points:
Looking back at our company’s history, most of the practices we’ve adopted started with these goals. And they weren’t driven by either Dianne or I. They came from the people that work for us. Then, they quickly move and change based on how it’s working, or how it’s not working. I’ll give three examples.
Early in our history, we did not have a daily standup. We didn’t need one. We were so small that we always knew what others were doing. Mike Woelmer suggested adding one. He is one of our first employees, and he recognized that as we added people, we didn’t information about what others were doing. We started a daily company-wide standup. That helped, but it wasn’t perfect. We’ve always prided ourselves in being flexible. Some days people work at home. That’s fine, but participating in standup is important. We added a free conference line, and asked people telecommuting, or at client sites, to call in. For those in the office, the phone is now our token for standup. Anyone working remotely chimes in in the order they joined the call.
As we continued to grow, we added project specific standups. Customers are encouraged to join their specific standup. We still have the company wide standup for all of us to learn about other projects. That just provides extra motivation to keep standups short. It may sound like a lot of meetings, but two standup meetings, both under 10 minutes, really increases communication and doesn’t have much of an impact on other tasks.
Oh, and if you can’t make standup because you are in a meeting at that time, email your standup report.
Our space has 5 offices, so we need to split up among the rooms. We still want everyone to get to know each other, and work together. Chris Marinos suggested that we switch offices every two months. If you’ve come to visit, and wonder why people are not where you last saw them, that’s why. Every two months (or so), we switch offices and change who we share space with.
This is one of those ideas that changed quite a bit during the last few years. We found we wanted to keep project teams in the same room. This is critical as deadlines and deliverables near. We wanted to time moves so they didn’t disrupt anything for our customers. Many projects last more than two months. Some people may decide not to move on a single rotation. There were times when Dianne and I needed to be in the same room so that we could concentrate on company direction. Other times, we needed to spend more time with other developers in the company.
Sometimes we assign people randomly to rooms. Sometimes we assign people based on the project they are on. Sometimes we assign people because someone hasn’t shared a room with someone else yet or in quite a while. It’s always changing. It’s always getting better.
At this time, I can say that almost everyone in the company has spent at least two months sharing an office with everyone else in the company. The only excxpetions are people that have been with the company a very short time.
Pairing is an emotional subject. Some people love it. Some people hate it. Some people refuse to try it. We experiment with it all the time.
We’ve let anyone on the team work in pairs whenever they want. Sometimes people need time to think individually. Personally, I find I work on my own when I’m working on books, articles, and technical presentations. I get in a flow and create content. Any interruptions throws me off. I don’t think I could pair on those tasks. Other times, I really need to bounce ideas off of others. I’ll pair with someone. Maybe using a computer and a screen, or maybe at a whiteboard. Either way, the collaboration is important. We have found ways to respect that both solitary time and collaborative time is important. we need to support both.
We’ve let people experiment with how and when they want to pair. That’s given us several new ideas. I can’t name everyone, because so many ideas came from so many different people. Some people pair by hooking up multiple monitors, keyboards, and mice to one machine. They can sit across from each other, making eye contact while working together.
Other people have experimented by using a server as a shared development machine and remotely accessing the ‘pair computer’. This gives them the advantages of pairing, and the advantages of having another machine to drive for searching, finding answers, or looking at docs for the problem at hand.
Others have paired remotely, using shared desktop applications. This isn’t the same as being together, but is better than being isolated because you can’t make it to the office.
Yes. I’m not going to give specific examples, because I won’t discourage anyone from suggesting new ideas because a previous idea didn’t work the way we’d hoped.
But I will say that we’ve discarded some ideas after giving them a small pilot and deciding it didn’t help as much as we’d hoped. Even ideas Dianne or I suggest are given the same evaluation. If it helps, we’ll do more of it. If it doesn’t help, it goes away, or changes.
We’re happy with the process we have now. We think we do a great job creating software for our customers. But we’re also convinced we can do better. Everyone on our team reads, explores, and learns constantly. They bring back the ideas the like, and we try them. We refine them, and we make them our own.
Today at lunch, new ideas came out and we’ll be experimenting with them shortly We continue to evolve, and continue to improve.
I can’t wait to hear the next great idea.
All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.