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…

• Stop being in pain
• Scrum Release Planning
• The impact of Human Resources in the Agile Enterprise
• The ScrumMaster role
• Why do we estimate?

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

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…

• Agile is about Reality not Fairy Tales
• Why do we estimate?
• Dynamics of the Daily Standups
• Certified ScrumMaster Training
• Coping with Quality Assurance Issues

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

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?
• The impact of Human Resources in the Agile Enterprise
• Scrum Release Planning
• Outsourcing Software Development to another Country Stinks
• The ScrumMaster role

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

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?

People who looked at this item also looked at…

• Certified ScrumMaster Training
• Stop being in pain
• The impact of Human Resources in the Agile Enterprise
• The ScrumMaster role
• Why do we estimate?

Related items

• Coping with Quality Assurance Issues
• Scrum Release Planning
• Don’t take commitment and loyalty for granted
• Stop being in pain
• The wisdom of knowing when to use Agile

Finally I am back!! I apologize for my temporal aloofness!!
I was reading interesting postings at ScrumDevelopment group about Taskboard and how the progress is visualized so I want to share some ideas from our particular experience.

A very engaging aspect of Scrum (and Agile in general) is to find innovative ways for solving problems found in the Retrospective meetings. By the way, the Retrospectives are are rich well of requests and improvement opportunities. By pandering to those requests (and inspecting at the solutions) you will get a tailored improvement to the process.

How do we at Artinsoft do for keeping track of our Sprint progress using the Task Board? Let me explaining it to you by telling you the story.

We have acknowledged that the following phases are needed in order to set a done criteria for the User Stories we committed:

• Design: Meetings to discusses architectural issues,
• Development: Coding
• Application Quality Improvement: Pair Programming and/or Code Review. We prefer Pair Programming.
• Testing: Quality Assurance in the way of Developer or Integration Tests
• Usability Tests

Additionally, a sixth kind of tasks emerged: Environment, as a mean to say that it is a task that encompasses all the environment setup (technology setup) to accomplish the User Story.

Well, in one Retrospective long time ago we pointed out that some User Stories were lacking of enough quality. Why? …. Got it! one or more aforementioned phases were being skipped when planning and implementing features. Why? We EASILY forget to get sure we get them while planning and even implementing. At the second level of “Why?” we realized we needed something catchy to remember those phases and to avoid the constant tendency of realizing them when the deadline is looming, or even worse: never!

We devised a solution: Use a specific color for each kind of task when doing the Sprint Planning and do a Color Distribution Assessment constantly: Do we have enough of all colors for all User Stories? If not, is there a unanimous and intentional awareness of it?

Our Taskboard looks like this:

We always have a good supply of sticky notes next to the TaskBoard, one color stack per phase or kind.

Along the Sticky notes we also have a supply of red round labels. Why so?

In the diagram, I pictured an hypothetical second day of the Sprint, in the Stand Up. The team member David (hence the “D” in the sticky note) delayed more than the recommended (and estimated) one day for that pink task (Usability) he committed to finished. He sticks a red round label to the task and in that way the Task Board is irradiating to the whole team that we are behind of the Sprint schedule.

Again, this has worked for us and fits to our specific circumstances. What do you think about it? Feel free to give me your opinions, all your comments are needed and welcomed!!

People who looked at this item also looked at…

• No agile practices or processes are substitutes for a Roadmap or Vision
• The ScrumMaster role
• Why do we estimate?
• Scrum Release Planning
• Getting even more serious about your meeting problem

Related items

• Scrum Release Planning
• Six Practices to deal with assumptions, risks and priorities
• Attaching Business Value to User Stories
• Collaborative environments to achieve goals
• Coping with Quality Assurance Issues

“Inertia is a non-quantifiable property of matter by which it remains at rest or in uniform motion in the same straight line unless acted upon by some external force.”

“Sprints are short running races in athletics. They are roughly classified as events in which top runners will not have to “pace themselves”, but can run as fast as possible for the entire distance.”

Let’s mix Physics, Athletics and Software Development: Scrum’s Sprints are meant to have an increment in the team’s metabolism so we can run as fast as possible in a motion near to uniform. Once we start to “run as fast as possible” , we feel the inertia that help us to complete the race. A race against time.

So, let me point out two specific features related to a Sprint:

• In athletics, I normally see that the longer the sprint’s distance is, the lower the racer’s velocity is.
• In physics, gravity acts as the external force that finally stops the uniform motion.

Sprint Duration and Gravity
For a good use of your team’s inertia, you will find out that a two week sprint is the best, look a this post of Tobias Mayer about it. In a three week sprint (or longer), you will see your team not running as fast as possible through all the sprint stretches. Why so? Because external forces start creeping around you. Examples of those forces are: errands and meetings that are not related to your project. The false sensation of “we still have plenty of time to finish this task” is like that gravity that slows you down.

Uncertainty is something to expect. However, in longer sprints, uncertainty become a strong hindering force. In shorter Sprints, uncertainty becomes tamable and even beneficial to get “the agile edge“.

The Sprint Review is as rewarding as winning a race could be. Why do you have those rewards not so often?

Two Weeks Sprints are highly recommended. One week sprints are specially great in those cases when product definition is in its very early stages. In that way, the Product Owner can shape better what he wants by seeing highly frequent increments of the product.

If iterations are so often, you need to keep Planning, Preview and Retrospective meetings in a proportional timeboxing. You can’t have a eight hour Planning Meeting for a One Week sprint.  These meetings are vital and also have to be effective.

Doing Scrum is not running like a mad. It is running effectively little and smart races that are part of a big circuit or championship. That championship is explaining by the Roadmap, which I will post my comments about it very soon.

Keep on tuned!

Related items

• Coping with Quality Assurance Issues
• Scrum Release Planning
• Stop being in pain
• Dynamics of the Daily Standups
• The task board shows WHAT and HOW we are doing during a sprint