About 20 years back, I was a hardcore developer. My focus was on technology and I didn’t put in much effort in understanding the holistic view of the project or how the requirements benefitted customers. I was the technical lead on the Asset Discovery Management product (This product is used for analysing the hardware details and software applications running on the hardware).
Generally, requirements used to come in the form of documents, I used to immediately work on converting it into code or coming up with technical solutions without bothering how this requirement is helpful to the customer. The product I was working on was used by different clients for different purposes. One of the client’s field personnel was using our product/tool to address their client’s problems. They were using our tool for discovering software assets running on the hardware and checking the feasibility of moving resources to the virtual environment. Clients had lots of challenges in using the discovered data from our tool. Since end-user (field people) were facing issues, my Manager encouraged me to go to the field and work with the field personnel.
That was my first close interaction with the end-user. Our tool had lots of limitations in reporting the discovered asset data due to which clients were facing some issues. That was the first time I understood the real intent, how the product serves the end-user. From then onwards I started to envision how the product will serve the end-user and I started enhancing my product domain knowledge. Later, I collaborated with field personnel and added an Asset Analysis module into the product.
Agile culture naturally provides a platform for the team to collaborate with customers, operation team, and which in-turn helps to enhance product knowledge and understand customer needs. In traditional project management, managers (particularly the middle management layer) spend most of their energy in managing people, monitoring, and tracking progress. If every employee contemplates from the customer perspective, it reduces lots of effort spent by managers in monitoring and managing teams. They can focus their energy and time on setting the direction and sharing vision. Automatically, organization culture shifts to outcomes rather than focusing on effort spent by team / office hours. This helps to remove the heavyweight off middle management’s shoulders. Agile culture greatly enhances the customer perspective of product development teams
I’d like to share another experience which highlights the importance of management to allow sufficient time for attitude adjustments. As part of the agile transformation from traditional project management culture, our organization arranged for SCRUM training for our teams. The bad part was, in the training we learned only about agile practices but not the underlying values and principles behind these practices. The team strictly followed agile ceremonies like daily stand-up, planning meetings, retrospectives, sprint demo. Since team and managers had a traditional project management background, this led to lots of anti-patterns like blame games, conflicts. Under stress, people fell back into old patterns of taking charge and telling people what to do.
However Agile coaches as change agents played a key role in coaching and mentoring the team. Based on coaching/mentoring, some people switched to agile culture immediately and for some, it was a challenge as there was an adjustment required in attitude. It took nearly two years to build an agile culture in the organization. The point I am making here is – the organization should have lots of patience and needs to allow sufficient time as attitude adjustments are a slow process. When organization starts initiatives to enhance employee thinking from customer perspective, they can’t expect perfection in all employees from day one. The going can be considered good, as long as employees are moving in the right direction
The retrospective is one more pivotal platform that helped us to build the culture change in our organization. Having a retrospective forces teams to come up with what went well and what could be improved. In addition to this, once in two or three sprints, senior management needs to give themes to retrospect for all the agile teams like: produce more versus quality, reasons for velocity variation / prediction issues, challenges in requirement understanding, service as a differentiator. Since action items coming from retros are identified by employees, there will be automatic buy in from them and the chance for cultural changes coming into effect will be high.
Look back and assess, take learnings into account for upcoming days. This made me keep changing and moving in right direction and cultivate the agile mindset.