David Alfaro: Scrum Costa Rica

I just finished the round #2 of Usability Tests of Aggiorno. It was amazing! I found out many important issues regarding how the user expects Aggiorno to behave given the Interaction Design it presents. And because I assume you are here to receive value I will tell you the generalities of doing a usability test and the general lessons.

I can’t show you specific details about the detected issues neither clips because of privacy matters outside of my control. However, in a near future post I can talk a bit about the design principles you always need to remember when designing User Interface.

The Process

The Usablity Test was conducted in a web development company called Cis-Solutions. From that company, five users were picked for this test. The selection process was based on a questionnaire where we were sure each user fits our target persona. The main aspects in this sample are:

1. College’s Bachelor Degree.

2. 20 to 30 years old.

3. 1 to 3 years working in ASP and/or ASP.NET

4. Uses Visual Studio Environment usually.

5. Develops sites of 16 to 50 pages

6. Maintains sites of +50 pages

Due technical problems during test executions, I wasn’t able to gather data to do a System Usability Scale (SUS). Instead of SUS, I resorted to ask the users to score (from a scale from 1 to 7) the satisfaction level using Aggiorno. Additionally, I asked them to score how useful Aggiorno is.

After a short but complete explanation of what Aggiorno is, does and how it is invoked, each user was asked to do some tasks with Aggiorno in a Web site already opened in Visual Studio 2005. Those tasks were carefully selected in order for us to see user’s behavior in our intended User Interface.

Conducting a Usability Test

Every time I conduct a usability test, I learn a lot and become more aware of more details. “User A is tapping his feet” “User B is humming” “User C is yawning” That’s behavior!! That together with “Think aloud” exercise allow me to collect the user is feeling (i.e. usability). I always ask the users: “Please pretend I am hot here (neither is any observer) so can swear freely in the case you want to.” I collected a big amount of notes in my chronological log. This is an art!

Finding patterns in raw data and reporting

Reviewing collected data is like drinking water from a hydrant. My preferred method for organizing that data into themes is Affinity Diagrams where each sticky note has a color correspondent to a user: User A has sticky notes in green and User B in yellow and so on. So I and observers (it would be great if any) organize in themes all the sticky notes. If a theme has all the colors available it means that that is a common issue, worthy to be noted.

Because the sticky notes are OBSERVATIONS, that is, OBJECTIVE NOTES, you have to describe consistently the behavior (crystallize the pattern) and make it an issue for the report.

What to do with that?

Soon I’ll let you know how to manage the Debriefing meeting.

There are so many details I am skipping in doing this post, so feel free of contacting me.

Why is User Studies so important for me? Because it means getting closer to user, being iterative, being open to the issues you are going to find and the potential changes they imply, learning to watch as an alternative to listen, inspecting over the collected data, adjust your course because of the lessons your learn from the tests. Do you follow me? For me THAT’S BEING AGILE!

People who looked at this item also looked at…

• Certified ScrumMaster Training
• Six Practices to deal with assumptions, risks and priorities
• Why do we estimate?
• Dynamics of the Daily Standups
• Collaborative environments to achieve goals

Related items

• Usability Test: Want valuable feedback? Recruit real user for testing
• Collaborative environments to achieve goals
• No agile practices or processes are substitutes for a Roadmap or Vision
• The impact of Human Resources in the Agile Enterprise
• The task board shows WHAT and HOW we are doing during a sprint

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…

• Why do we estimate?
• Getting even more serious about your meeting problem
• Six Practices to deal with assumptions, risks and priorities
• Attaching Business Value to User Stories
• Collaborative environments to achieve goals

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

The Product Owner role is highly important within the Scrum Process. He is in charge in getting sure the team is delivering business value.

Building a Product Roadmap
Building a Product Roadmap is an art. I had had the chance to talk with Luke Hohmann, founder and CEO of enthiosys, about all forces you need to take into account when you set out on defining your product roadmap. Surely, you can find an excellent and comprehensive explanation of Luke’s insights in his amazing book “Beyond Software Architecture: Creating and Sustaining Winning Solutions“. Luke’s advice and guidance have been instrumental for me to successfully push towards a realistic planning state in my projects at Artinsoft.

Up to now, I just tell you how important is to establish a clear distinction between the system’s architecture and the business perspective of that. Combining the business value features, market forces, technological forces, and events (among other things that I will blog later) you are able to build a roadmap.

