No wonder that more and more product development organizations are adopting Agile as software development methodologies. Despite its popularity for productivity, adaptability and quick turnaround time, it has its own challenges. In this post, I am trying to explore and address commonly occurring concerns around Agile/Scrum implementation. Comments, suggestions, concerns on this post are most welcome.
Agile software development methodologies are widely accepted in IT industry now a days and becoming de-facto method of project management. With each passing day, it is gaining popularity and resulting into high adoption across industries.
Every organization has unique culture and characteristic, so interesting challenges occurs during Agile adoption and implementation. These challenges are more pronounced in the cultures where people are very processes oriented, resist changes/innovations, take leniency as liberty and are inflexible by nature. This is because Agile by nature is frank, adaptable, empirical and meant for matured and dedicated individuals.
Scrum, one of the implementation of Agile, is collection self-organizing individuals bind together with a set of deliverables for the product success. Scrum emphasizes team efforts rather than individual contribution. Challenges occur when geographically distributed team members communicate within or across different scrums and also when individuals from different cultural background transition into Agile environment. Most of them interpret Agile differently.
Agile/Scrum implementation has never been easy and organizations are bound to face challenges during adoption and implementation. In order to address organization specific needs of cultures and work practices, organizations often tend to customize scrum framework to overcome these challenges. Sometimes customization is so high that put core agile principles and manifesto at risk.
Following concerns needs to be thought of while adopting Agile for a product. There is no common panacea for these, but depending on team culture, expertise, flexibility these challenges can be addressed.
Scrum process strongly emphasizes team’s collective ownership rather than individual ownership. However sometimes collective ownership leads to (or ends up in) no ownership.
Agile supports self managing team up to extent that it suggests ‘managers’ (who don’t directly participate into deliverables) to avoid daily meetings. But practically, many a times team members can have diverse opinion about a point and it is tough for powerless (authority less) scrum master to reach to a consensus. Teams often spends considerable amount of time in sprint planning meeting in order to accommodate everyone's point of view. Then team wastes considerable time in decision making.
Agile advocates team taking decisions about the deliverables (like finalizing contents of an iteration). But most of the time, relying on majority rules results in safe decisions and a mediocre deliverables.
Agile support self organizing teams. Here few things need to be thought of about this Agile principle. Is team self motivated? Monitoring is needed? Is team enough matured to take decisions? Is team well aware of organization strategy, vision and mission?
As a part of scrum, all members are expected to convert the requirement into shippable product and also provide estimates for their tasks. Wrong or untrue estimates lead to unexpected results and surprises. Also, team needs to have all expertise present in the team to deliver a shippable product like architect, coder, tester, domain, localization, documentation experts. This is practically very challenging to achieve.
Non availability of product owners
Many times, team wait for detailing, more info about a requirement from product owner(s). But practically it is tough for product owner to give sufficient time for each scrum team and that leads to wastage of time and resources of scrum teams. If team takes decisions locally without product owner consent, it results in rework and/or scrap.
High vs. low performers
Scrum methodology exhibits team centric approach to software development rather than individual centric. Productivity and performance are measured with respect to team's collective efforts. A team usually consists of varied degrees of expertise among team members, some high performing and some low performing ones. In scrum burnout of a team efforts are measured in man days. This does not distinguish a high performer from low ones.
Leadership vs. management
Lead: do it and let other know how to do it. Manage: ability to match resources requirements with resources availability (with negotiations). Scrum framework by definition does not want scrum master to be leader or a manager. It defines scrum master as someone who helps “removing any impediment”. This ends up in scrum master neither lead nor manager.
Individual career path
How to make sure scrum deliverables of an individual are aligned with his or her career objectives. Just an example, scrum suggests a developer to test code, whenever needed. This can’t be welcome by developers always. Scrum literature talks about functional leadership role within the organization like architects, product managers or business analysts and also explains how these roles get molded in scrum framework. However, Agile is equally silent over the path or process that individuals should follow for taking up higher roles.
For service packs and maintenance releases, generally there is no product owner, release planning meetings, demos, feedback mechanisms etc and thus it dilutes Agile philosophy.
Daily scrum becomes formality and does not utilize time to fullest. Sometimes it ends up stretching office hours, if team members are across time zones.
Sometimes product owners have too much expertise in domain and product knowledge as compare to team member. This creates big gap between them.
Coaching and mentoring
Team needs coaching and mentoring to achieve team success.
Following are few opportunities that product team can think of materializing. This needs tuning (not customization) into core Agile philosophy and practices.
These opportunities are not one to one mapping with above challenges.
Develop scrum leadership
Develop delivery owner or scrum leader type roles into scrum team. This role mainly focuses on effectively leading the team and improving decision making of team.
Proxy product owner
Empower 1 or 2 team members in team with domain and product knowledge up to extent that s/he can take functional decision, prioritize contents, do requirement detailing, guide team about functionality in day to day tasks in the absence of product owner. Of course, s/he can get back to core product owner whenever needed on tough issues. In short, s/he to interact with product owner(s), and represent them while working with team (at least for trivial issues).
Empower 1 or 2 team members with technical knowledge and expertise up to extent that s/he can represent architect to the team. S/he can guide, mentor team on all technical issues and set up processes in day to day development. For example, s/he can help laying out common development and testing procedures like daily builds, automation tests, setting best coding practices and rules for code review across the entire product
Mentor and coach
Develop coaching and mentoring to novice members with regard to day to day activities like, just for an example, assist team in breaking the requirement into smaller tasks and also guide them in correctly estimating their tasks. Also, help team to achieve their own career goals by aligning it with team deliverables.
This way, I see Agile is inevitable in today fast changing product requirements and technologies. And at the same time it opens lot of new opportunities, roles and career path to folks dealing with it.
I am sure most of you would have suggestions based on your interpretation and adoption of agile. I request to post comments about it.