Regarding processes and practices, a lot of what is published or promoted in the Rails world comes from the consultant point of view. I think it’s fantastic these companies and individuals share their lessons learned and there is great value in those lessons. If you are in a Rails shop looking at these examples as templates for organizing your team please take this information as guidelines. Very good guidelines indeed, but not everything that fits for a consultancy will directly translate for your organization. It is important for your team to discover what works for you in your environment. Here’s the discovery process we went through, hopefully this will help you and your team.
Many months ago we started down the wrong road trying to do things in a rigid agile manner. Sound weird? Well it was, but we didn’t know any better at the time. We were ignoring our gut instincts hoping this agile thing would prove us wrong. After a short time, the word agile became an excuse used by some to avoid any architecture (any thought into the long term goal). In fact, the term architecture became a symbol of everything anti-agile and therefore evil. It was at this point for me that agile became an evil term and a symbol of avoidance. These were not good times.
After a couple of missed deadlines and the realization that the ‘extra’ time wasn’t producing a better product, we revolted. Now this isn’t like we had opposition during this revolt, just the opposite. We given charge of this and the revolt was against our own blind stupidity. It was embarrassing.
We then decided that nothing was sacred. From the tools we used to the processes we employ, anything could be challenged and changed.
As we were just starting down this path we had the great fortune in having Hashrocket come aboard and pair with us. With their help we delved deeper into the practices we already employed: pairing, bdd and daily scrums to name a few. We were also introduced to tools like PivotalTracker and Campfire.
Some of the practices we were doing (pre-Hashrocket) were so weak that saying we employed them was almost laughable. We got a lot of help in those areas. We also were given rules for some practices that just did not transfer to our environment. Did we expect them to? Well yes, but that was incorrect to do so. What we have done is taken the ideas as a starting point and let team define the rest.
Are we done, do we have everything ironed out and run flawlessly? Absolutely not, but our team has grown in fantastic leaps and bounds and while things will continue to evolve, here are a few of core practices we will not abandon. They are the reasons we will continue to learn and improve.
**wow that was a really long intro for a short list
Weekly Retrospective
Every Friday afternoon our dev team gets together, closes the door and talks about the week. What we should keep doing, what we should stop doing and what did we learn are all discussed. We have removed/added/altered processes, practices and tools from the result of these meetings. This is the single greatest impetus for change.
Iteration Leads
In order to spread knowledge about the different projects across the team we assign someone to the iteration lead role. This is the go to person for the iteration and is responsible for seeing it through to a successful release.
Team Board
This is simply a rolling whiteboard that we use to show the following:
- Pairs for the iteration and what they are working on.
- Iteration leads
- Release dates
Daily Standups
We actually have two different sessions every morning. Since we have multiple products, the dev team breaks apart and goes to their product related standup. We then get together and have a developer only standup to relay any information. This divide and conquer technique has proven to be very efficient.
Last and not least:
Pairing
This one is a post in itself, I’ll only briefly cover pairing. Pairing is good, but like most things in the computer world doing something ALL the time usually fails. At a minimum, I think there are times when pairing should be approached differently. For example: If the pair is tasked with researching something that neither knows, I think researching the problem individually and regrouping later is a better approach. Not everyone process information the same way. More on this later, but as a basic rule: Pairing is good.
Over the past few months I have become more and more interested in what people are doing in the corporate setting. I even went so far as to create RubyTrends.com in an effort to get a picture of the entire Rails landscape, not just the consultancies. While the site is rough right now (updates are coming soon), I would appreciate you voting on the projects, books and practices you use. I think this information would be beneficial to us all.
Thanks for reading,
-stonean
