As I wrote in the last posting about Agile, truly moving to Agile development requires a buy in from company hire ups. In our case, we knew we had to change directions. There were lofty goals ahead of us on what the business was asking for in the platform we were creating. Way more than three engineers could handle.
Our current operation just wasn’t scalable. The founder, who had, among 50 or so other hats, was acting as the product manager and the QA manager. To give full credit, he did start with an idea, and hired contractors to start his vision. He had started long before the Atlassian stack exited, let alone other tools. He had learned to organize his operation through the extensive use of spreadsheets (and he loved the Google stack).
When our new CTO came on, during the testing cycle of last waterfall iteration, he saw the chaos that was our testing scheme. The system had become large enough, and inter-twined enough, that his testing spreadsheet had over 10,000 tests on it. A lot of support engineers, along with us developers spent quite a few late nights running through the tests, to get a release done we were comfortable with.
On top of that, the current platform required a build. The only system that could do the build was on the system of our most senior engineer, who lived in Canada, not the Southern United States. As you can see, getting to done was a monstrous task, and we knew we needed to ramp up the number engineers we had working on the product.
This shows one of the huge strengths of Agile. It’s built for scale. And since as a team, you focus on breaking down the projects into small tasks, accomplished and tested quickly, you eventually get rid of the huge testing cycle (admittedly, getting to that point takes time, but you’re able to shorten what is tested based on what was worked on).
As we were educated on Agile, we were also introduced to the concept of Srum. In a few weeks, after finishing the last release, the CTO started hiring more engineers, and got us working in the Scrum format. Really getting into Scrum took a little bit of time, since along with hiring more Software Engineers, the CTO also had to start building a QA team, as well as a Product Development team.
For those new to Scrum, a Scrum team consists of 3 to 8 Software Developers, a QA Engineer, and a Product Manager. Over time, we came to learn, in our teams, the ideal number of Software Developers was 5.
We were introduced to the concept of breaking projects into a series of “stories”, and weighting the “stories” with a point basis. The point basis is a numerical description of how hard a task is. The idea is, the entire team points the stories, discussing and debating the weight, until a consensus is reached. Once all the stories are pointed, team members choose what they are going to work on over the next iteration, called a sprint.
One of the genius points of Scrum, is that is it supposed to be self-organizing. There is a designated “Scrum Master”, who leads the team, but not from an authoritarian stance. The value of the points are supposed to grow organically (though we did end up adopting a standard hour-value for a point, to make it easier for management to project timelines and efficiency).
Since team members choose what they are going to work on, they are in essence committing to the rest of the team that they will have the tasks completed within the next sprint. The length of the sprint is arbitrary, and our teams chose to make each sprint 2 weeks long. The tasks were not considered complete, until after the QA member of the team had tested each tasks, and product management had accepted the work.
As we were making the evolution to full Agile and Scrum, we broke into two teams: a team specialized to a very unique set of code (which I was on), and the other, larger team, that did more generalized work. The other team investigated build systems (to free up our most Senior Engineer, and to protect the company in case something ever happened to him), and also investigated frameworks, since our code was old enough to be very custom.
One other thing the other team worked on (other than code enhancements) was creating coding standards for each language we worked in. Unfortunately, since all these major enhancements were being done by the other team, while my team was neck deep in new code, we were always playing catch up after the fact on learning these technologies (and never did have a say in the accepted coding standards).
One other change that happened very quickly was moving our development process to the Atlassian stack (even before investigations into the build systems occurred). I was so thankful to get away from all the spreadsheets, and start using a Scrum board. Eventually, as our teams grew out, there was one team that was working on integrations for our front end system that chose to use a Kanban board. This also meant moving away from SVN server (which had served us well for many years), and moved over to Bitbucket (a GIT based system, focused more on private repositories rather than Open Source repositories – also part of the Atlassian stack).
When we first started doing Scrum, our CTO acted as our Scrum Master. Over time, as he was getting spread wider in his responsibilities, those who chose to volunteer to become Scrum Masters were sent off to classes to become Certified Scrum Masters. I was one of those. As our CTO said, not all trainers were of the same value. The one he recommend, which we went to, was a group called “Mountain Goat”. If you are interested in becoming a Scrum Master, I highly recommend this group (I don’t get any kind of kick back for saying that, or linking to their site – I really mean it!).
For those interesting in learning Agile development, here are a few suggested readings:
Learning Agile: Understanding Scrum, XP, Lean, and Kanban