More businesses are requesting their projects be managed using agile methodology. While, agile is the most used software development practice it is not a one-size-fits-all solution.  There are very few benefits of replacing one rigid software development methodology, such as the V-model, with another methodology such as "full-Agile." All the principles of the "full Agile" have a limitation in applicability. What we experienced in a real world software development is that we only apply selected aspects of the Agile. Combining different elements from other methodologies, in a hybrid approach will help to maintain the required flexibility. In fact, this hybrid approach to iterative development is where we''ve architected "Agile-ish", which is far more common than using a "full-Agile" approach. VDC Research believes that this "Agile-ish" model represents the future of all Agile development in enterprise markets.

What is Agile-ish development model ?

Agile-ish is a derivative of agile scrum development model with a pre-development phase that involves an exhaustive specification process that outlines user stories and set the backlogs so that the scope is well defined and can be better priced out upfront. In an Agile-ish, the development phase itself is advanced using iterative, collaborative, and evolving imperative of agile scrum processes.

Agile-ish can be summarized in 5 stages

1.    Identify the task or the problematic area
2.    Develop a plan to address it
3.    Give it a shot
4.    Analyze the end results (what did work and what didn’t work)
5.    Repeat, do it again & again, rinse & repeat…

Daily work Habits of an Agile-ish Developer

1.    They always talk to the other developers around them about what is going on in their task, what team is doing, and know what is going to affect overall work.
2.    They often pair up with other developers to develop components that they all respectively working on.
3.    Get user stories, if questions arise about the story, they ask questions, if the story does not make sense, they get the story changed.
4.    They try to ensure that their code is testable. If they can''t then they are most likely developing something poorly.
5.    When they find themselves getting lost in code, they Refactor.  If they find they''ve written a piece of code before and déjà vu is setting in, they Refactor.  If they have more than 2-3 questions every few minutes about a piece of code, they Refactor. If they can''t read a story from the code and the code tests, they Refactor.

Conclusion:
It is important to note that being Agile-ish doesn’t earn you a badge or a certificate of perfection. Being Agile-ish is all about continuously taking the best guess at what to do, learning and building from it. Being Agile-ish means you have to recognized, accepted and learned from all your failures. There are no silver bullets but there are infinite opportunities. The quest for quality is never over, and that is hopefully what keeps us going…

References :
http://www.vdcresearch.com/landing/esw/esw_agile_QC.aspx
https://speakerdeck.com/bradwhittington/agile-ish-is-good-enough

*If you find something is misleading or not correct then please throw some light on it.