Development Managers in Agile

To understand the role of a development manager in Agile, we must first understand the difference between management and leadership.

The goal of management is to attain perfection in its processes in an effort to maximize productivity. The goal of leadership is to be an agent for change in an effort to maximize organizational sustainability through innovation and adaptability.

Although they are counteracting forces they are both required to be successful. It is as important to get things done efficiently as it is to innovate and adapt.

So how should leadership and management manifest themselves in an Agile-based organization?

From a management perspective, Agile assigns management roles through clear delineation of authority between the Agile roles, i.e. Product Owner, ScrumMaster, and Team.

Leadership is an implied attribute in Agile. Agile consciously acceptances that much of what we believe to be true will prove to be either fundamentally flawed, or, will become flawed because of real-world change. Since change is inevitable, leadership is a universal trait that is necessary for Agile entities to be successful.

A leader is often characterized as a charismatic and/or visionary manager. As I mentioned in my previous blog post, that is because most organizations are autocratic in nature and thus leaders are part the management tier.

Agile is not autocratic. There is no hierarchy. As part of this structure, it is intended that leaders emerge and assert themselves as part of the process of getting things done. This also means that leadership resides in each of the three Agile roles in a quantity that is not assigned or dictated but emerges according to need.

So if Agile groups are not hierarchical and leaders emerge naturally, then what is the role of the development manager?

The job of a development manager in an Agile organization is to promote both leadership and management; to value both within the organization; and to empower both to grow and change organically through the Agile principles. If it sounds like a development manager is more leader than manager - you are right.

I'm sure as you read this, many of you recognize command-and-control (autocracy) as a significant attribute within your workplace. Through your commitment to Agile principles, you are provided the opportunity of implementing the aforementioned organizational model - if not throughout your organization, then as a model for your organization.

Self-Managing Teams, Adaptability and Innovation

Technological advancements and the global economy has made innovation and adaptability a critical component for sustainability. Thus we need to push our conventional management model into antiquity and move towards the more dynamic model of self-managing teams.

As we all know, Agile promotes the concept of self-managing teams. This concept has been gaining steam recently but has actually been around for quite some time. W.L. Gore, for example, has been organized around self-managing teams since 1958.

Let’s start with what we have today and how we got here.

Top-down leadership is the prevalent model in most organizations and is ingrained in most of our thinking and behaviors. The current autocratic nature of management was introduced during the industrial revolution. Its ability to churn out vast quantities of manufactured goods is undeniable. Its primary limitation in today’s business climate is that it requires that a select few contain the wisdom, vision, and authority - and the masses execute the plan. This is great for repetitive tasks but less so for innovation and adaptability.

Just as it is irrational to think that we can plan the development of software up front and rigidly adhere to and execute the plan – as if change isn’t going to happen - so too is it delusional to think that adaptability and innovation is borne out of autocracies and bureaucracies.

Innovations are not planned or commanded into existence. Instead, innovations are developed serendipitously. We search for one thing and unexpectedly find another. We need to structure our organizations in a way that promotes the manifestation of the unforeseen.

As with all things, we must make compromises when changing from one management model to another. As Gary Hamel so aptly puts it in his book The Future of Management:

“You can build a company that is virtually error and mistake free. You can build a company that is highly adaptable. But you can’t do both. In this sense, perfection is the enemy of progress”

If I sound like an anarchist who thinks there’s no room for authority, I assure you I am far from it. Leadership is always needed and always sought out. I believe in authority too. I just think that it is ineffectively distributed in the conventional management model.

The requirements for managers in the contemporary world in which we compete are:

• Leading by pushing authority, accountability, and reward to small front line teams.
• Leading by creating an environment that allows for experimentation, collaboration, and not only self-managing but self-organizing teams.

These steps will encourage creativity, passion, and a sense of community and mission – all of which are ingredients for a dynamic, adaptable and innovative workplace. A workplace built to compete in the 21st century.

Distributed Scrum - Integrating Offshore Resources

Tranistioning to distributed scrum with offshore resources is hard. It requires significant change in the way teams are run and how members interact. There is also potential for dramatic improvement with productivity and ROI in general.

There are plenty of articles written about offshoring projects, significantly less written on distributed teams, and a trivial amount written on distributed scrum with oursourced and offshore teams.

