Agile, But not Agile

I am sure that is post of mine would resonate with the readers with respect to that we are Agile, but Not Agile. The best part of the story is that most of the organization in India are doing something or the other in the world of Agile and trying to make their hands dirty with the concept and implementation of Agile.

Not sure if the organizations that have adopted Agile, have done any retrospective on their adoption of Agile, we expect that at the end of the iteration / sprint cycle, the team would perform the retrospective and learn from their practices that needs to be improved. Not sure why the same yard stick is not applied at the organizational level. The management expects all the principles and practices to be applied at the team level, but when it comes to its own application, they have washed their hands off

I am finding it very difficult in India for Agile to be practiced in true spirits, not saying that all organizations can be clubbed together, nor am I trying to paint the town red, but the real story is that in most of the places, I have not observed majority of the Agile Manifesto and Principles adopted and done in the true manner

Most of the people and the Agilist that I have met have given the impression of working with Agile and related stuff with the waterfall mindset. Not sure if the required change would come via this element / approach.

Speaking on the same, Lets discuss one of the principles of Agile …. “Customer and the Development Team should speak daily”, All of the agile methods require that the Customer (in this case the Product Owner) would be based at the same location as that of the team, but this is hardly practiced in real life execution of projects, due to the Onsite / Offshore engagement models, where the product owner is not located in the same location as that of the development team. Have observed practices such as proxy product owner, it is like complicating the matters beyond repairs, If the Proxy PO can do the job, then why have the PO? During my training and consulting with various customers, Have always heard that if we have any query to resolve with respect to the user stories, it is difficult, as we have nobody to bank upon, the queries are delayed, at times information is provided at the eleventh hour. This has its own impact on the quality of the deliverable that we make to the customer.

One of the other major issues faced by team adopting Agile and related elements in India is the changes that come in the sprint after the commitment has been done during sprint planning meeting. It is stated and given that no changes in duration or goals of the sprint, but this is not in place for majority of the organization. Every change has a cost, but agile does not account for this. The result? People often change really big things late in the game using the rationale that since it’s an agile project, it can handle it. This encourages poor and irresponsible planning while hiding its effects. As iterations / sprint continue and the defect list grows, the customer becomes more frustrated—not only because of the lack of quality, but because delivery expectations aren’t being met either. The only way the project can handle this is by adding iterations / sprints. As that happens, defects that might have been easy to fix at one point get harder and harder to fix, since the code base keeps changing.

Remember, the goal is to deliver a quality product on time and to budget; as a rule, there are always some elements that have to be sacrificed to fulfil the needs of the others. It’s the How to Develop Next-Generation Scrum Masters / Agile Project Managers role of the project manager to define and maintain the project priorities so they can function as a decision framework for team members as they carry out their tasks.

Off-late I am in touch with a number of customer, who want to actually redefine the concept of Agile to suit their requirements and needs of working, well I see nothing wrong in this approach, but my recommendation is not qualify that we are following Agile, it is a misnomer, We are giving false impression and views to the world of our capabilities and understanding of Agile

People love certifications in the industry where I work. But when a particular methodology gets popular enough that a certification industry rises around it, organizations try to adopt that methodology without bothering to understand it. It’s as if certification replaces the need for thinking or experimenting. It becomes a check in a box: “We’re certified, therefore we know what we’re doing and you should hire us.” The primary focus becomes figuring out what you need to go to get certified; figuring out ways to actually improve productivity becomes secondary. That’s the problem I have with certification – I’ve seen it happen multiple times (and even been involved in it), but it’s particularly ironic with Agile development.

There’s a reason behind the demand for certification – it’s human nature to want a simple way of discriminating those who know what they’re doing from those who don’t (especially if you don’t either) – so I’m not sure there’s a good solution. In any case, I don’t have a problem with scrum training, just certification.

It high time, that we re-channelize our focus and energy to do the real thing rather than running after pseudo stuff ….. My prediction, Agile has lived its utility (though more than 70% of the IT industry does not implement and practice the way it should be done), We are now waiting for the next BIG wave to come in and that in my view would be DEVOPS

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s