by on

I started my career with a waterfall style development taking a finished product after extensive quality control to the customer. Release was a major event, marked in our calendar where no one can take days off and the weekends are taken for granted that you will be at work. People spent a considerable amount of time on go/no-go calls and then a marathon effort to make a release happen. The releases were also followed up by hotfixes, bugfixes and minor enhancements which took a toll on the people making it happen.

We think waterfall is extinct now but it is not. There is still a great fear in releasing software to end users. We have progressed so much in software development that a lot of boiler plate is getting taken care by frameworks/tools, extensive automation capabilities help remove toil, abstractions and off the shelf components make it possible to develop and deliver something in matter of days and weeks not in months and years. Combine this with tech practices advocated by XP, we have a very agile tech team.

Photo by Pavel Danilyuk on Pexels.com

No matter what agility comes in technology, the inertia from the business and the product always robs the advantage of agility especially in mid and large organisations. Product teams always want to put a finished product in front of the customer that will wow them, in reality software development never sees a finished product, you just stop giving updates. Tech teams are capable to ship smaller increments of product, in a great frequency in the order of multiple times a day. In a mature continuous delivery enabled team setup, every commit or merge can go to prod within an hour.

Should we call each deployment as a release then. Deployment is a increment to the software, release is a logical grouping of many increments. Branch by abstraction will safeguard existing functionality while new increments are getting delivered and it will be a matter of another small increment to consider it as a release.

I have worked with some teams where the lines blurred, there were only deployments and no releases. One such team had to revamp a user profile page which aimed to declutter the UX and make it more easy to use. The team put a toggle button to preview the under construction page on the current user profile saying “we are revamping the page and let us know how it is coming along”. The designer also asked for feedback from the end user by providing comment ability on the new screen. Along with the comments, analytics was also baked in the new page to learn from user behaviour. This led to super fast iterations of the design as the feedback was instant and from real customers who use the product every day.

Coming back to the inertia from the product to go with a release mindset, this rots the continuous delivery mindset and quickly the teams align to a release mode making it slow, effort intensive and tiring. Decouple releases and deployment, product evolution is supported only when you can iterate as fast as you wish.

by on

I recently installed an app to get groceries and milk delivery at home every morning. When I browsed through the catalog, a lot of items were cheap but when added to cart they asked for a subscription fee to checkout at the listed price or pay markup on the items which were much more than what it was listed on the catalog. So I went ahead and paid the subscription fee and when checking out I see that only some of the items are discounted but not all the others. When I looked into the details, the subscription had a fine print that the price was applicable for only 15 items and it auto applied to all the cheapest items, leaving out the bigger items at the markup price.

I anyways continued to order to check the quality of deliverables and over the course of few days I felt that provisions ran out a bit faster than the previous vendor. On checking the details, all the products sold are in the range of 400-450 grams or 400-450 ml instead of the standard measures of multiples of 500. I checked around who these people were and found a patch which proudly claimed that it was a product of IIM alumni. Why on earth someone spends entire early adulthood preparing to earn a good degree just to mislead and profit.

Photo by Wendelin Jacober on Pexels.com

These kind of rots and rusts are evident in the society, at workplace it is hard to spot. While it may not be deliberate act of mislead and profit, it is more of rent seeking that is rusting the workplaces. Job characteristic theory mentions that a good favourable job will promote

  1. Skill variety – To learn continuously and implement
  2. Task identity – Where people understand the larger picture about whatever small they are doing
  3. Task significance – The general good feeling of doing something positive for others
  4. Autonomy – Accountability on actions, elbow room and breathing space. No one constantly telling people what to do
  5. Feedback – To know whether what someone did is good for not in an actionable way so that they can build on the failures

Conventional industrial processes did not worry about any of the above as it was primarily a dead end job. When software was first developed it was very similar. Breakdown the entire work into small chunks, sequence it and give it to people to finish the product. The industrial type work relied on individual contributors working in isolation with a specific skill, as long as they follow the job description the end output however complex it looks can be achieved. The knowledge type work relies on individual contributors working along with others in the group to be successful. It is a key difference, the industrial type of job is a dead end job with no autonomy, skill variety or task significance.

