White papers

Is there a single method for the Internet of things?

The Industrial Internet Consortium predicts the IoT (Internet of Things) will become the third technological revolution after the Industrial Revolution and the Internet Revolution. Its impact across all industries and businesses can hardly be imagined. Existing software (business, telecom, aerospace, defense, etc.) is expected to be modified or redesigned, and a huge amount of new software, solving new problems, will have to be developed. As a consequence, the software industry should welcome new and better methods.

This article makes the case that to be a major player in this space you will need a multitude of methods, not just a single one. Existing popular approaches such as Scrum and SAFe (Scaled Agile Framework) may be part of the future, but you will also need many new methods and practices—some of which aren’t even known today. Extending a single method to incorporate all that is needed would result in something that is way too big and unwieldy. Instead, the new OMG (Object Management Group) standard Essence can be used to describe modular practices that can be composed together to form a multitude of methods, not only to provide for all of today’s needs, but also to be prepared for whatever the future may bring.

Feature Slicing Guide and Poster

One of the key activities that will help make your SAFe® program a success is the careful preparation of your Features prior to Program Increment (PI) planning. And one important part of this preparation is to slice up any of the targeted Features that are too large to be easily delivered within the PI.

This handy downloadable guide shares some of our experiences in slicing Features. And, in tribute to Richard Lawrence and his popular Story Splitting poster, the authors have provided you with a complementary Feature Slicing poster for you to use in your SAFe program. Sweet!

ABC of Essentialization

An ABC Guide to Leveraging Adaptive, Bite-Sized, Composable Practices

To be agile as teams, we need to adjust our approach to meet our immediate challenges and needs. To be agile as an organization, we need to learn collectively and evolve our approach over time to support our evolving mission, so that we continue to excel in an ever-changing environment.

We would not call a TV set “adaptive” if, in order to adjust the volume, we had to throw it away and replace it with a model with a different volume setting. So why are we prepared to accept process frameworks that leave us in a similar predicament every time we want to improve our product development performance as an organization?

What Should You Measure?

Every agile organisation aims to run successful programmes that demonstrate true value and IT results, presented in a way the business can understand. But many struggle with showing how IT and the business are better, faster, cheaper or that their customers, users and other stakeholders are happier since going agile?

The single biggest problem we see organisations continuing to grapple with in their agile transformation programmes is not understanding why they are changing the way they work – not visualising the goal, setting targets, measuring improvements, or demonstrating the benefits generated.

The key here is to establish a set of actionable measures to drive the change and inspire the teams. These should explicitly support the principles and values being promoted and challenge the teams to improve.

Essence is instrumental in moving software development toward a true engineering discipline

Industrial-­scale agile requires much more than just being able to scale agile. It also means taking a disciplined approach to ensuring that our IT investments are resulting in sustainable benefits for both the producing organization and its customers. This involves adopting a different approach to many aspects of agility. We need to look beyond small-­scale agile, beyond independent competitive islands of agile excellence, beyond individual craftsmanship and heroic teams, and beyond the short-­term, instant gratification that seems to be the focus of many well-­intentioned but self-­centered agile teams. It is this adoption of a more holistic approach that we call moving from craft to engineering.

This paper is published at acm.org.