Agile: Killing Brains

%Grab trending news%buzzgrab

Agile the process which has been accommodated by all large or small company is actually killing engineers brain. Do not believe me, but once you read I guarantee you are gonna agree with me.

Agile Manifesto” is one sided story from the point of view of Product Owner without caring about the team who is responsible for delivery, i.e. the development team.

In this article, agile and scrum has been used alternately as needed. The article covers development team’s difficulty across industry at small, medium or large scale. Also how the agile has been twisted in the name of adaptive project environment to maximize the delivery.

Now let read once more the so called “Agile Manifesto” the killing mechanism.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Now in the light of above 4 lines of agile manifesto, let look back the responsibility of each role in agile team and how they have evolved.

Product Owner:

  1. Clearly expressing Product Backlog items;
  2. Ordering the items in the Product Backlog to best achieve goals and missions;
  3. Optimizing the value of the work the Development Team performs;
  4. Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  5. Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

Development Team:

  1. They are self-organizing. Noone (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
  2. Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
  3. Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
  4. Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
  5. Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Scrum Master [The obsolete role]:

  1. Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
  2. Finding techniques for effective Product Backlog management;
  3. Helping the Scrum Team understand the need for clear and concise Product Backlog items;
  4. Understanding product planning in an empirical environment;
  5. Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
  6. Understanding and practicing agility; and,
  7. Facilitating Scrum events as requested or needed.

%Grab trending news%buzzgrab

Threat / Development Team Extra Burden:

  1. The scrum master is an obsolete role. Almost 90% agile team does not have the role. So at least one responsibility of scrum master is passed over to development team since the team is the one responsible for delivery. Which is causing extra burden to development team:
    1. Ensuring that goals, scope, and product domain are understood by developer.
  2. The Product Owner may do the above work, or have the Development Team do it“. However, the Product Owner remains accountable. There is a big difference between being accountable (product owner) and doing it by spending hours (development team).
  3. Most of the backlog items are just one liner. Which might be understandable to product owner due to his product knowledge but not for development team. In the name of clear requirement, development team receives some phone, slack and email communication. And responsibility of clearly noting down requirement by gathering information shared, is passed over to developers.
  4. Processes, tools and comprehensive documentations are not as important as working software, but documentation becomes P1 for developer when working software break at production after few cycle due to some missing edge case consideration. Developers has to spend more time even extra hours finding what has been asked in the name of requirement vs what has been delivered. Who is right, who is wrong and a follow up escalation about quality and standard.
  5. Also “comprehensive documentations” might not be important at the beginning of product development but that becomes more important along with increasing complexity and size.
  6. Also documentation is very important in consulting model. Correct document is being used as a tools of contract negotiation by forgetting agile manifesto “Customer collaboration over contract negotiation”.
  7. Responding to change over following a plan” is being used as a tool of “forever changing requirement” which lead development team to work in a support mode. By support mode means task is defined by priority and service level agreement, not by sprint planning and predefined priority before sprint starts.
  8. Absence of separate QA team or even absence of role swapping among team for 2 individual taking care of development of QA role, results developer to be responsible for end to end testing process as well. This leads to missing business scenario, edge case consideration and frequent post deployment issues.
  9. Peer Review: To mitigate post deployment issues new term has been introduced in many scrum in the name of buddy review or peer review. Which does not solve actual problem of role swapping “QA vs Development” but add additional burden on individual team members.
  10. One of the main guideline of scrum was collocated team and easy communication. Which is way different from offshore onsite model of consulting work. In most cases product owner is an onsite member and majority of development team is at offshore. The easy communication causes time and effort with different timezone, extra hours of effort and exhausted buffer time of project delivery. This the biggest mistake of agile. Product knowledge and actually working unit are not collocated. To overcome this high level of documentation is needed, which is again not priority in agile.
  11. All above extra burden is not being considered during sprint planning since “Working software over comprehensive documentation”. Which leads extra working hours for development team.
  12. With more passing sprints, the project grows in size of complexity, client manager gains the accountable for codebase and project documentation. So development team gets additional responsibility of code standard and documentation standard, which is against “Working software over comprehensive documentation”.
  13. Daily Standup sucks: Everyday progress towards delivery is being tracked via 15 mins meeting. Which is nothing but a tug war of 8 working hours. How much achieved, was the progress worth 8 hours, are the tasks are in correct state, are the task status updated daily with current situation. In case of unwanted technical difficulty or new team member addition to the team, extra hours spend for knowledge transfer is not being considered as working hours. These unaccounted extra hours put burden on development team.

The contribution of unwanted guest [Client Manager/Project manager]:

  1. The role of project manager is not the same as scrum master. Since the role of scrum master does not exists anymore in most of the scrum environment, client manager or project manager play the role of partial scrum master.
  2. In consulting mode of work, client manager is the unwanted guest in scrum. He is neither scrum master, not product owner. But he plays the role of associated product owner during sprint planning and scrum master during daily standup with a point of view of billing rate. The role itself is a conflict of interest within scrum.
  3. Client manager point of view is always aligned with hourly spending on resources including consideration of different billing rate of onsite and offshore member. In typical onsite-offshore consulting model, within development team member ratio 1:5 and billing rate is 4:1.
  4. Client manager becomes part of scrum and calculates daily progress with his spending of per hourly resource cost (development team).

The final words:

For development team, everyday update in daily standup, no breathing time between sprints, extra overhead along with sprint activity, does not give scope of quality or innovative development. The whole agile process has been developed from product owners point of view of getting early measurable delivery with accountability of daily billing rate, additional support work in the name of changing priority and ever changing requirement in the name of adaptive project environment are killing developers thinking process. The process is designed to kill individuality and individual’s ability of creative thinking. Each resource is being treated as a tool of input billing rate and output delivery with 2-3 weeks of breeding time.

Some additional Quote I heard during my so call agile experience:

  1. I need accountability of every hour I am spending for you.
  2. If X can do a work in 2 days why Y can not.
  3. The project documentation should be in such a way that, a resource could be replaced with 1 week.
  4. Do you think this task would take 1 week of time, I can complete and give you in ½ day.
  5. Why you need buffer time, each hour comes at a cost.
Because #Stories Brings Us #Together Click To Tweet


© BUZZGRAB | 2018 | All Right Reserved | Crafted With Love


Log in with your credentials

Forgot your details?