David Alfaro: Scrum Costa Rica

Doing something because we really believe in doing it is the best moral code one can have, there’s nothing better than the celebration of reason and the standing of the “Why?”.

Doing something because I say so, because is mandatory make it sounds like “just because”. Even more, forgetting the “Please” particle ignores the existence of the order’s recipient, transforming him in a entity without volition.

Companies start loosing perspective when they start giving the message that in the company’s magnanimity, the employee has the job benefit of, well, having a job. That easily degenerate from leadership to direct management. Thinking that the employees don’t have any other job choices encourages patronizing. Ok, in the current economic turmoil, maybe job choices are really scarce. However, the huge challenges that such turmoil is creating requires a strong, adaptable and High-Performance company.

Surviving in the current market requires having a compelling performance purpose that exceeds sum of individuals goals. Requires joint work to integrate complementary skills. And guess what, just leadership can inspire a bunch of employees to do that.

There are several angles of good leader, however I want to focus in the foundation of leadership: Credibility.

James Kouzes and Barry Posner, authors of the best selling book “The Leadership Challenge”, lay out the common phrases many company employees have used to describe how they know credibility when they see it:

• Leaders practice what they preach.
• They walk the talk.
• Their actions are consistent with their words.
• They put their money where their mouth is.
• They follow through on their promises.
• They do what they say they will do.

People first listen to the words, then they watch the actions.[...] If people don’t see consistency, they conclude that the leader is, at best, not really serious, or at worst, an outright hypocrite.

Are you saying you are very innovative company but in reality you don’t have the money for a R&D Department or new Product/Services initiatives? Do you promise a extra benefit or promotion, but you are not sure you have the money to do it? Do you say you listen to your clients but your products and/or services hasn’t evolved  for a while and they won’t? Do you say you are building something but zero effort is on it? Are you serious at all with this credibility thing? Good employees are smart and wary, specially technical ones.

Don’t ask for a leap of faith if you haven’t proved how trustworthy your judgment is. Don’t encourage a company culture where there isn’t any. Don’t complaint about lack of communication when you have enforced silos.

Commitment and loyalty are patiently built on credibility. Once they are built, and with the right skills, your company will go beyond surviving.

Further reading

Leading Teams – First Comes Credibility
Wikipedia entry: Credibility

A False dilemma “involves a situation in which only two alternatives are considered”, states the Wikipedia, “when in fact there are other options”. Do you remember “If you are not with us, you are against us.”? Well, that happens when you fall in fundamentalism.

Fundamentalist anti-agilists got deeply offended because they say agile doesn’t follow a scientific approach, that it is offensive not treating Project Management as a Computer Science, alas! Turing is wallowing in his tomb!

Fundamentalist anti-cascadists say that traditional software management techniques are obsolete, that it ignores the innate nature of uncertainty of every software project, the virtue of self-managed teams always outperforms past management practices.

Before continuing, let me state clearly that I am a truly believer of High Performance Teams (HPT). In the way of getting a HPT you will inevitably  ended up practicing the agile principles.

That said, HPT’s are not always needed. So practicing agile is not always needed. Although most of the software projects fall in the uncertainty levels suitable for Agile, there a bunch of cases when direct and cascade-like managing is the best fit, so a group, rather than a team is needed.

Take the case of some massive web agencies or software sweat shops (very common down here in Costa Rica), or a well established  and reliable software migration processes. They are a typical production line. They’ve got efficiency through specializing and strongly documenting every phase  of the project development (or better said: production  line). Of course, there are parts of those processes that can be significantly improved by implementing agile practices. Even more, those kind of companies would want to jump to the “Product Creation” wagon where Agile is the best.

Be wise and take time for analyzing the complexity of the problem/project about to start. To do that, make your homework and use the Ralph Stacey’s Agreement &  Certainty Matrix against the project:

Identifying management decisions on two dimensions: the degree of certainty and the level of agreement.

When issues are Close to Agreement and Close to Certainty, Stacey says:

