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

by on

A hunter watches a mountain goat grazing on the pastures on the side of a highway. A speeding truck loses control and starts veering towards the grazing goat, in split seconds it jumps off to a safe place. The hunter’s kid who was watching all this asked his dad, “Did the goat escape because it is agile?”. The hunter replied “It is just common sense to avoid a speeding truck”.

There was a question posted in programmers forum in stack exchange site asking Is agile the new micro management? I am not sure why such an impression about agile has been formed in that person’s mind. It could be due to some recommendations being wrongly interpreted. First of all the recommendations like “a quiet place to work” is a necessity for development teams anywhere following any methodology. Interpreting that as a no talking zone requirement is against improving communication between the team members. My perception about why these kind of wrong interpretations arise is due to wrong sense of accomplishment provided by having something tangible. If someone has to show any progress in adopting a new process or a method then it is natural for him/her to incline for a support in some form which could be seen or measured. This has led someone to believe that following some guidelines verbatim and measuring the level of adherence to it is equal being successful in adopting a new process or method.

I have not been aware that I was part of agile teams for a few years until I met someone who joined my team because it was an agile team. We were a team of 12 people doing weekly releases to production, wearing different hats of Dev, QA, BA and had everyday interaction with the customers. That is how I started my career and I never felt the value of it until I worked in a conservative setup. There was one golden rule of thumb we followed in the teams I worked, treat the team (client team included) as your own organization and do what makes sense to deliver the right value.

I asked one of the directors of a company that how come he never used the word agile though he was part of agile teams for quite long, he replied  “talking to your customers often; keeping the code well tested, integrated  and delivering the right value on time is all about common sense. There is nothing agile about it!”. He sure left me to figure out what agile meant.

Is there a prescription? Check the answers given out in that forum for that question.