So folks! You should be well aware now about the elementary Agile adoption in your organization. But it is just getting to the first base of successful Agile implementation in an organization.
Please have a look at the articles we covered till now in this ‘Successful Agile implementation‘ series.
Agile has the capability to spread across all the fronts of software development and delivery. It has been built to have deep roots within the management framework. And to achieve this expansion and depth, there has to be a continuous improvement approachand an ongoing journey towards Agile implementation.
In this article, I shall list down some necessary ingredients to take with you on this voyage, the milestones and the guidelines to help you keep advancing safely in a right direction.
As this is a prolonged subject and includes multiple complexities and challenges of Agile, it is fragmented into two segments.
The pilot testing
Just as Agile preaches about the “Minimum Viable Product” and “Iterative development”, it follows the same rule for its own implementation.
There is a famous proverb that “He who chases two rabbits will catch neither”.
Trying to make Agile work in a project is as challenging as trying to catch a rabbit especially if you are in a transition from another process. So, it’s better not to be over ambitious initially and try catching two rabbits simultaneously. You have to experiment with a small chunk, which may be a small product or a module, as a pilot.
Experimentation, learning and iterations are such an integral part of every process that it’s implicit but it is equally significant to be explicated as a necessary ingredient of successful agile implementation. We needed to have a success story to get going andconvince everyone within the organization about Agile importancewithin our context.
Secondly, by starting with simpler and smaller teams and products, it was rather easy to diagnose the issues and rectify them early. So, ultimately we developed and customized certain practices in couple of months to try out in other products.
Figure 1
Reinforcement
“Excellence is not an act but a habit”, says Aristotle.
It is relatively easy to do it right the first time with a simpler product and a smaller team without many expectations and high level of energy to focus on the process. It is appreciable but does not qualify to be called “Excellence”.
Interestingly, it becomes more challenging when we try to reinforce the same effectiveness and value repeatedly. Management doesn’t expect you to make mistakes all the time in the name of learning. So, the pressure to do it right is always building up.
Another problem is the potential of repeating the same practices and solutions for newer problems that need a different solution. Soon, you might realize that it’s even difficult to unlearn something than to learn it. So, you might end up treating every problem like a nail just because you had got a hammer.
The objective of identifying the “Reinforcement issue” is not to discourage you to utilize your experience. Rather, it is to motivate you for more learning with unlearning and re-learning embedded in the learning process. You cannot take it for granted doing it second time just because you have accomplished the similar before.
You have to be more mindful and put-in even more effort to get it right second time and so on. The best way to reinforce is throughRetrospectives.
My personal observation is that teams and even the process engineers are too lazy to do the retrospectives. It is considered as the secondary or an optional practice which is implemented conditionally with having enough time but getting an input from the team and looking to make it better is the only way to make it sustainable.
Figure 2
Pragmatism
The worst mistake an Agile practitioner can do is an attempt to standardize the practices across different teams. Unfortunately, it is the most common mistake found among the Agile practitioners inspired from the standardized models like CMMI and ISO which believe in repetition of practices across various projects.
I do not feel ashamed to admit that I was one of those practitioners. I rather take it as a pride to realize it quickly and allow the flexibility in practices among different teams.
With a success story and a model that worked in one of the project, it is a general temptation to replicate it in the other projects. Although it looks good apparently not to change a winning strategy but this approach overlooks a very significant factor i.e. diversity of the team psychologies. While one team prefers certain practice or in a certain way, another might not be at comfort with it. Without teams feeling at home and owning the process, you cannot do any wonders being a process guy.
Figure 3
Team psychologies are most often led by the technical leads’ psychology. They are the opinion leaders. They have their own style of working which reflects in the team to a certain extent.
We recently faced an interesting situation that is worth sharing with the “wanna bees” Agile organizations.
The Problem:
We were following very similar practices among two different products with two different teams having different technical leads, product owners and the team members. Both of the technical leads are regarded as equally competent and committed with their roles. But I started getting feedback from the top management that one of the technical leads does not look in command of the situation and is not as intimately involved with the product as the other lead.
Top management thought that his over-delegation of tasks and taking a back seat is leading to some major design flaws in the application. His experience and skills could have been a major difference in the application architecture and user experience.
When he was inquired about his lack of control on the team and the product itself, he informed us that he was not really happy with the standup and sprint planning meetings and pushed him to be more passive in his leadership.
Since these meetings were attended and dominated by the product manager, who liked to micro manage the team members, he could not break down the PBIs into tasks and follow them up with the developers. He wanted to take the ownership of the technical solution after getting the business requirement from the product owner. Exposing all his team players to the product manager was not a favorable thing for him.
The Solution:
For me, this problem was uncalled for because I had learnt that these meetings are the essential practices of SCRUM methodology. Those meetups are the tools for materializing the concept of team collaboration. However, after some debate with the top management, we came up with the notion that “Process is there to serve people and not the other way round”.
So, if a particular practice is causing a friction among important stakeholders or a loss of ownership sense to a technical lead, we must find an alternate.
On that note, we came up with a fairly customized version of SCRUM for that product. Instead of gathering the whole team along with stake holders for the meetings every day, we decided to meet up with the representatives of all the three functions for daily standups.
------------
Currently, the technical lead represents the developers. I represent testers as a QA lead while product manager represents the product owner. We meet daily where we share the status of each individual of our respective functions and overall team issues and agenda.
Before we gather, we have a look at the tasks statuses of all the team members and discuss with them if required. Sometimes, we even call any of them to inquire about certain task status or a particular assignment during the daily standups. Developers demonstrate their enhancements or new features every week to the whole team and stakeholders. That provides foundation for the sprint planning meeting among three of us the next day.
This customization of the standard SCRUM method might look crazy for someone sitting outside the context and I know some typical Agile lovers might be furious with me for justifying the alteration of something as important as standups and sprint planning but I have mentioned this amendment on purpose.
The point I want to substantiate here is that the teams and the leaders must own the process and the product to its core, even on their own terms. There is price for this in the form of collaboration loss among team members but we have tried to minimize it through other practices. Although the previous strategy worked well in product A but we had to customize it in product B based on team psychology for the time being.
You might well have to change some standard practices of your adopted Agile method in order to make it work. To me, this adaptation is inevitable. Don’t be afraid to be innovative! Create your own tool or a practice right from the scratch if you need it and you are convinced that it will work.
Standardization
Standardization and discipline is as important in the Agile implementation as customization.
Here, I must be looking like self-contradictory and a confused soul to my readers. But actually, it’s not a dichotomy. Rather, it’s a universal rule of keeping the balance between every two extremes.
In this case, it’s all about keeping a balance between pragmatism and standardization. You cannot afford to keep altering the recommended practices and guidelines to infinite level and with unbounded frequency just to make it work for the time being. Similarly, you cannot show rigidity to make the team follow discipline all the time.
Figure 4
Standardization actually becomes essential after customizing a practice or a tool to an acceptable and required level. Like in our case, I have made it mandatory for my team to update their daily tasks before I go for the daily standups representing them.
They have been provided a standard format to list down the tasks and their statuses. And for the technical lead and the product manager, I have allocated a time slot to meet up which should be followed strictly and regularly. Providing further flexibility in the timings or the formats could result in a mess as we had already compromised on a significant collaboration practice of daily meet ups.
Standardization can further be done on an organizational level after product level. We can come up with some golden rules that should be shared across the organization and possibly across the industry.
In order to achieve an organization level standardization, it is advisable to share the good and bad experiences of different teams with certain practices. Being inspired from the other team’s experiences, it should be left at the discretion of the teams (or possibly SCRUM Masters in case if your organization has multiple of them) to adopt them according to their convenience and needs.
At the cost of repeating myself, I want to remind the significance of keeping a balance between pragmatism and standardization, which is an art learnt with time rather than by reading a book or an article.
Defining Roles & Responsibilities
One of the major challenges of Agile based organization is the roles and responsibilities. A typical agile organization has a task culture and the hierarchies are rather flat with task-oriented structure with a lot of flexibility and cross-functionality. It is perfectly compatible with the Agile process.
But the only problem is with the mindsets of individuals and the teams which are in the transition from role based culture. Even within the task culture, they need some boundaries of roles and responsibilities to avoid conflicts and making sure that they are producing what is expected of them. And even if we eliminate the factor of mindset transition, it is not practical to hold the group or a team responsible for each action or its result.
The concepts of “Collective Ownership”, “Self-managed teams” and “Headless units” are good to create an enabling environment but they are more of an underlying philosophy than a hardcore set of practices. There are situations where someone has to be held responsible and accountable for certain tasks and objectives. If we leave everything for “anyone can do it”, there’s a big risk of ending up with actually no one doing it.
A simple conversion of traditional roles to the Agile roles by just changing the titles is a recipe for failure. It is a different framework, so there has to be a change in responsibilities and authorities with different roles. Some roles have standard responsibilities while others are subjected to the organizational context.
For example, in our organization, we decided to follow the SCRUM methodology. It has standard roles of Product owner, SCRUM Master, Technical Lead, Team Members (Developers and Testers) and other stakeholders (product manager, top management, client, vendor etc). We dedicated our existing team members into each of these roles that was closest to the function they were already performing.
Business Analysts were given the charge as product owners, Development team leads were chosen as technical leads and other team members remained intact. I, myself being the initiator of Agile implementation, was given an extra charge of SCRUM Master for taking care of the overall methodology and making sure that it is developed and executed in a right manner.
All the roles were communicated broadly what was expected of them. Product owners were given the responsibility to coordinate with other stakeholders to entertain their needs, views, suggestions and concerns related to the product and plan the priorities and scope of the product accordingly.
No comments:
Post a Comment