David Alfaro: Scrum Costa Rica

As the team develops in practicing real Scrum, team members see missing any scrum activity as something painful. Scrum is about people and making them work as a unit more powerful than the sum of the individual powers. That kind of power is lost when someone misses ANY scrum activity.

Off Sick

In practice, punctuality is a supreme rule and Scrum activities have priority over other work activities.

Unexpected events require good judgment, I don’t suspend a scrum activity because someone is sick, unless the Product Owner is sick for the Sprint Review, in such case we have a prioritized Product Backlog so we can pull up the next high priority User Story from it. Maybe the PO is not so sick to be present by phone. Conversely, a team member can present by phone in case of a unforeseen event. Slipping dates undermines commitment.

The team itself sees unfavorably when unjustifiably someone misses or arrives late to a meeting. And that person suffers the lack of involvement and tries hard for not suffer that again. The team become self-managed.

Everybody understand when some is off sick. You have to live with that when rarely occurs. Suffering means “Hey, those meeting are really important, I don’t miss them better”

In cases of someone’s sickness (I have dealt with that quite a few times) I try to keep that person updated, as much as possible, that’s the best way to reduce the absence effects.

On the other hand, if the team frequently experiences “being off” frames, scrum can hardly be done, and by my experience, that team is hardly a team.

I am really passionate when it comes to organizational culture, specially the attitudes and values it comprises. People who choose to be in a company for a while, coalesce around attitudes and values, that’s the lock-in factor.

How to take a sip of a company culture? Go to those corporate/company meetings when every is invited.

I willenumerate the common behaviors in a traditional company meeting, a company that thinks itself living in a Cold War world of secrecy and castes. Conversely, I’ll enumerate the common behaviors of a company meeting that promotes credibility and commitment. Effective leaders realize that Information Workers of today baulk more at any imposed directive. Information Workers grudgingly do something that they consider whimsical or not fully explained.

Old-Fashioned Corporate meetings

• Boring.
• Upper management is seen as Ivory Towers.
• Flaunting Managers.
• Patronizing, overemphasis on hierarchy.
• One way channel:  Management just want to talk, not conversation-friendly.
• TOO formal.
• Technology oriented rather than people oriented.
• Management is noncommittal when asked about goals committed in past meetings.

Engaging Corporate meetings

• Topics provoke interest.
• Upper Management is seen as connection hub for employees and customers, willing to hear.
• Presentations are succinct, result-oriented, but in a “telling story” fashion.
• Managers are humble: no problem in admitting mistakes.
• Informal enough: It’s not a bacchanalia, but is not a mass either. The environment tend to be conversational.
• People oriented (customer, employees) rather than Technology oriented. REMEMBER: Technology is a tool to satisfy PEOPLE. PEOPLE FIRST, then technology. When you think in that order of priorities, you end up with the most advanced technologies, or advanced enough at worst.
• Management commit to specific and reachable goals, and present results in following meetings.

The latter kind of company understands how important is getting people connected, how important is to listen and joining the conversation that employees are already happening in the hallways, and customers are already happening in the streets.

     For traditional Human Resources department (well, the kind that maybe is still needed in textile manufacturer factories in the third world) the most outstanding sign of its success can be said in terms of: being kind, payroll done on time and deliver required Wage Statements with punctuality.

However, for a Technology Company, such achievements are not enough. How different is a Software company from a textile manufacturer factory?

1. Employees are Knowledge Workers:

a. Replacing a position is very difficult. It’s not just a prescriptive position; it’s also a lot of knowledge and expertise that is lost when someone leaves the company. So Talent Management (attraction and retention) becomes the number one concern for HR.

b. Psychology of Knowledge Workers is peculiar, complex. Programmers can be Systematic, Pragmatic and/or Opportunistic Programmers. We can be more demanding in the reason and effectiveness of managerial orders or “team building” requests: We can sense easily when HR is doing activities just for the sake of doing them, or just because HR wants to show off its power. HR needs to understand Geek culture.

c. Good Software Companies move at Internet Speed; the best move faster. That kind of movement requires embracing a lot of change and innovation. That means tolerance to continuous questioning of hierarchical structures and building self managed teams. Open discussion and constructive conflict, problem understanding and coaching. Exploring new ways of doing things and anticipating risks and opportunities on a daily basis. And very importantly, HR needs to understand and appreciate the needs and aspirations of sophisticated talent. The company is not supposed to dealing with a HR that has been left behind of technology and opportunities. HR is meant to be an adviser.

d. Employees are smarter. Like saying that my readers are smarter than me (why? Visit this wonderful article), HR must have healthy perspective of her ego and thrive for collaboration and dialogue.

2. Recruiting is a challenge: Any high performance company requires the right set of skills, among others things. Not only highly talented people but also highly agile people, able to work in an agile company, able to define and follow a reached approach and willing to inspect regularly such collaborative approach. In many cases a strict description of a job position is not useful, the kind of company I’m talking about have people able to contribute beyond the prescribed position. They are resilient. Where can HR find that kind of people? What would you do if you have a product and want to reach people that fit your persona description? GO WHERE THEY ARE! Where are the talented people? Where are people that keep up with technology? Web 2.0 is helping a lot. Don’t come whining saying you are not from the Technology world and those techie fads like blogging, LinkedIn and Facebook are unbeknownst to you. That’s the way talking today, whether you like it or not. Need to have any good idea of a candidate for a position? Take a look at her profile in LinkedIn, it is updated? Is she well recommended? Has a very remarkable blog? What can you see through all that? A LOT! Sure you have to do it wisely and good timed.

