David Alfaro: Scrum Costa Rica

Many productivity problems I’ve found in teams are closely related to collaboration barriers. Really, any time frustration or problem your team is up to, please take the time to see if the roots of the problem is because your team is not fitting the following description:

A group of people come together, create a sufficiently shared understanding of an equifinal meaning that enables coordinated behavior, and then the actual activities of task identification, decomposition, distribution, coordination, and integration of outcomes are accomplished in a manner that lasts long enough for the goals [...] are realized.

That’s the definition of Collaboration as stated in Luke Hohmann’s article Some Answers to What’s Collaboration? .

Enforce collaboration. Agile practicesare meant to enforce collaboration. Think about it:

• A dedicate workspace for team.
• The workspace is in itself a meeting place, so anyone can convoke a meeting at any time without waiting for meeting room to be available.
• The team is working in a circle-like distribution, everybody facing averybody.
• Pair programming.
• People participating in Daily stand-ups are talking to everybody, not only to ScrumMaster/Leader.
• The ScrumMaster enforces a shared vision.
• Openness in any meeting, specially in Retrospective meetings.
• Shared agreement in decisions, even in controversial matters.
• Reflect and Inspect what went wrong and right in each iteration (Retrospective meetings) in order to improve teaming.

Further reading

How to set up a productive working environment for Agile teams

Pair Programming with VNC

Organizing an Agile Modeling Room

People who looked at this item also looked at…

• Why do we estimate?
• Certified ScrumMaster Training
• Six Practices to deal with assumptions, risks and priorities
• Coping with Quality Assurance Issues
• The wisdom of knowing when to use Agile

Related items

• The task board shows WHAT and HOW we are doing during a sprint
• Costa Rica Agile: Let’s bring the revolution here
• Six Practices to deal with assumptions, risks and priorities
• No agile practices or processes are substitutes for a Roadmap or Vision
• Usability Test: Want valuable feedback? Recruit real user for testing

A False dilemma “involves a situation in which only two alternatives are considered”, states the Wikipedia, “when in fact there are other options”. Do you remember “If you are not with us, you are against us.”? Well, that happens when you fall in fundamentalism.

Fundamentalist anti-agilists got deeply offended because they say agile doesn’t follow a scientific approach, that it is offensive not treating Project Management as a Computer Science, alas! Turing is wallowing in his tomb!

Fundamentalist anti-cascadists say that traditional software management techniques are obsolete, that it ignores the innate nature of uncertainty of every software project, the virtue of self-managed teams always outperforms past management practices.

Before continuing, let me state clearly that I am a truly believer of High Performance Teams (HPT). In the way of getting a HPT you will inevitably  ended up practicing the agile principles.

That said, HPT’s are not always needed. So practicing agile is not always needed. Although most of the software projects fall in the uncertainty levels suitable for Agile, there a bunch of cases when direct and cascade-like managing is the best fit, so a group, rather than a team is needed.

Take the case of some massive web agencies or software sweat shops (very common down here in Costa Rica), or a well established  and reliable software migration processes. They are a typical production line. They’ve got efficiency through specializing and strongly documenting every phase  of the project development (or better said: production  line). Of course, there are parts of those processes that can be significantly improved by implementing agile practices. Even more, those kind of companies would want to jump to the “Product Creation” wagon where Agile is the best.

Be wise and take time for analyzing the complexity of the problem/project about to start. To do that, make your homework and use the Ralph Stacey’s Agreement &  Certainty Matrix against the project:

Identifying management decisions on two dimensions: the degree of certainty and the level of agreement.

When issues are Close to Agreement and Close to Certainty, Stacey says:

Much of the management literature and theory addresses the region on the matrix which is close to certainty and close to agreement. In this region, we use techniques which gather data from the past and use that to predict the future. We plan specific paths of action to achieve outcomes and monitor the actual behavior by comparing it against these plans. This is sound management practice for issues and decisions that fall in this area. The goal is to repeat what works to improve efficiency and effectiveness.

That is: use Cascade.
When issues are in the edge of chaos (Complex gray area), Stacey says:

This is the zone of complexity where the traditional management approaches are not very effective but it is the zone of high creativity, innovation, and breaking with the past to create new modes of operating.

That is: use agile.

Further reading