In my view, the best option when working with offshore resources is distributed scrum. I have faith in Agile as a framework for development. With all of the risks associated with software engineering and the added complexity of team members distributed across the planet, I want control over how projects are executed and the emphasis on continuous improvement.

With that said, here are a few things to consider when considering distributed scrum with offshore resources:

Team and Agreement Structure

• Limit resource distribution: The more distributed the team the more complex the work becomes. Limit the distribution of resources as much as possible.
• Aim for long-term partnership: When you find the right partner, don't be afraid of arranging a long-term partnership, e.g. 1-2+ years. This allows for you and your outsourcer to concentrate on team building and continuous improvement without distraction of the next agreement. This does not preclude a 30-90 day exit strategy built into the contract if the partnership goes south.
• Measurable results: I'm on the fence with this one. It is common to insert milestone-based payments based on deliverables. This is common for any project that is completely outsourced regardless of whether it is software, buildings, etc. But in this structure, any performance incentive is more akin to a performance-based bonus for employees. I keep harkening back to a book I read by B.F. Skinner where he postulated that most incentives are actually disincentives. Agile principles, when adopted fully, make it clear when resources, or outsourcers for that matter, are failing. Payment schemes typically provide incentive to maximize financial reward not necessarily maximizing productivity and effectiveness.

Build a rapport with your outsourcing partner

• Stay close at the executive level: The best situation is one where you have access to the executive level of the outsourcer. When you really need something done, you want to be able to reach out at the highest levels.
• Find a true partner: It's important that your offshore partner be your business partner too. The organization that you choose should be an advocate for your vision.
• Trade players for a few weeks: It cannot be overstated how important it is that the team members get to know one another on a personal level. The affect on a team when dispartely located people finally meet each other face to face and work together for a period of time is stunning.
• Maximize overlapping working hours: Both sides should help to extend the overlapping work hours in a day. It's easy to say "your my vendor, you should bend to my wishes". Altough yoru oursourcer may acquiesce, you should expect more to get accomplished when both sides are engaged and working together to solve this particular proximity problem.

Expect Proficient Communication

• One language: Pick a single language for communication and make sure everyone one on the team speaks it well. Seems obvious but I've heard of translators being hired to bridge language barriers. With that said, don't be afraid to learn a few words and phrases in their native language. It will help to add character and color to the team.
• Good communication skills - Communication is more than language, it's also proactively alerting the team of potential problems, sharing knowledge, willingness to disagree, recommending improvements, etc. As with onshore resources, have high standards with each person's ability to communicate effectively.
• Video conference: For good reasons, we don't conduct telephone meetings when everyone is in the office. As humans, we prefer in person conversation. It is important to emulate the behaviour of colocation and video conferencing is the next best thing to holograms. It's a bit awkward at first but becomes very comfortable very quickly.

Treat Offshore Resources Like Employees

• Expect profient professionals: Just as with colocated permanent employees, look forward to the right balance of intelligence, creativity, passion, dedication, and all of the other traits we look for when adding to our teams. Don't lower your standards!
• Fit people to jobs: The best team is made up of people who are in positions that accentuate their strengths and marginalize their weaknesses.
• Career pathing and mentoring: Check-in with your offshore team mates to make sure they are experiencing job satisfaction. Provide mentoring to advance their careers and expertise. Just as with colocated permanent employees, this helps to build a stronger team.
• Work/life balance: Expect that your offshore resources have families and lives outside of work.

Be Patient

• Coalescing a team takes time: It takes longer for distributed teams, especially when they are offshore vendors, to coalesce. Many people on the team were hired not by you but by your vendor. Don't underestimate this obstacle. Team building is hard enough when everyone works for the same company and is in the same building. This structure is orders of magnitude more complex.
• Encourage coalescence: Agile is inherently one of the best methods of coalescing a team. Let that process of direct communication happen naturally. Assuming good quality team members, the only obstacle is you if you act as a proxy between team members.
• Facilitation is key: There will be a lot of change immediately and stability can feel very far off. The person who is in charge of building and motivating the team must have good facilitation skills.

Yes, there is risk and some parts of this are down right scary. But don't lose site of the fact that distributed srum work. When it does, most organizations will find themselves fundamentally stronger than they were before.