Agile & Lean Product Development

A Practical Approach to Agility and Product Management

Tag: SAFe

Project Runway

April 7, 2018 / / 0 Comments

Planning ahead in software development – just enough

Big Design Up Front (BDUF) is dead. There may not be too much agreement about any one thing in software development, but the industry has pretty much concluded that BDUF doesn’t work. 

As Agile practices and mindset took hold, up-front architecture was essentially looked down upon. And for good reason: in many cases, a system architecture can evolve and be adjusted over time as the system matures. We call this emergent design. (On the far side of the continuum of up-front planning, opposed to BDUF, lies “Just start coding”, which is still practiced quite a bit too, with varying degrees of success as it is more the extreme case, but may be sufficient in simple cases.) 

Another mantra circulating in Agile circles is to focus on and start with the easiest thing that can possibly work. This approach allows us to focus on solving the immediate problem at hand while ensuring we are not pursuing an overly complex solution. The theory is that – with the help of emergent design – the implementation can be adjusted down the line.

However, as organizations scaled their development teams and systems grew more complex, problems started to surface. It became problematic for several teams working on the same large solution to let design simply “emerge” in real-time, at the team level. After all, an application architecture is not fully malleable and might be resistant to change. And several teams working on the same application require coordination, agreement on architectural approach and at least some level of planning. A more intentional architecture was needed, without resorting back to the BDUF days. And therein lies the key, which is more art than science: finding the sweet spot between emergent design and intentional architecture (see Agile architecture). 

Continue reading

Reducing Variability and the Airport Omelette

March 5, 2018 / / 0 Comments

Like many times before, I was sitting in my favorite airport restaurant before my first flight and enjoyed my typical egg white omelette. Then I questioned myself: why don’t I eat breakfast at home instead and leave later for the airport? That didn’t feel right (apart from the fact that my home cooked omelettes don’t taste as good), until I realized there was a deeper reason for it: Eating at home meant leaving later, which would increase the likelihood of hitting traffic on the road and longer lines in the airport. Leaving later would also reduce the safety buffer I can rely on if something unforeseen happens. If worst came to worst, I could skip my airport breakfast and chow down a bar instead and still make my flight. If I ate at ours have that safety buffer.

Taking a step back, making a flight as well as completing work projects on time is about increasing predictability. One way to do that is to reduce schedule and other risks by eliminating variability early on in the process. So if a project consists of multiple sequential steps, it makes sense to eliminate variables as early as possible and take on those tasks that have the highest possible variability first (assuming the tasks can be resequenced accordingly).

This is very much in line with Agile’s recommendation to take on those stories and features with the highest level of technical risk first. It’s all about reducing risk and increasing predictability.

Wait, you might say, doesn’t SAFe propose to preserve options and defer decisions till the last responsible moment? Yes. If these options bear the same amount of risk and variability, doing so may not necessarily increase project duration and risk, but it certainly doesn’t remove variability early on. The goal here is to stay responsive to changes in market and business demands and not place technical bets until necessary.

In practice, one will need to find the right sweet spot between reducing variability and preserving options as those two approaching are some what opposites sides of the same continuum. SAFe practitioners are, at the end of the day, also incentivized to be predictable and meet PI commitments, if possible.

Now that I understand why my usual airport omelette actually helps me make my early flight, I will certainly keep my eyes open for other opportunities in my life to reduce variability and increase predictability where it matters.

Journey to the Center of SAFe

April 22, 2016 / / 0 Comments

I recently went through the SAFe SPC4 class, which was quite interesting in the light of my earlier post about “my problem with SAFe“. First and foremost, I wanted to understand SAFe better and kept an open mind throughout the experience.

