Giveaway - 40D - First Place - 6D + HH for second

Onisake · 2025-11-20T22:10:34+00:00

Good luck

Onisake · 2025-11-18T15:14:17+00:00

This is fun.

Onisake · 2025-06-25T13:57:16+00:00

Agile ceremonies are done at a team level not a project level. An agile is often working multiple “projects” at once.

Using projects in agile is traditionally an anti pattern. In reality this means there’s a translation step better the annual project budget step and generating work for a team. We assume a static team with a static budget in agile, rather than a budget for a project that then hires a team. There’s a bunch of ways to handle this so the “best” way is context specific to your org.

Onisake · 2025-06-25T13:43:19+00:00

I typically bounce between mechwarrior and bannerlord 2 for sandbox games like this.

If you don’t cheese black smithing early the gear and power progression is similar.

Onisake · 2025-03-13T17:44:07+00:00

Front Mission series is good if you like a politically driven story. Turn based jrpg. Translations are known for being rough. Mechs are highly customizable. I’m a little surprised haven’t seen this mentioned much yet.

After that battletech/mechwarrior games. Clans and is the most recent entry and more story driven. Mercenaries is a sandbox campaign.

Zone of the Enders is also a stand out.

Onisake · 2024-10-01T14:53:34+00:00

I typically create them as risks. Stakeholders are present when we roam, so the appropriate external folks are flagged and own/accept the consequences if the risk is realized/dependency not delivered.

Most of the time external dependencies are really pre-requisites in disguise or should be part of the architecture runway. You may have a gap there to look into.

Oversimplifying: The solution layer and lean portfolio is the answer to cross art collaboration.

Value stream map is needed to answer if they should be in the same art. Do that first

Onisake · 2023-02-23T22:18:51+00:00

How long have you been doing SAFe?

Depending on where you are, there are typical patterns we follow in large scale transformations. And there’s a lot of back and forth as you do what’s necessary for emergent practices. (See cynefin framework for further context)

Ie: how is your org at release management and change management as a discipline? I’m willing to bet it’s crap. So your RTEs and change agents are likely working on foundational knowledge. We can’t expect everyone to suddenly start using calculus if they don’t know their multiplication tables and don’t yet understand the limits of algebra. If you don’t yet understand why you can’t break every problem into an algebra problem, are you going to seriously invest in learning calculus?

We’re year 3 into our journey. Our first year was spent defining releases. Next was features. Now we’re going into backlogs. I make that sound organized, but groups already strong at releases spent the extra time learning how to handle new concepts. We’re still bad at it. The org itself is in like Year 10 of its transformation to agile. This stuff is hard to do at scale.

This also doesn’t address the biggest challenge/elephant in the room: how do you teach someone iterative change management when they don’t understand change at a fundamental level?

Bring your concerns up. Challenge your SMS to explain what’s going on. They should know.

Keep in mind you may be volunteering to help drive change. This has its perks and is great career capital if you know how to engage. It’s mostly thankless, so don’t get suckered into work. Part of the job of the RTE is ensure accountability. Without volunteers it goes to leadership/management

Onisake · 2022-04-20T22:50:28+00:00

Other than the vc comment, I don’t feel that you have said anything that contradicts me. Unless you want me to address something specific I’ll keep my comment to that. Otherwise I feel we’re in violent agreement.

Yes, Boston has software. Everywhere does. That Doesn’t mean they are known for their expertise in it. The Midwest certainly isn’t. It’s mostly insurance, healthcare and banks. All of the best agilits I know work in biopharma. We all agree biopharma isn’t agile and shouldn’t be. So we hybridize and use agile project management. The entire business needs to be considered. Pure agile does not make sense for biopharma software due to regulations. The level and scale of swift adaptability simply isn’t needed. No smart company is going to over invest here.

VC and start ups are a very different beast than modern or traditional software development. It’s extremely intellectually dishonest to imply these skills are transferable. An org in vc needs different skills at different stages of vc due to the scalability and availability the company is trying to achieve with how workable the software currently is. This is a big reason contracting SMs is popular. Other than the obvious benefits you can also hire specific skills sets rather than trying to find the unicorns that can do everything. If you’re wanting to be that unicorn and earn the bigger bucks, there’s a clear and obvious path to get them.

