Regarding Hybrid Agile

When do you see it as an advantage to be inagile in developing software?

Do you think those circumstances are typical of all software projects?

Thanks Simon Mayer

When do you see it as an advantage to be inagile in developing software?

In many cases, like:

1-when we cannot dedicated a developer for one project

2-when it is difficult to meet with customers, and this case happens too much times

3-when we 100% that the requirements won’t be changed

Do you think those circumstances are typical of all software projects?

No one way is correct.

Sometimes agile will be good, other times inagile will be the best J

Why would there be an advantage in those cases? Would a non-agile approach promote greater certainty regarding outcomes?

Ian Mitchell

Excuse me for mistake, I think Simon Mayer didn't got me idea, then I used inagile instead of hybrid agile

what I mean is that the hybrid agile is the best in many cases becauses it takes the advantages of agile and non agile in a form that solve the problem

The Following article Declares more:

Water-Scrum-fall is a hybrid approach to application lifecycle management that combines waterfall and Scrum development methodologies.

Generally speaking, a development team that uses a waterfall approach regards the development process for a software product as one large project. At the end of the project, the team releases working software to an operations team for installation and maintenance. Typically, the business owner (also called the product owner) only sees the finished product.

In contrast, a development team that uses Scrum, or some other Agile methodology, would approach the same development project as a series of very small projects called sprints. Working software is released periodically in an iterative manner until the entire software product is complete. Typically, the project’s business owner plays an active role throughout the process and joins the development team's retrospective after each release.   

A flexible approach that embraces both traditional and Agile development principles allows development teams to use whatever practices and techniques best meet the needs of the problem being solved. Many organizations use Agile principles and Scrum communication techniques in their day-to-day product development but employ traditional waterfall methodologies for planning, budgeting or documenting the project’s progress. 

The need for flexibility has also given rise to a movement called DevOps, an approach that blends the tasks performed by a company's development and systems operations teams.

The methods described will only be as useful as the organization is willing to let them.  The same could be said for pure Waterfall, pure Scrum, pure Kanban, etc.   Agile was born for software development out of the need to improve the old styles of project management so that they could adapt to the changing markets for which the project management was being used.  I will admit that Scrum is not the right choice for everything.  To quote the Agile Manifesto for Software Development(emphasis added by me).

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

First I will point out that it is not an Agile Manifesto. It is an Agile Manifesto for Software Development  While some of these principles can be applied to other disciplines, it was never meant for that.  

Second, none of the italicized say anything about Scrum, Kanban, etc.  It is about valuing something over the other. It also doesn't say that one is better than the other or do one not the other.  They are all still important, just the left side is valued more. 

Regardless of what you want to call your process, Agile can be accomplished in software development if you follow the principles and values of the Agile Manifest for Software Development.  Accomplishing Agile in other disciplines isn't as cut and dry. 

Many organizations use Agile principles and Scrum communication techniques in their day-to-day product development but employ traditional waterfall methodologies for planning, budgeting or documenting the project’s progress. 

The way I read that is that the Development organization has adopted Agile practices for developing software but the rest of the company may not.  It isn't completely obvious from that statement. I have used Agile practices while doing waterfall project management by honoring the Empirical model, making decisions at the latest possible time, ensuring that stakeholders/customers are included all through the process of building a solution and helping the organization recognize early and often when something in the "plan" should change.

When do you see it as an advantage to be inagile in developing software?

So my previous question was intended to be slightly provocative. "Inagile" could be considered a synonym of "inflexible" and "unadaptable".

Sometimes it is important to be flexible, or adaptable. Sometimes it is less important. But I would say its rare that being flexible or adaptable is problematic.

Being agile does not require you to apply certain frameworks, methodologies or toolkits. It is about the values and principles that you embrace.

Agile is what you can be, not something you can do.

Al Suabiee wrote:

1-when we cannot dedicated a developer for one project

2-when it is difficult to meet with customers, and this case happens too much times

 

What would an expert do in a situation with the above factors?

Warning: Long post....

In contrast, a development team that uses Scrum, or some other Agile methodology, would approach the same development project as a series of very small projects called sprints.

Um.... no. That gives the impression that you release after every Sprint given that the author believes each sprint itself is a small project. In reality, the team develops and tests an increment of working software that is potentially releasable. In most cases, releases are done quarterly or maybe monthly; not every sprint. 

