True agility is not just a process attribute. It is also a by-product of the architecture and design of your software system. But, what does an agile architecture look like, and how do we measure it? The crux of more honest measurement is to quantify design quality. If you can quantify and then minimize growth in architectural complexity, you can free-up your software teams from playing defense (mired in late scrap and rework and unnecessary overhead), and unleash them to play more offense by increasing value, quality or responsiveness. Measurably improving design quality earlier in the life cycle and continuously thereafter can help enterprises achieve breakthrough economic outcomes.
Agile is seen, correctly, as a means to achieving better results developing Software and in Systems development. In the small, agile practices and defined methodologies have been supporting good results for over a decade. As practices are scaled to value stream, portfolio, and enterprise levels each organization struggles at the point of including groups like Finance, Business Controls, and Compliance.
Presented by Doug Stewart, SPC4, CSM, 321 Gang
Many systems in aerospace, defense, automotive, medical, banking, and other industries have an unacceptable social or economic cost of failure. As a result, these systems are often subject to regulatory oversight and compliance standards. These organizations are adopting Lean-Agile methods, and are struggling to understand how their existing stage-gate compliance activities participate in a Lean-Agile flow of value.
Reviews are a key aspect to improving product design and development. Not only do reviews provide an opportunity to find errors, omissions, risks and opportunities early and often in the product lifecycle, but they also enable increased understanding and communication amongst the development team. Comments, design decisions and rationale are valuable outputs from these reviews, and yet this data is frequently not recorded and kept with the data it describes. Meeting minutes, action item lists and other review artifacts are scattered in different tools, notes, notebooks, and folders disjointed from the design artifacts.
The classical systems engineering practice is mostly process centric, but with the recent advances in Information Technologies, we have started to engage in model-based and other software-supported activities that make us more efficient and our products better. The subject of our INCOSE IS 2016 paper was a pursuit of further improvements in the software tools supporting the systems engineers,
Product line growth can create a natural degradation into chaos. The common engineering solution follows a copy-and-tailor for requirements, designs, code, and tests rather than a strategic, planned reuse. A global, strategic configuration management approach across lifecycle domains (e.g. requirements) can bring order to this chaos. Order replaces uncontrolled costs with direct profits. In this webcast we walk you through a detailed scenario based on a real product line problem and solution.
Learn how many legacy Rational users, as well as the JAZZ tools (DOORS Next Gen, RTC, RQM, CLM, etc.,)are using a “new” licensing paradigm in order to get advantages that are not available in the perpetual license model such as, reducing their software and maintenance costs.
Now that your organization has streamlined your Agile Release Train, how do you keep it on track all the way through to customer value? We’ll show you how delivery automation and coordination with DevOps is a key element of scaled agile success.
In this webinar presented by strategic partners Tasktop and 321 Gang, you’ll learn how to connect ALM development tools across development teams to create an architecture for DevOps automation and build process models that connect the various stages of software delivery. 321 Gang and Tasktop will demonstrate various integration workflows that leverage both synchronization and OSLC linking; e.g., requirements traceability between Rational Collaborative Lifecycle Management and systems like JIR
This talk presents the “Agile System Engineering Specification Workshop” and our experiences applying it. We begin with a background or lean-agile principles and practice and discuss where specification workshops fit into the lean-agile flow. We then present the workshops details specifics including guidance structure, mechanics, attendees, frequency, and logistics. We discuss how behavioral threads from SysML specifications become backlog items and how to prioritize by focusing on the highest