There is also a outstanding article in the Harvard Business Review called “A Leader’s Framework for Decision Making”. Really amazing article. Do read it! I’ve found a PDF version of it.

People who looked at this item also looked at…

• Six Practices to deal with assumptions, risks and priorities
• Coping with Quality Assurance Issues
• Why do we estimate?
• Certified ScrumMaster Training
• Collaborative environments to achieve goals

Related items

• Don’t take commitment and loyalty for granted
• Getting even more serious about your meeting problem
• Dynamics of the Daily Standups
• Being off and Team Commitment
• Cold War Company versus Value-Driven Company

Seth Godin has posted a wonderful checklist for solving the terrible problem of long unfruitful meetings. I have lost count of how many too long meetings have finished with the uncomfortable sense of being in the middle of nowhere.

Making an unshameful copy-paste act, the list goes like this:

1. Understand that all problems are not the same. So why are your meetings? Does every issue deserve an hour? Why is there a default length?
2. Schedule meetings in increments of five minutes. Require that the meeting organizer have a truly great reason to need more than four increments of realtime face time.
3. Require preparation. Give people things to read or do before the meeting, and if they don’t, kick them out.
4. Remove all the chairs from the conference room. I’m serious.
5. If someone is more than two minutes later than the last person to the meeting, they have to pay a fine of $10 to the coffee fund.
6. Bring an egg timer to the meeting. When it goes off, you’re done. Not your fault, it’s the timer’s.
7. The organizer of the meeting is required to send a short email summary, with action items, to every attendee within ten minutes of the end of the meeting.
8. Create a public space (either a big piece of poster board or a simple online page) that allows attendees to rate meetings and their organizers on a scale of 1 to 5 in terms of usefulness. Just a simple box where everyone can write a number. Watch what happens.
9. If you’re not adding value to a meeting, leave. You can always read the summary later.

Seth Godin is a genius in the marketing arena and product development and you better subscribe to his blog to get digestible chunks of wisdom on a frequent basis.

To that list I want to add:

1. Make everybody clear how much money the meeting is costing. Sum all the fractions of involved people’s salaries invested in being gathered X amount of time.
2. Boldly leave the room once the egg timer rings or when your have detected that the meeting has been ineffective.
3. Don’t wait for your boss. If your boss is late and anyone else is on time, start the meeting. Be consistent with the policy. Make him pay the fine as anyone else.
4. Identify issues that can be effectively resolved in the meeting.
5. Define clear Action Items to deal with detected issues that need to be resolved out of the meeting.
   1. Set a person to take accountability on the resolution of the issue.
   2. Measure the issue and set the metrics to know if the issue was clarified or resolved.
6. At the end of the meeting, review all the agreements reached, action items and people responsible  for those action items.

Recommended reading

Running Effective Meetings

People who looked at this item also looked at…

• The task board shows WHAT and HOW we are doing during a sprint
• Why do we estimate?
• The wisdom of knowing when to use Agile
• Don’t take commitment and loyalty for granted

Related items

• Six Practices to deal with assumptions, risks and priorities
• Don’t take commitment and loyalty for granted
• Stop being in pain
• The wisdom of knowing when to use Agile
• Cold War Company versus Value-Driven Company

More and more I see Products/Start-ups failing to sell once they go out to the market. Here’s my take on their main reason of failure.

Problem: The Product Manager has an Idea for a Product and starts throwing User  Stories to the Team. The Team consumes them using the discipline they have devised by themselves thought the Sprints. Because we are doing Agile and Usability Studies, everything just have to end up fine, right? So at the end of the engineering effort the website will progressively go from glugging some sales to enabling more servers to control the fire hose throwing sale requests. Reality? if your are managing your product as I just described your are playing at the jackpot. You will have chances to have a fire hose throwing sales, but those chances are the same as hitting the jackpot.

Listen! Synthesize!

A Product Manager has to have conviction of his/her vision and the understanding that detractors will try to take the Product down, I mean, we live in the human jungle, don’t we?  However, such a conviction has to be tempered with Company’s Business Strategy, market trends, with Subject Matter Experts opinions, and, most important, with fact your Product is changing the world for better, that you are solving a real pain. So listening has to be the key factor when envisioning a Product. After you have listened to all the aforementioned stakeholders the following two hardest steps are ahead: 1) Synthesize all that input into something really remarkable, feasible to implement and affordable for customers. 2) Communicate that synthesis to stakeholders and team in order to go for it.