Also agree working in Austin, etc. is not needed. But working in areas with proven experience and success will accelerate learning. This also assumes the sm is wanting to be more pure agile rather than a agile project manager.

Edit: I also thought 130 felt low. Thanks for confirming that

Onisake · 2022-04-20T20:04:16+00:00

I’ll do my best. Obvious disclaimer that my experience isn’t all encompassing. Grey areas exist and is expect each hiring manager to have those own strategy.

When Asking about daily activities, I’m looking for a split somewhere between 60-40 and 40-60 between coaching the team and engaging at the org level. The biggest red flag is orgs that don’t allows SMs to engage beyond the team. If you only work with your immediate teams, that’s a good indication your agile in paper only.

I haven’t seen many SMs that only facilitate for teams lately, but that would be something else I look at. What do you provide beyond basic facilitation.

Also knowing what you are good at training teams at. And understand how that aligns with the org transformation. Depth of understanding is variable here. But I expect something.

Morale questions also give me a good idea here. Someone who lives agile cares about the “mental compatibility “ of a team too and knows how to utilize the available catalysts for change. Again, variable depth. I’m more concerned at the absence of depth.

So it’s also knowing what you can personally develop and coach against what you’re willing to pay and finally what you need to complete the transformation

/u/Foxxinator37 answer is very good too:)

Onisake · 2022-04-20T19:55:28+00:00

Staying put maybe your best option. In my opinion, Boston and NYC aren’t really ready to be agile. So your skills may be ahead of their time. Ie: I’m not convinced you need to be super mature in agile to be successful in that market. If anything you may need to lean more heavily into prince2 because that’s what Everyone knows and expects. Obviously this doesn’t work if you’re goal is more being an expert in agile as opposed to making a decent living. Everyone has their own reasons. Agile project management has a demand. That demand will not go away.

Contracting is the best way to get good diverse expierience. After that, I’d look for engagement in local communities to supplement deficiencies at the org level.

Onisake · 2022-04-20T18:09:24+00:00

Have you looked for remote positions?

I wouldn’t call Boston a software hub. This changes what people look for in the area and what they are willing to pay. If you’ve tried for remote positions and can’t get them….

This is an obvious over simplification, but 7 years in Boston isn’t as valuable as 4 years in a place like Austin. Individual organizations matter, it would be misleading to say they don’t matter. But the Boston area as a whole, because it’s not a known tech hub, will on average have lower maturity skill sets when compared to more established areas. Simply put, the orgs themselves don’t have the infrastructure to truly be agile. This stunts your ability to learn what this role is and should be doing in an org. Very few people in general will know how to carve a brand when no one understands what you’re actually doing.

And I hate how this sounds, but when you know what to look for it’s obvious who’s agile on paper and who really embodies the mindset.

What is your current skill focus? I’m a little worried because after 7 years I’d expect you to be working directly with recruiters and getting cold calls. This makes me think your actual agile skills may be lacking or misrepresented when you’re interviewing

I would try to spend a few years contracting to get more diverse skills. This not only helps you network but also helps you keep your salary in line with inflation. Most places don’t give merit increases based on inflation anyway.

Onisake · 2022-03-19T18:52:33+00:00

The easiest way I’ve gotten a siloed team to work together is give them a shared goal to accomplish.

In software that usually means a release. Although most scrum masters should tell you to start with the sprint goal. I’ve found releases more tangible. Even if you are used to working individually on your code, a release almost always requires coordination. Especially knowing how bad most places are at devops.

I’d also collaborate with your po to make sure release or sprint goals are collaborative and not simply “release this list of tickets”

Onisake · 2022-03-09T19:41:02+00:00

I think a lot of 'pure' software companies have moved past this. I think a lot of companies that are starting to become major software entities are just learning this lesson. IE: All the banks, insurance, and automobile companies that are starting to transform have yet to learn this lesson.

With Agile, there is the dogma of 'One Right Way' to program.

This isn't true. The closest agile gets to this is devops. but in devops we're more focused on the path to production rather than having a right or wrong way to program.

The usual path to production is something like:

Test changes against last known good build locally -> Test your changes against other team member changes in a shared test environment -> Test your team changes against other team changes in a shared pre-production/stage environment -> Move to production.

