It’s his job

Perhaps it is. But does he know it? Have you told him? In teamwork, as in marriage, implicit expectations create tension that’s bound to explode at some point. Disarming that bomb is as easy as saying “could you?”

Some jobs have tighter-defined responsibilities than others. Across the spectrum of employment that’s obvious—if you’re, say, a train driver your job is to safely steer a few thousand tons of steel, carrying a few hundred human lives to their desired destinations. If you’re an artist, there’s much less specificity.

Even within the IT industry there are vast differences in job descriptions. A DBA is tasked with maintaining dabatase servers, often including developing data models and optimizing queries for efficiency. For a developer, things get a bit more blurry, being expected not just to write code, but these days often also setting up server infrastructure, configuring deployments, monitoring service health and, perhaps hardest of all, understanding and catering for user needs.

Then there are the managers, whose job descriptions are becoming increasingly confusing. Ensuring timely delivery, supervising quality, motivating their reports and caring for their career development. Everybody nods their heads in agreement on those, but what do these mean in practice?

In the (inherent) absence of specifics in one’s listing of responsibilities, both the manager in question as well as everyone around them will develop their own image of what these should be. In particular, their reports will have varying expectations. Some will want them to be a communications bridge, others will prefer communicating directly. Some will want vision and guidance, others will want to have their own say. (I’m singling out managers here because of the evidence of the problem here, but the same concerns every job with a blurry description.)

The issue? Nobody tells them! The manager have their own view on responsibilities, obviously, and will execute against those. (Plus there are the manager’s managers to cater for.) They will, regretably, often not sit down for a frank conversation with their team to talk out what everybody’s role is. The result is frustration buildup. Reports holding watercooler conversations, complaining about their manager not leading this, not reacting to that, not talking to someone, etc. And they won’t tell the manager because they feel it’s inappropriate or for fear of retaliation.

I made a sport of calling out these situations. My lovely wife had thaught me from the outset of our relationship that if either of us wants the other to do (or not to do) something, we better voice it. Otherwise it’ll pile up over time, explode at the least opportune moment, causing irreparable damage.

It’s the same at work.

Take your manager out for coffee (if it’s your first time, the setting should help loosen up everybody), then tell them: “Bob/Kathleen, could you ask our CTO for help with resolving the issue we’re having with this vendor? Could you tell me how you see our priorities for the next three months?” No “I expect you…”, “it’s your job to…” crap. Just a human to human request—firm, direct, but very much considerate. You’ll be well on your way to deflating the baloon of unmet expectations that would’ve blown you both away when (not “if”) it popped.

What does it mean to be Agile?

Agile? Yeah, we do Kanban. We’ve got our user stories, backlog and deliver iteratively. All good. Except that that’s not what Agile is. Not at all. It’s not the planning poker, story points nor squadrons of Scrum Masters. It’s the spirit.

Whenever the name Agile pops-up, invariably follows the “manifesto”. The 4 principles that you and I have seen over and over again and know by heart. Or do we? We definitively should because they are the Agile. They’re a way of approaching software development, while Kanban, Scrum, XP and all the others are just tools built to serve these very principles.

By declaring to be Agile software developers, we commit to value:

Individuals and interactions over processes and tools

Joel Spolsky has a fun recall of a conversation with a programmer:

  • “Who is going to write the code?” I asked.
  • “I am…”
  • “OK, who checks things into source control?”
  • “Me, I guess, …”
  • “So what’s the problem, exactly?” I asked. “You have absolute control over the state of each and every bit in the final product. What else do you need? A tiara?”

How to be a program manager, Joel Spolsky

It’s people, who make the software that works wonders. No process or tool ever produced anything on its own. It’s the combined power of all the team’s brains that spawns code and turns dreams into reality. It’s in the casual conversations that new ideas are born. It’s in the war rooms that they’re developed.

