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.

Performing a Review of a Software Development Team

I've had several conversations this week about how difficult it is to provide reliable and consistent software development. Whether the team is an internal IT team, a product team, or a team of consultants, software development is rarely a pretty sight. It is sort of inline with the "making sausage" analogy. However, it doesn't have to be ugly so to help I thought I'd provide a checklist of attributes that every development team should consider.

Development Infrastructure

Each developer should be working in a virtual environment. Whether those VMs should live on the users computer or on the network is a debatable point. I believe the environments should live on the network to ensure they reside in the safest place possible. Residing VMs on the network also removes the dependency of a workstation being online.

Each developers’ local version of source code and folder structure should be identical so if someone were to go from developer to developer the location and folder structure would be identical.

There should be an integration environment to which a build is deployed at least once a day automatically. If the build fails the entire teams should be notified. At least one person should get an email when it succeeds. I’ve been in situations when everyone thought the build was succeeding reliably when in actuality the build machine was down. The integration environment should be identical to the production environment, e.g. web server, app server, database server. When the application is deployed it should tear down the servers to a base environment and rebuild it from scratch. At the very least, this environment provides developers with the ability to test their code in an environment that replicates production. Ideally, there should be automated QA testing that happens with each deployment. It doesn’t have to be full regression testing; an automated smoke test goes a long way.

Continuous integration is a must have. Finding out immediately when a developer has broken the build is vital. It’s so much easier to fix issues as they occur than to untangle them weeks after many developers have introduced their own flavors of bugs.

Development Methodology

This one is a big deal to me because I think very few shops actually have a development methodology. My evidence is anecdotal evidence from being a consultant talking with many clients and prospects and through interviewing software engineers. Most profess to having a methodology which turn out to be more of a set of development procedures than a methodology.

One definition of the term methodology is “the methods or organizing principles underlying a particular art, science, or other area of study.” Organizing principles is the key phrase. Organizing principles are more than a set of procedures. Your methodology should be well understood and those using it should evoke confidence that when the going gets rough that your organizing principles will protect you - as long as you stick to them. Abandoning your organizing principles, in whole or in part, when times get tough results in pain for you, your team, your management and your internal/external customers. In other words – everyone.

Estimation Techniques

My own little survival handbook is called “Demystifying the Black Art of Software Estimation” by Steve McConnell. In it, the author states that studies have shown that estimates are, on average, 30% of what the actual level of effort will be. Thus, know that your developers will significantly and consistently underestimate tasks. If you have never read a book on software estimation then it is a must.

The absence of formal estimation techniques could be the biggest failure point in software development. Communicate estimates in the form or ranges not in single values; e.g. 4-6 weeks. Include all the ancillary tasks such as user documentation, technical documentation, project management, etc. When developing the schedule consider vacations and holidays. And lastly, stand strong in the face of resistance from those who want the job done cheaper and/or sooner. You can negotiate rate, features, etc. but you can’t negotiate how long it’s going to take by magically lowering the number of hours and expecting good things to come from it.

Strong Project Management
A project manager, depending on the organization, is either just another resource keeping track of the project plan, or a leadership role on the project. The latter role requires the project manager to be an oracle and captain at the helm and is the one I prefer. “The captain” reference refers to that person as a significant influencer of decisions and direction. The oracle reference  refers to the ability to recognize patterns to identify risks and potential pitfalls. Project management is a combination of art and science. It also requires a strong personality who is willing to give bad news as soon as it is known. This isn’t easy for most people to do and lots shy away from it and futiley hoping things will work out.

Team Composition

We all want the best an brightest. But what’s often overlooked is how the team is composed. Being smart isn’t enough. Your team needs to be filled with smart people who fill specific roles and view the world in a specific way. People can be big picture oriented or not, detail oriented or not, organized or not, ambitious or not, etc. It is vital to architect your teams composition, meaning, defining how many of what types of people you want/need on the team. Teams need a variety of types to be successful. Know what those types are and fill them accordingly.

QA Process

The business should write the test plans and ideally they should be written before development begins. If you are an Agile shop, each user story should have test scenarios. There should be automated QA testing. If there are budget constraints there are free tools out there to leverage (Selenium and NUnit combined with Cruise Control will work fine in most cases).

Stakeholder Roles & Cross Functional Relationships

