Featured in Architecture & Design

Monal Daxini presents a blueprint for streaming data architectures and a review of desirable features of a streaming engine. He also talks about streaming application patterns and anti-patterns, and use cases and concrete examples using Apache Flink.

Featured in AI, ML & Data Engineering

Joy Gao talks about how database streaming is essential to WePay's infrastructure and the many functions that database streaming serves. She provides information on how the database streaming infrastructure was created & managed so that others can leverage their work to develop their own database streaming solutions. She goes over challenges faced with streaming peer-to-peer distributed databases.

Measuring Agile Performance with the Agile Triangle

Traditional software development teams are supposed to work within the confines of the software 'Iron triangle'. The three sides of the triangle are Scope, Schedule and Cost. Since Agile places a lot of emphasis on quality, it is often considered a dimension which sits at the middle of the triangle. For any project to succeed there is a need to manoeuvre one of the dimensions keeping the others relatively constant. Most Agile teams vary the scope and keep a tab on Cost, Schedule and Quality.

Jim Highsmith suggested that the Iron triangle, imposes a lot of constraints on the flexibility of the Agile teams and suggested an alternate Agile Triangle.

Many agile teams are now caught in a dilemma. On one hand they are told to be agile, flexible, and adaptable, but on the other they are told to conform to pre-planned traditional Iron Triangle framework of scope, schedule, and cost. In essence they are being told “be flexible in a very small box.” Agile teams are striving to meet one set of goals and managers and executives are measuring against another set.

Jim suggested that the Agile triangle consists of the following vertices

Value – to the customer in terms of current releasable product.

Quality – continuous delivery of value to the customer in terms of reliable, adaptable product.

Constraints - the traditional scope, schedule, and cost.

He suggested that though the constraints are important project parameters but they are not the goal of the project. He added that,

Value and Quality are the goals and constraints may need to be adjusted as the project moves forward to increase customer value. Schedule might still be a fixed constraint, but then scope could be adjusted to deliver the highest value within the schedule constraint.

Jim also suggested that the focus of development should be on the releasable product rather than the implemented scope. Agile teams should ask the question “Does the product have enough capability to release today?” This would help maintain a strategic focus for the product rather than keeping a focus on the detailed requirements.

He admitted that though Value and Quality are difficult to measure as compared to Cost and Schedule, however, focus should be more on measuring value delivered via a releasable product rather than trying to precisely calculate less important things like the constraints of the Agile triangle.

It’s much better to have fuzzy measures of really important things that precise measures of less important things.

Thus, according to Jim, Agile teams should focus on the releasable product rather than getting constrained by the iron triangle. The three vertices of the iron triangle collapse into one vertex of the Agile triangle called constraints. The other vertices i.e. value and quality define the goals, they are of utmost importance to the stakeholders and need more attention.