Agile Leadership and Coaching (Development Manager’s Need to grow up!)
With modern business needs changing at a rapid pace, software development must respond in tandem. Agile Development Methodologies promote responding to change, by balancing order and chaos. This is an art form more than it is a practice. All too often have I chatted with development managers who have attempted to enact agile, only to fail. Is it the methodologies fault or a fault in leadership and understanding?
Veteran development managers that are accustomed to traditional software development models must be willing to learn a new art form of leadership. That which cultivates innovation, cooperation, dedication, self sacrifice, humility and above all teamwork. These soft skills while simple in context prove to be intangible to the majority of development leadership that I meet. This post is meant to gain greater insight into cultivating these soft skills.
“It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change.” Darwin, The Origin of Species
I know that most of you have read the Agile Manifesto but it is important to reiterate and reflect upon in your day to day activities. It is the foundation and backbone that cultivates the team into one organic structure that you as a development manager must be held accountable for maintaining and persisting.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
If you focus of the left side of manifesto you will notice it focuses on the people dynamic of software development. Why is this important? I will reiterate “They focus on the people dynamic of software development.” People! We as human beings have lost all touch with the reality of who we are. Most of us are selfish, egocentric elitists who have zero compassion for others. The primary focus is how can I attain more and trample on others that get in the way. I like to refer to us as the “Me Generation.” And going to church every Sunday does not take you out of this league. As usual, I digress.
The people element of the equation is the most complex ingredient to deal with in agile development teams. Your people are your team. Your team is your people. Just like in object oriented development since the Manager is a derived class of a person (team member) you inherit all the emotional nuances of your team. Their behavior, psychology, feelings, relationships, personalities, all become part of your overall structure of influence.
As technologist we are bombarded by PDAs, email, cell phones, wiki’s, forums etc. The point I am trying to make is that we have taken people out of the equation. We hide behind our electronic creations as a means of communication. The safeguard in knowing that the receipt of an email or the acceptance of a phone call sparks understanding of our intentions or idea, only to be followed up by a responsorial email indicating the perceived acknowledgment of intent. Laymen translation, we are too lazy to walk over to individuals strike up a conversation and discuss and expound upon an idea or concept together and together agree upon direction and vision.
In traditional software development, the development manager performs more of a task master role. They insure that the project is delivered on time by delegating development task to individuals. These tasks are usually governed by a project plan of some kind that are held by fixed dates that are rarely discussed or agreed upon with the development manager. The development manager must do their best to insure that the work is accomplished, while at the same time dealing with schedule changes, requirement changes and the ever imposing technical debt that is building because of the deluge of change that they are being bombarded with.
The development managers have the best intentions of trying to maintain the breath of exposure for all the developers under them in relation to the problem domain. They delegate task to competent individuals thus creating expert silos of information. Envy and discord encroaches upon the team as each member becomes boxed into their constructs. Dialog begins to breakdown and is replaced with requirements documentation and technical specification documents. Each developer acts as an island uttering phrases such as “It was working fine until they changed UI”. Through some miracle these projects manage to get off the ground and into production but there is a lot of blood sweat and not to mention known instability that goes along with it.
If the preceding two paragraphs struck a chord, rest assured you are not alone. You know that your job is more than a task master. You have told yourself countless times that the next project will be different but somehow you fall back into the same routine. Is this a programmed conditional response based on your years of experience with software development? Where you mentored by someone who simply fell in line with the status quos and this is all that they were able to convey? Possibly. Is there an alternative? Yes, but it is going to take communication, courage, respect and above all humility.
The following are a checklist of qualities that an Agile Development manager must have.
1. You have to be a developer yourself. If you don’t know how to code don’t manage developers period!!!! And knowing COBOL doesn’t count!
This aspect alone is hard to grasp for the seasoned development manager. Most development managers that I meet contest that managing developers does not mean you have to know how to code, all you need is basic project management skills and understanding of how the code is being constructed at a high-level. Rubish! Take some pride in your skills. You are here because of the code not the other way around. Your team and the code they create reflect on who you are as a leader. They will look to you to set guidance and standards. They will trust you to be their advocate for what they are creating. They will trust that you are keeping their best interest at hand. The only way you can do this is have an understanding of why it is difficult to create modern object oriented systems. Don’t assume that just because Microsoft demos a grid being plopped on a webpage and simply binding it directly to a SQL table is all it takes to create great software. Get the training, READ, CODE!!!!
2. You have to manage the team not the individuals. Think of yourself more as a coach not a manager. Maximize your assets by understanding your team’s weakness and strengths.
The best analogy I can give you is sports. Understanding the skill set of your team is crucial to the success of the team. Imagine if you were playing football with just 8 players. Each player would have to play both defense and offence. Some players will be stronger on offence then they are on defense and vice versa. Have your player’s pair with each other. Allow them to strengthen each other organically. Remember you are the coach. Your job is to give the players the play and then they execute and do what they do best, code! They will correct each other. If it gets too out of hand then you inject yourself and get them back on track. Don’t be afraid to call a timeout!
3. If you have mediocre programmers (first off yikes!) second as long as they show a willingness to learn, paired programming is the key to success for bringing the juniors up to par with the seniors.
Every member of an agile development team must be willing not only to act as the mentor but also as the mentee. Don’t be afraid to get your own hands dirty. Like any other craft the less you practice the more rusty you will become, you will never know everything but the collective of the team is pretty close. Use them to mentor you on areas of concern. Understand their pain and difficulty. How else can you make the correct course corrections?
4. Empowerment, allow EVERYONE to take ownership of stories and task. If a junior wants to take on a story or task let him/her role with it. Your TDD practices along with the pressure from their peers will make certain it is done correctly.
Ever fumbled the ball playing football? I am sure your team wasn’t too happy with you and you made certain not to do it again. The team will self correct themselves. This is probably the most rewarding part of being an Agile Development Manager. You don’t have to worry about the little things anymore the team usually takes care of it for you.
5. Embrace the fact that your team need to understand their goals! What they are playing for? What is the goal for the week (Velocity, Stories)?
Setting goals does not mean micro manage! Setting goals does not mean micro manage! I think I said that enough. Your job as a manager has not changed. You must still set goals that are measurable and attainable. The difference is that you don’t do it with individuals you set the goal for the entire team. Some Agile concepts for doing this is are Iteration Velocity, and prioritized product owner backlog.
6. They need a way to measure and understand if it is first and ten or fourth and twenty?
Your team needs to know the overall progress of the game. Are they winning are they losing? When is it going to be halftime? Information radiators coupled with a good agile project management tool such as Target Process, RallyDev or even XPlanner can help with this.
7. Coach them every day!
Think of your daily standup as halftime locker room pep talk. If they are behind you need to pep them up help them understand why the defense is getting clobbered or why the offence can’t score. If they are ahead you need to continue with the positive motivation.
8. Get rid of your heroes or code hogs!!!!
You know who they are the ones that always want the ball, who yell at the other players for not doing what they want. Usually this personality starts to create dissention amongst the team members and doesn’t listen or adhere to any guidance and direction that you give them. They are there for their own personal glory and do not care for the team concept. They are a cancer and must be removed.
The information that I have shared with you here is both controversial and subjective but as all truth, it usually is. Development managers must realize that their traditional approaches just will not work in an agile development environment. It time to go back to basics and rely upon leadership, enthusiasm and above all humility. You are the leader of your team. You are the captain that has been appointed to lead them into battle. Rely on your greatest strength, your team and all your battles will be victorious!