Whooaa!! Thats a huge statement.. I can hear you! But let me explain.
Its been quite some time since I have been running my projects in Scrum – and boy I can say I am glad I discovered it!
It all started a year back when my current project was about to start. It had a weird problem. It was not clear what the requirements were, the UX was not final and there was a lot of learning and experimentation along the way. Simply put, the product was revolutionary and not evolutionary. It was unlike all the projects I had executed before, which were very clear in requirements and scope and these were evolutionary projects and not radically different from the previous versions of the same product.
Having spent my entire career writing software and developing products, I always knew about Agile.. and so I thought! 🙂
Well, I started reading a lot about Agile and more specifically Scrum. I wanted to make sure I got it right. I wanted to make sure we follow Scrum in its real essence and just not do a lip service.
Scrum Guide, which is like the bible for Scrum (and a very brief one at that) and books from Mike Cohn (extremely indebted to his books) had been very useful. And Jira (from Atlassian) was a excellent tool to implement Scrum for the project team.
I am not going to further dwell into Scrum as a methodology and its related process and tools. Thats not the point of this post. What I realized as we tried Scrum was that, it solved a lot of my problems as a leader of my group.
One of the biggest and worrisome problems was the team getting too silo’ed under the different managers/leaders who report unto me.
Though its not obvious, I could clearly sense that there used be a subtle power struggle in terms of headcount. The manager who had the highest headcount, felt better and powerful, though I, as their boss, did not perceive it that way. In fact, I hated it.
Now this silo’ing of teams by managers has a lot of other side effects, which would suck my time either literally or mentally. When managers had surplus count and less work, I would have to further identify work. Once the work is identified, the work gets further locked down under this manager (with them being resistant to letting their people move). Other scenario is, where a manager with a lesser headcount will crave for more work, so that he/she can further add more headcount.
I am not saying that manager/leaders being so desperate for headcount and work is bad. In fact, it shows that they are willing to take up more challenges and prove that they are worthy of more responsibilities and consequently, a promotion. My problem is with the fine balancing act of not pissing of one his/her peers in the process. The other problem is with the resources getting locked down (kindof permanently) under these managers.
The first thing I did was to separate out the roles for folks who were hands-on (the developers & testers) and the managerial folks.
I pooled in all the hands-on folks into what is called as a Scrum team. As Scrum says, its not good to have Scrum teams which are greater than 12 members. So consequently, I had to break the hands-on group into multiple Scrum teams.
For success of Scrum, I realized that the teams have to be “Self-organized”, which means they have to be empowered in terms of decision making and let on their own. Which means that they needed to be prevented from being wet-nursed by their managers.
It took a lot of messaging on “self-organized teams” and “empowerment” to have these teams step up and take responsibility of the work that comes their way. The other thing that I did was to break the virtual silos that I kind of sensed in the Scrum teams. I could notice that initial Scrum teams were comprised of the same team members (mostly) who were reporting to a particular manager under me. So as we moved forward with the sprints, I thoroughly mixed up the teams to make sure there were no virtual silos.
The managerial folks were given the task of being the pseudo-product owners, interacting with the actual product owners to understand the requirements and translating them in User Stories for consumption by the Scrum team.
The managers, now having a more outward facing role, which was putting them closer to the business folks, were enjoying it. Also, since none of the managers had folks reporting them (in terms of responsibility) they were are okay and that they did not see headcount being a criteria for success. I could sense these managers being more relaxed and happier in their new role.
Now silo-busting effects of Scrum is much more wider. For example, the devs and testers are working together like never before. The client and server folks are doing the same. If I further zoom out, I can see that the product owners (folks who pass down the requirements), the UX folks and the Dev team (such as mine) are working together seamlessly. Wow!!
The next thing I could notice in the Scrum setup was that the productivity was off the roof. With the silos having gone and the teams expected to be “self-organizing”, they decide as a team as to who works on what User Stories. The only thing that matters to a Scrum team is whether or not they are succeeding as a team. Individual success and heroism is not recognized nor encouraged. No more were there pockets of productivity locked down.
I could sense the same with the managerial folks who took up a more outward facing role. Having been relieved of work-breakdown and team management responsiblities, they were more focused in terms of making progress and getting results.
The other thing I noticed is that there was a strong sense of bonding both within the Scrum teams and the psuedo-product owner team (comprising of the senior/managerial folks).
I guess, since they were not restricted by any silos and with the overall team success driving them, there was a sense of group success and celebration.
Similarly for the folks who were acting as psuedo-product owners, they enter into Sprint planning/review meetings as single team.
I could sense a strong sense of camaraderie within teams during such meetings. During intense debates I could see the Scrum teams (handson folks) and the Psuedo-Product Owners sitting across each other and supporting their team’s point of view. I love such sights.
Responsibility & Visibility:
The team members were taking up bigger responsibilities. For example, the work-breakdown which was managers’ responsibility in the earlier setup, was now being taken over by the members of the Scrum team. Similarly, folks who were really junior and who were 2 or more layers below, in the organizational hierarchy, were taking part in Sprint Planning & Review meetings that gave them a lot of visibility to requirements (when User Stories are being explained by psuedo-product owners). It also gave them the opportunity to present their work to their team as well as the psuedo-product owners (which comprises of their managers/senior folks, who would still have a say during the performance management cycle).
This is hard to explain, but overall I can say that folks are a lot happier because of the clarity, transparency, working-togetherness and absence of organizational overlaps/politics. The team is completely focused on the product and are in lock-steps, proceeding towards their goal.
There is also scope for some serious research from an “organizational behavior” perspective. I am able to relate how Scrum solves the very problems that lead to poor organizational health. I may have touched some of them above and there could be more.
Scrum has been designed intelligently and I really appreciate it’s authors. Its been an insightful experience all along and the journey is continuing. I will probably refine this post as my insights and experience expand.