Model Maturity Versus Software Value Delivery

Tony TimbolOur experience in helping organizations implement frameworks and maturity models (TMMi, CMMI) has been nothing short of positive. Maturity models are useful devices to guide understanding for a large, organized group of professionals working together. So, what about using maturity levels within a SAFe implementation? Why? In order to help different release trains (groups of people) be incentivized to improve.

On the surface, this seems reasonable and the intention sincere. However, the maturity level designation is inappropriate for the scaled Agile environment. A maturity level is a static point in time. It is a declaration of compliance or conformity. Conformity is not a core Agile value, adaptability to purpose is, which is about getting work done as fast as possible within immediate, observable timeframes.

Now the intention to provide incentives to improve is commendable. Retrospectives built into the process (within Agile and SAFe) are designed to accomplish that. Immediate impediments are addressed on a short horizon. Enterprise-level obstacles are identified but may take some time to address. Having an appraisal, inspecting artifacts and declaring an achievement of compliance does not add value. Again, in the SAFe environment, maturity level compliance is incongruous.

Incentives, in Agile, can be tied to many things. In SAFe, tying them to value delivered ultimately respects the organizing principle of the Value Stream, elemental to SAFe. Creating and publishing value delivery metrics on a per-release-train basis calls back to factory production lines. Positive peer pressure works. It’s a core principle at the team level and it is scalable.

Designing the right value delivery metrics, that not only incentivize, but also inform the organization as to throughput, capability and potential issues is a worthy internal discussion to have. What do you think?

Tony Timbol
Vice President

Written by Tony Timbol at 05:00
Categories :

Enterprise Agile: ‘Water – Agile – Fall’ Makes a Splash in New Forrester Report

Tony TimbolIt's safe to say that for Agile practitioners who are working with clients, the recent findings about enterprise Agile in Forrester's "The 2015 State of Agile Development Report” are not all that surprising. For Agile purists the findings may seem discouraging, but in my view, the report shows that Agile’s benefits are so clear, that it is driving change regardless of barriers to adoption.

This quote about enterprise teams struck me specifically, "The teams know how to integrate Agile development with waterfall practices in an overall enterprise governance framework. When done well, Forrester calls this Water-Agile-Fall. 'Done well' means upfront planning and an understanding of very high-level product requirements (water), then sprints kick off with further user stories of refinement, design, development, testing, and integration (Agile), and, lastly, release packaging and deployment (fall).”

The words "upfront planning" and "high-level product requirements" indicate that enterprises are trying to fit Agile into existing organizational lines of command-and-control, as opposed to decentralizing decision making. Change is hard - these types of allowances are expected.

This chart from the report underscores the challenges organizations are facing in full Agile adoption:

Forrester State of Agile 

What's the big takeaway here? Do not underestimate the challenge in moving from a functional line-of-business model to a product/value stream structure, which aligns better with Agile and lean software engineering. This transition brings many organizational, personnel, and financial issues to the forefront that are not so easily addressed.

Even as solid as the SAFe (Scaled Agile Framework) approach is to scaling Agile, enterprises should move deliberately and carefully and understand that scaling is less about technique and more about effective change management.

You can download a copy of the report here.

Tony Timbol
VP of Business Development & SAFe Program Consultant


Written by Tony Timbol at 05:00
Categories :

The Scaled Agile Framework Enables Realistic Enterprise Change

Tony TimbolSteve Denning’s recent Forbes article, “How To Make the Whole Organization Agile,” had some excellent commentary on corporate cultural dynamics and the headwinds produced when change is attempted, especially in the case of Agile.

 On the whole, the article is about how easy it is for Agile to fail because it requires a commitment and a new way of thinking, not just from the Agile teams, but from the entire organization. This is largely because the top levels of an organization care almost entirely about making money – and command-and-control reinforces this belief down the lines of the organization. Agile, however, is about creating value for the customers (increased profits will come as a result).

