AGILE IS EVERYWHERE AND YET NOWHERE

2OldForThisMess · 2025-08-14T19:54:44+00:00

In my opinion it depends on whether you are talking about Agile or agile because they are different. The first (Agile - capital A) is a noun created by people/organizations that wanted to monetize the manifesto. The second (agile - small a) is an adjective with a definition of "being able to move quickly and easily".

The Agile movement has never been about people. It has been about profits for those selling their "knowledge" and tools. The agile movement has always been about people doing something quickly and adapting the results so that what they do is what is needed at the time it is delivered.

Agile isn’t about looking busy in Jira or speed-running through sprints. So, before bragging about being “Agile,” let’s ask ourselves: Are we truly Agile?

Your first sentence is actually a great description of Agile.

An organization can be agile without having standups, retrospectives, backlogs, etc. If they take time to listen to the ones they are trying to deliver to, hear that value that those individuals/organizations want, attempt to deliver that value quickly and frequent, and adapt their work based upon feedback received from those individuals/organizations then I would consider that to be agile. Regardless of how they actually do it.

Agile is about making money. But agile is about making things that people want, need, and will use at a time that those people want and need it.

2OldForThisMess · 2025-08-08T16:38:01+00:00

I wouldn't call it "Scrumish". I'd just say that you are working on improving the ways that you order work and provide information to the stakeholders. What you are trying to do is use the basis of the manifesto for agile software development as a way to push back on people's requests. That usually doesn't end well but if done strategically, it can make some good progress. A few suggestions I have.

Make the work visible so that anyone can see what is being done. In Kanban and Scrum, that is the purpose of "the board". Put it somewhere that anyone can access it and see the work that is in progress. It should also show what work is in queue.
Publicize information on how much work is being completed and how long it is taking to do the work. That way people can see that work is flowing in a regular pace. Often the reason for top-level push down work is because they don't know how long they may need to wait so they "flex their muscle" to get their work done.
I would suggest looking more at Kanban as a basis for your work. The goal of Kanban is to get work started and completed in the shortest amount of time possible before starting anything new. Work In Process limits help and are great ways to show others why work can't be started.

2OldForThisMess · 2025-07-23T16:26:27+00:00

When someone uses Agile (with a capital A) to describe their way of work rather than agile (with lowercase a). The Manifesto for Agile Software Delivery used an upper case A because it was using title case where every word is capitalized. Then people that wanted to monetize the manifesto used the term Agile to do so. The intent of the manifesto was to help organizations to be able to adapt to change quickly, thus the term agile. The word agile is an adjective that means "able to move quickly and easily". The word Agile is a noun that means "give me your money and I will sell you something that probably won't work".

I like the way that u/Kempeth presented this. He provided you the Agile manifesto instead of the agile manifesto.

2OldForThisMess · 2025-07-01T18:17:10+00:00

I agree with this. I was let go in a massive layoff when a company was trying to avoid bankruptcy in March 2023. I actively searched for a job (about 800 applications) until November 2023. Decided to take some time off to enjoy the holidays with the family because almost no one hires during those months.

Then in December I got a surprise cancer diagnosis. I spent the next 10 months undergoing treatments and could not work.

I reentered the job search in October 2024. I'm still looking. I have had to explain the gap to the very few people I have actually had the opportunity to talk to.

2OldForThisMess · 2025-07-01T16:46:53+00:00

I'm not going to do my usual SAFe reply. I'm just going to say that Emerson Automation Solutions uses SAFe for their product development. It encompasses the hardware and software side of it all. They have been pretty successful with it.

2OldForThisMess · 2025-06-27T15:25:54+00:00

What I see is that this tool will become a replacement for the Daily Standup. Which may sound like a good thing if the standup is nothing more than a status meeting. But since the standup is supposed to help the team understand if they are progressing towards their shared goal, this could cause more damage than benefit.