The business users should be heavily involved. My mantra to customers when negotiating for their time is “the quality of the end product correlates directly with the level of your direct involvement.” Given that they are often making a significant capital expenditure, they tend to get involved to whatever degree they are needed. The reality of the outcome as a result of their involvement, or lack thereof, just needs to be communicated.

Resource roles should be clearly defined at the beginning of the project. There should be no ambiguity with what’s needed from the business users.

Cross functional relationships should be nurtured during and outside of projects. it is important that the business and technical teams know that they are partners and together they will be succeed or fail.

Communication

The glue that hold all of these together individually and as a whole is communication. Everyone should be communicating to everyone often and transparently. When issues occur, make sure everyone knows. I’m not saying that there shouldn’t be a communication protocol. There should be. However, when Engineering disagrees that a bug found by QA is actually a bug, the engineer who developed the feature should have direct access to the QA engineer who logged the bug and the product manager who articulated the feature.

Customers should be involved on a daily basis (with Agile via the daily standup). This makes the weekly status report nothing more than a summary of what the customer already knows. Demo working code frequently to get feedback from the customer. At least one engineer should be in the demo to hear directly from the customer and be able to ask questions accordingly.

Transparency can be scary because we are afraid of the repercussions of allowing the customer to see our problems as they occur. What I’ve found is that customers are reasonable business people who understand the ups and downs of projects. The surprises are what get them angry. Transparency eliminates surprises and keeps everyone in the loop with everything that is happening with the project. Under this umbrella of openness the cross functional team inherently act as a unified team navigating the project towards a mutual success.

Economic Darwinism

Over the summer, I wrote an article in this space called It's Winter in July. The premise being that in these tough economic times everything you've done to this point in your career has culminated to your current market value. This article extends that subject in the form of what I call Economic Darwinism. Surprisingly, my Google searches on the term came up with hits but not in the way that I think of it.

Economic Darwinism in my mind is related to survival of the fittest. We have been in this downturn for over a year and it's been difficult. Lot's of layoffs, attrition, hard looks at the way we do business, and in many cases lots of change.

For the past year or so you have been in survival mode which is a good and healthy process. If you have survived being in survival mode then it likely means that you are built for what you are doing.

When you look around at your respective team members you likely see a strong set of individuals that as a group can deliver whatever needs to be delivered. In a culture of meritocracy, which for the most part describes software engineering, we have been transformed into lean teams with a kick-ass set of players that gets shit done. Yes, it was painful getting to this point, but the result is good.

If that accurately describes your situation, then from a leadership perspective the view should be "The recovery starts with us. The inevitable new phase of growth will be through this team. And through that inevitable growth there are opportunities for everyone."

Morale, whether poor or euphoric, is a state of mind. The thoughts bouncing around your cranium, regardless of whether they are verbalized or not, influence those whom you lead. It's your belief system that will - and does - significantly influence whether your team feels confident or insecure. Look around, see the strength of your team, and know that the recovery starts with you. If you believe that, confidence/morale will increase. If you choose otherwise then you should expect the malaise to continue.

Let there be no doubt that which ever side you land is all in your head. Your harvest is in part dependent on the seeds sown now in the Spring of this recovery.

The Balance Between Talent and Team

I came across an old Joel on Software (Joel Spolsky) article from 2005 called Hitting the High Notes that I thought was particularly thought provoking. One of the premises of the article is that a single brilliant developer is more valuable for innovation and invention than an army of mediocre ones. His reasoning is that the brilliant developer is capable of thinking things and creating things that are virtually impossible for mediocre developers. The best line that captures the essence of the article is "Five Antonio Salierie's won't produce Mozart's Requiem. Ever. Not if they work 100 years."

But how often does the average organization require the elegance and brilliance of Mozart to compose the software equivalent of his Requiem? When viewed from the context of what the overwhelming majority of software engineers do every day, the answer is “almost never”.

Like Joel Spolsky, I’m a big fan of greatness. Real life accomplishments can often be better than fiction. However, software is as prolific and ubiquitous as there are people and it is because it doesn’t require Mozarts to create useful software to serve an organization and save tons of time and money and provide insight into business and industry trends.In fact, the effect of hiring purely on programming talent is at best problematic.

Let’s agree that software engineering is intellectually demanding. You can't be a dolt and do this job effectively. Technologies and subject matter change too quickly so having intellectual horsepower is a must. It’s also my opinion that for those same reasons one needs to understand that being a software engineer is not a 9-5 job.