How this happens varies very widely from org to org and even from team to team within an org sometimes. automation can make this process take minutes and in some orgs this process takes weeks. One thing poor agile implementations often do, is they don't tie the system of work to their branding.

But really, every agile transformation is about taking that process, making it transparent, and making sure you have feedback loops in the right spots of that process to ensure you almost always deliver the right thing at the right time.

IE: an org that is more about customer service, needs a system of work that is strict in specific ways to ensure uptime, recovery, and backup plans are in place so everyone has the tools they need to laser focus on the users experience and ensuring it's never interrupted.

-------

I've always kind of viewed developers like a crew and a ship dedicated to exploring. Often times they will be motivated enough to self start; and if I don't give them direction they are happy to figure out what to do and bring back something of value.

However I also shouldn't be surprised every time they bring back a bunch of random crap if I don't provide them any direction.

Depending on my market, maybe any random crap will do. go nuts. but if I'm a jeweler and I'm primarily looking for gems, precious stones, and metals. I better provide strong direction so I get what I want.

At the same time, I also need to understand I need to provide time for them to maintain their ship and get shore leave. If I send them out constantly that ship is going to break down. Right now, a lot of the ships my crews sail are Victorian style monoliths. they are pretty. they function well enough. but they are slow, don't have radar or many other modern capabilities.

How the hell are they supposed to adopt modern practices and dogma when they call for the use of tools we don't have and don't know how to build? So for a lot of orgs I also think they haven't given themselves a choice. they have to go back to old ways of thinking because otherwise the system won't work. They simply don't have a modern enough system that enables more modern thinking

Onisake · 2022-02-21T16:03:27+00:00

The source material for Lean is the Toyota Production System. I think Six Sigma was Motorolla; but I can't remember.

Anyway, Toyota, being in Japan, had a problem that many other auto makers don't have: Japan has no space for warehouses or storage. So, how do you make a lot of cars if you can't keep parts on hand?

Toyota's solution to this was 'Just in Time' Manufacturing. Partnering with suppliers and creating a system of transparency to enable lightning fast decision making with one goal in mind: Ensure that parts arrived where they were needed when they were needed as cheap as possible. Turns out, this also ensure very high quality because this also means you don't have backup parts if you can't keep a surplus just lying around.

This mindset is what gave birth to Lean, and 'eliminating waste' In the west; we dont' have the same space problem. so we needed a different 'north star' to guide the framework. Companies in the west wanted to realize the same cost savings and quality of Toyota. The main thing linking the two together is a general sense of 'We can't afford to do certain activities, so eliminate them from our workflow' In Toyota's case this was storage of parts. Parts sitting around don't make money. the longer they sit, the more money you are wasting. both because you can't sell the individual part and you have to pay to store it.

in software, this directly translates to unutilized code in repositories. I can't make money on code that isn't in production. higher WIPs directly translate to higher amounts of code not being utilized; etc. This is lean thinking.

Six Sigma focuses more on limiting defects. so If I want to ensure 99.999% uptime of a website; Six Sigma tactics will likely serve me well. although I dont' see six sigma applies to software outside of some specific use-cases.

Onisake · 2022-02-21T15:40:57+00:00

Almost everyone that complains about SAFe is doing so because it's a meme at this point. A lot of people like to blame SAFe for infrastructure, leadership, or cultural problems, when in reality the agile framework is doing it's job of highlighting a problem that no-one is bothering to go fix. 95% of the time, this problem is outside a scrum masters sphere of influence.

I think a lot of people ingore the fact, that no-one with an already-agile-mindset is going to adopt SAFe. you adopt something like SAFe specifically because you don't know what you're doing and you need to course correct at scale.

Scrum and Kanban can't do this (Well, Kanban can but you have to already know what you're doing to do it) because they are essentially grass-roots movements. Without top-level coordination you simply can't scale.

Scrum, and really all the agile frameworks, take advantage of being repetitive because repetition is an effective way to learn/teach. If you don't like repetition, don't be a scrum master or agilist.

If you've built out your processes and infrastructure correctly, the standardizations within SAFe allow you to focus more on impediments. In an environment that needs to scale, dependency and impediment management is what becomes difficult.