Denning’s statement about a top-down management approach is spot on. He claims that in this environment, implementing Agile is tricky. When the manager is boss, “adoption of Agile is limited to the team level, [and] it risks being incomplete and dysfunctional, producing little if any improvement for the organization.”

The article then becomes a focus on how to create an Agile environment throughout the organization. Denning is quick to introduce – and dismiss – the Scaled Agile Framework (SAFe) as a solution. So far as we understand his point, this is because he sees SAFe as an attempt to align Agile teams with corporate goals (that is, to make money), which is ultimately not fostering an Agile atmosphere and is not focusing on increased value for the customers.

He asserts that, “In the process of ‘aligning’ Agile teams with corporate goals, such as making quarterly profits and pumping up the stock price, SAFe destroys the very essence of Agile.”

We struggle with this assertion for two reasons: First, SAFe is very much built on lean and Agile principles. Second, the alignment of which Denning speaks is not a sell-out accommodation to existing corporate authority structures. It is a negotiated agreement between management and Agile teams regarding value streams – and yes, that means value to the customer. That very discussion should be a catalyst for basing corporate goals on achievable customer value. This “alignment” between management and the teams is actually what has been missing in most development, resulting in a high rate of project failure.

Denning is right that making Agile work requires change within the entire organization, but we disagree with his belief that SAFe doesn’t meet this need. Indeed, we believe that a deeper understanding of SAFe shows that it facilitates such a change. SAFe is not the only workable way to scale Agile, but it is a realistic one.


Tony Timbol

SAFe Program Consultant

Written by Tony Timbol at 05:00

Tony Timbol Reflects on the Software Industry

DCG 1994 Logo 2C

This is the third post in a series that will offer our management team's reflections on DCG's 20th anniversary and the state of the software industry. Previous posts are here and here.

This year, I celebrate my 11th year with DCG as it celebrates its 20th anniversary. Through these 11 years, I’ve been able to talk with clients about their needs and objectives and have gotten to watch first-hand how technology and best practices change the way people do business.

Space ShuttleGlobalization and the commoditization of technology (continually advancing cheaper and more powerful products and services) are the two most powerful forces shaping how people use tech to make their businesses run better. That will continue unabated, with the most successful ones being those that leverage tech to create accessible value. For example, think about how the cell phone went from a clunky voice box to a mobile computing platform. I worked on the Space Shuttle program in the early '80s and the iPhone I carry today has 1,000 times more computing power then the four modified F15 flight computers flying STS-1.

Further, business leaders who build a culture of innovation within their companies will win in the marketplace. I believe the West Coast high-tech culture will continue to change the way U.S. businesses operate. Business culture is more important than technique because methods and practices will always advance, but the innovators will always be a step ahead. Amazon is a good example of innovation that disrupts tradition.

As these trends take shape, DCG’s ability to anticipate what's coming and to provide thought leadership is one of the things that makes us a valuable partner and a great place for our team to work and thrive. I look forward to what's ahead!

Tony Timbol
VP of Sales

Written by Tony Timbol at 05:00
Categories :

Is There a Business Case for Better Estimation

Another month, another new Trusted Advisor report! David Herron, Vice President of Software Performance Management, and I wrote this month’s report, “Is There a Business Case for Better Estimation."

Is There a Business Case for Better Estimation?
Improving software project estimation requires an organization to commit resources to the development and execution of a well-defined software estimating practice. The ROI or value add of an enhanced estimating process may be directly linked to tangible cost savings or there may be savings that are less direct and harder to specify.

This report is intended to provide a value analysis, or business case, for how an effective estimating practice contributes value to the organization in both financial and non-financial terms.

Trusted Advisor is our free research service, open to all IT professionals. Join Trusted Advisor to submit questions to the research backlog and to vote each month on the question you want to have researched!

Tony Timbol
Vice President of Sales

Written by Tony Timbol at 05:00

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!