David Alfaro: Scrum Costa Rica

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?

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

I have the immense privilege of having this article by Gareth Powell. Initially, it was thought as a post, but it turned out to be a great article about why we estimate.

Quoting InsideAgile: “Dr. Gareth Powell is a Team Lead and Senior Architect at Ternary. Gareth’s 25 year background in software development includes key roles in the delivery of robust solutions for Wall Street and the Telecommunications Industry. [...] He is passionate about improving programmers’ productivity and their ability to deliver useful solutions to customers, and he is an expert in the use of agile methodologies.”

Since February Gareth Powell has been working part-time in Aggiono team while visiting Costa Rica for his family to learn Spanish. His insight in our team has been great and I can tell you that his many good pieces of advice are helping us to improve our agile process, remember: you can always improve! Rotating the facilitator role for retrospectives, one week sprints, effective meetings, are just few examples of on how Gareth is helping us to inspect our everyday activities. Thank you Gareth!

In this article, Gareth Powell discusses estimation, covering the following points:

• Why it’s important
• Why it’s difficult
• The different dimensions of estimating
• How to incorporate estimates into a development effort
• Improving team-client interactions

The article does not address techniques for estimating.

Well, this is Gareth’s article, check it out, it is worth it!