The roadmap will provide you deadlines and features in order to build an Agile Release Planning. The ScrumMaster training given by Stacia Broderick is a wonderful source of tools for an effective release planning.

Along with the team, the Product Owner is ready to organize the priorized features by Sprints . That is, in earlier sprints the team will deliver the highest business value!!

Product Owner’s Fairy Tale
Ideally, before starting development, the Product Owner has a clear idea of what is needed for the product to be profitable. He has clear idea of all the market behavior and since he is supported by an experienced marketing team, building a Roadmap is just one more step forward.

In this ideal world, he just sit down and write all the User Stories needed to accomplish that wonderful profitable product. With a brightly bunch of User Stories, he now can sort them by business value: from the highest to the lowest. Let’s make an Agile Release Planning and voila! just let the Scrum team bring potentially shippable increments.

Wake up!
The most powerful weapon of Scrum for software delivering is Adaptation in an uncertain environment. In most cases of the real world, the Product Owner just has some idea of what is needed to have a profitable product. Even more difficult: maybe the team doesn’t have a velocity yet because they have never worked together and don’t have a deep understanding of the possible platform. Does it mean we don’t need a Roadmap and Release Planning? Well, this when we need them the most!

I’s alive!
Roadmap and Release Planning are Adaptive! I don’t want to touch metaphysical areas, but in order for something to be adaptive, that something needs to be animated, for me: alive! The Product Owner needs something to start with. At least he would have a fuzzy idea of the product. At the beginning the product features, technology and marking architectures are vague. THAT’S FINE! Let’s do our best in defining the Roadmap and the Release Planning.

Product Owner, remember: be responsive!
For the product perspective, each Sprint will give you high quality software to play with and that will give a magnifying glass to discern what do you want. You will sharp your vision with every Sprint. Every Sprint will give the chance to be more concrete in the Roadmap and Release Planning. Don’t miss an opportunity to update them. Every time you update, do all the meritorious market research, try to be more concrete and definitive in deadlines. Deadlines are important as we don’t have infinite resources to be vague all the time.
For the team perspective, each Sprint will give you a solid idea of what is your velocity based on what was done in earlier Sprints. Team velocity is vital parameter to wisely update in the Release Planning.

That’s all folks so far. Keep on tuned!

People who looked at this item also looked at…

• Six Practices to deal with assumptions, risks and priorities
• No agile practices or processes are substitutes for a Roadmap or Vision
• Predictive Planning vs Adaptive Planning
• Why do we estimate?
• Attaching Business Value to User Stories

Related items

• No agile practices or processes are substitutes for a Roadmap or Vision
• Scrum Release Planning

“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

The immediate purpose of software development is precisely that: SOFTWARE. Our ultimate goal is delivering software. The prize (whatever it could be) will depend on software delivery success. You will feel in the right path as long you now what your customer wants and how you can satisfy him.

The more quality our delivered software has, the more fulfillment our purpose reaches. All the software we produced should be supposed to be used. We make it for our customers. Our customers are represented by the Product Owner, who is able to realize and prioritize the features (User Stories) that the end customer wants.

The software or product is made out of features. Sometimes the team forgets about the business value that every single task should have. Certainly, the explicitly stated business value is in the User Story. However, when it comes to take that User Story and disaggregating it into tasks, all the team is responsible for remembering how every single technical-level task is going to build the committed User Story. Every single task should be able to make (directly or indirectly) our Product Owner happy.

Each Sprint has a compass: The “sprint backlog” out of the Product Backlog. Every release has a compass: the Product Backlog out of the Roadmap. As you can see, each user story of the sprint is a glimpse of what our customer or Product Owner wants.

Iteration Zero
What about “Iteration Zero” ? By “Iteration or Sprint Zero” I mean that period of time when the team doesn’t feel able to deliver a “potentially shippable increment”. Before that, team needs to make some setup and “architectural” decisions.

In that special Sprint, many teams had found useful to make User Stories whose Product Owner is “The Team”. Even without the normal nature of the Product Owner and without the normal nature of User Stories, the Team needs to be focused. In those circumstances, the Acceptance Criteria are still extremely important as well as the Iteration Zero Review meeting. If not, you will find your team upset and lost. Without a clear goal (set by User Stories with Acceptance Criteria) it is highly probable get distracted and get developers implementing unnecessary stuff.