The Agile Manifesto for SW Development mentions nothing about releasing, it's a way of working and mindset. You can still be 100% Agile yet only do a single product release. If you're keeping the stakeholders in the loop and getting feedback from them throughout your development, allowing the team to be empowered to make decisions and self-organize, and utilizing empirical data to make decisions; you're being Agile. 

My elevator pitch when describing Agile vs Waterfall correlates with this:

Agile vs Waterfall is akin to comparing Pizza Hut and Subway

Pizza Hut: You call in and put your order in, employee reads back the order "Large, hand tossed, meat lovers with light sauce. 1 half needs Mushrooms and onions added, the other half add only green peppers. That will be $20 and will be delivered in an hour"

An hour later, delivery guy shows up and come to find out, they put mushrooms and green peppers together on one half and onions on the other instead of what you actually ordered. As the customer, you can either take the incorrect product or send it back and have them make it correctly. Either way, you lose because you're not getting the product that you ordered, or you're having to wait another hour to get the correct product. 

Subway: Walk up to the counter, order a foot long Italian B.M.T. The employee repeats it back and then you walk down the line with the employee involved in the making of your sandwich. The entire process is transparent, you can see all the work being done, you're giving feedback at various intervals throughout the process. The employee asks what kind of bread you want, you give feedback, she moves to the meat and cheese, you give feedback saying you'd like more cheese than she initially added. Then go to the toppings and sauce, you ask for jalapenos to be added but unfortunately, they are out of jalapenos so it's unavailable; but you know immediately because you're involved throughout the process. At the end of the line, there is no surprise about what is on the sandwich or what is missing. 

In both scenarios there are situations where there is not a huge need for consistent stakeholder/customer interaction. If you go to Subway and order a meatball Sub the way it comes with no changes or just order a large pepperoni pizza from pizza hut. Both are very simple, odds of changes are slim so Waterfall seems to be a good approach. I still say that there is nothing wrong with having customer interaction and feedback loops even when requirements and expectations are simple.

Now, was there a release to the customer in either situation before the product was complete? Nope. Which scenario is more Agile? I would hope you say Subway. Pizza Hut you're not involved at all after placing the order until the pizza arrives on your doorstep. Subway you're involved throughout the entire process, giving feedback, the employee is managing any expectations as you go on the journey. Multiple and frequent releases is just a part of Agile, it is not the defining principle on what it means to be Agile.

Curtis Slough  Nicely described :-) I liked the example

@Al,

The author of the article you copied and pasted proposing a hybrid solution of Agile and waterfall has an unfortunately poor understanding of Scrum.

Scrum is much more than simply taking a long project and breaking it up into smaller "chunks" (iterations).   Scrum is designed around embracing uncertainty by developing and delivering small pieces of functionality, and soliciting feedback that has the potential to change the scope of future development (i.e. - Empiricism).

There simply is no feedback loop described in the article.   One can only assume that the hybrid agile example is fixed scope, in which case I would question the use of Agile at all, as waterfall is usually sufficient for fixed scope projects (like construction).

FYI - love the analogy Curtis.   Thank you.

I second @TImothy's opinion on the links you posted.  The explanations really show the lack of knowledge of Scrum and agile in general.  It appears to be written for the purpose of leading people away from agile and into old style project management practices. I read all the links you provided and also looked at other "definitions" that were provided. I never saw any that really accurately represents the thing they were trying to define.  She may be someone that people respect but I do not agree with her statement that she "speaks fluent ...., Agile,....".  

As I mentioned in my earlier post, I can and have been able to use some waterfall approaches in agile implementations.  If you look at SAFe, it prescribes a few of them.  There can be benefit of some waterfall practices very early in the SDLC but their usefulness ends pretty quickly if you want to survive in today's global economy. 

And @Curtis.  That is the best analogy I have ever seen/heard and it has completely escaped me until now.  I am not going to lie. I AM UNASHAMEDLY STEALING THAT!!!!  I will give credit but it is going to be used.  I may actually be able to explain all of this to my wife and parents now.  :-)

I wish I could say that analogy was mine but I got it from none other than Mr. Don McGreal. He ran my PSM training at Improving in Dallas and I've been using that analogy ever since. I like it because nearly 100% of the developed world has ordered a pizza or gone to Subway style shop so it resonates regardless of a person's background.