Lessons learnt in making a good team out of great team members

Buiding a team and building it right is tough.Building a team from scratch which has a collective experience of almost 200 years is very tough. Building a team while also teaching them new ways  (better,  repeatable and innovative) of doing things, changing their behaviours , changing their mindset, overcoming resistance at every step of the journey (be it documentation or doing automated testing or have a meeting at same time everyday), balancing coaching versus training , convincing versus directing – all these things are even tougher.Building a culture of accountability instead of responsibility is  toughest not just within a team but also within customer/stakeholders and other teams. And then to ensure that we consistently deliver to our commitment while doing all of the above is terribly tough.

Doing all this  and leading this change is very fulfilling to say the least.However admittedly and unfortunately one thing that I also had to do is –  micro manage.This style of management and leading  is totally contrary to a lot of good agile tenets like collaboration, ownership, autonomy, automation, continuous self improvement; constant feedback and pairing .And I get that. And I’d rather work within such environments instead of having to chase up every bit of work for completion – the right thing and in the right way.

However I did not start with this approach. Given the collective experience, deep domain ,tech and industry expertise within the team I always felt that ownership ,  good sustainable software engineering practices would be natural and core delivery principles of commitment ,communication and collaboration would be obvious. However I was wrong  – not because my team is bad or  doesn’t follow it on purpose or are really not up to the mark. Quite the contrary each of us in the team is an ‘A’ player in this business. I have not yet worked on a team which has such high calibre people who can single-handedly identify a problem, envision a solution and build a suite of solutions  all by themselves.

The catch is that when u have a team with all A players its hard , very hard in many ways. Managing and controlling passionate individuals; pushing pragmatism over perfectionism; finding an optimum solution instead of the most ideal solution; driving context over correctness, all this at a time when organisation is also embracing new delivery processes – it becomes increasingly hard to manage , deliver and be awesome every day. This also resulted in low quality deliverables which were not on time and not up to the customer expectations (internal and external customers). This eventually led to lack of credibility in this team of “all stars”

The initials signs for me to micro manage the team became evident when we consistently failed to deliver and continued to overcommit sprint after sprint. I bet if you asked each of us if we could do it individually the answer would be a big Yes then why were we not able to meet our goals as a team?  Why was it that during sprint planning the solutions were very clear in everyones mind but when it came to implementation the same tasks took very long and the implementation become more complicated? Why was it that individually we all were rockstars but  as a team we could never sing and dance nicely together. Our team started to feel incoherent and that we could not get our act together.And effectively lost credibility amongst business community.

I figured that our extensive experience , in-depth knowledge , delivery background was our nemesis.It was a typical case where each of us was putting best efforts and having the best interest of delivery and customer at heart.Then why was it that the customer never got what they wanted ? Thats when I realised that even though we are putting efforts we are not putting it in the same directions. The way each of us was driving the effort and focus was subtly different which eventually led to missing the goals completely.

Thats when I decided to go basic extremely basic. I moved the fancy electronic wall to a simple physical wall. I decided that during sprint planning we will read each and every story to the letter and talk about acceptance criteria and agree to each task to ensure nothing was left to personal understanding and interpretation. I started running standup in the same way every day by “walking the wall”.Even if the info shared was redundant i encourage everyone to share it. I asked every member to move their card themselves. Code reviews were mandatory.Acceptance criteria was an absolutely  essential.INVEST principles were to be strictly followed. Each user story had to have business value else it was not in sprint.

More importantly I did not consider any opportunities for ‘improvement’ for almost 3 sprints. Showcase was mandatory regardless of attendance. Showcase was run by me and the BA just to introduce a vigour and discipline of what and how it should be run. Retros were run –  actions items taken , assigned to relevant members and then tracked during standup along with other cards. Anything that cannot be actioned was thrown in the bin or assigned to someone up the food chain to handle. We committed a set number of stories and then removed a few to have capacity of prod issues. bugs and unplanned leaves.

During this “back to basic” phase I did not try to improve anything substantially. A few minor things like format of showcase or how much details to discuss at standup were tweaked but by no means were they “improvements”.The reason was simple. Unless we got the basic absolutely right there was no point in looking for improvement opportunities because honestly we just would not know whether we improved and / or what did we improve, if anything. And it took us 3 – 4 sprints until we got back to basics and practiced it without any effort

The discipline and dedication to continuously pursue the discipline started paying right from sprint 1. We became a team that under committed but over delivered. Team regained confidence and credibility. We started to think out of the box solutions. Collaboration has become a habit rather than exception. Picking additional items from product backlog are quite a normal thing cause we always understand the impact and benefit as a team before we pick up anything new. The team is more focussed to an outcome rather than output.Automated testing is “has to be done” rather than “can be done if time permits”. Build pipelines are the only way the code moves from dev box to prod.

If these are the benefits of micro managing I would trade that anytime for an autonomous team. However I am very hopeful and confident that I would not need micro managing the team for too long. After all I  am a part of an A star team and once we get into rhythm its hard to stop us anymore.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s