Once you start to deliver business value, that is, product features, you will find your team uplifted when they can see a satisfied Product Owner reviewing the completed User Stories of the Sprint. That experience is extraordinarily motivational and depends on the quality and completeness of what is delivered.

Before leaving I want to give you this quote from Mike Cohn’s book Stories Applied: For Agile Software Development

“A team is not allowed to deliver half of a feature. Similarly, a team is not allowed to deliver the full feature but at half the quality. By the end of each iteration the team is responsible for delivering working, tested code that can immediately be put to use.”

Related items

• Predictive Planning vs Adaptive Planning
• Scrum Release Planning
• Six Practices to deal with assumptions, risks and priorities
• Attaching Business Value to User Stories
• The task board shows WHAT and HOW we are doing during a sprint

We had an exciting week at Artinsoft. We are very close to an alpha state of our product named Aggiorno. What Aggiorno is about? Well,l I can’t tell you yet until release. But I can tell you I don’t know any other product claiming to do the same thing.

After several Sprints, we are ready to follow all the sacred guidelines for conducting Usability Tests. How do we know about those? Artinsoft foresaw this necessity and I was sent to the Usability Week 2007, Washington D.C. on April 22 through 27.

Roughly, I am leading the following steps

• Recruiting people based on a Screening definition.
• Scheduling the usability tests.
• Executing the usability tests
• Analyzing the usability tests

Recruiting people based on a Screening definition

To make a long story short, we found a way to form partnerships with high quality companies whose employees can be benefited with product. They found users (that fit our Aggiorno User Profile) able to willingly participate in our usability tests.

I am especially grateful to those companies for helping us to make a very usable product. I would let you know who they are very soon.

In this matter I just want to point out how important was to recruit just five users for this product stage. The reason is clearly explained in the following article Why You Only Need to Test With 5 Users of Jakob Nielsen. Nielsen was one of the speakers at Usability Week. I had the chance to talk with him after the training in order to discussing how to fit agile processes with Usability Studies.

Next steps

We setup our Usability Lab to run the tests at after work hours. I improve considerably my facilitator skills with each usability test, I love it!! Currently, we are evaluating the Morae software of Techsmith and in a future post I will let you know my opinion about it.

In this picture you can see me facilitating the test and explaining the setting of the usability lab to one of our users.

Keep tuned!

People who looked at this item also looked at…

• Agile is about Reality not Fairy Tales

Related items

• Collaborative environments to achieve goals
• No agile practices or processes are substitutes for a Roadmap or Vision
• Usability Test: Want valuable feedback? Recruit real user for testing
• Usability Process: Using Aggiorno Round #2
• The task board shows WHAT and HOW we are doing during a sprint

“Intensive and enjoyable at the same time”
“SCRUM is about people”
“Very intuitive and really gives you the sense that this is the natural way to go”

The latter comments belong to people who participated in our first Certified Scrum Master training in Costa Rica during the last week of August. We had the privilege of having Stacia Broderick and Tobias Mayer as the trainers. We really had a good time meditating and (most important) practicing all the agile principles behind Scrum.

What is Scrum?

I would say that Scrum is the natural way of thinking applied to project management of software development process. It enforces, in many ways, “working on your edge” in order to “achieve reliable innovation” as stated in the wonderful book Artful Making, of Rob Austin and Lee Devin. Similarly, Alistair Cockburn says in the book Agile Software Development: The Cooperative Game that “Scrum tells people to think for themselves”.

By my own experience, Scrum is the right process for software development based in Cooperation, Communication, Courage and Accountability. That list would augmented by Stacia Broderick (remembering what she emphasized in the training) with the following values: Commitment, Focus, Openness, Respect, Courage and Trust. On the other hand, Tobias Mayer was clear in this important point: “Scrum is a Collaborative Space involving developers and customers in ongoing dialog.”

The trainings

A nice feature of Scrum, is that you are able to apply it also in things not related to software. Successful Project Management in general requires commitment and the agile factor: Inspect and Adapt boosted by iterative cycles. In August, two private/closed Scrum trainings were held, the first one was directed to top executives of different software companies and the second one was directed to software developers and project managers.

People who looked at this item also looked at…

• Six Practices to deal with assumptions, risks and priorities
• Collaborative environments to achieve goals
• Coping with Quality Assurance Issues
• The wisdom of knowing when to use Agile
• Why do we estimate?

Related items

• Costa Rica Agile: Let’s bring the revolution here
• Collaborative environments to achieve goals