Agile – Impediments to successful execution




For the last several years I have had the privilege to be part of several projects executed in ‘Agile’ during which I have held various roles including, as a team member, technical  lead/architect and overall responsible manager. While there are plenty of articles already on the web that openly praise or abhor the methodology, this article intends to highlight my individual experiences and provides a quick primer to understand the key factors which could be detrimental to the success of ‘Agile’ in any particular project.

Top impediments for ‘Agile’:

  1. Lack of separate internal team organization for new-development: 
This is the #1 ‘real’ problem in any enterprise organization with work being either around ‘new’ feature/enhancements versus addressing ‘production issues’ or customer escalations. For ‘Agile’ to succeed you first need to have a well defined team that purely focuses on ‘new’ development and never mix the two.



  1. All teams need to go ‘Agile’ or none at all: 
All impacted teams need to be part of the ‘Scrum’, typically Development, FVT (QA), Documentation. Any deviation would mean it effectively would result in plain ‘Iterative’ development and that is NOT Agile.



  1. Not-so-‘Agile’ change-management/approval processes: 
Any fairly large enterprise product is bound to have ‘traditional/time consuming’ approval processes for any ‘change’ in the ‘product backlog’/‘committed feature set’. When the expectation with ‘Agile’ is to have a ‘consumable product’ in short  time-bound iterations (~4 weeks), it is critical for change-management to go the ‘Agile’ route too! Going 'agile' also requires an entire organization to change their business processes.



  1. Purely ‘go-by-the-book’ for ‘Agile’: 
Agile only defines a bare-bone framework but leaves enough room to customize the ‘rules from the book’ to suite your specific project needs. While the book might recommend sprints of 3-4 weeks, you might have a need for slightly longer sprints (~6 weeks) especially towards the beginning of the project. It is understood that ‘daily stand-ups’ need to be short face-to-face daily meeting, you might be pressed to have it over phone (as teams are very rarely co-located) and have it may be 3 times in a week.



  1. Not breaking tasks to small enough sub-tasks: 
Features should not be built in a single sprint or iteration. Instead, features should be evolved and grow over time. A feature should start out small and develop and evolve over time as feedback is received and customers or the product owner tries it out.



  1. Product Owner is Consistently Unavailable: 
Product owners not passionately engaged in the agile adoption hold the software development team hostage until the expected benefits have been delivered. An unavailable product owner perpetuates the wait time and creates waste, which is a problem that more traditional approaches are known for.



  1. Reduced focus on ‘overall’ architecture: 
‘Agile’ is often mis-construed to mean ‘start coding’. As stated in point (4), scrum allows for enough scope to customize as per specific project needs. One recommendation is to have a sprint zero to focus on overall architecture and create user-stories for such non-functional requirements.



  1. Insufficient focus on retrospective and customer feedback: 
Gaining periodic customer feedback of working software is an important aspect of agile development, because it ensures that you are constructing a valuable solution for the customer. Without customer validation, you are not really applying agile; you are just doing a form of iterative development without aligning your work with the customer’s need.

Comments

Popular posts from this blog

What does it take to develop 'cloud-first'?

Can IBM Watson gain wisdom?