In my previous post, I proposed that the True Value of Agile is derived from fostering an environment of Continuous Improvement through Communication and Collaboration. To be sure, Communication and Collaboration alone will not bring success. As Vin D’Amico (www.brainslink.com) commented, a critical component to Agile Value and success is a shift in corporate culture to support an environment that encourages risk taking and refrains from seeking to assign blame on any individual when things go awry.   The challenge here is that this goes against most traditional Western, and Asian, cultures for that matter.   In order to improve we must identify what we do well as well as what needs to be addressed. Sometimes finding a better way requires taking the risk to do something no one has thought of before. That does not always lead to success; however, it provides an opportunity for learning and growth. In “Agile,” teams we do not work and make decisions in isolation only to be the single “neck in the noose.” To be an effective Agile team there is no “You” and there is no “Me”, and definitely no “Them.” To be successful the group must live and die as a team.

I am not suggesting Agile teams are like hippie communes, but there are similarities (remember that Steve Jobs lived in a commune before his 15 minutes of fame). Everyone works for the greater good, which is moving the product forward and delivering business value. There is much work to be done and defined timeframes in which to do it. We have tools, and skills, and ideas about how best to complete those tasks. We are jacks of all trades and masters of a few, not one. Effective agile development teams are made up of generalizing specialists. It is this cross-training that helps mitigate singled threaded development as well as unforeseen events that may remove someone from the team for a period of time such as attrition or illness. Once we have our list of work items, which becomes our product backlog, we are able to self-select which tasks we can commit to completing. This is another shift in culture. Traditionally, work is assigned by management to the individual specialists. In an Agile culture the people performing the work are trusted to know best how to distribute the load so that they can successfully meet their commitments and provide value quickly. There should always be something for everyone to do to move forward.  To this end, no one should be waiting for work.

We are not alone in our agile commune either. The business product owner is there with us, every day, to prioritize and test, and yes, re-prioritize and add or defer features based on our velocity and changes in scope. This is not normal for the business owner in relationship to traditional requirements planning for software development.   The scrum master, our servant leader, is also with the team, every day, to work with the product owner to find the most valuable work that can be reasonably fit into the sprint. The scrum master is a servant leader in that it is this role that both serves the needs of the development team to remove obstacles, and provide whatever is necessary for the team to be successful and at the same time leads the team by working as a bridge between the product owner and the team, working on the backlog and the schedule. The dynamic is not unlike an orchestra. The Product Owner is the composer. The scrum master is the conductor, and the members of the development team are the musicians.

What I have described is contrary to most traditional organizations where the business and IT only communicate at the beginning and the end of the project, where divided IT teams are comprised of specialists like a relay team that wait on each other to pass the baton. We need to be more like a volleyball team who work together and support each other to move that ball over the net in the most effective way possible.

Changing corporate culture where failure is treated as a cardinal sin to one where it is addressed, reviewed and used as a learning point is challenging and requires buy-in from all levels of the organization. These concepts are taught in Agile training courses; however, they are not often embraced and supported by corporate management culture. The folks sent to class are typically the developers and the project managers, but rarely the upper management and business sponsors that play a key role in making “Agile” successful.

To achieve the true value of agile we must all work together for the greater good of the company by creating and supporting a nurturing environment of continuous improvement and stop pointing fingers.


0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *