David Alfaro: Scrum Costa Rica

How the Scrum adoption in Costa Rica is going? How many software companies use Scrum?  Which companies?

How many times have you done these questions? I have heard them many times.

The Agile movement -being Scrum the most popular manifestation of it- is having an impressive traction in North America and Europe. In fact, you can see some evidence of that by seeing this job trends chart of Indeed.com that compares RUP against Scrum:

RUP, scrum Job Trends

RUP jobs - scrum jobs

In South America, the movement started in Argentina, Brazil, now it’s getting hot Chile and Perú.

In Central America (no, Central America is not part of North America, and no, Costa Rica is not Puerto Rico) there is not a visible adoption of Scrum, except Costa Rica.

These are some events related to me that shows an increase of interest of Agile in Costa Rica:

• August 2007, I was vital in bringing Stacia Broderick and Tobias Mayer for the first Certified Scrum Master training in Costa Rica, it was a closed activity for corporate upper management.
• October 2008, Mike Griffiths came to give a one-day workshop about agile. I took him to give a presentation at the University of Costa Rica about Agile, it was a full classroom presentation.
• September 2009, Brian Foote paid a visit to Costa Rica and we had a very insightful discussion about possible things to bust Agility in Costa Rica.
• December 2009, I brought Michael Vizdos to do the first open  ScrumMaster Certification Workshop [as far as I know, previous workshops done in Costa Rica were closed]. I was intending to have sixteen attendees, but we had twenty two and some in the waiting list for the next workshop in April. About eight companies sent people to get trained.

Costa Rica Agile User Group

On December 17th, 2009, we had our first meeting of the Costa Rica Agile User Group. Michael Vizdos gave a very customized and cozy presentation about Scrum. It started as a normal Scrum presentation but the audience quickly drove the attention to the Costa Rica reality: Scrum in a Near-shore Software Development Company. Michael has so much real life experience around the world so he gave us valuable insights, really unforgettable.

At the end of the meeting, we detailed a list of possible topics for future meetings. Just now I am pinging everywhere the poll [in Spanish] to pick the topic of the next meeting.

We already have our Google Group [in Spanish] of forty eight members so far. We have our location secured in Cenfotec Academic Center. Right now we are working in the website.

In future, we want to register our group at Agile Alliance, Scrum Alliance and APLN. We now are looking for sponsorship.

Agile Day Costa Rica

After some talking with Brian Marick, Brian Foote and Michael Vizdos, Carlos Sirias of Pernix Solutions and Gilberto Medrano of Thought Works we finally get close to start to promote the first Agile Day in Costa Rica. We already got the venue, now the hard work ahead is regarding the sponsorship, but we are confident we can make it. It’s going to be a great event.

Now what?

This year is very promising for Agile and a lot of work lay ahead of us.

For me, this year my work will be focused in building near-shore distributed teams effective.

I’ll keep you posted. Stay tuned.

While doing my efforts of promoting agile practices down here in Costa Rica, it is normal to meet skeptic people that simply don’t want to swallow the agile argument against a Big Design Up Front, commonly associated to waterfall model.

Those skeptic people are quick to get offended when I say that Software Engineering is not Computer Science. They take pride in citing Frederick Taylor’s “scientific management.”

And maybe that’s the problem: The traditional project management approach was tagged as “scientific”, so anything else that is not traditional project management is not “scientific”. This argument is not only a Denying the Antecedent fallacy, but also it’s a clear disregard of the fact that the empiricism (the foundation of Agile) is a cornerstone of the scientific method.

So these are the arguments I heard from them:

• “The absence of up front planning in Scrum gives to much freedom to the customer”
• “Given that the client can change anything in the backlog, you can’t take any stable architectural decisions”.

Why this is not a problem?

1. Vision must to be clear up front. We are going to build an account system or a social network? What is the value obtained with this project?
2. Agile does Planning. Agile does just enough up planning in order to have User Stories. The team should have enough User Stories to make a Release Agile Planning where costs of user stories are given based in complexity and dependencies between them. Afterwards, long enough architectural and design discussions take place before starting the first Sprint.
3. Through the iterations, Adaptive planning is performed while the team takes advantage of the flexible architecture that was chosen.
4. The most valuable User Stories are delivered first, each User Story represent an End-to-End functionality that traverses all the architecture required by the system, that is what is called a Walking Skeleton. So the team has a clear vision of architectural requirements from the beginning. That vision is clearer as the User Stories are consumed.
5. An important rule to remember is: The Customer can change anything in the backlog as long as he/she stays within the constraints of the Iron Triangle [Update: I better use "Agile Constrained Triangle", A concept I just made up to depict a Triangle where the constraint of Scope is flexible, but Time and Cost are not]. That is, the client can delete User Stories or replace cost-equivalent User Stories. If client wants a User Story that can’t be implemented with the tools, design and architecture, that means that the vision wasn’t clear at the beginning of the project. Please observe that more up front planned user stories would have not avoided this problem. This is not a problem of lack of depth, it’s lack of breadth. Up front planning deals, by definition with, greater depth. What I’m saying is that the same problem would have happened using any kind of project management. On the other hand, if the User Story the customer wants is more expensive than the one being replaced, it is also breaking the cost constrain, but in a lesser way. So that’s why I recommend flexible contracts with scheduled buffers to handle those minor changes in cost.