3. Information sharing is vital, of course, we deal with knowledge. HR needs to foster transparency of fluid communication between teams, between teams and managers/executive board. Sharing knowledge? Blogging has smooth conversations in many ways, especially inside the company. Where can you keep all you employees’ profiles updated? Again LinkedIn is by most the proven answer. More and more I hear about companies asking their employees to update their profile in Linkedin. Intranets must reflect such willing to communicate. Facebook can be an interesting idea, but whatever the choice is, invest to have a good intranet that ease the talking through the company.

4. Compensation packages must be based on performance, ROI, and must be transparent, understood by anyone. Remember, money is not the most important motivator. I highly recommend this article of Mary Poppendieck about it.

5. HR is strategic. HR is not just coordinating parties. HR is not meant to be in charge of merely operative aspects of managing people. It could be at the highest organizational level reporting to the CEO or even the Chairman. HR is an adviser. That means a complete awareness and constant contribution of company’s strategy. That means a complete understanding of technology market and company’s product portfolio and current strategic and future needs as the company evolves.

The speed of our technology world can be daunting; the HR Manager must help the company to embrace change, must help to be agile.

Recommended articles:

• Are You Ready for an Agile Future? by Susan M. Heathfield
• The New “DNA” of HR by John Sullivan

Do you know any HR Manager (who fits this description) willing to work in Costa Rica? Let me know.

Yesterday I heard someone saying proudly that he was able to conduct successfully usability test for non-internal-use product using his employees because they fit the target user profile, so recruiting users for the “usability exercises” was easy. That comment made me feel impelled to state clearly why you should look for REAL users to conduct usability test, and BTW what does REAL mean?

In Aggiorno we are totally concern about letting our users to shape the product, to give them value in the way the want. In Aggiorno we have a rigorous process to find the appropriate users to participate in our usability tests, so I can tell you we are able to observe high quality behavior during the usability tests, why?

Carolyn Snyder states it clearly in her book Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces (Interactive Technologies) when talking about recruiting in general Usability Tests (that is, not only applies for paper-prototyping):

“Co-workers aren’t real users. Co-workers are usually not representative of real users, even if they talk to users every day or used to be users themselves. Your co-workers know stuff that real users don’t, such as your company’s business strategy, acronyms, brand, other products, and so on. Very likely, your co-workers know more about your interface—even if they haven’t seen it—than real users do. Therefore, the behavior of a co-worker usually isn’t a good proxy for what real users will do. (Possible exception: You’re designing an intranet or other interface specifically intended for employees of your company.) ”

Anyone who has assisted to any Usability Week will recall (as I do) the guidelines about recruiting once you have done a user profile that fit your persona description:

1. Look for people who never had seen the product you are going to test. Your target market has never seen your product, you need to watch the first impression the final users is going to get, the pains that someone you want to convince will go through.
2. Look for people who had never been in a usability test. Once someone participates in one Usability Test, that person, consciously or not, will learn what makes a facilitator taking notes, will try please or annoy the facilitator. Neutrality and the effort to emulate a real setting are lost. At least, allow six months between tests of different products for the same user.
3. Look for people unfamiliar with you. Any feeling linked with the familiarity with you easily mares the objectivity of the test. Consider possible user’s thoughts: “My friend/girlfriend/father/husband/boss has worked so hard in this product! I would be uplifted during the test, I’m sure this is a great product”, “I don’t want to be fired” “I don’t want to hurt my friend’s feelings” “I hate this guy, I will be sure to let him know that his product sucks”.

All the companies that charges you for recruiting users for usability tests set good part of their quality by finding users that comply with those guidelines.

Any “tropicalization” of such guidelines of methodologies doesn’t make them better. The realities behind them are still valid everywhere. Even when the product is created in a “tropical” country, there is no reason to loose those guidelines, specially when your target market is not “tropical”.

Still, I am not against reviewing the UX with co-workers, even so remember this piece of advice of Carolyn Snyder:

“You don’t want more opinions. I’ve yet to work at a company where there’s a shortage of opinions. The whole purpose of usability testing is to gather data from real users, not yet another internal opinion. It may not be wise to redesign an interface solely on the basis of internal feedback. If a co-worker gives you feedback that you don’t want to act upon (at least not yet), then you’re put in the awkward position of explaining why you’re apparently ignoring the valuable advice you asked him or her to give.”

Remember, a usability test is getting a REALITY CHECK, not yet another co-workers discussion. Is that easy Not at all! In the case of Aggiorno, we had had to go the places where our real users are, we had had to move our usability lab in order to get them. We want to listen, to watch as real as possible the Aggiorno use.

Feel free to let know any other useful guideline in recruiting users for usability tests.

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!

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!

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!!