Processes are only there to get repeatable tasks off people’s mind. If you find yourself repeating the same steps over and over again, for instance when releasing code to a live environment, write a checklist, so you don’t have to rediscover the wheel every time.

Better yet, write a script to automate the the tasks. Tools are there to support programmers so that mundane work takes less time and more brainpower can be used for creative work. Neither tools nor processes should limit people in any way.

That’s why Agile development methodologies are often very open bags of best practices, rather than hands-on manuals. They’re meant for people to digest and adapt to their needs.

Working software over comprehensive documentation

We can always tell whether we like the software we work with. Whether it meets our needs and expectations. But we can’t reliably say whether we will like the software based on specifications. We can’t even properly express our thoughts in writing. It’s insane to expect a programmer to understand our intentions based their flawed description. While the natural reaction is to produce even more documents, it only ensures that they either:

  • get ignored, or
  • need plenty of updating on the way.

An Agile team demonstrates small portions of fully working software to collect feedback and stick it right into the development process. The team delivers all layers that make up a particular feature, because then and only then does the result have business value. Only then can it be measured as a completed step towards the ultimate goal. And that goal is never the software itself but always solving real-world problems. That is why requirements are described as user stories, so that everyone involved stays focused on the business impact of their work.

Customer collaboration over contract negotiation

Everyone involved in producing a piece of software plays on the same team. The customer wants a product that will meet his needs and the developer wants to make the customer happy by delivering one. Any conflicts inside the team are nothing but a waste of energy, that should be used elsewhere.

There is no space for complaining about incompetent customers, lazy programmers, stupid managers and those a**holes that are “too stupid to get it.” Every person is probably pretty smart and reasonable, or else she wouldn’t have her job in the first place. Communication issues must be distinguished from emotionally charged judgments.

Agile teams keep their customers close. Perhaps not “on” the team and in the office daily, but staying in touch often, asking questions, clarifying issues as they pop up, and regularly demonstrating progress.

Contracts are created merely to protect their signees. When projects work well, everyone may as well forget that they exist.

Responding to change over following a plan

Another layout change? They’ve got to be kidding.” is the attitude most programmers present towards modification in project scope. “Why can’t they make up their minds?” I already argued that that is not possible. Everything about a project may change at any moment, because the reality around us changes and because our minds change once we face reality. Accept it, embrace it.

A plan is still necessary so that everyone knows where the project’s heading and can make credible commitments about it. Therefore, in the words of general Eisenhower “plans are nothing; planning is everything.”

Agile teams keep their plans light and flexible, so that adjustments don’t require hours of fixing dependencies (I’m looking at you, Microsoft Project). Changes are expected to pop up until the last minutes of the schedule, so everyone treats them as regular, daily business.

Customers are happy, being free to produce new ideas and see them implemented. In the end they will still receive something of true value.

 

So, are you an Agile software developer? Stop talking about user stories and Kanban. Start talking about business and people.

A team that never was

You cannot build a team merely by replacing “me” for “we” in communication. You won’t get there either by placing people in one room and giving them a common name. A team is much more than a group of individuals sharing the same space and some characteristics. What binds a team is spirit, not labels.

A team:

  • shares a common goal, which must not be a vague statement like “customer satisfaction” or “top quality”. Instead, it has to be a plain, concrete, down-to-earth target like “delivering version 10.1 with killer feature Banana Split by the next holiday season.” To get there team members have to:
  • share work, not receive their own tasks, and submerge in them for 3 months without anyone else around knowing. Members must operate together, like a Navy Seals expedition – switch posts, cover each others’ backs, communicate regularly to keep everyone informed of the common progress towards the established goal, as well as encountered risks and problems.

A leader’s role in team building is defining and distributing work in such a way, that naturally requires team cooperation to achieve goals. Ideally, failure to cooperate should result in failure of the whole team. Remember the movie “300“? Leonidas explains to the deformed Ephialtes how Spartans fight: as a single, impenetrable unit. Arm to arm, fighting the same enemy, protecting each other. That is team spirit.