You keep on sharing amazing posts. This too is a lovely share. Thanks! :) I liked this line in particular - Agile is a “Way of Thinking not a Way of Working”
It is a fact that overuse of "Agile" & selling it as a panacea has diluted & negatively impacted it's effectiveness. Add to that the crazy trend of certification!
I don't blame you or anyone - who really had it with Agile - as that is how the situation is. We need to call for a "reboot"! Else, people will soon show the mass repulsion & throw this out the window!
Excellent share! I used to feel it was me alone! I am so glad that it's not so, other too are feeling the same way - fatigued! It had to be today or tomorrow. We are dealing with too much marketing and overselling Agile. And in the process, the simplicity and the good practices are getting thrown out.
I love this quote - "Those who cannot remember the past are condemned to repeat it".
Yes - I do agree! Initially, the role is to ensure that the team/project may work per their own rthythm. And gradually, as situation may demand - provide options to decide which "may" work even better for the project, under that given context. Here - nothing should be enforced (which I see happening in many cases - very unfortunate).
I feel sorry for your organization - as it appears from your statement, Agile way of working has not been implemented right. E.g. if a Sprint planning is done well, you should be considering around 6-7 hours per day as true productive hours (I prefer 6). So, assuming 5 days a week - even 50 hours is a totally unacceptable figure. This can't generally be productive (but counter productive mostly).
Good question! If you fine WAKA "heretics" - you will most likely notice the unwritten claims of being a thought leader or an evengelist or a thought provoker etc. etc. and a claim (& attempt) to enforce his/her beliefs on to others way of working.
Whereas a person who follows Agile by understanding what is advises, will be extremely flexible & won't stick to a stereotype prescription of mandatory steps or ceremonies etc.
This was a very high level differentiator. :) I wish it was easy - but unfortunately, it is not. So, I can well understand your anger & frustration.
There is another interesting version which is in circulation.?It says, when a projet fails, claim it was following Agile (what I call "PA"). So traditional models will never take the hit. Getting the vibe?
What we are failing to understand - it's not about comparing Waterfall vs Agile. Every item has its purpose. Reaching from point A to point B could be achieved in multiple ways. If your need is satisfied by a Car - sure. But someone may prefer using a plane instead. Both are correct from their own perspective and should be respecting each other for that. Then through retrospection one may decide to give the plane a try on next opportunity. Why not?
You are correct! But why should we limit it to Agile? Wherever there is an opinion, a belief, you will find a set of people trying to blindly follow it to a T. That is why I repeatedly advise - stay away from WAKA!
That could well be one of the reasons. And they probably saw - "Scrum: The Art of Doing Twice the Work in Half the Time". If you haven't read it, you should give it a try.
If someone teaches 2+2=5 - that is not the fault of Mathematics. If you witnessed a faulty implementation of Agile way of working (or any transformation) - that is the problem with whoever did that transformation, not the framework (well, there are some pathetic frameworks in the market - no denying).
Agile may resemble (from outside) to be mini waterfall & that is how many try to do it - but Agile way of working is NOT that. So, if you are made to understand Agile as this - my friend, you missed it by a long shot.
Why Agile is not (& definitely not JUST) a series of mini waterfall. Unfortunately that is beyond the scope to discuss here. But you gave me cue to my next post - so stay tuned. :)
It is largely dependent on the domain & technology as well. But as long as it is working for you - nothing to complaint! Just need to be cautious that it stays that way.
Apologies! I missed this response in the nested loop of responses (I was using my mobile).
Your statement - "The project can "respect" triple constraints (I assume, you mean Time, Scope, and Cost, right?) without being anything close to Agile."
Correct! Success is measured using Time, Cost, Scope. End of story (i.e. customer got what he/she expected in the defined time, within agreed budget)! Now, how one wishes to reach to that stage - it is for them to decide. Someone may use traditional approach, some may use Agile mode. The interesting fact is - if we look at how Agile frameworks have evolved, they were always transparent is letting team decide what works best for them (well, nowadays you do see very rigid & prescriptive frameworks as well - very unfortunate). The spread of cult culture can be rather attributed to the WAKA community (I stay clear from them). Scrum being a framework - it only proposes a way of working, with 3 roles, 5 events, 3 artifacts. If we wish to follow that - excellent. But half way through our journey, we may feel that it will make more sense to have 4 roles or 2 events or perhaps 10 artifacts. Now - as long as we inspect and adapt towards betterment, we are good. Such learning in fact helps in improvement of the framework itself.
The sole purpose of having a framework is to let people pick from learning of past, than starting from scratch. And if the learning or experience has been leveraged well, it allows us to reach our destination faster. So, today I may be doing great with my current way of working. But I can probably do way better than this - not only to deliver more value, make customer event happier but also to reduce time and keep my employees more motivated & engaged. Food for thought! ;)
I hope this clarifies your doubts (well, in universal sense i.e. no more feeling of uncertainty). :)
I am not sure what makes you think that I didn't answer your point. I will again try (iterations, right?):
- The major difference between Agile and Non-Agile project is nothing but the approach - which comes from a preset notin, stuck in our minds & Agile liberates us from those fixed, rigid rules.
- This is precisely what makes the success rates differ & hence the asusmption that success rate of non-Agile is similar - is not correct.
Now just the way people tend to do Agile - without realizing that they are not! There are similar examples - where people are actually doing Agile, where the don't call it or have not named it as "Agile". In the days - when people had not heard the words like "Scrum" or "XP" or similar - were projects not successful? Of course they were & even today there are success stories. No denying!
But with the market volatility and disruptive changes - it is no longer a want, but NEED of the hour to adap Agility to stay in the game.
As per the report - success rate for Non Agile projects is 26%. This should not be surprising, right? Coz gone are the days when we used to say use Agile way of working when you see changing requirements. It is time for adapting to the mantra of "Doing Twice the Work in Half the Time".
But as I stated in my article & I advise the same in my training or speeches as well - end of the day, follow the approach in which your team is most comfortable. No point in trying to do something where you are putting half-hearted effort. That way we can neither succeed with Agile nor with any approach for the matter.
Lastly - you said it very aptly "Clear requirements, stakeholder engagement, high-performing team, appropriate technology". What do Agile frameworks deliver in reality? They are nothing but an attempt to facilitate all of those and more for a team and organization.
I am hoping my previous answer will clarify the doubts. If not - please let me know. I will be happy to elaborate further.
However, just to ensure alignment:
- The other 58% claimed that they were following Agile (truly or not comes later) way of working, but they failed (i.e. unable to deliver per the "Triple Constraint").
- If one tried to deliver projects in a PA-SA-WAKA-DA pattern, it may appear that there was a sincere attempt, but failed. In reality - it was wrong from the very beginning.
What is truly Agile?
As long as a project is following Agile way of working, respecting the Triple Constraints. That sounds pretty much like "true" to me. But do note - "Agile way of working" is pretty deep. It is not a doctraine as some people may try to put it. It is rather free from bias or designation and very much in favor of the context & most importantly for the team.
Lastly, your favor for the word "zealot" makes me think - you probably faced someone from the WAKA group. Stay away! :)
My apologies if the statement confused anyone. The fact that I was trying to present is - on average Agile Projects have a 42% success rate (Source: Jim Johnson, Standish Group, Chaos Report, 2018).
What is success in this context? It simply means - ability to deliver the agreed scope of work on agreed time, within agreed budget - following the quality parameters agreed between parties involved.
So, it is not about delivering just anything, we have to follow the "Triple Constraint"to be able to deliver successfully.
You also asked: "What does 'truly being agile" have to do with that? What does the word 'truly' mean here? This is a marketing and religious term, not an engineering term. "
The figures speak for themselves. Out of the entire population of projects - claiming to be following Agile for Software Development, only 42% were successful. Why? They managed to follow their Agile way of working to successfully deliver. Simple, isn't it?
"Truly" - signifies the ability to use & adapt their Agile way of working to something that suits their context best! That is the core concept behind Agile way of wroking (not a doctrain - as you put it).
And I am afraid I don't see any marketing or religious intent. But happy to discuss offline. "Individual interactions" are more effective. ;)
Christian thank you for answering! Yes - it is a very much marketable item. Even so, some corporates put it as part of the roadmap to wow the investors.
Very interesting observation from you! Why do you think Agile is needed to kill innovation? The reality is just the opposite. And as I put towards the conclusion - if done wrong - we use those as an excuse to pass the buck.
If done "properly" (there are many paramemters) - a Scrum team will consider 6 productive hours per day. Where goes the other 2 hours? Use those for planning, learning, reskilling, admin etc. Now, if you are not following that - should we blame it on Agile?
You are spot on! That is why we need the drive to be aligned/approved by top level. Stay away from the "We Also Know Agile" (WAKA) folks! They are one of the major contributors of Agile failure!
Comments
Jul 11, 2019 · Arijit Sarbagna
You keep on sharing amazing posts. This too is a lovely share. Thanks! :) I liked this line in particular - Agile is a “Way of Thinking not a Way of Working”
Jun 19, 2019 · Arijit Sarbagna
It is a fact that overuse of "Agile" & selling it as a panacea has diluted & negatively impacted it's effectiveness. Add to that the crazy trend of certification!
I don't blame you or anyone - who really had it with Agile - as that is how the situation is. We need to call for a "reboot"! Else, people will soon show the mass repulsion & throw this out the window!
Time for introspection!
Jun 19, 2019 · Arijit Sarbagna
Very true! Totally agree!
Jun 18, 2019 · Arijit Sarbagna
Excellent share! I used to feel it was me alone! I am so glad that it's not so, other too are feeling the same way - fatigued! It had to be today or tomorrow. We are dealing with too much marketing and overselling Agile. And in the process, the simplicity and the good practices are getting thrown out.
I love this quote - "Those who cannot remember the past are condemned to repeat it".
Jun 12, 2019 · Arijit Sarbagna
Correct! That's what keeps the work going, without putting too much effort on building the big picture (as that could change per market need).
Jun 12, 2019 · Arijit Sarbagna
Thanks for your hint. I managed to put something together on Mini Waterfall concept: https://dzone.com/articles/scrum-is-not-mini-waterfall
May 28, 2019 · Arijit Sarbagna
Yes - I do agree! Initially, the role is to ensure that the team/project may work per their own rthythm. And gradually, as situation may demand - provide options to decide which "may" work even better for the project, under that given context. Here - nothing should be enforced (which I see happening in many cases - very unfortunate).
May 24, 2019 · Arijit Sarbagna
Incidentally, I shared this towards morning (IST):
https://www.linkedin.com/feed/update/urn:li:activity:6537613397607968768
May 20, 2019 · Arijit Sarbagna
I feel sorry for your organization - as it appears from your statement, Agile way of working has not been implemented right. E.g. if a Sprint planning is done well, you should be considering around 6-7 hours per day as true productive hours (I prefer 6). So, assuming 5 days a week - even 50 hours is a totally unacceptable figure. This can't generally be productive (but counter productive mostly).
May 17, 2019 · Arijit Sarbagna
Good question! If you fine WAKA "heretics" - you will most likely notice the unwritten claims of being a thought leader or an evengelist or a thought provoker etc. etc. and a claim (& attempt) to enforce his/her beliefs on to others way of working.
Whereas a person who follows Agile by understanding what is advises, will be extremely flexible & won't stick to a stereotype prescription of mandatory steps or ceremonies etc.
This was a very high level differentiator. :) I wish it was easy - but unfortunately, it is not. So, I can well understand your anger & frustration.
May 15, 2019 · Arijit Sarbagna
Well said!
May 15, 2019 · Arijit Sarbagna
There is another interesting version which is in circulation.?It says, when a projet fails, claim it was following Agile (what I call "PA"). So traditional models will never take the hit. Getting the vibe?
What we are failing to understand - it's not about comparing Waterfall vs Agile. Every item has its purpose. Reaching from point A to point B could be achieved in multiple ways. If your need is satisfied by a Car - sure. But someone may prefer using a plane instead. Both are correct from their own perspective and should be respecting each other for that. Then through retrospection one may decide to give the plane a try on next opportunity. Why not?
May 15, 2019 · Arijit Sarbagna
You are correct! But why should we limit it to Agile? Wherever there is an opinion, a belief, you will find a set of people trying to blindly follow it to a T. That is why I repeatedly advise - stay away from WAKA!
May 14, 2019 · Arijit Sarbagna
That could well be one of the reasons. And they probably saw - "Scrum: The Art of Doing Twice the Work in Half the Time". If you haven't read it, you should give it a try.
May 14, 2019 · Arijit Sarbagna
If someone teaches 2+2=5 - that is not the fault of Mathematics. If you witnessed a faulty implementation of Agile way of working (or any transformation) - that is the problem with whoever did that transformation, not the framework (well, there are some pathetic frameworks in the market - no denying).
May 13, 2019 · Arijit Sarbagna
Ok...now we are drifting.
Agile may resemble (from outside) to be mini waterfall & that is how many try to do it - but Agile way of working is NOT that. So, if you are made to understand Agile as this - my friend, you missed it by a long shot.
Why Agile is not (& definitely not JUST) a series of mini waterfall. Unfortunately that is beyond the scope to discuss here. But you gave me cue to my next post - so stay tuned. :)
May 12, 2019 · Arijit Sarbagna
Nice to know! Lucky you! :)
It is largely dependent on the domain & technology as well. But as long as it is working for you - nothing to complaint! Just need to be cautious that it stays that way.
May 12, 2019 · Arijit Sarbagna
Apologies! I missed this response in the nested loop of responses (I was using my mobile).
Your statement - "The project can "respect" triple constraints (I assume, you mean Time, Scope, and Cost, right?) without being anything close to Agile."
Correct! Success is measured using Time, Cost, Scope. End of story (i.e. customer got what he/she expected in the defined time, within agreed budget)! Now, how one wishes to reach to that stage - it is for them to decide. Someone may use traditional approach, some may use Agile mode. The interesting fact is - if we look at how Agile frameworks have evolved, they were always transparent is letting team decide what works best for them (well, nowadays you do see very rigid & prescriptive frameworks as well - very unfortunate). The spread of cult culture can be rather attributed to the WAKA community (I stay clear from them). Scrum being a framework - it only proposes a way of working, with 3 roles, 5 events, 3 artifacts. If we wish to follow that - excellent. But half way through our journey, we may feel that it will make more sense to have 4 roles or 2 events or perhaps 10 artifacts. Now - as long as we inspect and adapt towards betterment, we are good. Such learning in fact helps in improvement of the framework itself.
The sole purpose of having a framework is to let people pick from learning of past, than starting from scratch. And if the learning or experience has been leveraged well, it allows us to reach our destination faster. So, today I may be doing great with my current way of working. But I can probably do way better than this - not only to deliver more value, make customer event happier but also to reduce time and keep my employees more motivated & engaged. Food for thought! ;)
I hope this clarifies your doubts (well, in universal sense i.e. no more feeling of uncertainty). :)
May 12, 2019 · Arijit Sarbagna
I can only wish you best of luck!
May 12, 2019 · Arijit Sarbagna
BTW - I did run companies in the past. Not an unfamiliar territory for me.
May 12, 2019 · Arijit Sarbagna
I am not sure what makes you think that I didn't answer your point. I will again try (iterations, right?):
- The major difference between Agile and Non-Agile project is nothing but the approach - which comes from a preset notin, stuck in our minds & Agile liberates us from those fixed, rigid rules.
- This is precisely what makes the success rates differ & hence the asusmption that success rate of non-Agile is similar - is not correct.
Now just the way people tend to do Agile - without realizing that they are not! There are similar examples - where people are actually doing Agile, where the don't call it or have not named it as "Agile". In the days - when people had not heard the words like "Scrum" or "XP" or similar - were projects not successful? Of course they were & even today there are success stories. No denying!
But with the market volatility and disruptive changes - it is no longer a want, but NEED of the hour to adap Agility to stay in the game.
May 12, 2019 · Arijit Sarbagna
As per the report - success rate for Non Agile projects is 26%. This should not be surprising, right? Coz gone are the days when we used to say use Agile way of working when you see changing requirements. It is time for adapting to the mantra of "Doing Twice the Work in Half the Time".
But as I stated in my article & I advise the same in my training or speeches as well - end of the day, follow the approach in which your team is most comfortable. No point in trying to do something where you are putting half-hearted effort. That way we can neither succeed with Agile nor with any approach for the matter.
Lastly - you said it very aptly "Clear requirements, stakeholder engagement, high-performing team, appropriate technology". What do Agile frameworks deliver in reality? They are nothing but an attempt to facilitate all of those and more for a team and organization.
May 12, 2019 · Arijit Sarbagna
I am hoping my previous answer will clarify the doubts. If not - please let me know. I will be happy to elaborate further.
However, just to ensure alignment:
- The other 58% claimed that they were following Agile (truly or not comes later) way of working, but they failed (i.e. unable to deliver per the "Triple Constraint").
- If one tried to deliver projects in a PA-SA-WAKA-DA pattern, it may appear that there was a sincere attempt, but failed. In reality - it was wrong from the very beginning.
What is truly Agile?
As long as a project is following Agile way of working, respecting the Triple Constraints. That sounds pretty much like "true" to me. But do note - "Agile way of working" is pretty deep. It is not a doctraine as some people may try to put it. It is rather free from bias or designation and very much in favor of the context & most importantly for the team.
Lastly, your favor for the word "zealot" makes me think - you probably faced someone from the WAKA group. Stay away! :)
May 12, 2019 · Arijit Sarbagna
My apologies if the statement confused anyone. The fact that I was trying to present is - on average Agile Projects have a 42% success rate (Source: Jim Johnson, Standish Group, Chaos Report, 2018).
What is success in this context? It simply means - ability to deliver the agreed scope of work on agreed time, within agreed budget - following the quality parameters agreed between parties involved.
So, it is not about delivering just anything, we have to follow the "Triple Constraint" to be able to deliver successfully.
You also asked:
"What does 'truly being agile" have to do with that? What does the word 'truly' mean here? This is a marketing and religious term, not an engineering term. "
The figures speak for themselves. Out of the entire population of projects - claiming to be following Agile for Software Development, only 42% were successful. Why? They managed to follow their Agile way of working to successfully deliver. Simple, isn't it?
"Truly" - signifies the ability to use & adapt their Agile way of working to something that suits their context best! That is the core concept behind Agile way of wroking (not a doctrain - as you put it).
And I am afraid I don't see any marketing or religious intent. But happy to discuss offline. "Individual interactions" are more effective. ;)
May 12, 2019 · Arijit Sarbagna
Christian thank you for answering! Yes - it is a very much marketable item. Even so, some corporates put it as part of the roadmap to wow the investors.
May 12, 2019 · Arijit Sarbagna
Very interesting observation from you! Why do you think Agile is needed to kill innovation? The reality is just the opposite. And as I put towards the conclusion - if done wrong - we use those as an excuse to pass the buck.
If done "properly" (there are many paramemters) - a Scrum team will consider 6 productive hours per day. Where goes the other 2 hours? Use those for planning, learning, reskilling, admin etc. Now, if you are not following that - should we blame it on Agile?
May 11, 2019 · Arijit Sarbagna
You are spot on! That is why we need the drive to be aligned/approved by top level. Stay away from the "We Also Know Agile" (WAKA) folks! They are one of the major contributors of Agile failure!