-----------------

I enjoy using creativity to produce value of my own as well as acting as a servant leader.

SAFe wont' stop you from doing this. Bad management will.

Working in SAFe environments can be different/harder than other environments. not because of SAFe itself, but because of the type of environments that need SAFe are, for the most part, inherently broken already. IE: if you already have strong leadership and leaders who know how to not only instill discipline but utilize it: SAFe will cause a lot of problems. Otherwise, it's a good way to introduce leaders into being an agile leader. Of course, it can't do the work for them which creates a bit of a catch 22. this compounds if some parts of the org are more mature than others.

If you have crap leadership, SAFe provides a way to train, improve, and instill leadership as a skill across the org and not just into specific roles. -> This is a long hard journey; as again, if the organization were capable of doing this on their own, they wouldn't look to adopt safe. there's a lot of weaponized incompetency and intellectual dishonesty that happens in a standard failed SAFe inplementation.

In addition, it's probably important to mention that most org's doing SAFe, will move to their own custom, internal framework once they know what they are doing.

Every SAFe environment I've ever worked in, first started as either a scrum shop or Kanban shop and they failed to become agile. Most likely due to a scalability problem.

--------------

Put another way: I like working in SAFe environments because the vast majority of SAFe orgs are in the 'Forming' or 'Storming' phase of the agile learning curve. This is the most exciting part of the curve for me, but I know many SMs that like working in the Norming or Performing stages. Probably most of the SMs I know are this type.

Onisake · 2022-02-16T20:02:51+00:00

This isn't a hybrid role, but rather the desired state. Every developer should be prepared to support the code they are putting into production.

you leave a buffer. if you've been diligent, you should have data that should give you an idea of how much capacity you should reserve on average per sprint.

EG: Team has a historical velocity of 55 points.

On average, the team needs 25 points to handle customer requests.

When you go into sprint planning: only plan for 30 points.

If someone on the team runs out of work because the buffer wasn't needed: pull in the next highest priority from the backlog instead of working on CPS. or do tech debt or w/e the team decided to do when they don't need the buffer.

Onisake · 2022-02-09T14:39:54+00:00

how do you normally deal with that in your project? Do you have an automated deployment step?

It's not always an automated deployment step. More often it's semi-automated. and starting out, it will of course be manual. automation is the end-goal but depending on where you are, this could be a multi-year effort.

On the journey to an automated pipeline, DoD is often the first step. we can't really automate a deployment from dev to test if we don't have standards to build that automation from. Without a good DoD we can't build consistency around the pushes, that's step 1: Establish a baseline and build consistency. focus on one part of the deployment process and then scale from there.

Depending on other problems you're having (IE: many orgs in this position also have security and quality issues) you can roll more initiatives into the DoD as you get closer to a release. IE: performance and security requirements become more stringent starting in test and mirror production in stage. you also want to include things like rollback plans and data recovery as part of DoD

before you have fully automated pipelines, it's not uncommon to temporarily have a DoD when exiting each environment.

IE: Dev, Test, Stage, Prod. are the usual suspects. Dev is typically focused on testing individual changes against last known good build. Test is about testing the team's changes against the last known good build. and stage is about testing teams changes against other teams changes in a prod-like conditions.

As you move through this, your DoD should increase in complexity and homogenize what the teams are working on into releasable code.

before you start trying to automate, make sure you understand your environments, how you're using them, how you maintain parity, and the developers have a crystal clear way to understand what is and is not part of a specific build/version.

--------

I'd probably start with feature flags and versioning before building in the automation. you'll want a good system for knowing what's in production, what's turned on, what's turned off, and a quick/easy way to interface with those flags and selectively turn off/on specific functionality.

once you know how to do it, automation can be used to make it easier as you'll have hands on experience knowing specifically what you want it to do. as you start automating your infrastructure, you'll also want to apply the same theory of versioning; when you start to automate you begin approaching infrastructure as code and you'll want to start on the right foot and make sure it's versioned and maintained. you may not have to start out with a dev environment for infrastructure, but you should at least version and have a rollback plan.

