The truth of the matter is that teams should create a methodology that fits the unique environment they are in; and that methodology should focus on realizing the most possible value from the ideas in the agile manifesto. Every software team exists in an environment that is unique to their team; that uniqueness comes from a host of different variables including things like: company size, team size, company and team values, individual personalities, company goals, etc. And that means that the methodology they develop (and continue to refine over time) should be a methodology that is tailored to their unique circumstances.
Our industry is still learning and I think Agile is an important step on that path. As we come appreciate what agile gives us we do need to be careful that we don't become so focused on our process that we forget about the values. We need to frequently review how we are writing software and determine if there are unnecessary or less-effective processes that are adding dead weight to our chosen methodology. The objective should be to design a methodology that is as lean as possible without sacrificing important values.
This is one thing that I love about working at Pluralsight. Our methodology is the lightest methodology I've ever experienced. But our approach wouldn't work everywhere; we're lucky that our company environment allows for such a lean approach. This is due to a few factors, including:
- The pluralsight partners are developers, so we speak the same language;
- Keith, our IT manager, is not just the CTO but also a partner;
- our dev team, for now, is small (4 developers plus Keith, who used to do more development and is now moving more into directing the team);
- and our dev team has a lot of experience (we each have 13+ years experience and several years experience experience with agile).
The Planning Game
Since the person who manages our team also happens to be a Pluralsight partner, he already completely understands the company vision. He also has been very involved with the software (he wrote the initial software and still gets involved in the code from time to time). Having someone that understands both sides so well allows us to cut some corners. This, combined with the fact that our team is still small, has allowed us to completely forgo sizing meetings. The partners discuss and develop the IT roadmap and in their meetings Keith can provide feedback from a technical standpoint without having to do a round-trip to the dev team. We use a kanban board and we just put the stories on the board and Keith prioritizes them based on company priorities. When we're done working on a task, we just grab the next task. And this all works very well without the devs ever having to be involved in a planning meeting. Normally, this would make me nervous because the developers need customer affinity, but the awesome thing is, we still get that because Keith has the company vision and shares it with us freely in our "stand up" meetings.
Daily Stand-Ups (aka scrums)
We do have them, every day, but stand-ups are called stand-ups for a reason, right? You're supposed to stand up because it keeps people from going on and on about the details of some problem since people get tired of standing. Some people might be shocked to learn we never stand-up in our stand-ups. And some of our stand-ups do go longer than a "status update" meeting should go. But our stand-ups are more than discussions about status and roadblocks -- because our team is so small, we can afford to talk architecture or business in our stand-ups. Although there may be some occasions where part of the discussion isn't totally applicable to everyone in the meeting, I find our stand-up meetings to be very valuable. It is a great opportunity for the team to talk together about important directions and even get into the details of some of the roadblocks. It is also a great opportunity for Keith to share the business vision and direction changes. This meeting ends up taking the place of at least 3 meetings (stand-up, architectural design, and parts of the planning game). And because our team is small, we still manage to typically get it all done in under 30 minutes each morning. I realize that for some 30-minutes is an awfully long stand-up, but this is much more valuable than just a stand-up. We won't be small forever, so this may have to change some-day to a more traditional stand-up supported by other meetings, but for now, it's awesome.
Short Iterations
I've worked on teams that have had 1-week and 2-week iterations. The odd thing about our environment is we don't really even have defined iterations. I realize this may sound like cowboy coding, but it really isn't. Because we don't need a planning game (for the reasons discussed above), there is less of a need for defined iterations. We are able to keep this from becoming a cowboy coding shop because of other practices we follow closely (TDD, paring, acceptance tests, etc.). Additionally, the partners understand the importance of quality so the devs are completely comfortable (and actually encouraged) to slow down and do it right. When we finish a task, we push it to our repository, let our CI builds run, and if it is a meaningful enough change we push it to our staging environment where the changes are QA'd and accepted by other developers and once it passes it is pushed to production if everyone agrees its safe to push all the current changes.
Collective Ownership
In Extreme Programming Installed, Ron Jeffries says "I'm not afraid to change my own code. And it's all my own code." This is a benefit that comes from pairing and switching pairs regularly. When we have to work on code we're not familiar with it takes longer and we're more timid. Because our team is so small, this one just comes naturally. We all get into the various parts of the code eventually and the more we do, the more comfortable we are to make changes.
Pluralsight is growing quickly and it seems inevitable that our team will grow too. As our team grows, we will no doubt have to make changes to our process and add additional pieces that we don't have now. And that's ok, in fact, that's how it should be -- we should always be tailoring our methodology to fit the current needs of our team. But for now, I am totally loving how lean we can be.
What are your thoughts and experiences with designing a methodology to fit your needs?