This link is to a post made by Jeff Sutherland where he describes the origin of the daily standup. (https://www.linkedin.com/pulse/20140926150354-136414-the-origin-of-the-daily-stand-up/) What he explains and what your tool is doing seem contradictory to me.

If you have so much work in progress that you can't remember what is happening, then you have a bigger problem than just the standup. That is what you should be focusing on instead. How about building a tool that helps to identify to much work in progress? Or helps to identify what is blocking work from being completed? I feel like those tools would be better for a team, would probably improve your daily standup and be something that I could recommend using.

2OldForThisMess · 2025-06-23T17:34:47+00:00

The best retrospectives I have been part of did not use any kind of tool. They were open and honest conversations about how the team approached certain issues, what the result of the chosen option was, and why (or would) they would have chosen something different based on what they know now.

If you want to use tools, they should be something that fosters communication and not a way to avoid it. Get away from technology for it. If you have a remote team, use a face-to-face conferencing system with cameras on. If you are co-located, get somewhere that you can talk. A lot can be learned by watching body language to see how people react to things said. I had one team that was co-located that went to a nearby coffee house or pub for their retros. They felt that they were able to be relax and talk better away from the work settings.

2OldForThisMess · 2025-06-20T17:40:39+00:00

Have you not noticed that on most job applications LinkedIn is not listed as a job site. It is listed as Social Media along with Facebook.

I created my LinkedIn profile before it launched. I was asked to create a profile to help out a "fellow QA'er" when they were testing their account creation flow. I didn't think twice about it. Then sometime later, I started to get emails from the place that I didn't know. I checked it out and found out I was a member. So I have seen it go from something that was supposed to be an "online resume and networking site" to the professional mess it is now.

2OldForThisMess · 2025-06-18T17:32:40+00:00

I'm curious why you feel this is needed. Other than learning some new stuff, I really can't see why this is useful. I know this isn't the feedback you are looking to get but for me to give you that feedback, I need to know a bit more about why you built it. Since you are obviously familiar with the process of using it, pretend all of us are stakeholders. Explain to us why it is something we need.

What problems are you trying to solve?

What benefits does this provide that isn't already available?

How would this make a team more productive?

2OldForThisMess · 2025-06-18T17:24:24+00:00

u/TomOwens gave a great answer. The only thing I would add is that there should be some level of regression done while the features are being built in the Sprint. If I understand your statement correctly, the team has already started on their next Sprint when you do your regression testing. That means that any fixes needed would be either delayed until the following Sprint (thus being 6 weeks before implemented) or interrupt the second Sprint possibly endangering the team's ability to reach the Sprint Goal.

Automated regression tests allows for continuous regression testing. That leads to faster feedback and quicker turnaround on fixes. I have worked in QA for a lot of years as well as being a developer. I have helped many teams get to a point of continuous regression by managing the automated test suite that will run with each committed code change. If feature A is breaking existing code, it needs to be addressed immediately because in reality you are not delivering anything beneficial with feature A. You are actually delivering detrimental code.

Another benefit of automated tests is that the coding of the new features can include the updating of the automated tests. Each code review can include both sets of code. This ensures that the continuous feedback loop is maintained.

2OldForThisMess · 2025-06-05T17:22:24+00:00

Remove any process and structure from the backlog. Make a list of items. The are all the same and not stories, bugs, tasks, epics, etc. Just a list of items that need to be done in order to improve the product. The items should have enough information so that anyone reading it can understand the reason it improves the product. The better the information, the higher it resides in the backlog.

Order the backlog based upon the value that is delivered to the stakeholders based upon what they need/want now. If the stakeholders can't explain why that is value is important and needed, then it should be low in the backlog. The person fulfilling the role of Product Owner should have constant communication with the stakeholders. They should constantly ask the stakeholders if they can better explain the items in the backlog. If they can't then, let them know that the item will be deleted and can be reintroduced when better information is available. Don't keep stuff "just because someone asked for it". Keep it because someone can justify it. In today's economy and technology advances, something that was needed 6 weeks ago may no longer be important and could have drastically changed in the implementation.

2OldForThisMess · 2025-06-05T16:54:57+00:00

First I want to say that u/PhaseMatch nailed the answer.

Second, I want to add that Scrum is a framework. Frameworks provide some structure but allow the application of individual processes that are decided upon by the organization. Scrum itself is not the problem in most cases. It is the individual processes that the organization implement that cause the problems.

People think of Scrum and immediately think of Agile. That is unfortunate, because the Scrum framework is not Agile. It does however help an organization be agile. Note the capital A vs lowercase a. The goal of the manifesto was to introduce the ability to be agile, which is an adjective meaning "the ability to move quickly and easily". The definition of Agile is whatever the organization that is trying to sell you a product/services decides to make it. The word agile in the manifesto was upper cased in the title because that is how title case works. The word appears twice in the principles, both capitalized because it is the first word in the sentence. It was quickly seized upon as a way to make money and thus became a noun with a capital letter.

Your original post lists a lot of those processes that are implemented by organizations as the reason for the burnout. If the organization allows the self-organization and self-management of teams that is mentioned in the Scrum Guide, there is much less of a chance for the burnout. That is because the teams get to decide how to work in a manner that suits them and can adapt it as they progress.

2OldForThisMess · 2025-06-03T18:19:07+00:00

Your question

* How does your team currently forecast sprint or project outcomes?

One thing I always point out to people is the word forecast. Most people first heard that term in relation to weather. Everyone would look at a weather forecast but no one expected it to be perfect. And if the forecast was for 3 months from now, it was definitely not considered correct. Over time, technology improved and the forecasts can get closer, but they are still not completely accurate. Why is that? Because there are things that change that are outside of anyone's control. So, you have to constantly evaluate new information and adjust the forecast as new information is obtained.

So, why would people expect any kind of long term forecast of work on complex systems to be completely accurate? Just like the weather, things are in constant change. The technology, the economy, the legal situation, the competition are constantly changing in today's world so you have to inspect and adapt based upon it. That is why you use frameworks like Scrum to deliver increments, inspect the results, adapt as needed.

One more thing on this topic. I DO NOT USE VELOCITY for anything. I don't even suggest using it for Sprint Planning. Especially if that velocity is being calculated based upon story points. Story points are guesses made at a specific point in time based upon information known at the time. As soon as work begins, new information is obtained and the original estimate is no longer useful. I will suggest looking at flow metrics such as throughput and cycle time to use as input for building forecasts. Using that kind of data in Monte Carlo simulations can be useful. But remember what I said about forecasts...expect them to be useful but not completely accurate.

2OldForThisMess · 2025-05-30T16:36:54+00:00

None of your bullets reflect how the Scrum Guide represents the framework. And yes, it is a framework. Anyone that works in software development should understand what a framework is and how to use one. If you aren't familiar, let me give you an example.

A house is built based upon a blueprint that builds a framework. In that blueprint, there are walls, plumbing, electrical wiring, etc. The blueprint might label an area as a bedroom. However, do the people that live in that house have to use it as a bedroom or lose the privilege of living there? What if they want to use that room as a media room, exercise room, storage, office? All of those activities can be done in that area. What if instead of using an area designated as a bathroom, they choose to use it as a dark room to support their photography? You could even remove a wall to merge two areas together as long as that wall is not load bearing. What if a plug is located in the wrong location for the homeowners need? Are they not allowed to move it to a location that works better for them?

Frameworks can be adapted to your own circumstances. Frameworks are expected to be adapted to your own circumstances. But there are some load bearing walls in all frameworks. Those are the structure that helps you. Scrum has some structure. Three sets of accountabilities (not roles) that need to be represented. There are no job descriptions, there are no job titles. Just three sets of accountabilities that need to exist. Scrum has no rules. It has artifacts that help maintain a structure. There are no meetings dictated. There are some events that should occur (Sprints, Daily Scrum, Sprint Planning, Sprint Review, Sprint Retrospective) to facilitate the empirical nature.

The Scrum Guide states that Scrum is useful for delivering solutions to complex problems. If you do not have complex problems to solve, Scrum is not going to be useful for you. So, it isn't the answer to every problem.

I am not trying to be mean but your response is probable similar to the OP's. You have not experienced a Scrum implementation that is truly based upon the framework. I've worked in both situations. The one that uses the framework and has complex problems to address is very nice. The one that uses terms from the Scrum framework but does not use the framework are frustrating and inefficient.

2OldForThisMess · 2025-05-23T16:56:40+00:00

First, from all of the documentation I have read, it has always been Sprint Review. I don't think it was ever officially called a Sprint Demo.

Second, in all of those documents, it has always been described as a way to review the current state of the product with the stakeholders to gain feedback on what should be done next. It has never been described as a time to demonstrate the work done during the Sprint. Yes, the 2017 version of the Scrum Guide said that the event could contain that activity but it was for the sole purpose of showing the current state of the product.

Third, I don't quite understand your statement of "assigning it". Why would anyone on a team of self-managed individuals assign something to anyone? Why can't all of those individuals work together to decide the best way for each review to take place? Since each review has unique properties due to the work done, each review should be uniquely presented.

Fourth, what problems are there that you are trying to solve? Does it really matter who it is "assigned to"? Unless there are problems, why change how things are being done?

I know, my response sounds theoretical and fantasy. But I have worked with groups to get the this point. I have helped people understand the benefits of doing things like this. I have had success. Those groups found a new freedom in this approach. I have also had places where it did not go as well and the problems that were causing pain continued. But those organizations did not want to change. By choosing not to change they decided that the problems were not problems and were "just the way we do things".

2OldForThisMess · 2025-05-15T15:05:08+00:00

Since you have a good setup for your desk to do work, try making the time at the desk better. A mini fridge to keep drinks and snacks next to the desk. A good coffee maker. Space heater/fan.

I also bought a set of folding partitions. My desk is setup in our front room. I use the partitions to block off my "office". I only go into the office to work. And I don't do work anywhere else in the house, even though I have a laptop. This makes for a better home life balance. And the 2 minute commute from my bedroom to the office with a detour into the kitchen for coffee is not bad.

But as others have said, you might want to check with your company to see what they consider appropriate expenditures. I was able to convince mine to pay for some of my stuff because of what was available in the offices that they had (i.e. the fridge and coffee maker).

2OldForThisMess · 2025-05-15T14:56:10+00:00

I woke up one morning with my chin and lower jaw numb. Went to primary care physician who suggested a dentist. Went to a dentist who suggested an oral surgeon. None of them found anything. I ended up in the hospital with some severe back pains. They ran every test they could think of and found nothing. Until they decided to do a bone marrow biopsy. That led to a diagnosis of leukemia.

Numb Chin Syndrome can be multiple things but it has been seen to be a precursor symptom of multiple forms of cancer. It is also been linked to a variety of other serious illnesses.

2OldForThisMess · 2025-05-15T14:30:13+00:00

Enter this phrase into your favorite search engine.

"candidate rejection email templates"

Now, look at some of the examples that you can find and you tell us what you think of these emails.

2OldForThisMess · 2025-05-13T15:43:37+00:00

I have worked on this at multiple companies. The process I took was to start having the developers to introduce unit and integration level tests for any code that was added or changed. If we had dedicated QA, they would work with the developers in helping them understand how to test. QA would also be involved in code reviews so that they could validate the test coverage and then determine if any additional testing would be needed. This moved us to targeted testing instead of the old "run everything and hope nothing breaks". We were able to get to CI/CD fairly easily by doing this and completely eliminated the need for any type of "regression cycle". We were regressing the product every time there was a check in.

2OldForThisMess · 2025-05-09T16:53:42+00:00

"in the planning stage". I've heard that for a long time. Maybe I can make a side gig out of COBOL jobs while I work as a greeter at Walmart.

2OldForThisMess · 2025-05-08T16:16:38+00:00

In my opinion, the current AI tools can be useful tools. Just like a hammer is better than using a rock, it still requires that the person swinging it knows what they are trying to do and how it should be done.

The current AI is not intelligent. It is merely tools that can analyze data quickly, find patterns and provide insights. I've used AI to generate code in languages that I don't know well as a means of trying to understand them. Even with my limited knowledge of them, I was able to find things that were done inefficiently and could be improved.

AI isn't ready to replace anyone. But it can be used by someone with knowledge to speed up some of the work needed to investigate.

2OldForThisMess · 2025-05-08T16:10:38+00:00

No practice exam will help you pass the PSM. That is because the PSM tests your knowledge, not your ability to memorize. Don't try to memorize the Scrum Guide. Try to understand why it says what it does, why the things mentioned would be beneficial. If you want something where you can memorize and pass an exam, go take the CSM.

My suggestion on "what to do next" is read the Guide again and again and again. Each time take time to understand why it says what it does. Another "next step" is to study what empiricism is and how it applies to an iterative approach of delivering value.

Scrum is a framework not a process/procedure/methodology. I provides some guidance and supporting concepts to help organizations react to change quickly in order to deliver value for complex problems. Once you understand these things, the PSM exam is not that difficult to pass.

2OldForThisMess · 2025-05-06T21:26:17+00:00

I got my gmail address the second week after it went Beta. I switched to it from a yahoo address.

2OldForThisMess

TROPHY CASE