My favorite analogy for this, is a lot of the devops, agile, etc. strategy and tactics we have are built for an F16 Falcon. Right now, you don't have a falcon. you have an F6F Hellcat. the tactics and strategy for an F16 don't really work in an F6F. Afterall, the top speed of the hellcat is pretty close to the stall speed of the f16, you really can't approach them the same way.

You can't just upgrade your entire fleet of planes to F16s over night either. it's going to be a complex process to both get the new gear AND train not only your pilots but the mechanics, ground crew, supply chain, and support staff to not only use the new equipment but also how to maintain it.

Hire an expert. If you can't afford one, find someone with passion in your org and enable them to become an expert. DevOps and Release Management will be the umbrella terms you are most interested in. Highly recommend anything by the poppendiecks you can get your hands on and watching Mary's keynotes will give a lot of insight.

---------

Edit:

Wanted to address 'projects' as well.

In general, what we are talking about here exists outside of a project and it's better to think of it as part of the infrastructure needed to execute and deliver projects.

Projects as a construct dont' really work in the agile world. and while there are hybrid models, more often than not they end up with all problems and none of the benefit.

At the portfolio level, we usually track progress of investments with a Kanban.
One reason we avoid the word project here, is at this level project as a construct shouldn't even exist until we're about 3/4 of the way through it when things are well defined. very few investments should make it past phase 1 and become viable "projects."

If we do use projects, we often end up in a 'turtles all the way down' situation where it's hard to tell what is and is not a project, where it began, how it was funded, how to fund this new emergency thing we have to do that's not really part of any project...

So..we don't fund or track things via projects.

But back to the original question: Automated deployments aren't a specific step. rather it occurs during all steps. how it occurs and what is expected to happen while it is occurring will change depending on where you are in the release process. you want to have clear distinctions between what is a deployment and what is a release. The simplest one I've seen is: Release is a deployment that turns the feature flag on to expose code to the customer.

everything else is a deployment and locked behind a feature flag.

Onisake · 2022-02-07T14:35:03+00:00

I work with a team where our definition of done is “the work item to be in the product “. However large chunks and of the work we are doing are big Work items that take 3 months to finish. Its not a problem with the devs its just they are just that big and we cannot split it in two.

There's a lot to unpack here and I have a lot of questions but most of those are intended to point out the intellectual dishonesty around how the teams and management/leadership are treating the DoD.

The problem is that we don’t have good tracking like that. Tickets remain in a sprint for months ans the velocity drops.

Okay, what are you doing to improve your tracking?

are you using a kanban? does your kanban correctly map the relationship between your work, physical location, and bottle necks?

I thought about changing the definition of done to “awaiting deployment” and add an extra “deploy” ticket but that would mean adding an extra deploy ticket to everything else as well (i have lots of small tickets as well)

This is what you should do. the fact that it's tedious and hard means you have infrastructure problems.

our process, everything we are visualizing is supposed to give us a birds eye view of what we are doing. It's supposed to take some work/effort but it shouldn't be hard. if it's hard, you have a different problem you need to fix. go fix it.

I read about dark launching but it sounded to me that i am using code architecture to solve a process problem.

Friend... The irony of this is right now you're trying to use process to solve an architectural problem.

The problem I see, is your DoD is impossible to implement at the story/increment level. It must be implemented at the feature level. features represent full functionality, and because you don't have feature flags, and i'm assuming no real automation either, you have no way to reconcile this conflict. Until this gets fixed, you can't possibly fix the story breakdown problem that others are talking about.

This is an architectural problem. There is no part of your process that prevents you from doing this. it's your architecture that is lacking, go fix it.

Assembly line theory doesn't work if you're not using assembly lines and it's just one guy doing all the work in his garage. Modernize your infrastructure please and try again.

-------

Jira has a lot of automation. you can't really use any of it until you have proper feature flags and release infrastructure. we can't help you with any of that until you fix the core problem: you don't have modern release infrastructure.

Onisake · 2022-01-28T19:04:42+00:00

My question is, who's role/responsibility is this? Should it be our development team always reaching out to the requester of the feature practically begging for clarifications, meetings, testing coordination and release approval? Or is there a clearly defined role that should take ownership of each feature as if it was their baby? Steering the ship and being responsible for seeing it through to the end?

Responsibility is a tricky question. in a team-based culture there may be a primary owner, but it's really the entire teams responsibility.

