This empirical process should apply to both what we’re building i.e. the product but also to how we build it our ways of working, team, tools, etc.

Empiricism requires transparency so that inspection may occur and then drive adaption.

A product example would be: We have metrics that give us transparency regarding how customers are using our mobile app. We inspect those metrics frequently and then adapt our product backlog based on our learning.

A ways-of-working example would be: we have data giving us transparency about the number of defects making it to the staging environment, we inspect those metrics regularly and then adapt our ways of working for example with automated regression testing.

It’s helpful to think of both these inspection and adaption loops (product one and ways of working one) as applications of the scientific method. We start with observation, then formulate a hypothesis, conduct some experiments, analyze the data, and determine if the hypothesis is correct. In this way, we evolve the product or our way of working.

Next time you’re crafting a feature for the product backlog or considering an improvement action for your ways of working make sure to ask yourself “What is the hypothesis I’m testing here?” and “What data will prove or disprove my hypothesis?”

The post Agile is Empirical first appeared on Agile Sunrise.

What are these frameworks?

SAFe focuses on agility through the adoption of several methods, such as design thinking, lean principles, agile principles, and more. The combination of these methods enables teams of teams to collaborate and deliver efficiently.  TOGAF aligns business goals with IT strategy. It offers a method for developing an enterprise architecture (EA) that supports long-term business strategies.

How SAFe and TOGAF Can Work Together

1. Strategic Alignment and Vision: TOGAF provides the vision and strategic direction, which SAFe translates into actionable deliverables. This ensures agile teams align with long-term goals.

2. Architectural Enablement in Agile Release Trains (ARTs): TOGAF guides the intentional architectural aspects within SAFe’s ARTs, ensuring each increment contributes to the broader enterprise vision.

3. Governance and Iteration: TOGAF’s governance can oversee SAFe implementations, ensuring alignment with enterprise architecture. SAFe’s iterative nature allows continuous feedback and adaptation.

4. Cross-Functional Collaboration: Both frameworks emphasise cross-functional collaboration; however, aligning closer to the SAFe framework will enable agility across the enterprise.

Considerations

• Cross-training: Train enterprise and solution architecture teams in both frameworks to improve communication and alignment.

• Adaptation and Customisation: Customising frameworks too much dilutes the benefits that each framework will give you.

Conclusion

SAFe and TOGAF approach architecture from different angles, and because of this, they certainly can coexist in the same enterprise; when done correctly, they can also complement one another. Before jumping in headfirst, you need to understand the strengths of each framework and assess if, by combining these frameworks, you will still get the required benefits. One word of caution: these frameworks work because they are implemented in their entirety; if you only implement half the framework, only expect half of the benefits.

The post Can TOGAF and SAFe coexist? first appeared on Agile Sunrise.

The post The Top 6 Things to Like About SAFe 6.0 first appeared on Agile Sunrise.

It is however, an interruption to the flow, so use it wisely…

• How often will you have them, is hourly too frequently? The size and maturity of your train will have an impact here.
• What questions will you ask? Avoid asking too many questions or questions you already know the answer to.
• Park any discussion for a meet-after or to be taken back into the room for planning.
• Who needs to be there? It can be tempting to swell the list of participants to get everyone aligned but this tends to draw out proceedings, is it better to just have Scrum Masters there? Do you need a separate Product Owner (PO) Sync?

Overall are you inspecting and adapting both during PI planning and from one event to the next?

The post Lean SoS in PI Planning first appeared on Agile Sunrise.

I find myself increasingly suggesting to teams (of teams) that they define, or at least discuss to the point of having a shared understanding, what will constitute a Epic, Feature & Story in their context.

This seems to be an easier exercise if we’re not starting from software specific definitions. So how to think about Epics, Features & Stories more generically than that…

Epics are the largest unit of work. They’re our investment decisions. They’re typically going to ‘move the needle’ on an organization or value streams KPIs. They’re probably bigger than one three-month Program Increment (PI) to implement. They’re likely defined in some ‘lean’ business case that covers expected benefit, estimate of the work, top features and some consideration of what’s MVP versus the full set of features.

Example: The new brand identity.

Features are (potentially) releasable increments of done. They might need a couple of other features to be ready to make sense being released but they’ll often be released / launched / made public on their own. They should not take more than one three-month Program Increment (PI) to implement. They may or may not be part of an Epic.

Example: The Christmas TV advert.

Stories are verifiable (sign-off-able) increments of done that may or may not be releasable on their own and may or may not be part of a feature. They will fit into a single sprint (usually two-weeks).

Example: Poster for the company party.

The post Units of Work first appeared on Agile Sunrise.

The post Lean Business Case Format first appeared on Agile Sunrise.