I read this interesting post on Agile Antipatterns. Various agile methodologies are in practice since early 2000. Today, Agile practices in IT world are given. I have, at least, forgotten what it used to be before agile. Yet, even today, we continue to see more or less the same antipatterns. Here is my take on same eight antipatterns.
- Miscommunication
I focus here on miscommunication pertaining to requirements and delivery against them.
Agile methodology is high-bandwidth practice. In doubt, you stand up and confirm. However, miscommunication always exist. More so due to people working remotely. There are hindrances when we work remotely.
Way out: Metaphors, more Metaphors, and more specific Metaphors. Metaphors play a big role in team. They help bring the Product Owner and the developer on the same page. Provide more specific metaphors and re-confirm the end goals of the Story/Task.
- Unclear Requirements and Scope Creep
Even with the best of our intentions, we tend to miss on requirements. Therefore, agile methodologies thrive on constant feedback. If the Product Owner is plain lazy or too busy and gets to see the product only at the end of Sprint, unsurprisingly, he will be up for surprise.
Way out: Feedback channel must be open all the time between dev team and product owner (in turn with customer, if product owner is a mediator). The product owner review must be formally identified periodic activity.
- Scope Stretching
In my opinion, it does not happen because of developers adding a couple of extra features out of generosity. However, good developers do tend to generalize some features, try to build generic code to handle future changes. Scope may not have changed externally, internally it does take more effort and time due to generalization.
Way out: On the face of it, generalization may indeed look reasonable, but it is better to avoid them, unless the problem statement itself is to provide a generalized solution. Closely watch developers to check if they are doing unnecessary generalization.
- Scrum Master Acts as Team Lead
In fact, most of midsized IT companies in India do not have dedicated Scrum Masters. This role is generally played by Project Manager, having undergone Scrum Master training. Project Manager being scrum masters of his own project/team is like a Judge hearing the divorce case of her daughter. Objectivity is the victim.
Way out: If an organization cannot afford/get a dedicated scrum master/s, it should make Project Manager of other teams to play scrum master role. In case of an independent scrum master, team members should not hesitate to point out if the scrum master is enforcing anything without their consent.
Next part soon. There are 4 more.
so{M}usings 