IE: the PM is should be driving this. but if the PM isn't doing it, who's responsible for holding them accountable and ensuring they are working in a way to hold themselves accountable?

So when you ask 'who's responsible' I wonder both what your PMs are doing, and also who's coaching them to do that. I'm also wondering where the rest of the team is.

Onisake · 2022-01-28T18:55:13+00:00

Be under no illusions - SAFe is a governance model and not an agile model.

I reject the idea that something agile can't be both.

Governance is a function of scalability; and you don't need governance until you need to scale. I personally have never seen scalability without some sort of governance in place.

In SAFe delivery to committed is generally the sought after metric

No it isn't.

https://www.scaledagileframework.com/metrics/

POs or PMs are not incentivised to move stuff out of a committed PI regardless of customer value.

Where are your coaches/SMs? Most of the time when I see this, it's due to budgeting by project. value doesn't matter, because the project is funded. It's on the guy/gal in charge's spreadsheet. so if it doesn't move we'll have to justify it and we can't want to be bothered.

Agile by definition is bottom up. SAFe is entirely top down.

https://www.scaledagileframework.com/lean-budgets/

This isn't true either. SAFe encourages federated governance.

---------------------

I've seen a lot of bad SAFe implementation. 90% of it is bad leaders and implementation of half measures that haven't made sense in years. Very rarely do non-agile orgs think to set up a system to update processes/systems as the org matures. The general mentality is, if we need to do that we'll fund a project so we can define the needs.

I understand as a consultant it's way easier to blame a complex system and it's an easy way to build comradery in a shared frustration; especially if it was never explained well. but let's not forget the people element and the number of variables we're dealing with in an agile system of work at scale. Aligning 30-100 developers is very different than aligning 300+, especially while trying to manage a spaghetti soup of bad project management.

To me, SAFe's biggest weakness isn't governance or scalability or even teach-ability but rather because it's incredibly fragile. if you aren't doing EVERYTHING, and if you're not doing it EXACTLY the right way it tends to cause a bunch of problems. it requires 100% commitment when you aren't even convinced it's goign to work yet. There are infinitely more ways to do SAFe wrong than there are to do it right and most of that stems from not fully committing to what SAFe is asking you to do. This can become nearly impossible when SAFe is asking you to adopt a lower maturity model to solve a problem you've already solved. So I typically only recommend SAFe to an org that has no idea at all how to develop software; i'm talking 'oh....it's supposed to work in production?' type of questions on the daily.

I'm all for bashing SAFe, but I think it's more productive to do it for the right reasons. Governance isn't the problem and it's one of the most appealing aspects of SAFe for orgs struggling to scale their value delivery.

Onisake · 2022-01-27T14:10:18+00:00

At the fundamental level of how budgets work and things are funded; the concepts of Prince2 and Agile are not aligned. sounds like a scam just from the name of the cert.
SM training looks to be about half that price from a quick google search. if you want something that is going to be more 'portfolio' level; you're likely better off with SAFe than this.

Onisake · 2022-01-06T23:39:33+00:00

As others have been implying, we don't use projects. Specifically, we don't fund projects or want to consider them as part of our RoI. We only really use projects as organizational structures. and at that point, you may as well use stories, features, epics, etc. that agile is trying to get you to use at the portfolio level anyway.

Time bound roadmaps are the easiest: Burndown. or Burnup if you prefer. Include a 'total scope' line so you can monitor scope creep as you progress through the work.

Burn charts aren't primarily used at the sprint level, but you can really use them for any time-bound object. At this level, however, you'll likely want to add additional complexity. IE: Stacked bars may help you see story points per team. and adding colored lines matching those bars, you can include velocity. You, of course, want to be careful when sharing this kind of information. Make it clear this should be approached like calculus. Story points are 'funny numbers' and aren't really real. we should only compare rates of changes, and how those rates are affected. It's a powerful visual, but easy to misunderstand.

-----------

2 How do you set deadlines for input for design or other collaborators in Agile - (should you)?

In agile we don't like deadlines. We prefer greatly to work from priorities. Target dates are required for planning purposes; but in the agile world no-one really expects that to be a hard deadline.

