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

Why are organizations not seeing the benefits of doing Agile?

Due to a difference in goals and approaches, friction occurs between Agile teams and the rest of the organization - who has yet to see the benefits...

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.

Agility requires cultural change

Article published in German magazine

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.

Agile in Everywhere: Sales

An experiment as a ScrumMaster and Agile coach working with a Sales team, where Agile practices are supporting new acquisition and retention targets

Image of ebru4984

Ebru Yalçınkaya

I act as a change agent where the teams, domains need to enhance agility to reach their goals, to create a shared vision if needed. I coach every kind of team , every domain, like management teams or like customer care, technology and sales groups.

Good VIBE at Scrumtisch Berlin

Scrumtisch March 2018 at SAP Berlin

Image of simsab

Simon Sablowski

Simon has spent several years working as a software developer, ScrumMaster and CTO. He is dedicated to shortening feedback loops to accelerate learning and strengthening team collaboration to maximise synergies. At agile42, Simon enjoys coaching and training teams and organisations that desire to attain higher productivity, continuous innovation and extraordinary performance.

Step up your Kanban game

In the upcoming weeks, Accredited Kanban Trainers from agile42 will facilitate certified Kanban training in locations all around the world

Image of mikefreislich

Mike Freislich

Image of rhilll

Russell Hill

Image of mgaewsj

Gaetano Mazzanti

My background includes a long experience as a manager in the Software and Machinery Industry. I worked in USA and India leading distributed teams in advanced software projects (CAD/CAM, PLM, Industrial Automation, Plant Control and Supervision). As a coach I am now trying to help organizations to change embracing Agile and Lean values and principles. I am a WIP limit addict :) and a KCP