Sunday, January 26, 2014

Starting with Teams Requires Fixing the System

Being a part of Agile transformations since 2001 I have listened to and participated in several discussions about teams vs system changes. However, I am not sure these two things in and of themselves are different. If you start with teams, as most Scrum and XP transformations do, it is a system change in many organizations. Teams don't just magically happen because you put people together and tell them to self organize many changes to the system must take place.

Teams that stay together will be an early system change for an agile development environment to succeed. Quite often, this means financing has to change. Financing happens for projects and long term teams that last for the lifetime of a product or service is a system change that is likely to be met with resistance. Budgets are made to support x number of people for y number of months to deliver scope z. An organization must ask how is it going to maintain that software? How are we going to adapt that software to changing needs of it's customers? Who is likely to be most effective at maintaining that software, those who created or the junior maintenance team?

Teams that are cross functional are required in order to complete work every two weeks or less and is likely to run into several system issues. Teams in many organizations are dependent on design decisions from people outside the team, such as technical leads and architects in a global architecture team. Their ability to make decisions are slowed by late reviews and feedback leading to incomplete work each iteration. Teams in many organizations rely on a long lists of specialists such as architects, technical leads, database specialists and official build and deployments teams just to lists a few. The system will have to change to allow the team to do builds at will and deploy them to different environments. An organization will need to trust teams to build the software in a consistent manner? They will need to overcome the resistance of those teams currently doing that effort trying to protect the perceived loss of responsibility and the fear of losing their jobs. They will need to solve the problem of global architecture concerns and shared direction among teams that deploy into common environments while allowing the team to learn and adjust to the needs of the customer. All very difficult system changes.

After cross functional team are created it becomes clear that further improvement will require reducing the frequency that specialists are needed. This will again require a system change that requires overcoming fear of losing control and influence from those specialists. The benefits are good for everyone as each person gains a broader set of skill the organization becomes more agile. However, this apparent loss of control and influence is difficult to overcome in most organizations.

Teams that are focused on value versus projects focused on fixed budget and scope is another system change that is required in many organizations. Traditional systems are setup to expect a fixed budget and scope setup in advance. Agile says fix the teams and the budget and adjusts the scope to adapt to current needs and learning. The system will fight against and undermine the team making good decisions if it is not changed. An organization must honestly ask itself, with my fixed budget and scope projects in the past, did I get the things I wanted, needed or even originally planned? If not why? How long did we spend in discovery and analysis? When did we learn the most information that disagreed with our original assumptions? What do we do that really does have a fixed dates, such as compliance requirements, and how much of our work consists of these true fixed dates? Is software changes the only way to meet those fixed dates? This type of openness and honesty is also a system change in most organizations.

Teams that deliver as often as possible versus those who hand over testing at the end with n cycles of bug fixes is also a system change. Most organizations do not believe it is possible to deliver quality software quickly. Their experience likely backs up the assumption that software is very buggy early on. They may never have experienced a team that is focused on high quality rapid delivery, a team that is automating most or all normal checks of the system freeing time to dig deeper into possible limits of the system, a team that is collaborating so closely that all parts of the organization know what is being delivered and understand each direction change. They have experienced miscommunication, lack of trust and finger pointing between product, project management, development, testing, marketing and sales to look for who is to blame for the latest failed project. My experience says this trust is very difficult to overcome and will hinder teams until they can get quite a few wins under them. Wins that the system is, unintentionally, fighting against.

Teams are a system change in most organizations. Teams are not an evolutionary system change that you get in a Kanban environment, instead they are a chosen from the beginning system change that will bring fear and disruption. Don't fool yourself that you can start with teams and wait on system changes later. Creating teams will point out and magnify each of the systemic issues before teams become effective at delivering quality software. Start dealing with these issues before you create teams or you will likely lose many of the people who have the most knowledge and experience about the system and can help you fix those issues.