Just tuning into business agility? Dean and Mik define the new paradigm in two video keynotes.
February 20, 2020
4 comments
By Dean Leffingwell
Those of you who have been with us for awhile know that the launch of SAFe 5.0 represented a significant evolution in thinking when it expanded its focus to enabling full business agility. The imperative was clear. It was time to go beyond IT to align the entire enterprise on strategy and execution; to empower companies to undertake company-wide initiatives that are critical for the company’s future. Of course, we need our business partners to do this.
If you are just wrapping your head around this new direction and what it means to businesses competing in today’s fast-moving markets, I’d encourage you to watch two keynotes, both from the 2019 Global SAFe Summit where we launched SAFe 5.0 in October, 2019:
One features Mik Kersten, CEO of Tasktop and author of the best-selling book, Project to Product which Gene Kim describes as “Every decade there are a couple of books that genuinely change my worldview … This is one such book.” In his keynote, Mik talks about how many business leaders are tracking actual delivery results of transformations, rather than measuring via project plans and cost centers. He discusses the fundamental problem, which is that the way transformations are structured has a very different meaning to the technology side than it does to the business. And he describes how a product-focused operating model can provide the critical glue between the hierarchical and finance-oriented structures of the business and the agility enabled by delivery teams adopting SAFe.
In my keynote, I discuss how all aspects of the business can operate in harmony to deliver and evolve innovative business solutions faster than the competition. I describe the technical and business competencies needed to achieve business agility, how they are integrated into SAFe, and I share insights as to how an enterprise can measure and grow the prowess they need to thrive in the digital age.
And if you happen to be in Europe in June, and you want to take a deep dive into this new way of thinking, join Mik and I at the 2020 European SAFe Summit in The Hague, June 10 – 11.
Stay SAFe,
—Dean
Author Info
design and build
Thanks for sharing this information with us. I love to read your article, The way you explained is excellent. It’s really a nice and helpful piece of info. Keep posting and keep sharing like this.
Harry Koehnemann
Thanks for the feedback! We will keep posting and sharing items like this. That’s what we do!
Mark Allen
Dean, as a data architect, I am trying to understand where both enterprise -level and application-level data modelling (both logical and physical) happen in the SAFe approach.
I did a search for “data model” and “database model” on your website and the only reference I found was that Shared Services includes “Data modeling, data engineering, and database support” and, in the SAFe Case Study: Fannie Mae, i read “Best Practices – Work on database modelling upfront: For any data-heavy effort, perform advance work on database modelling to avoid the impact of changes identified later in the sprint”.
Your architectural roles diagram also does not include any reference to data architecture (see below – interestingly, the Enterprise Architect role is also mentioned as a Shared Service). How/where does database design (again, both at an enterprise-level and at an application-level) take place in this approach.
In addition to the immediate need to design a database to support any application, having metadata defined and agreed on across business lines and applications is fundamental to enterprise reporting, as well as to data governance, master data management, data warehouses, etc.
There seems to be a substantial gap in the methodology in not addressing the need for data architecture, especially as we are still very much in a relational-database-centric mode in commercial systems.
Harry Koehnemann
Thank you for the comment, Mark. The Agile Architecture article describes how the SAFe architectural roles (System, Solution, Enterprise) address concerns at their various levels. These roles are functions of potentially multiple people that have all the skills necessary to support teams and ARTs, including information, application, and other architectural domains. But it is not an exhaustive list and can include other domains, like data architecture. Database design and other architectural work typically appear as Enablers. Some of that work may be performed by the Architect roles, but much of that work is also performed by the teams. Architects collaborate up and down the hierarchy to ensure alignment across teams on many technical items including common metadata and also bring feedback from the teams on how well technical decisions are working. We are also collaborating with The Feld Group to add more knowledge on architectural technical practices within SAFe. The initial collaboration is described in this whitepaper. Thanks again for the comment.