Agile Engineering Training explained
Often we get the question what do we do in our trainings? Especially how we can help companies which "do" Scrum already. So we decided to create a loose series of blog posts presenting some insights from our trainings :-)
Many Scrum teams face a great challenge even to comply with the basic premise of Scrum: They fail to deliver a potentially shippable product after every sprint. Manual testing takes a long time, bugs fixed once reappear in the next version. During the demo meeting the Product Owner rejects a lot of stories because the team missed too many small issues. After a couple of sprints, the internal architecture is a mess which no one dares to touch anymore. And last but not least the team wants to rewrite the complete legacy application from scratch as the old code can not be tested automatically.
To fight these all-too-common problems, there are a couple of techniques, also known as 'Agile Engineering Practices', that emerged during the last decade. In our 3-day Agile Engineering Course we teach developers modern engineering practices which complement the Scrum Process. The course combines a step-by-step introduction in a presentation-like manner with workshops and practical application. So let's talk about our most recent Agile Engineering course in a bit more detail:
The company employs about 20 developers who built a fast-growing web platform. While the company is successful from a commercial point of view, there are ongoing problems with new feature development technology and quality. Therefore the company turned to Scrum and we helped them during the initial transition. So the process was under control, development worked out quite well. The biggest remaining pain point was a big legacy system in their platform which was built by an external company some years ago. These days, only three developers were able to touch that system. Needless to say that there were highly valuable requirements which affect this system and, in fact, the technological problems in this system even blocked further company expansion to new markets.
First we needed to get more effective knowledge sharing between developers. Also there were big differences in quality, coding style and code structure between components and developers. So we started off with some lessons on pair programming, which requires some social skills that many developers had not yet practiced (at work). Pair programming is not only just two people sitting together - indeed there are many small tips and tricks.
We believe that the best way to learn something is to apply the new concepts yourself with the help of experienced coaches. Therefore the course contains a lot of time for participants to try out new techniques as they learn them. After two hours of pair programming, we evaluated the results together with the developers. In fact, this worked great - after the course the team members decided on their own that they wanted to see five new committers in the mentioned legacy subsystem within the next two months. Frankly, the entire management was taken back to see that as no one had wanted to touch that beast before!
In the beginning I mentioned that this old legacy system was in urgent need of refactoring. Obviously throwing away all this code is not an option. Therefore we had a big session on refactoring techniques and refactoring patterns to enable the team to improve the legacy system. When the participants tried to practice these techniques using their real product as an example, they had great success: Within 90 minutes they got rid of 100 lines of code (by removing duplication), committed fixes for two real bugs in their production code (which only became obvious after the refactoring) and started refactoring in a file which contained 1500 lines of code (with up to 800 characters per line) which did not contain a single function until then!
This was just the start of the course, and over the complete 3-day course we covered many other topics, such as Continuous Integration, Test-driven development, and Emerging Architecture.
Usually we provide this training to companies who have already started to use Scrum so that the developers have a chance to experience the real quality problems involved in delivering a shippable product and have taken the first steps on their own to solve these issues. During the training we can get rid of many misconceptions, show them 'best of breed' solutions and provide the team with more tools to solve their technological challenges!
I hope this post gave you a bit better impression about our Agile Engineering Course and that you liked it. :-)
By the way: Our client told us that one small comment, taken during a round-table discussion, led to the team cutting their time to release by more than 80% just a few weeks after the training. :-)