First of all, I don’t believe there’s something like Scrum Release Planning. Let me get this straight: Scrum is the alternative for traditional Project Management, it is not the substitution of Product Management.  The PO is immediate responsible for setting up a Release Plan, and the ScrumMaster is responsible for requiring the Release Plan.

By the way, remember that the Product Owner role is a subset of the Product Manager. That is, the Product Manager is the best fit for being the Product Owner.

That said, what you are going to see in ScrumMaster trainings are the practices and values the ScrumMaster has to monitor thought the Sprints. I had the luck to have a short discussion about the Agile Release Planning during my training three years ago, but as far as I know that was an extra.

I hihgly recommend therefore this couple of posts about agile release planning:

Release Planning

Agile Release Planning

“Maximizing Value with Agile Release Planning” Recording

In the making of a new product, you have some very few proven assumptions (realities) and a lot of not proven ones. That’s good because those assumptions gives an interpretation of reality, a set of axioms that serve as a starting point to build that product that will change the world, as you are assuming it is.

Failure appears when something you assumed proved to be false. That’s the time to review our axioms, with the honest willingness to change them if necessary.

For a Product Management perspective, the longer you wait to realize an assumption is false, the more expensive it is to change what you built over that assumption.

The “cost of changing what was built” as time passes and the probability of the happening that in fact it was a bad assumption is what I understand as risk.

Here my six practices to embrace and live comfortably with assumptions, risks and priorities:

1. Associate a risk numeric value to each assumption.
2. Associate a risk description and the correspondent assumption to each User Story.
3. Before starting the product development, be sure to have cleared all the higher market, platform, technology risks.
   • Refine your persona.
   • Talk A LOT with users fitting your persona.
   • Continue refining your persona in the process of talking.
   • Review market penetration of the platform and technology used by your product.
   • Review market trends.
   • Review the Business Strategy of your company.
4. Star developing those User Stories with higher Business Value and those with the higher risk associated. Answer the tougher questions first.
5. Pay consulting services to a Subject Matter Expert to review the iterations increments. This is a review process independent, not related to the Team Review Meeting. Remember the team presents the increments to the Product Owner, not to the SME, at least of course the PO is the SME.
6. Start a customer base, even when you have only the concept of the product.

Further Reading

Brutal Prioritization in Agile: cut costs by NOT building the fluff

I came across this wonderful short post entitled “User Stories: Value and Size”. The most interesting paragraph for me is this one:

Maximizing work not done is the art of our trade. The business value of a story is looked into precisely for this reason. If you don’t have a good reason business value) behind a given piece of functionality (story), you are wasting time by working on it.

Brilliant.  I can’t add more but this few words: If you are building products maybe finding the Business Value for a User Story is hard, really hard. But if you can’t find one, you loose credibility of the team. The team will have the feeling that you are making up the value of the feature. So talk with customers, talk with them a lot, talk with many of them in order to find how much the story is worth with respect the total price they will pay for each copy, and then project the revenue this story will have, given how much copies you are going to realistically sell. That will be just an estimate, but a very educated one.

Further reading

Why do we estimate?

Agile adoption is accelerating. It’s very common to find panelists or podcasters recommending the adoption of agile.  Therefore, if you are thinking seriously about adopting agile, I have some important pieces of advice about the ScrumMaster role.

Resetting your Project/Product Delivery mindset

Don’t try fit the roles of agile into the traditional role structure of your company. Agile needs a complete different position structure. Don’t try to treat a ScrumMaster as a Technical Lead. Don’ treat a ScrumMaster as a Project Manager. Those roles are a not the same. That’s why is wise starting with a project, let it execute and finish for you to understand all the implications of having a new structure in the company. Note: when finding a good candidate for the ScrumMaster role, normally Project Manager or Technical Lead is a good fit after training and coaching.

ScrumMaster as a full time job

Don’t fool yourself thinking that there isn’t a more laziest job than ScrumMaster. Specially if the company is in the early stages of agile adoption. The impediment resolution is the hardest part when managing an agile team: Finding a suitable workroom, a taskboard, stopping chickens interference, monitoring advancements of the Action Items agreed last Retrospective meeting, monitoring progress along the Sprint, monitoring quality, convoking and facilitating meetings, fighting IT, promoting the vision, helping to find resources, pushing to keep the backlog, the taskboard, avoid the team over commit, avoiding confusion between tasks and User Stories, get the team committed, cheer leader, etc..

Every time the ScrumMaster role is degenerated to a part-time role, the Scrum practices are poorly followed at best.

Further reading

The Mythical Part-Time ScrumMaster

Scrum Master role vs Leadership vs Project manager

Can Product Owner and Scrum Master be Combined?

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

This video is kind of old, but it gives me good stuff to ponder around why agile became to exist:

