SATURN 2015: Maturing Agile Teams and Driving Quality Through Architecture Principles (Session Notes)

Amine Chigani and Yun Freund, GE Software

At GE, software is a horizontal capability in the company, with over 14,000 software professionals in the business. GE Software is launching the Predix™ platform, which will be a common theme across all of GE’s industries, and the company will make this platform available to the world later this year.

GE Software’s multiple Scrum teams work on various projects, from data science NTI to legacy integration. The customer for Chigani’s experience report was GE Transportation, a 100-year market leader in Class 1 railroads, with several billion dollars in backlog. The teams used an agile development approach of XP/Scrum/Six Sigma. They used rigor-less architecture or no architecture, and Chigani’s goal for the project was to establish a focus on architecture.

He started with the basic value proposition of architecture: Quality and architecture are two sides of the same coin. Regardless of the development method, software quality comes from both functional and structural aspects. The sell to the customer through functions, but architecture represents the cross-cutting structural concerns. Chigani’s team had to ensure that these structural concerns made it into the agile process, so they scheduled discussion time for architecture concerns.

The team worked with stakeholders to define key quality attributes and then worked to make them livable for the developers. To do this, they established a quality matrix and test plan templates with measurements and targets for each quality attribute. They started with a defragmented infrastructure, then they built a dev-test-deploy infrastructure, implemented an automated continuous integration/continuous delivery process, and aligned the architecture with their platform technology choices. Throughout the project, they maintained consistent code-level standards, with the maintenance metric of adhering to the code style.

During this project, the teams needed to learn new practices and skills. They began code reviews and encouraged teams to do as-needed pair programming. They added QA engineers to teams to drive quality implementation. And they added build and release engineer capabilities. The customers also assigned dedicated product owners and IT subject-matter experts, usually the person who owned the legacy system, to each team. This last practice was critical; otherwise, a team may build a very shiny system that doesn’t integrate where it needs to. The product owner is the voice of the customer and a big influence on architecture tradeoff decisions.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s