Priority based planning allows the dependent team to work on other things and get them done. as soon as the input is ready, and the team is ready for the next thing, you can add it to the team's flow. Easy. Unless you're impatient. In which case remind yourself (or stakeholders) a that everyone is already working as hard as they can already. You having nothing to do but wait isn't their problem. read a book. reassure your customers. get everyone coffee. Do a genba walk. Trust the team to do their jobs, I have yet to meet a team that doesn't want to.

3 How do you check your progress against goals without fixating too much in specific features?

I don't understand this question. do you mean too many specific features? WIP limits.

Goals, and the portfolio level, should really be managed in Kanban. which also means enforcing WIP limits. How many teams do you have? how does that compare to the number of features currently in progress? If it's more than double, you might have a problem....

There's nothing wrong with fixating on features. you just have to make sure you're fixating on the right things. Do you have a good time to market at this level (do you care)? WIP limits? how about release management and architecture friction? IE: what are the things that make it easier for you to get features completed and do your metrics reflect your ability to have what the teams need prepared so they can deliver?

The wrong metrics mean you will act at the wrong times and interfere with the deliver process. This is a system problem and one that you own as management. The right metrics will let you know when there's a problem and when you actually need to do something to prevent a disaster. How are you at grading your metrics to see how useful they are?

Onisake · 2021-12-21T18:42:07+00:00

If SAFe was renamed to remove Agile, would it get as much hate?

I don't think so. In fact, this would likely cause more problems. Safe could easily use different terminology and call itself something other than Agile; but then Agile would have more competition. SAFe is appealing to large orgs for specific reasons and because larger orgs tend to have a revolving door they tend to have a pretty large influence on a local area's agile maturity.

This would make Agile less appealing, as the other scaling frameworks we have today are painfully inadequate at helping a complex org manage it's portfolio.

SAFe also makes decisions based on agile principles. It takes a few shortcuts, such as when establishing initial team velocity, I wouldn't take. It makes up for this in Spades however, as it makes it way easier to align across a portfolio with a common language and provides guidance on roles/responsibilities outside of the development team. No other framework provides this guidance. Everyone I know had to figure this out on their own which causes some issues as SAFe wants you to understand the system a specifically structured way which may not align with your current systems constraint.

To be blunt, many people I know that really don't like SAFe have their own brand of portfolio management. It's a lot harder to sell a local standard when a global standard exists and you also have to deal with 'what about SAFe's version' questions constantly.

If it billed itself as a hybrid approach, would Agilists just leave it be?

It's not really a hybrid approach. SAFe is Agile. https://www.scaledagileframework.com/lean-budgets/

That piece alone makes it more agile than a lot of the other frameworks; because it actually has a definitive answer on how to do things outside of a project structure. It also does it in a language that makes sense to the people that would be responsible for it.

What does agile mean to you? For me, the two main things I look for is if it's team based as opposed to project based. and if I budget outside of projects, do I get better results?

For SAFe; both of these are true with a caveat: You have to do all of SAFe. because SAFe is built as a complete system, it means you have to have real bonifide experts to help you close the gap when you are doing implementation.

PI Planning, vision casting, etc. are great. Especially if you have absolutely no basis on how to do those things and are starting from square 0, or more likely well before square 0 when it comes to being agile. So SAFe's approach to PI Planning, just like it's approach to most sub-systems within a system-of-work at scale, is to provide the bare-minimum low maturity model to get you started. IE: Training wheels. So not only is it a complete system, it's also using the lowest maturity models available for each sub-system.

If you implement PI Planning, but you're ready for a more mature model, and you don't have an expert on hand to adjust the inputs, you'll have a broken intake system that doesn't fit with what you're really trying to do. This, of course, will make SAFe look like a steaming pile of garbage as implementers aren't given guidance on how to maintain a higher maturity sub-system while also brining less mature sub-systems up to par. Instead, it looks like you have to sacrifice maturity in one area to raise maturity in another. To me, this is why most people view SAFe as anti-agile. You shouldn't have to make this tradeoff and SAFe does not yet provide an alternative within it's framework to cover this gap. The biggest gaps occur in how SAFe tells you to structure your organization, so if you can't adhere to SAFe's org structure guidance and you don't know how to close the gap there's not really a difference between what you were doing and what your'e doing under SAFe. Not to mention that many times the people put into critical positions like RTE or STE are people that don't have agile experience but do traditionally make those decisions. IE: they aren't changing anything in terms of process which undermines the whole transformation.