The rots and rusts start from there, young individuals join the knowledge workforce expecting to do big on their career but are stifled by the system that was designed for industrial type of work. Eventually people become victim of systems, they become tired of always being told how to do and what to do. The faster they escape from the situation, the better so they try to get into management as soon as possible. This steps furthers the rot, an individual contributor who did not understand well how to do their work within a team is now equipped to tell others how, when and what to do.

Where do people look up for guidance in a new job role?, it is their peers who are doing similar things. Anything which has a short term gain and less learning horizon gains traction compared to long horizon ones. Example – Click bait to increase engagement but lose the brand value over long run. As long as the increase in engagement is rewarded handsomely this behaviour will continue and the person will move on to another place leaving the after effects to be handled by a successor.

Shanty towns – Locally optimised but a collective failure. Picture from pexels.com

Slowly many anti patterns become an accepted practice and become templates for career growth. A rotted and rusted system will cause more victims of the system. Every one will be governed to optimise for themselves but collectively fail. Agility in software development was a key issue when people were following the industrial type of work breakdown and development, a bunch of people got together and came up with the manifesto to bring agility into software development. What followed after 2 decades is that there are plenty of frameworks and processes but no agility. Ask this question, if a business needs to wait for a release train next quarter to test out their hypothesis and implement that in the following quarter, how is it agile?

People can attend a training for 3 days and become masters in driving agility in their teams, it is like saying you can become a football coach by attending a 3 day training, that is how broken the industry is. Unless an individual realises and resists to contribute to the rot, the rotting and rusting will continue.

by on

Few years ago one of my friends suggested that I read the book “Maverick” by Ricardo Semler. In this book, the owner of Semco corporation in Brazil details out on how he transformed an ailing company which he inherited, into a successful and profitable one. He did this by redefining the rules of management and empowering employees at all levels. One of my favourite moves was to remove the traditional hierarchical designations and introduce roles which explain the nature of the job. Roles like Associates, Partners, Coordinators & Counsellors removed the perceived hierarchy and brought titles closer to what people do, instead of who is the boss of whom. Taking few leaves out of the book I tried the following in teams which were adopting agile.

  • Introducing new roles; associates, coordinators and facilitators.
  • Separating leadership and management

Roles

  • Associates: Any one part of the team who writes code, tests, creates requirements, builds & deploys is an associate. Irrespective of the experience and skill level every one who contributes to the day to day activities are associates. 
  • Coordinators: They are the representatives of a particular discipline of work and are usually the external point of contact for the team. As the name suggest they are responsible for coordinating several activities in the project. For example a technical coordinator spends some part of their time every week to ensure that the engineering practices are up to the mark and take up the task of keeping all the associates in same page. 
  • Facilitators: These are the people who help the team set their goals and makes sure they are able to achieve by collaboration. They remove the hurdles in the team and ensure smoother journey towards the goals. They also ensure traction to the plan and help the team identify and mitigate potential risks.

Both the coordinators and facilitators can be rotated from the pool of associates in the team. Each team’s associates together comprise of all the skill sets needed for achieving the goal or in the course acquire them.

Teamwork

Leadership and Management

Like a football team each team needs to have a separation of leadership and management, leadership is always on the ground working with the team; management takes care of the team’s needs, sets expectations and vision for the future. In a hierarchical setup, leadership and management either meant the same or leadership was synonymous with senior management, leaders were always seen as someone whom people report to but not as an expert who works along with the team. It is essential that there are people who can provide technical and thought leadership in the team.

What are the benefits? When people don’t perceive hierarchy within their team, they were able to own things collectively. Irrespective of the seniority & experience, I have observed healthy debates in the team which has contributed to good work. People become comfortable with each other when the perception of hierarchy is taken out which helps in easy retrospection and one to one feedback also gets better as people consider every one in the team as peers.

Introducing these roles (associates, coordinators and facilitators) in the team does not need any structural changes in the hierarchy of an organisation, these are just titles in the team for people to identify themselves with the nature of work they do and remove the perception of hierarchy.

Image courtesy of [Sweet Crisis] / FreeDigitalPhotos.net