Much of the management literature and theory addresses the region on the matrix which is close to certainty and close to agreement. In this region, we use techniques which gather data from the past and use that to predict the future. We plan specific paths of action to achieve outcomes and monitor the actual behavior by comparing it against these plans. This is sound management practice for issues and decisions that fall in this area. The goal is to repeat what works to improve efficiency and effectiveness.

That is: use Cascade.
When issues are in the edge of chaos (Complex gray area), Stacey says:

This is the zone of complexity where the traditional management approaches are not very effective but it is the zone of high creativity, innovation, and breaking with the past to create new modes of operating.

That is: use agile.

Further reading

There is also a outstanding article in the Harvard Business Review called “A Leader’s Framework for Decision Making”. Really amazing article. Do read it! I’ve found a PDF version of it.

In my experience, Daily Meetings or Daily Stand-ups are the easiest agile “ceremony” to adopt, but the easiest to drop.

In this post I’ll talk about what’s the problem with adoption of agile in this specific matter.

Easiest to adopt

Even agile skepticals appreciate a huge value in daily stand-ups. Martin Fowler summarizes pretty well the goals of the stand-up meeting:

• share commitment
• communicate daily status, progress, and plans to the team and any observers
• identify obstacles so that the team can take steps to remove them
• set direction and focus
• build a team

The magic about this meeting is that those goals are easily perceived as achieved because of the dynamic and energy you can feel and the immediate results you achieve.

Easiest to drop

But if stand-up meetings are such good thing, why is it that after a while, some groups (not teams, groups and teams are not the same, I’ll talk about that in another post) tend to dismiss stand-ups?

Here are some causes:

• It’s viewed as a “ceremony”. This is not a ceremony, a magical ritual that by means of routinary practice, the stars will bless you live. Not at all, if you are not seeing any objective advantage of doing  any ritual then stop doing it! Stand-ups are not silver-bullets for eliminating risks, but invaluable opportunities to find them. It’s not a source of energy, but an energy incrementator, which assumes energy inputs.
• It just pursue a single goal. This is not a just a daily status tool, if you turn it in a status checker, it will become a boring unilateral meeting without sight of the road ahead beyond current iteration, building uncommon interests in team members. Don’t pick just one goal and make it the single goal to pursue. Pick them all, before facilitating any stand-up, review them all and give them equal importance.
• It’s not kept stand-up. A sit-down meeting conveys a feeling of formal meeting that can last longer that fifteen minutes. If that happen, daily meeting will start to be expensive and boring. All Agile practices a meant to be like oil that lubricates the motor of execution. But oil changes can’t be as expensive as the gasoline or as the motor itself. So be efficient in stand-up meetings, keep it short, keep it stand-up.

More information about stand-ups:

• Daily Stand-up / Scrum meeting.
• Daily Scrum: Sitting or Standing?

As the team develops in practicing real Scrum, team members see missing any scrum activity as something painful. Scrum is about people and making them work as a unit more powerful than the sum of the individual powers. That kind of power is lost when someone misses ANY scrum activity.

Off Sick

In practice, punctuality is a supreme rule and Scrum activities have priority over other work activities.

Unexpected events require good judgment, I don’t suspend a scrum activity because someone is sick, unless the Product Owner is sick for the Sprint Review, in such case we have a prioritized Product Backlog so we can pull up the next high priority User Story from it. Maybe the PO is not so sick to be present by phone. Conversely, a team member can present by phone in case of a unforeseen event. Slipping dates undermines commitment.

The team itself sees unfavorably when unjustifiably someone misses or arrives late to a meeting. And that person suffers the lack of involvement and tries hard for not suffer that again. The team become self-managed.

Everybody understand when some is off sick. You have to live with that when rarely occurs. Suffering means “Hey, those meeting are really important, I don’t miss them better”

In cases of someone’s sickness (I have dealt with that quite a few times) I try to keep that person updated, as much as possible, that’s the best way to reduce the absence effects.

On the other hand, if the team frequently experiences “being off” frames, scrum can hardly be done, and by my experience, that team is hardly a team.