Here are some first impressions:

  • The guys from Scaled Agile do understand Agile well and spent a good amount of time on the underlying principles.
  • SAFe is supportive of self-organizing and empowered teams, which is a good thing and maybe not what I would’ve expected.
  • The SAFe hierarchy does not imply that all items always flow top down. Work items can also be inserted horizontally and the framework includes a bottom up flow of information and collaboration. This is different from other hierarchical scaling models I’ve seen.
  • In SAFe 4, value streams were introduced and there’s admittedly not all that much experience with them. The transition from operational to development-centric value streams in the process of figuring the structure out is interesting but also confusing and not very clear. It’s still somewhat illusive to me how this is going to work and how to get from there to release trains.
  • Lots of material to cover in SPC4, lots of stuff…
  • I expected the framework to be more prescriptive, but as a matter of fact, the further up you go in the hierarchy, the more fuzzy it gets around roles, processes, etc. to the point where I wanted more information.
  • The PI planning ceremonies, which are to be run as big room planning events and are arguably the core of SAFe together with release trains, are logistically challenging and incredibly expensive. One could even argue that the PI (planning and innovation) sprint at the end of the PI is a sprint lost to make room for PI planning. I wonder if there are cheaper and easier ways to accomplish this.
  • The jury is still out whether pre- and post PI planning events are sufficient to really pull off a value stream planning.
  • Dependencies are what kills big Agile systems and while SAFe does a decent job of surfacing them, I’m not sensing they have magic sauce to deal with them either.
  • With any decent mass, i.e. number of teams, I’m struggling to see how sticky notes and paper can work during PI planning events although that is being advertised. I tend to think that without a decent ALM, this will be very hard to pull off and even more so with distributed teams.
  • Did I mention that the logistics of planning multiple release trains concurrently seems outrageous?
  • Release trains (ARTs) and PIs assume a lot of maturity, including the ability to more or less lock scope for an average of 10 weeks. That may be a challenge in quite a few environments. And starting teams that haven’t done Agile yet as release trains seems like a pretty big jump. And how do we deal with teams who can only plan 1-2 sprints ahead but are part of the ART due to dependencies with the other teams in the train?
  • SAFe 4.0 speaks to Kanban teams participating in release trains, but it’s not unite clear how exactly this will work and whether teams will be required to break some Kanban rules in the process. Scrum seems like a better fit.
  • I like the principle of “taking an economic view”, which I feel will be helpful at various levels.
  • SAFe does not mess with the team-level roles including the Product Owner. I like that the teams continue to have someone in the team that plays this critical role.
  • Not much time is spent talking about situations or circumstances where SAFe is not a good fit. For example: what about teams with volatile backlogs or teams that are able to function rather independently?
  • Scaled Agile itself is not so much a consulting company, but seems to focus more on and monetize education, training and licensing their materials.

Overall, this was a good class and really helped me understand the framework. Am I a believer? Not quite yet; as they say: “the proof is in the pudding”. That said, the number of companies claiming success with SAFe seems to indicate that the SAFe guys are onto something. I’m encouraged by Dean Leffingwell himself saying that he’s not married to SAFe itself and doesn’t get emotional about it. It’s simply something he found works pretty well, but if he finds something that proves to work better, he’ll do that instead. I’m glad I have SAFe in my toolbox now and am curious to try some stuff out!

My Problem with SAFe

October 18, 2014 / / 1 Comment
I have a problem with SAFe.  It’s not that it’s necessarily a bad scaling methodology for Agile (I’m not familiar enough with it to make that judgment). It’s that it’s the default Agile scaling methodology.
Why is that? It seems that anybody who’s starting to research scaling online stumbles upon SAFe – and pretty much only SAFe. The conclusion drawn from this is that SAFe is the only option. SAFe has the advantage of having been early to market in this space and filled a vacuum. There have been and are other methodologies out there, but they are – for some reason – less known, less catchy and definitely not branded and promoted as well. Therefore SAFe is perceived as the only viable option. On top of that, it seems comprehensive and prescriptive enough to appeal to enterprise users seeking “all the answers” and an “enterprise-class process” they can roll out. If that does happen, the Agile mindset and culture may quickly be forgotten since the process seems provide all the answers.
Again, I’m not all against SAFe. There are good things about it. But it’s not the only option and has – despite the hype – remained somewhat controversial in the Agile community and has its critics.
Let’s not forget other ways to scale, such as Scrum of Scrums (admittedly a questionable methodology in terms of effectiveness and ability to scale large), Large Scale Scrum (LeSS), Disciplined Agile Delivery (DAD), the Spotify model, as well effective methodologies used and proven by Agile consultancies (let’s call them custom methodologies). For an interesting comparison check out www.agilescaling.org.
As always in Agile, let’s make sure we do our homework and pick an approach that’s appropriate for the given organization and problem space – instead of jumping straight into SAFe.

Agile Scaling and Organizational Culture

October 17, 2014 / / 0 Comments
You might be familiar with Conway’s Law, which basically states that applications in their structure mirror the (communication) structure of the organization they were developed in. This law in itself is quite fascinating in and of itself.
During a recent Agile Open conference, I came to a realization related to scaling Agile that reminded me of Conway’s law. I venture to postulate that an organization’s Agile scaling method is the reflection of its culture and management style. (Maybe this shall be known as “Rosendahl’s Law” going forward, but I digress.)
What do I mean by this theory? If the organizational culture is that of command and control, it will choose an Agile scaling model which directly or indirectly embodies those values. In this case, an organization may choose SAFe since it – at least on the surface – seems to be more prescriptive and appears to provide more control.
If an organization’s culture is more characterized by empowerment and trust, it is more likely to choose a different scaling model, maybe just Scrum of Scrums or the Spotify model. As an extension of this theory, one might also predict that a command and control culture may lean more towards Scrum due to its (perceived) high predictability vs. Kanban which provides less clarity on roles, “process” and delivery dates.
What do you think, am I off here or have you seen  this “law” in action?

© 2024 Agile & Lean Product Development

Theme by Anders Noren — Up ↑