Sept. 30, 2010

Agile Engineering Training explained

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 ...

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!

Afterwards we spent quite some time introducing automated testing (not just "unit testing") as well as a lot of testing best practices. Many modern web applications contain a lot of Javascript which grows more complex day by day. So how can you get this code under test? Selenium alone is obviously not the right tool as these tests tend to be to fragile and slow. How can tests help you in finding memory leaks before you even notice them in your application? How can keep your test suite maintainable? How can you identify bad tests? We touched on these issues and more, and had a lot of surprised and excited front-end developers finally able to build test suites for their code.

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. :-)

Image of FSchwarz

Felix Schwarz

blog comments powered by Disqus
Image of FSchwarz

Felix Schwarz

Latest Posts

Workshops on the Certified Agile Leadership pathway

CAL 2 workshops offered in Berlin on Agile Leadership, Organizational Design, Changing Leadership, part of the Certified Agile Leadership program

Image of marion

Marion Eickmann

I am one of the founders and the executive director of agile42. I am supporting strategic product development and leadership challenges for more than 15 years now. Since 2007 I have been realizing local and global agile projects with agile42's international team successfully. You like to talk about: Organic Agility, complexity, resilience, organizational culture & Agile? Just send an email :-)

Exhaustion is Not a Status Symbol

Leverage the agile values to mitigate the risks of exhaustion becoming a status symbol

Image of melissa.boggs

Melissa Boggs

Meet The Coach: Kemmy Raji

Having worked in various sectors from financial institutions to utility companies, meet Kemmy Raji.

Image of agile42


News and views from the Headquarter of the agile42 team

Meet us at Agile People Sweden 2018

Come and join the coaching clinic with agile42 at Agile People Sweden 2018 Conference in Stockholm

Image of sofia.svanback

Sofia Svanbäck

I am the Business Relationship Manager of agile42 in Finland and Sweden. I started working at agile42 in May 2018 and haven’t done anything so interesting before. The decision to join agile42 is a decision I am proud of today. My days are filled with customer related things, like negotiations, offers, and training / coaching bookings to mention a few.

Meet The Coach: Sunny Dhillon

For our Meet The Coach series, agile42 coach Sunny Dhillon talks about his background, his agile journey,  and insights about Agile adoption. 

Image of agile42


News and views from the Headquarter of the agile42 team