Hinweis: Die aktuelle German Testing Day Konferenz finden Sie hier!
SIGS DATACOM Fachinformationen für IT-Professionals

German Testing Day 2018

Die unabhängige Konferenz zu Software-Qualität | Frankfurt, 07.-08. Juni 2018

GTD Icons

Sessionsdetails

Vortrag: GTD 2.2
Datum: Fr, 08.06.2018
Uhrzeit: 11:20 - 11:55

How do you measure success rate of large scale agile process?

Uhrzeit: 11:20 - 11:55
Vortrag: GTD 2.2

 

Agile methods were originally designed for use in small and individual teams. Large scale Agile introduces unique challenges when different organizational units like software development teams, hardware teams, System teams, Customer Engineering teams must synchronize their activities when there is a need to interface with each other for a successful release. We coined a framework that connects Hardware, Software and other System requirements together under common roof called as - Common Quality framework, consisting of a common repository and metrics that were shared across hardware, Software and System teams, raising the quality bar to be aligned with the customer wants.This Framework is meant to stitch different Agile teams in the organization who are catering to a common business goals.

Target Audience: Engineering teams, Project/Program managers, Ship release Decision makers, other management members.
Prerequisites: Project management, release Quality management experience.
You will learn:
1. Independent of anything else going on, how will you increase collaboration?
2. Accounting for everything else going on, how can you increase trial and Quality deliveries to consumers?
3. What are some experiments people will do at different levels in the organization to make improvements?

Extended Abstract:

To succeed in this digital adapt-or-die environment, enterprises must be able to rapidly change the way they create and deliver value to their customers. Their ability to do that is highly dependent on their dexterity in developing software and systems. As those software and physical systems become increasingly complex, the methods used to develop those systems must allow the work culture to embrace collaboration, innovation, and speed.
To understand why there is a need for the Large scale Agile, I’m reminded of Jack Welch’s words: “If the rate of change on the outside exceeds the rate of change on the inside, the end is near.”
Agile methods were originally designed for use in small and individual teams. Large scale Agile
introduces unique challenges when different organizational units like software development teams,
hardware teams, System teams, Customer Engineering teams must synchronize their activities when there is a need to interface with each other for a successful release.
A system must be managed. It will not manage itself. Left to themselves, components become selfish, competitive, independent profit centers, and thus destroy the system. The secret is cooperation between components toward the aim of the organization – by W. Edwards Deming.
Inline to this, we established a built-in quality practices at an organization level which helps every team understand and ensure that each solution element, at every increment, achieves appropriate quality standards, throughout from development to release timeframe. We coined a framework that connects Hardware, Software and other System requirements together under common roof called as - Common Quality framework, consisting of a common repository and metrics that were shared across hardware, Software and System teams, raising the quality bar to be aligned with the customer expectations. Common Quality Framework is meant to stitch different Agile teams in the organization who are catering to a common Business Goal. This Framework mandates to follow a common yardstick to evaluate and the release schedule to be synchronized based on the dependencies which in turn aids customers to explore the final release samples with sufficient quality and maturity.

Despite the widespread proliferation of agile practices, implementation often suffers due to lack of
adequate project management support, System interdependencies, distributed teams or fear of increased interaction, to name a few. This at times called for financial risks.

Large systems have more economic sensitivity to quality than do the features and subsystems that define them. A definition in Steve McConnell's Code Complete divides software into two pieces: internal and external quality characteristics. External quality characteristics are those parts of a product that face its users, where internal quality characteristics are those that do not.
With this small experiment of having a common quality language across organization, we could see an increase in team collaboration/transparency, asking the right questions during milestone and ship release approvals."