Tag: scaling

Why “Yes” Doesn’t Scale

June 12, 2018 / rrosendahl / 0 Comments

Everyone loves a “can do” attitude. “Yes, we can!” has become – even when stripped of any political connotations – the rallying call of an entire generation, empowered, driven, and enthusiastic. For a young startup, this type of optimism is a prerequisite. Pessimists would probably never embark on a dangerous journey into uncharted waters, let alone survive the trials and tribulations that are an integral part of bringing a new product to market. But as startups grow, …

Continue reading on ProductCraft (where this full post has been published)

Agile is Everything – Everything is Agile

June 21, 2016 / rrosendahl / 0 Comments

As agilists, we are all fighting – to various extents – the perception that Agile is a set of processes, techniques, and (if we’re lucky enough that people understand this) mindsets to optimize software development teams. To some degree I can’t blame people for thinking that because that’s kinda how Agile got started. But nowadays Agile is taking a very holistic approach, a perspective that goes far beyond helping a team of developers function better. By the way, when I say “Agile”, I’m including Agile scaling frameworks as well as Lean and related product development approaches (so yes, I’m casting a pretty wide net, which is reflective of the close relationships between these different knowledge areas).

Here are additional angles Agile is looking at the world from and tries to impact:

Organizational agility: enabling the organization to act and react quickly to environmental and market conditions.
Portfolio management, i.e. understanding size and benefit of high-level initiatives and making optimal decisions for the business. Working on the right things (in the right order).
Systems thinking (vs. local optimizations), aimed at optimizing the whole process of value delivery, not just software development.
Removal of waste in processes and shortening cycle times of value delivery (not just creating shippable code).
Making decisions based on economical and empirical considerations.
The Lean Agile mindset which influences leadership style and organizational decision making.
Organizational culture, including, but not limited to trust, respect, empowerment, etc.
Organizational design and structure as well as performance management and recognition approaches.
Product development approaches, e.g. the Lean Startup.
Drive away from industrial era management beliefs and styles.
Accounting practices impacting if and how capitalization is practiced, budgeting and planning.
Appropriate metrics and KPIs.
Technical practices (CI, CD, DevOps) and quality practices (test automation etc.) and technical craftsmanship.
Architecture (think emergent architecture, loosely-coupled components, micro services, etc.)
Relentless (self-) improvement at all levels. Kaizen.
Team and interpersonal dynamics.
Team and organizational health.
Product innovation.

I probably forgot a few elements, but you get the gist. This is why agilists want to engage with and influence various levels in the organization, including senior management, and individuals in

Engineering, technology, architecture, quality (obviously)
IT infrastructure
Product management
Project management
Finance & accounting
Human resources

Hopefully over time the limited perception of Agile will be corrected by people and organizations understanding the holistic nature of Agile. With that approach, we can really unlock and enable the potential of an organization and its products.

Journey to the Center of SAFe

April 22, 2016 / rrosendahl / 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!

Closing the Impediment Gap

August 7, 2015 / rrosendahl / 3 Comments

In theory, it sounds pretty straightforward: an Agile team identifies an impediment and either solves for it or the Scrum Master takes it upon himself to remove it. Easy, right?

Internal Impediments

As long as it’s within the team’s or Scrum Master’s control to successfully deal with an impediment, this is a viable approach and
hopefully most impediments fall into this category. (Let’s call these “internal impediments”.)

External Impediments

The problem is, there are these other impediments that are outside the team’s or Scrum Master’s control (let’s call these “external dependencies” because their root cause lies outside the team). What happens to those? Scrum doesn’t really say and is missing explicit mechanisms and ceremonies to deal with them, so it’s often left to the Scrum Master to figure this out.

During an Agile transformation, when a lot attention is paid to the maturing Agile teams and the overall progress, there is – in most cases – a person or a group of people in place who “own” the transformation. This group is a good audience for helping the teams resolve external impediments because it is motivated and empowered to keep the transformation on track.

In organizations which have been Agile for some time (maybe several years), often there is no clear ownership of “Agility” any more and it’s (hopefully) just part of an organization’s DNA and status quo. In these cases, the Agile steering committee has often-times already been disbanded and with that, there’s now a void in that a Scrum Master with external dependencies has no clear audience to get resolution. He may improvise, try to track down various involved stakeholders and affect organizational change himself, but, due to his lack of organizational influence, may not get very far. In those cases, these external dependencies often remain unsolved and the teams tend to get frustrated and numb to the impediments that never get taken care of. They feel the lack of organizational support, give up and often just “deal with it”.

What to do?

So what is the solution? During an Agile transformation and beyond, an organization should have a clearly identified group of Agile stakeholders, people who feel responsible for the success of Agile in the organization. Then there should be an explicit process for dealing with external dependencies that involves those stakeholders who will hopefully take ownership of these hairier organizational impediments.

That said, organizations aren’t always great at putting these mechanisms in place and might require to be given more specific guidance and tools. That’s where AgilityHealth (an Agile assessment and growth tool) can provide the necessary structure:

Resulting from regular strategic retrospectives, external impediments are identified and clearly flagged as “organizational growth items”
Those impediments are reviewed quarterly with an explicitly defined leadership group
That group pulls a number of these impediments from the growth backlog and commits to resolving them
Impediments are dealt with and resolved (likely in collaboration with the team)
After 3 months, the leadership group is asked to review with the teams the progress that has been made (this doesn’t imply that impediments shouldn’t be resolved faster if possible).
The cycle starts over.

In essence, this process & tool create a new macro feedback loop as well as a quarterly “impediment sprint” with leadership. (In larger organizations, there could be several concentric layers of impediment sprints, e.g. involving portfolios first and then the overall organization.) Since this approach makes explicit the process, its cadence, the process participants and roles, it helps fill the gap that Scrum and other team-based Agile frameworks leave unfilled. Institutionalizing the process will provide accountability and heart beat that ensure these external impediments aren’t left unresolved.

I’m hoping this blog post has helped identify different types of impediments that need to be treated differently and will encourage organizations to be more deliberate with regards to how to deal with external impediments.

My Problem with SAFe

October 18, 2014 / rrosendahl / 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 / rrosendahl / 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?

Tag: scaling

Why “Yes” Doesn’t Scale

Agile is Everything – Everything is Agile

Journey to the Center of SAFe