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.

The Wild West of Mobile Governance

With many years of network infrastructure experience and evolution behind us, the networks and workstations within most organizations are pretty well standardized. It’s a different story for mobile devices and especially tablets, where the landscape could be aptly described as a lawless wild west.

The Aberdeen Group just published a study called Enterprise Mobility Management 2011: Mobility Becomes Core IT that show dramatic gaps in IT governance with smart devices in general and tablets specifically have been approached from an “adopt now - manage later” philosophy.

Here are some industry averages of companies that have implemented basic security features which in my opinion depicts a frenzied adoption of mobile technologies in lieu of an IT infrastructure to support them:

• Lock and Wipe Capabilities: Smartphones 56%, Tablets 22%
  
• Two Factor User Authentication: Smartphone 29%, Tablets 22%
  
• Data Encryption of Removable Media: Smartphones 26%, Tablets 12%

These data are unbelievable. In the Aberdeen paper, the best in class data are at points significantly better than industry averages but certainly still unacceptable. The laggards are abhorrently bad in their adoption of many of the most basic security features.

As software developers, we should view the rapid - and apparently reckless - adoption of tablets as a precursor to an imminent explosion of mobile development internally within each of our organizations.

We are entering an era unlike any that has ever been seen. One that will make the Internet boom look tame and uneventful. Interestingly, all the development we’ve done in the past has prepared us well for this moment in time. The mobile platform is not nearly as challenging as when the Internet was introduced to us.

The difference maker this time around is having a creative workforce with a vision of how a mobile workforce is different than the status quo and what tools are required to leverage their nearly ubiquitous connectivity.

How Does Your App Dev/Support IT Budget Compare to Industry Averages?

The Gartner Group has done a great job with compiling data related to industry averages for application development and support. Those industry averages are also sliced and diced by vertical.

Industry averages do not indicate best practices or imply the sweet spot for spending for application development resources; they are merely averages for how your peers are balancing resources.

Anyway, here are some interesting stats compiled by the Gartner Group in 2010. There are lots more to go along with these and you can get them here. Do you know how your organization stacks up against your peers and the IT teams in general?

• IT Spend Distribution
  • 34% of IT spend goes to application development and support resources. 83% of that spend is towards personnel, of which 60% are programmers.
  • Of the IT budget for application development and support, 52% goes towards application development and 48% goes towards application support.
• Personnel and Work Distribution
  • 37% of IT staff is dedicated to application development and support
  • 53% of the work distributed to application development support goes to development projects with the balance towards support.
  • Work distribution aligned to the SDLC breaks out to 27% requirements/design, 26% development, 32% testing, and the balance being PM and other admin functions.
• Development Methodology
• Surprisingly, only 14% of organizations consider themselves to be Agile shops. However, there are an additional 31% that use some form of iterative development.
• Believe it or not, Waterfall is still king with 55% of organization using that methodology.

Why Wireframing Should be a Required Activity

The overwhelming majority of users we deal with are non-technical and visual learners. As a result, requirements documents that are heavy on narrative are a poor conduit to understanding the way in which users will interact with a proposed application. By visually manifesting the application prior to development, wireframes put everyone in the best position to win.

Here’s my anecdotal allegory of the problem with requirements documents. When distributing a requirements document, if there are six business users in the room there are probably four that have read the document and two that understand it. Of the two who have understood the document, each of them is imagining a different application in their mind’s eye. It’s not their fault. This stuff isn’t what they do for living and when they become involved it’s on top of their normal day job.

Wireframes replace the written word with visual manifestations of the screens/pages. From a users perspective (an even from our respective) they are significantly easier to understand than dozens of pages of narrative. Software developers and business users live in different worlds and often think very differently. Wireframes help to bridge that gap through pictures that represent a common understanding of functionality. Because wireframes are a visual representation of the application, everyone in the room leaves with the same understanding of what will be developed.

Wireframes should be developed either alongside requirements documents or in lieu of them. They should also be developed deeply and completely to the point where the development team can state at the end of the wireframing sessions:

“This is what we are building – no more and no less. If we are forgetting a feature and it needs to be added later it will likely effect the schedule and budget.”

From my experience, when the wireframing sessions are done well and are complete, change orders are almost never disputed. Don’t get the wrong idea, however, that wireframes result in everyone living happily ever after. Change orders, regardless of whether disputed or not, still frequently cause frustration and require negotiations with scope, schedule, and/or budget.

It’s amazing how often what seems to make sense in thought and speech requires modification once manifested on screen. Wireframes help to alleviate, but not eliminate, this affect. Needless to say, virtually every project succumbs to Humphrey’s Requirements Uncertainty Principle which states:

“For a new software system, the requirements will not be completely known until after the users have used it.”

Wireframes also help to uncover hidden business rules. We all take what we know as professionals for granted and sometimes inadvertently omit information from those with less experience than ourselves. When the development team is discussing the need for each page, workflow, control, validation rule, et al it’s a natural process to hit upon each of the business reasons and processes and discuss them in detail.

Wireframing also helps with estimating projects. I’ve mentioned in previous posts about the inherent problem with estimating software projects. A good example of how badly human beings are at estimating is a statistic from “Demystifying the Black Art of Estimation” by Steve McConnell that most estimates are actually 30% of the actual level of effort. With that kind of epidemic of over-optimism, the clearer we, and the business users, can visualize the application – the better.

Once the wireframes are developed, a finer grained estimate is possible than prior to the wireframes. Each page and feature is able to be enumerated, sized and prioritized. Any prior estimates should be validated against the new information provided by the wireframes.

Wireframing the application doesn’t eliminate documentation. Things like complex business processes still need to be codified.

Wireframes, however, do a better job than requirements documents at articulating for what purposes users need to use a system and the most efficient way in which to use it.