As an organization, having intelligent and committed individuals is still not enough. The New York Yankees proved that by trying to buy World Series championships year after year through the assembly of the most talented players alone and failed miserably (As a Red Sox fan I consider that a success story).

That talent-alone strategy doesn’t work in software engineering either. The whole doesn’t necessarily have to be more than the sum its parts to be effective but in those cases one should expect mediocrity and not a whole lotta fun for those involved.

To accomplish cool things, if not world changing things, and have fun doing it there has to be synergy. Included with talent, intellect, and commitment, everyone should respect one another as people and professionals, understand what each other needs to be effective, compliment each others talents, and together fill all pieces of the engineering pie. If you think getting all these pieces to fit together properly sounds really, really, hard - I'm in full agreement!

Accomplishing the assembly of the aforementioned team is certainly a non-trivial task. As with everything in life, it requires compromise and balance. In this case, the compromise and balance is between the individual and team attributes needed, weighting them accordingly, and then hoping you’re right when hiring your next engineer.

It's Winter in July

Aesop's fable of the ant and the grasshopper still holds true – you better prepare for winter or you’re screwed. In case you haven’t noticed we are in an economic winter, my friends, and either you have prepared for it or you have not. It's really that simple.

These are difficult times - no doubt. With the economy the way it is, people will often feel fear and insecurity about their positions. If they've been laid off they may be concerned about when, or even if, they'll find another position.

Admittedly, sometimes being in the wrong place at the wrong time can result in losing one’s job. However, more often than not, the security we have at our current employer, and even the difference between having a job and not, is based on our present value-add to the organization. Your entire career has culminated to this point in time and the perception of your relative importance to the success of a team and organization is essentially set. It was built over the course of years both at this current position and every one before it.

I’ve been a solid ant for a number of years now. Unfortunately, I’ve had to learn hard lessons as a result of embracing my inner grasshopper. The repercussions of being cavalier about an important matter as the care and feeding of one’s career will eventually result in pain. Those grasshopper times, however painful, turned out OK for me and if you are experiencing a harsh winter it will likely be OK for you too. The trick is to constantly reflect on whether you are thinking like a grasshopper or an ant – and know and accept the consequences!

Over the course of a bunch of years I’ve come to realize that no one is entitled to anything. Everything you have and is dear to you is on the table. So have a vision, be pragmatic, take risks, and most certainly, be assertive with your career. If you do those things well you will not only best protect that which is now yours but you will grow as a person too.

Natural Leaders

Did I intend for this space to be used for discussions about leadership? No. However, the natural risks and pace of change that are inherent with software engineering makes leadership incredibly vital and high quality leadership hard to come by. When I came across an article written by Gary Hamel called How to Tell If You're a Natural Leader I immediately thought that it was important to share it here.

What made it most thought provoking are these paragraphs:

• "Think about your role at work. Now assume for a moment that you no longer have any positional authority—you’re not a project leader, a department head or vice president. There’s no title on your business card and you have no direct reports. Assume further that you have no way of penalizing those who refuse to do your bidding—you can’t fire them or cut their pay. Given this, how much could you get done in your organization? How much of a leader would you be if you no longer held even a tiny, tarnished scepter of bureaucratic power?".
• "... how much of your power comes from what you are (the VP for HR, for example), and how much comes from who you are ..."

In my mind, that's powerful stuff. Of course leadership is enhanced by title and power - perceived or otherwise. Who isn't going to follow someone, at least temporarily, who can dump your ass into the cold winter of this recession.

Yeah, Gary Hamel's article could be useful as an exercise in self-examination by existing leaders but I think a lot of that internal dialog has already happened. At most, this discussion could be a catalyst for calibrating oneself or possibly a reminder of some of those leadership principles. That's not what I find most interesting about this article.

I think this article is most useful for those that are not currently in an officially sanctioned leadership role. It's for self-examination of whether one is acting like the leader one thinks they are, or thinks they want to be, or possibly reluctant to be, or even in denial of being.

Another valuable aspect is to identify the natural leaders on your team and within your organization. Who is being followed without a title? Who on your team and organization tends to be at the center of things? Who do people go to for questions and advice? Those are the people that will build the teams for the future who are entrepreneurial, innovative, and mission oriented. You will need them because today's workforce is transient - and this is especially true in software engineering.

I recommend reading Gary Hamel's article How to Tell If You're a Natural Leader as well as subscribing to his Management 2.0 blog.

I'm interested in your thoughts.