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

Mike Freislich on the inevitability of change

Video of Mike Freislich interview with Klaus Leopold on the Lean Business Agility podcast

Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks

Agile Portfolio Management in it-daily.net

A new article in German magazine it-daily.net

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Why Agile Transformations Fail – Do You Fall Into The Same Pitfalls?

Insights from TAC2017: Why do agile transformations fail? Identify whether your team or organization falls into the same pitfalls.

Image of hwong

Hazel Wong

Marketing Assistant at agile42. Passionate about gaining insights from data in order to create content that resonates with the audience. Eager to help teams and companies open their mindset about the application of agile methods to address their challenges.

Sponsoring Let's Test South Africa

Let's Test South Africa 2017 sponsored by agile42

Image of joperold

Joanne Perold

Agile Coach in South Africa. Explorer, learner, experiencer, part time philosopher, working with teams and organisations to be more agile.

Niels Verdonk, new Certified Scrum Trainer in the Netherlands

Niels Verdonk has qualified as a Scrum Alliance Certified Scrum Trainer

Image of andreat

Andrea Tomasini

I am an Agile Coach and Trainer and I am helping customers all around the world to become more Agile. I am more and more keen on adopting adaptive emergent approaches to improve people's quality of life. Through an holistic and pragmatic approach - I consider Lean and Agile very powerful frameworks - it is possible to improve results, performance and also personal satisfaction.