why → improve workplace for myself and fellow developers
Note: Developer is someone who contributes to the project rather than just manage.
After working with the Agile Development Model for the past 4 years spread across various teams and organisations. I felt so disheartened when i found that the Agile Methodology was actually proposed by a coming together of developers who had spent years trying to improve the process of Software Development. How they came up with this? These were no mere mortals but the great philosophers of the art of Software Development.
I felt sick, being a developer myself how developers themselves can spawn such an abomination that is leading to such poorly constructed teams.
You might have noticed similar trends across teams:
- People constantly complained about not having proper work life balance and felt they over worked sacrificing their personnel time.
- Feeling of constant pressure to deliver since each task had time based estimations.
- Lack of desire to learn and improve while working on tasks since estimates needed to be met.
- Rebuke from Manager on daily basis since in Daily Stand Up status needed to be shared.
- Feeling of loneliness since no one had enough time to help in case someone was stuck with their tasks.
- Constant modification of tasks leading to lot of re-work on top of already stretching estimates.
- Rise in team politics since performance is gauged on story points delivered per resource.
- Tools and Documentations taking up substantial time each day.
These problems lead us to constantly change teams and organisations in search of improved work place conditions. We never really apply ourselves to tasks and most of us fail to reach our full potential.
Somehow for the corporations the process has become more important than the people themselves.
When you notice such troublesome things in the work place you can image my bewilderment when i found out that this methodology was actually proposed by people whom i and many of my fellow developers have considered inspirational. I wondered if there was something wrong with my understanding of this matter and indeed there was.
Behold - The Agile Manifesto
If you go through it you will notice that it is in no way a concrete document on how to implement this methodology but is just an abstract one where ideas are collected on how things should be.
Corporatization of Agile
Since then this methodology has sky rocketed in popularity leading to a rise in divergent implementations for the same base ideas.
Another dimension to this methodology has been added by corporations. Corporations love control over employee activities and complex projections of growth and hence have developed their own system around this methodology which keeps their interests first, in turn sacrificing employee autonomy and also leading to the dreaded time based estimations.
This system has led to the “so called” agile tools which complicate the process of development and needs substantial team effort to maintain. These tools increase accountability and answerability of teams based on numbers then the actual product development. So teams start to cut corners and provide falsified values.
How it should Be?
This is an amazingly difficult question to answer. But we can look to the very people who originally gave us the manifesto for answers. One of them is Jeff Sutherland and he has put forward his idea of Scrum. He has been able to refine his idea over his long career. But as we have ascertained already there is no one final implementation and you are free to explore.
His work is centered around the following principles:
- Organize daily stand ups to prioritize tasks and minimize time wastage.
- Do away with time based estimates as it is futile and bound for failure. Only use complexity based estimates.
- Plan plan plan but be ready as all plans fail.
- Use regular Retrospective Sessions to reflect on the good and the bad in the team and come up with action items to improve.
- Deliver End to End Use Cases regularly and this should be the holy grail to judge the progress of the project.
- Extrinsic motivations(hike, bonus, promotions etc) should be discussed beforehand so that they don’t lead to unhealthy competition.
- Process should only exist to facilitate the team and should not be used as a control mechanism. (Process for the people and by the people)
- Regard team velocity as the guiding stone and use that as the pivot for acceleration.
- Team should aspire to achieve transcendence.
Requirements rarely change but the interpretation changes constantly.
I highly recommend his books to better understand his philosophy.
Motivation
Another important factor in improving any methodology is the understanding of motivation. Why the team should do what it has to? why should the team improve constantly when it requires significant effort? why not just “get by”?
The great works of renowned writer Dan Pink guides us in this area.
- Focus on intrinsic motivation(internal) people have an intrinsic desire to improve, self master and live a life of purpose.
- Extrinsic motivation can provide a boost in the short term but it reduces cognitive capabilities of the team in the long one.
- Everyone has an innate desire for mastery, autonomy and purpose.
This is my first blog post so please be gracious towards my mistakes. I hope to improve my life as well as the life of people like me by sharing my quest for change in the current order. Also shout out to Simon Sinek for inspiring me to do so.