The Mirage of Bad Assumptions in Review Meetings and Usability Studies

A Review meeting becomes obsolete if you don’t have a Subject Matter Expert to evaluate the Sprint results. If you are doing software for kids, guess what, the final acceptance word is for the kids to give, not for you. When I say Acceptance Word, I mean: From a Product stand point, we got a increment, which is apart from the achievement the team has accomplished. If the team delivers what you asked for but displeased your final user, congratulate genuinely the team achievement and blame your inability of transmitting what the user needed to be solved. Although is vital to have team members skilled in the Product domain, I strongly recommend not to have a SME inside the team. Paying consulting hours to a external SME disconnect him/her from the fear of trying to please the Product Owner. The SME doesn’t have to fear telling the Product Manager “Your baby is ugly” or “Your baby is cute but the bodysuit that is wearing today is horrible”.

On the other hand, Usability Tests are tricky. First of all, Usability Studies are not a substitution of Marketing Studies. The latter are inputs for the former. Why? Because as Usability Test Facilitator will always be able to find users that fit a wrong characterization of your persona. The persona can easily represent a market segment that is not big enough to make your product profitable.

Let’s dot the i’s and cross the t’s

Scrum and popular Agile practices are good to deliver complex products on time assuring Product Owner satisfaction and fulfilling his/her vision.  But Scrum and popular Agile practices don’t cover all the responsibilities of a Product Manager, even more, the Product Owner role is a subset of responsibilities of a Product Manager. The ScrumMaster needs to receive a vision from the Product Owner to transmit it to the team. The Product Manager articulates a continuously validated vision and Product Strategy and then articulate a continuously validated Product Backlog. Don’t forget build an Agile Release Plan with clear milestones.

Further reading:

• It’s always about the problem
• Market problems are still THE problem — even when you’re Agile! (Excellent post of my friend
  Luke Hohmann)
• Retooling Early Stage Development

People who looked at this item also looked at…

• Agile is about Reality not Fairy Tales
• Attaching Business Value to User Stories
• Predictive Planning vs Adaptive Planning
• Six Practices to deal with assumptions, risks and priorities
• Why do we estimate?

Related items

• Agile is about Reality not Fairy Tales
• Collaborative environments to achieve goals
• 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

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
• Six Practices to deal with assumptions, risks and priorities
• Why do we estimate?
• Collaborative environments to achieve goals
• Usability Process: Using Aggiorno Round #2

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

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.

People who looked at this item also looked at…

• Certified ScrumMaster Training
• Six Practices to deal with assumptions, risks and priorities
• Usability Test: Want valuable feedback? Recruit real user for testing
• The task board shows WHAT and HOW we are doing during a sprint
• Collaborative environments to achieve goals

Related items

• Don’t take commitment and loyalty for granted
• The wisdom of knowing when to use Agile
• Dynamics of the Daily Standups

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.

Related items

• Don’t take commitment and loyalty for granted
• The wisdom of knowing when to use Agile
• Getting even more serious about your meeting problem
• The impact of Human Resources in the Agile Enterprise

     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.

People who looked at this item also looked at…

• Six Practices to deal with assumptions, risks and priorities
• Why do we estimate?
• Coping with Quality Assurance Issues
• Certified ScrumMaster Training
• Collaborative environments to achieve goals

Related items

• Don’t take commitment and loyalty for granted
• The wisdom of knowing when to use Agile
• Getting even more serious about your meeting problem
• Cold War Company versus Value-Driven Company
• Usability Process: Using Aggiorno Round #2

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.

People who looked at this item also looked at…

• Why do we estimate?
• The task board shows WHAT and HOW we are doing during a sprint
• Collaborative environments to achieve goals
• Certified ScrumMaster Training
• Six Practices to deal with assumptions, risks and priorities

Related items

• Usability Process: Using Aggiorno Round #2
• Collaborative environments to achieve goals
• No agile practices or processes are substitutes for a Roadmap or Vision
• The task board shows WHAT and HOW we are doing during a sprint
• Aggiorno’s First Usability Study

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