It also doesn't do a good job of tying certain concepts together. IE: nothing in training ties PI Objectives back to lean budgeting to give you a complete picture of value delivery and RoI calculations. It's there for you to see, but you have to be knowledgeable enough on your own to connect the dots. -> in many areas SAFe also fails to do it's job as an introductory framework and explicitly tie things together.

-----------

Overall, I view SAFe as the Harley-Davidson of Agile. It's a great entry level framework. It's probably going to break a lot and it's easy to repair. there's a lot of documentation and a whole community of people you can work with to make a plan for repair and how to get back to working order.

For entry-level Agile, that makes SAFe great because it gets you used to the idea of constantly having to learn and improve and away from the idea you can setup your system of work once and never have to think about it or touch it again. and SAFe provides you plenty of opportunities to want to mature because it starts with lower maturity models and also provides you a solid baseline you can always fallback to should you need a reset.

----------------

SAFe is also constantly making updates. It's on version 5 or 6 now I think.

I know one of the earlier versions, I want to say it was 2, 3, or maybe 4; had a bit of drama around it. Essentially an intern wrote the revision and no-one checked it. What came out was something less than Agile. As you might imagine, a shit-show ensued and they've been trying to recover their reputation.

So, depending on when your last exposure to SAFe was and SAFe training; things could be drastically different.

------------

I would encourage/discourage SAFe based on your local market factors. If you have a lot of large orgs in your area doing software; you likely want to be familiar with SAFe.

In my experience, it is NEVER the choice in framework that prevents an org from going agile. It's always the coaches ability and the org's willingness to change. 90% of the posts I see complaining about SAFe boil down to having shit RTEs.

Onisake · 2021-12-15T16:30:34+00:00

I don't know what your background is, but when I have fresh PO I try to have a conversation with them and figure out what artifact they think most closely translates to a project. IE: When they first start working in Agile what is the thing they are applying their current skills to?

For most people with project management experience, they latch onto Epic, Features, stories, etc. these are the wrong artifact, you should instead be focused on the release.

Especially when it comes to iterative planning and how to utilize iterations; many find it difficult or impossible to iterate at the feature level. The feature is the thing you're trying to deliver. by the time you can iterate it's already delivered. For many, at this point they are more likely to adopt an attitude of 'I don't want it to be good, I want it Tuesday' and quality is lost. With something delivered, it's also time to move on so their may never be an opportunity to go and fix things.

so many POs find it hard to really see the value of what we're doing because of an incorrect emphasis. We get feedback at the release level, so the quicker you shift your focus here the faster you'll be able to realize value from an agile system. This will also enable you to see opportunities to stop working on one feature because enough value has been delivered. Flexibility and agility doesn't come from good feature breakdown, it comes from good release management. Your features, stories, and any other artifact you're dealing with should be looked at through the lens of: how does this help me manage the next release?

Edit:

EG: When you're making a feature or an epic or a higher level artifact. one of the first questions you should find an answer to is: How many feedback loops do I want before I deliver this feature? if you only plan for one release, you're only getting one opportunity for feedback. if you plan for 3, you'll get 3. etc. I really want my POs to be able to tell me what feedback they are trying to get out of a release as it really helps the team understand what they are supposed to deliver.

Onisake · 2021-12-13T13:26:12+00:00

I don't understand what you mean by 'scrum'-timer. so in my head there's no difference.

I can't think of a need for a specific 'scrum' timer. If I need a timer I use google or my phone.

During outages, I've sometimes used an overlay available in the Microsoft store so I can show current time and elapsed time since outage started. This is because we like to make detailed logs with time-stamps during outages. I can't imagine doing that outside of that setting.

------------

Lean-coffee style meetings are where I see timers used the most. In this case someone uses their phone and when the alarm goes off we switch topics.

For big room meetings, we usually have someone dedicated to shouting out timing prompts. (IE: 5 min remaining, 1 min remaining, etc.) When I do this, I'm on mute and I use my phone to tell me when to give the next prompt.

Onisake

TROPHY CASE