Let’s cut to the point: Scaled Agile Framework (SAFe) offers a great approach to large companies that want to embrace Agile; well, perhaps, dabble a bit, more accurately. However, the SAFe journey continues to confuse many Empires with what gets started, when. Essentially, how to be Agile over how to do Agile.
This post offers a view to an information value stream from a vision and the relationship of what to develop and when to develop. Timely information remains an issue that continually confuses the empire.
Transformation has no safe journey. No clear path to success. When new ways to work disrupt the way people work, the only guarantee is that a series of twists and turns will disrupt success.
In recent years, Agile methods seem a business transformation catalyst. Suddenly companies with thousands of employees seem eager to capture the secret of— how small Agile teams of 10 to 12 people seem so successful.
The secret to Agile is no mystery: small teams succeed with fast feedback.
Vision, a SAFe Journey
SAFe does highlight a set of information artifacts and roles to connect context and improve the information flow. The below image presents some SAFe recommendation, but I needed a way to present information relation.
Many Agile approaches leave change for the culture to decide, but many a culture can expect an outline to follow, a guide, lest, belief that chaos will ensue and blame is assigned. A prescription does not exist.
Scaled Agile Framework (SAFe) is a popular approach to answer leadership’s cry for order. SAFe is a good alternative. In practice, as well: a 50,000-employee company I recently worked with found SAFe a viable solution to scale Agile.
- The right information,
- involving the right people,
- in the right time, for them.
SAFe recommends the above artifacts, not as separate burdens, but a flow of information that provides further development clarity, and importantly, priority. Each has distinct value to improve shared understanding.
Check Off or Check Up?
Unfortunately, many see the above as a quantity of items to check off and become paralyzed. There are too many EMPOs that riddle projects and people with document-heavy templates that please governance, but seem to delay ability to create working software.
The value stream from the company to the customer, demands fast feedback, but where to start? How to start? What to start? A consistent challenge with organizations I work with to adopt SAFe. This image shows information relation*, from the business to the development team’s feature builds. [jump down page for step-by-step, flow slider]
Notice the relational words such as:
- validated by,
- through, and
- satisfied by
Though there is thought of relation, you may believe better relations exist, just as IBM did in their presentation (see end of post).
I can address or recommend other SAFe alignment to roles and facilitation elsewhere, the company, Scaled Agile, has a good recap, the focus on this post, though, is information flow. Below is a view into SAFe’s recommendation for information needs to create development team clarity for final customer value.
Management expectation that the development team just deliver, just as fast, just in time, just as expected is the root of Agile failure. Agile, at any scale, only succeeds when the development team has a ready backlog to work from and a clear definition of done for each user story.
Misunderstanding begins with the concept to scale Agile larger to meet executive, senior, and middle-management governance need, but the opposite is critical: shared understanding must scale down to flow faster to meet the development team need.
Hover over the SAFe Information Value Stream to navigate.[return above]
SAFe to Lean
Information creates documents, communication creates shared understanding. The bigger the organization, the greater the gap. Any company with 10,000 employees rarely shows ability for anything resembling fast. More people seem involved to prioritize and prepare a development team backlog. As executives, senior management, and governance dither, the development team waits for clarity for shared understanding.
Wait is not Lean, wait is waste.
Critical business information that flows through templates and documents creates confusion. Confusion adds complexity to priority and assumes capability. Fear sets in as the company perceives SAFe suggestions through their current EPMO burden. This is not correct.
SAFe expects information to build insight and contribute to the next level of detail. Information from one source is relevant to guide the next, deeper, information level. This becomes input, not separate, but additive in detail, appropriate to refine and better determine context on what to develop. Goal-oriented design from better communication.
Confusion is not a development team problem. The reality is that Agile principles focus on making things smaller. Your executives focus on making things bigger.
The ability to deliver faster will accelerate mistakes and defects. Agile will accentuate all that is wrong with your organization.
A SAFe journey without a vision helps few.
SAFe has assembled many great tools from practiced delivery and experience, where I avoided 4.0 like the plague, release 4.5 and 4.6 are excellent and, as of this post, 5.0 version of their guidance.
*Image and content inspired by:
- Sprint Agile, has a one-page collection of SAFe Roles, Artefacts, and Ceremonies of Scaled Agile Framework in a Nutshell. Sprint Agile has combed the many SAFe pages to collect roles, artefacts, and ceremonies, please jump to this wonderful page;
- Great discussions with Brehk Kieft who also provided an early image that I worked from; and
- IBM: Vision Traceability an articulation of SAFe information value, other items are now behind a firewall, I am not sure when longer available, behind a firewall
Both Sprint Agile and IBM companies provide excellent articulation of SAFe elements to lend even more clarity. I modified both to help organizations see information context to enable communication flow.
For guidance SAFe is nice. For direction, a further SAFe vision is required.