First of all I don’t like the indiscriminate use of the word “requirements”, it easily buries the fact that a real human has goals to accomplish with the product we are building. Going from user’s goals to specific software requirements is a very delicate process. That’s why I prefer the agile term “User Story” instead of “Requirement” because it preserves the link to the final user. This format is great:

In order to <achieve some value>, as a <type of user>, I want <some functionality>.

However, for the sake of a fluid analysis, let’s keep using the video lingo and discuss each point:

0:13 We are 4 months in to 5 months schedule and I just received the final requeriments yesterday. (And they’ve changed again!)

There’s nothing wrong in changing requirements. That happens all time and it is normal since the final client/customer is reviewing each iteration of course he/she would have a better understanding of what he/she wants while it’s taking shape. It becomes a problem when:

• The boss wants to change a Requirement in the middle of the Sprint. He can’t do that. The team commits to deliver a set of User Stories at the end of the Sprint. It is just impossible to deliver the same amount of work in half the time. When some emergency occurs in the middle of the Sprint, it’s time to cancel the Sprint and to start another one, with its proper Planning Meeting for team commitment. When this happens frequently, the boss has no idea where to go. Someone has to scale this and the ScrumMaster, as team protector, is the most appropriate dude to do it,
• The project is  fixed price and the customer is requiring something that is out of scope of the contract. If so, the contract should have included a foreseen process of Change Request. The Change Request establishes the criteria of charging for extra functionality. If there isn’t a Change Request clause, things are tougher and renegotiation is required. The team is always able to review the Agile Release Plan with new dates or new User Stories.

0:22 I spent half my days in meetings about about how to get more work done. (Instead of working)

Be Lean! Eliminate the waste! Kill unnecessary meetings, make them effective! Certainly Retrospectives able the right tools for detecting productivity problems and for setting corrective Action Items. But if the team is unable to correct a clearly measurable productivity problem after several sprints, you may have a lack of skills problem or a measurement problem.

0:30 My boss read in a magazine that developers using “__” programming language are twice as productive. So he bought us a copy and cut our schedule in half

This is nonsense. Who is responsible to actually put all the bricks of the building? It’s not the Product Owner. The Product Owner needs to have the mental powers to say: “I need this building to make a lot of money”. The developers say: “Ok, it”ll cost you such amount of money in such time”. Who is the Product Owner to say otherwise? What could follow is long conversation about how Product Owner explains functional characteristics of the building, time and costs constrain; while the developers explain what can be done given the constrains and the tools (programming language for instance) available. From a development stand point, the team commits to deliver the Product, the Product Owner doesn’t. The boss can’t commit for the team. The boss can commit with superiors/client once the team has given him the commitment.

0:49 Every day my boss changes his mind about what we’re building

See 0:13

0:56 Dad: People keep asking me to fix their email, so I have no time to code. Son: My daddy has no time for me

Impediments and tasks unrelated to the Sprint are the ScrumMaster’s concern. This can’t happen. A commitment can’t be accomplished if you are not fully committed and accountable. You are in the team or not. If you are inside the team, you can’t attend to unrelated meetings, you can’t run CEO’s errands or whims, at least it’s part of the iteration’s commitment. The ScrumMaster need to have a thick skin to eliminate such distractions at once.

1:10 Some consultants told my boss they could build our next version in half the time, for half the money. He believed them but now they’ve have spent all their budget, used all their time and… are still half finished. Now they are gone and their code is a disaster. We have to fix it and finish what they started.

See 0:30

Eliminate the nonsense

If you pay close attention to the problems pointed in the video, they are flagrant negation of good sense. Set the expectation clearly, set the accountabilities clearly.

Further reading

Seven Principles of Lean Software Development - Eliminate Waste

A ScrumMaster Removing an Impediment at Apple

Many productivity problems I’ve found in teams are closely related to collaboration barriers. Really, any time frustration or problem your team is up to, please take the time to see if the roots of the problem is because your team is not fitting the following description:

A group of people come together, create a sufficiently shared understanding of an equifinal meaning that enables coordinated behavior, and then the actual activities of task identification, decomposition, distribution, coordination, and integration of outcomes are accomplished in a manner that lasts long enough for the goals [...] are realized.

That’s the definition of Collaboration as stated in Luke Hohmann’s article Some Answers to What’s Collaboration? .

Enforce collaboration. Agile practicesare meant to enforce collaboration. Think about it:

• A dedicate workspace for team.
• The workspace is in itself a meeting place, so anyone can convoke a meeting at any time without waiting for meeting room to be available.
• The team is working in a circle-like distribution, everybody facing averybody.
• Pair programming.
• People participating in Daily stand-ups are talking to everybody, not only to ScrumMaster/Leader.
• The ScrumMaster enforces a shared vision.
• Openness in any meeting, specially in Retrospective meetings.
• Shared agreement in decisions, even in controversial matters.
• Reflect and Inspect what went wrong and right in each iteration (Retrospective meetings) in order to improve teaming.

Further reading

How to set up a productive working environment for Agile teams

Pair Programming with VNC

Organizing an Agile Modeling Room

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.