David Alfaro: Scrum Costa Rica

Costa Rica is becoming the haven for agency-like companies. We have very talented creatives, front-end developers along with highly skilled back-end developers. This talent, along with other attractive traits this small country offers, makes many U.S. agencies to outsource their entire development effort to Costa Rica.

In this post I want to present some challenges that affect the software development life cycle in agency like companies in general. I’ll also present some action items that can be followed in order to start overcoming those challenges.

The root of the following challenges may be a bad approach to the quality assurance put in place, if any.

Requirement specifications nightmare

Quality is measurable compliance of what is specified in what is delivered. To have a clear understanding of what the client wants, we can use some traditional artifacts to specify requirements visually: Wireframes and Visual Design Guides.

There are pros and cons about their use, but let’s assume you use them to specify User Stories.

The most commons problems I’ve seen in many companies using this approach are:

• There is not a behavior-focused artifact for specifying requirements. Developers’ assumptions regarding workflow aspects inevitably creep in. This is a Quality hole.
• No visual specification artifact gets its sign-off from client before development starts mainly because the client has a lot of unprioritized requirements, and wants wireframes for all of them. Each wireframe follows an endless cycle of review and reword. Because the clock is clicking, developers commit to unclear requirements whose specifications change while it is developed. Developers never get sure of what the client really wants. The Development Team is penalized for this delay. [Bottlenecks in the value stream: 1) Too many kanban cards in the same stage, 2) a kanban card moves to next stage without being ready for that]

Quality Assurance pays the consequences

The biggest mistake I see is confusing Quality Control with Quality Assurance. Many companies only do Quality Control, and some do it poorly:

• Control quality of new features is unintentional: There is no any track system of new features to test and to add to the regression test pool. Every time estimates are given for new features, the final control quality effort is not analyzed; instead, an arbitrary constant amount of time for QA is assumed.
• Test cases a not automated at all: It takes several days to execute a full regression test.
• There is no explicit limit in the capacity to solve ongoing client bugs along the Sprints. There is not a well-known agreement on how many bugs can be solved weekly. Not setting this limit kills predictability and cadence in the overall quality control workflow.
• The testing team feels forced leave behind the essential part of “Quality Assurance”, focused entirely in quality control and not doing preventing tasks like helping to create and automate up-front Acceptance tests for developers.
• If the client has a testing team to certify that what is delivered is what was asked, against what are they certifying quality? Are they using the same artifacts that development is using to create the new functionality?

Suggested Action Items that have worked for me

• Set a Work In Progress Limit to the specification stage, focusing in finishing (I mean: getting sign-off from client) one specification artifact at a time. Only completed wireframes and visual designs guides set the signal for starting the development stage. Prioritize knowing your Work in Progress Limit!!
• Use a BDD tool for specification of application features and user scenarios like Cucumber, which has the happy nature of being potentially executable.
• Include testing effort in future estimates for new functionality.
• Set an upper limit to client bug management effort.
• Deliver to client the specification artifacts that the development team used to create the new functionality.
• Start efforts in automating some parts of the regression test, a good way to start is create and support the execution of Cucumber specs.

Some extra advice

Do a constant and merciless hunting of bottlenecks in your value stream.

Put your foot down and say: “We can’t start developing User Stories if they are not fully understood and agreed by every party”.

Avoid Analysis Paralysis: You don’t need have to have fully specified every User Story in the Product Backlog; you only need such detail for the User Stories to be implemented in the next Sprint. Acknowledge the fact that the rest of the Product Backlog will inevitably change, so don’t waste time in defining details that will be thrown away.

Specification artifacts are conversation enablers, not conversation substitutes.   Keep talking with your client to refine and handle unexpected details that will appear during Sprint.

Quality Assurance is a team responsibility; the major merit of it is preventing bugs.

Watch closely your code quality through Sprints.

People who looked at this item also looked at…

• Six Practices to deal with assumptions, risks and priorities
• The wisdom of knowing when to use Agile
• Collaborative environments to achieve goals
• Why do we estimate?
• Certified ScrumMaster Training

Related items

• Scrum Release Planning
• Stop being in pain
• Outsourcing Software Development to another Country Stinks
• Predictive Planning vs Adaptive Planning
• Six Practices to deal with assumptions, risks and priorities

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.

People who looked at this item also looked at…

• Six Practices to deal with assumptions, risks and priorities
• Agile is about Reality not Fairy Tales
• Why do we estimate?
• No agile practices or processes are substitutes for a Roadmap or Vision
• Attaching Business Value to User Stories

Related items

• Scrum Release Planning
• Six Practices to deal with assumptions, risks and priorities
• Attaching Business Value to User Stories
• Coping with Quality Assurance Issues
• Stop being in pain

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

People who looked at this item also looked at…

• Coping with Quality Assurance Issues
• Agile is about Reality not Fairy Tales
• Six Practices to deal with assumptions, risks and priorities
• The wisdom of knowing when to use Agile
• Why do we estimate?

Related items

• Six Practices to deal with assumptions, risks and priorities
• Coping with Quality Assurance Issues
• Predictive Planning vs Adaptive Planning
• Attaching Business Value to User Stories
• Stop being in pain

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

People who looked at this item also looked at…

• Why do we estimate?
• Predictive Planning vs Adaptive Planning
• Agile is about Reality not Fairy Tales
• Coping with Quality Assurance Issues
• The wisdom of knowing when to use Agile

Related items

• Scrum Release Planning
• Predictive Planning vs Adaptive Planning
• Attaching Business Value to User Stories
• Stop being in pain
• The task board shows WHAT and HOW we are doing during a sprint

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?

People who looked at this item also looked at…

• Why do we estimate?
• Six Practices to deal with assumptions, risks and priorities
• No agile practices or processes are substitutes for a Roadmap or Vision
• Agile is about Reality not Fairy Tales
• Coping with Quality Assurance Issues

Related items

• Predictive Planning vs Adaptive Planning
• Scrum Release Planning
• Six Practices to deal with assumptions, risks and priorities
• Guest Article by Gareth Powell: Why do we estimate?
• The task board shows WHAT and HOW we are doing during a sprint

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

People who looked at this item also looked at…

• Why do we estimate?
• Six Practices to deal with assumptions, risks and priorities
• Coping with Quality Assurance Issues
• The wisdom of knowing when to use Agile
• Don’t take commitment and loyalty for granted

Related items

• Coping with Quality Assurance Issues
• Scrum Release Planning
• Six Practices to deal with assumptions, risks and priorities
• Predictive Planning vs Adaptive Planning
• Attaching Business Value to User Stories

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!

People who looked at this item also looked at…

• Why do we estimate?
• Six Practices to deal with assumptions, risks and priorities
• Attaching Business Value to User Stories

Related items

• Attaching Business Value to User Stories
• Coping with Quality Assurance Issues
• Predictive Planning vs Adaptive Planning
• Scrum Release Planning
• Six Practices to deal with assumptions, risks and priorities