Tony

Excellent article Jen!
Here is another mantra I keep hearing "If Agile doesn't work for you, you are doing something wrong". This one is so untrue....

I have been in companies where they have a sprint plan set to be the same length regardless what project they working on.

I have seen user stories taken into a sprint without analyzing them with details such as defining the following::
1_ Data needed for the story for DB Schema
2_ Activities needed to reach user story goal
3_ Business rules that need to be applied
4_ Design session if needed
5_ Reusability analysis

If the above user story details are not practiced, then there is a high risk of failure.
And if we wait to find that detail in the middle of the Sprint, then there is another high risk of failure for not getting it done during this Sprint since developers will have to wait until the details are clear from ambiguity.

The Agile framework doesn't help the team on how to be agile performing Analysis and Design.
It's only a great framework for:
1_ Better communications
2_ Product demo
3_ Sprint Tasks planning
4_ Process Improvements

I would keep using your Mantra and add to it...
"DO WHAT IS RIGHT
FOR YOUR TEAM
FOR YOUR PROJECT
FOR YOUR PRODUCT BACKLOG ITEM"

SDLC Frameworks or Processes do not build software.
Following Software Engineering Best Practices for performing Analysis, Design, Coding and Testing, will help you build robust software and minimize your chances of failure in whatever SDLC framework you chose to follow.

Hi Mladen

I agree with you that the only beneficiaries from Agile are the ones giving certificates and selling books that have new buzzwords that confused the software engineers.

I am going to be honest and dare other IT professional to be honest as well.

I have been a software engineer for over 30 years and have obtained my scrum Master certificate to find out the following :

1_ A requirement was renamed User Story.
2_ Development tasks plan was renamed Sprint Plan.
3_ Improvement meeting was renamed Retrospective.
4_ Team Lead was renamed Scrum Master.
5_ Team communications was renamed Stand Up.
6_ A 2 to 4 weeks plan was renamed a Sprint.
7_ Business Stakeholder was renamed Product Owner.
8_ Stakeholder Review was renamed Sprint Demo.
9_ SDLC phases were polarized as Waterfall, this is so UNTRUE

The following critical roles were removed from the team:
A_ Project Manager
B_ Business Systems Analyst

Honestly stated, Agile has created confusion to the IT industry and sooner or later will either be replaced or adjusted to help IT professionals execute all the phases of SDLC more efficiently in performing Planning, Requirements Analysis, Design, Coding, Testing and Deployment.

I am not a fan of buzzwords, I follow good efficient software engineering principles to build reliable software solutions.

Following AGILE doesn't not build reliable solutions, it's the software engineering work effort needed to tackle each phase of SDLC depending on the project size and team needs for what artifacts are needed to be able to build the reliable software along with good planning for project delivery.

Let's not follow a process just because it's the trend, or a cool buzz word, make sure your team follows good software engineering practices whatever framework you want adopt.

Your comments to my reply are greatly appreciated.