Serving the Product Owner


The Product Owner role is highly strategic as she/he sets the direction fo the product that the development team will build. Often times this role is confused as someone that just writes detailed requirements and pass those to the team.

In other cases the Product Owner role is confused with the Project Manager role that makes sure that things work according to a planed scheduled, ironically meeting the schedule doesn’t guarantee that the product will perform well in the market or even solve a problem for the end users.

In the early days of eXtreme Programming a need was perceived for having in a team someone(s) with business  domain knowledge and that can voice the needs from the stakeholders [Beck99]. Scrum put more emphasis on that need and introduced the Product Owner role and made explicit that the she/he has final saying on the product.

It’s common to hear that the Product Owner’s primary tool is the Producto Backlog; that is factual but simplified to an extreme because there are other tools and knowledge from other disciplines that the Product Owner should master in order to do her/his job. The job of the Scrum Master is having that type of knowledge and guide the Product Owner’s learning via coaching and mentoring. 

Steps for Discovering the Product and the Product Backlog

Before even thinking in creating a Product Backlog there are several steps that often are ignored and because of that teams might end up building the wrong product, building it too costly or building it too late.

The first step is to understand the system in which the product will exit, this means not only thinking narrowly in the product but thinking systemically. It’s vital to understand that is not about saying yes to all client’s request but systemically analyzing all the variables that will influence product decisions [Larman17]. 

The second step after understanding the system consists in identifying what is the problem that the product aims to solve.  From a Lean perspective the product doesn’t really solves a problem, instead will mitigate it and by evolving the product better mitigations will be discovered.

The third step is evaluating with the development team the product technical feasibility; feasibility analysis can also be extended to other areas like finance, legal, marketing and others. A common trap that many teams fell in is to invest too much time analyzing and discussing feasibility instead of start building the product in little increments; it’s worth to remember that Scrum says start earlier and validate the product hypothesis as soon as possible.

The fourth step is discovering what features the product will include, who will be the users, and how they’ll benefit from using those features [Watts17]. The techniques from Innovation Games described by Hohmann [Hohmann07] have proveen to be very valuable for discovering and understanding a product. An important recommendation is to use those techniques in a face-to-face workshop with stakeholders, the Product Owners, representatives from the Development Team and the Scrum Master as a facilitator.

The fifth step consist in putting all product details in a Product Canvas [Pichler10] in which is very useful to include paper prototypes of how the product will look.

The sixth step is to discover the PBIs that will form the backlog and order them. User Story Mapping [Patton14] is my favorite technique for doing the discovery part.

The seventh and sometimes controversial step is to estimate PBIs in the Product Backlog. This is controversial because estimates often times can be interpreted as hard commitments. In actuality estimates are just that estimates that will need to be reestimate as we learn more about the product. Further, and estimate is a placeholder that remembers us that we need to keep talking and refining our understanding about a PBI.

The eight and last step is to define the product strategy [Pichler16], that has a very important component that is the Release Plan that defines how frequently the team intends to ship releases out of the door. The Release Plan must also include other important events that need to happen in alignment with the development of the product, event like a marketing campaign milestones, provisioning IT infrastructure, legal contracts, etc.

Lastly, whichever product that has been discover, alongside its backlog and Release Plan, will change in order to accommodate to market conditions and other forces. This is completely expected and should be embraced as the whole point in being Agile is adapting the product as we build it.

Thinking in the Backlog as a List

One of the recurring themes that I’ve observed in many organizations is the over complexation of the product backlog concept.  Agile Lifecycle Management electronic tools add additional terminology, interface and options that one needs to learn before even attempting to create a backlog.

Some Project Managers also contributed to the confusion thinking in the backlog like a new unidimensional version of a tradición Gantt chart where they can still apply technique that they know. 

Richardson [Richardson05] bring some light by pragmatically presenting the backlog in an analogous way and connecting it to a grocery shopping list.

Following that train of thought a grocery shopping list has characteristics such as:

  • Publicly visible and available meaning that there is no secret Product Owner’s list, instead there is a list that everybody in the Development Team has access for editing but only the Product Owner can change the order of the items
  • Prioritized using several criterion besides only estimates for duration
  • In a timeline  that implies that the items in the list can be completed in weeks or months but definitely not years. If the team runs out of time items in the bottom of the list might be sacrificed
  • Active and not static that means that the list will change over time to reflect the most current learnings of the Development Team, the Product Owner and the stakeholders
  • Measurable in a way the some qualifier can be applied to determine when an  item is completed or not
  • With a clear purpose that assure that if we’re implementing those items is because they’ll be part of a product that will be shipped, not just implementing items that may end up archived

Tools for Keeping the Product Backlog

Nowadays in the market you can find several electronic tools ranging from the ones that present a simple online task board to the ones that are part of a larger ecosystem with traceability across multiple tools.

A common feature in the majority of this tools is that they seem to be oriented to generate reports for upper management with metrics and indicators, and tracing back the work to who in the team is doing (or suppose to do) what.

Another characteristic of these tools is that they don’t allow a great degree of experimentation because they were designed as out of the box solutions that include terminology and standardized processes. Going back to Toyota roots is good to remember that we want tools that allow experimentation and continuos improvement in the tools themselves and in how the teams uses them.

Taking the above into account, a very simple alternative is to use Google Spreadsheets for keeping the backlog and a wiki for capturing additional details about PBIs. Even if this idea seems too amateurish it respects the principle of simplicity, saves costs, promotes experimentation, reduces the learning course and facilitates communication.

It is not just my personal experience observing good results with the tools described above but also authors like Larman and Vodde [Larman10] have observed the same at a much larger scale.

Including the Product Owners in the Team

Ideally Product Owner should be a full time member of the team but things like outsourcing and offshoring have distorted that.

If the Product Owner works for an organization that hires another organization abroad is highly recommended that she/he travels at least once a month to work and spend time with the remote team(s).

Having physically present the Product Owner is very valuable especially in the Sprint Review, the Sprint Retrospective and the  Sprint Planning that will come the day after. 

If the Product Owner participates in the Sprint Retrospectives she/he will be able to hear first hand about the problems and inefficiencies that the team suffered during the Sprint and also contributing her/his point of view. 

Similarly by being present the Product Owner will be able to learn in all sincerity how her/his work is perceived and think in what corrections she/he might need to do to better interact with the team.

Another benefit of having the Product Owner in the room is hearing from someone that is more connected to the business, and that can provide a different perspective about what to improve.


Product Owners have the potential to reshape the industry with new and innovative products but that is unlikely to happen if Product Owners lack an Agile mindset along side with an entrepreneurial spirit and solid knowledge about their business domains and the techniques and tools of their craft.

Practical experience is esencial and I consider that for a Product Owner having the opportunity to work in several products, one at a time, in a time horizon of let’s say five years is more enlightening that just writing user stories for the same product during the same period of time.

Finally it’s worth emphasizing a fundamental concept: the Product Owner role and in fact the idea behind having a Scrum Team is having a highly effective and motivated team that builds a product that can have a positive impact in the market.


Beck99 Beck K., 1999. Extreme Programming Explained: Embrace Change, Addison-Wesley

Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley

Watts17 Watts G., 2017. Product Mastery: From Good to Great Product Ownership, Inspect & Adapt Ltd

Hohman07 Hohman L., 2007. Innovation Games: Creating Breakthrough Products Through Collaborative Play, Addison-Wesley Professional

Pichler10 Pichler R., 2010. Agile Product Management with Scrum: Creating Products that Customers Love, Addison-Wesley Professional

Patton14 Patton J., 2014. User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media

Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting

Richardson05 Richardson J., Gwaltney W., 2005. Ship it!: A Practical Guide to Successful Software Projects, Pragmatic Bookshelf

Larman10 Larman C., Vodde B., 2010. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison-Wesley Professional

Serving the Development Team


Decades ago Toyota coined a phrase that represents its culture “Great people make great products” [Ohno13]. This represents a human-centered approach focused in developing people’s talents so they can build awesome products using their creativity and motivation.

Toyota among other things was the first automaker that didn’t thought that the key in its production process were the processes, tools, raw materials or capital; instead they trusted and empowered its people so they themselves discover how to do their work better and better. 

The Toyota Way has been tried to be imitated in many countries and industries with different levels of success, but there is simplify one ingredient that can’t not be copied and that it’s the Toyota people. 

Similarly Scrum is emphatic about saying that the Scrum Team must be self-organized, empowered, motivated, with individuals that are not right at all times and where is safe to experiment so true learning can occur constantly.

In a way a Scrum Master wouldn’t be doing anything that a coach in Toyota has not done before, the substantial difference though is that software is not directly comparable to manufacturing.  There is however a principle that can be extrapolated from Toyota: leaders as teachers and coaches that serve the teams.

The Self-Organization Panacea

Self-organization is not good for everybody because not everybody likes the idea of not having a manager that tells what to do at all times. In fact, I’ve encountered in some teams that they feel intimidate by the responsibility of making their decisions and I’ve have even observed a team asking back for a manager to direct them.

Something that helps to mitigate the initial fear to self-organization is clarifying that not because the team will self-organize will lack leadership, is just that leadership will be granted by the team to and individual based on her/his knowledge, charisma and respect. This is a deviation from the tradicional hierarchical structure that dictates team members who they must follow. 

In a self-organized team it’s very common to see that team members tend to listen and follow a fellow team member that carries knowledge, learned something interesting and wants to teach it, or came up with an innovative solution to a complicated problem.

Consequently can be said that leaders still exist in a self-organized team but their leadership rotates and is recognized based on their own merits.

The Challenge of Constantly Self-Organize

When the initial fear to self-organization has been overcome the next challenge presents: how to keep the team self-organized. It’s very human to get back to old bad habits as soon as we encounter problems with the new approach, even if we know that old good known is bad. I’ve seen cases in which upper managements gets impatient and decides to revert to command-and-control leaving people confused and even killing morale.

Something that helps to keep self-organization alive is to have a highly motivated team. From this perspective if motivation will positively impact in self-organization  we can infer that we need to star looking at techniques and approaches that can help us to keep the team motivated.

Daniel Pink [Pink11] presents a model based in three pilar that according to him if cultivated successfully can really keep individuals motivated; these pillars are:

  • Autonomy
  • Mastery
  • Purpose

I have experimentally applied this model in software development teams and I can say that its works and not only helps to motivate team members but also enables a true learning environment.

Myths About Self-Organizing Teams

Self-organized teams has been associated with many myths that of course are not factual. The following is a list of the more common ones that I’ve heard/observed over the years:

Self-organizing teams don’t know how to do a retrospective. This problems is not exclusive from self-organizing teams, that is why teams need a designated retrospective facilitator (Scrum Master)
Estimations from self-organizing teams are the worst There is no solid statistical information that proves or disproves this claim. Further, there is no direct correlation between self-organization and estimates precision
Self-organizing teams accumulate more technical debt because there is no single responsible for code quality Self-organization in combination with mastery, pair programming, test-first development and other practices can improve code quality and knowledge inside the team
In a self-organized team when someone quits all hers/his knowledge is gone The risk of loosing knowledge will be always present and is even worst with siloed knowledge. Self-organization tends to break those silos of knowledge because it allows better and more horizontal communication
Self-organized teams are dangerous for organizations because they can evolve into unions and call on strikes If workers conditions are not fair then there will be always the chance that workers self-organize in unions but this has nothing to do with self-organized Scrum Teams. Organizations should not use this as an excuse for not trying Scrum, instead they should look at this as a symptom of other dysfunctions. 

The Scrum Master as a coach needs to help people in organizations to start questioning these myths and maybe discovering some others that they have in their own context. By questions myths people start thinking why they believe in something that is not factual and that opens the door for other positive changes.

Team Dynamics

Let’s start by differentiating a collections of individual from a team; a team has synergy and creative power that is far superior to a group’s of individuals that recently met.

Teams that jelled and act like a cohesive unit share some characteristics such as:

  • Leaders are from the team and leadership rotates on-demand
  • The team is well equipped to deal with internal conflict 
  • All team members can voice their opinions without fear to be bullied or criticized  
  • Working agreements are known and followed by all team members
  • Team members share goals and motivations
  • Team members held each other accountable for performance and commitment
  • Long lived team with the same team members for years
  • All team members are full-timers 

And if we talk more specifically about and Agile Team we can say that it should have key attributes like:

  • Working agreements that are constantly inspected and adapted by the team itself
  • Awareness of the limitations, competencies, capabilities and fears of each team member
  • Effective and efficient collaboration among team members

From Homogenous to Diverse Teams

Typically when new teams are form upper management tend to make them homogenous en terms age, gender, work and academic background, system of beliefs, etc. 

Against common belief homogenous teams tend to lack self criticism and creative thinking, they experiment more instability and conflict and ultimate disband faster than heterogeneous teams [Pfeffer06].

A more promising alternative is to form team which diversity in mind. Gender diversity is a great starting point toward heterogenous teams.

Starting by gender diversity other options can be considered next:

gender —> age —> ethnicity  —> academic background —> etc.

A word of warning, heterogenous teams needs to be co-located so they can jell [Larman10]. Empirically I can state that heterogenous globally distributed teams consume a lot of time in trying to communicate effectively and that eventually affects the product.

The Obsession to Measure Team’s Performance

One of the most effective ways that I know to kill colaboración and transparency in a team is just by offering individual incentives, because those incentives are normally focused in increasing individual performance at the cost of team’s performance.

Performance can not be easily measure with just one metric and any metric that upper management decides to use can be gamed and it’s even worse when bonuses were offered. 

On the other hand, things like work stability and a fun working environment tend to foster collaboration and camaraderie among team members. Work stability is fundamental because the type of work that a team member does will change over time, and because of cross training and self-organization team members will be require to do more than type of work. 

Working agreements that promotes respect, learning and constant collaboration have an overall positivo impact on the team’s performance.  

Shared goals and benefits with the organization have also a positive influence in performance.  By shared benefits I meant to say that team members feel really rewarded when they build a product that is successful in the market, but then the organization should also considered sharing the gains from the product with the team.

Building New Teams

Teams are not form over night, in fact there are studies that identified several stages that a team would need to pass before being consider a real team.

If we talk about forming a new team from scratch the firs step is of course recruiting.  What I’ve seen working better for recruiting developers is that during the interview the candidate actually writes code.

Some variations might include pair programming with he candidate or coding katas. The key point is not to loose sight of what we’re after with this interviews and the is  seeing how the candidate can solve problems by coding solutions.

It’s feasible to build a productive team with excellent developers but is far more costly and sometimes even impossible to build such a team with developers that don’t know their own craft [McBreen01].

Definition of Done Created by the Team

One of the characteristics of a self-organized team is that they have the responsibility to create, together with the Product Owner, a Definition of Done that can be used to qualify all Product Backlog Items as truly done.  

There is sometimes confusion around the Definition of Done being static or dynamic, in actuality it is dynamic and will be perfected Sprint after Sprint. Actually a recurring topic during the retrospective is that teams feel that their Definition of Done needs to keep evolving.

The Definition of Done should be constantly changing as a reflection of the continuous improvement (kaizen) culture of the team that aims to have a Definition of Done that is good enough to allow the team to take Product Backlog Items all the way to production in the shorter time possible.

Making the connection with Toyota, the Definition of Done is like a check list that a car has to pass so it can be considered shippable and sellable.

Continuing with this analogy, we could see each individual car as a product formed by thousands of parts where each individual part needs to meet the Definition of Done.

There are couple of ways that I use for representing the Definition of Done:

  • A flipchart  with all the steps of the Definition of Done listed on it
  • A matrix where rows are for Product Backlog Items and columns are for the criterion on the Definition of Done. This matrix can allow to see which PBI has meet what criterion or vice versa.

The Value of Engineering Practices

A very simplified way to assess the capability of a team is by looking at how much its team members know about eXtreme Programming and how they use its practices.

For the many practices described in eXtreme Programming [Beck04] there is no prescribed order in which a team should start adopting them. However, I consider tome of them essential:

  • Continuous Integration  at smaller and smaller intervals of time in the main line [Kim16]

Following the XP mantra: Divide —> Conquer —> Integrate

  • Collective Code Ownership allowed by Feature Teams que knows the feature code in all layers and components. Notice that is not only about having cross functional teams but also cross component teams [Larman10]
  • Refactoring constantly improving the code internals without disrupting the output [Kerievsky04]. It’s easier to refactor when you have test built that can be execute and validate that the output has not changed. From a Lean perspective refactoring could be understood as something connected to kaizen ultimately reflected in the code
  • Simple Design that means keeping the systems design within the limits of comprehension without adding extra architectonical complexity [Fowler02]
  • Test Driven Development which out of all XP practices is the more difficult to internalize and master because it requieres a lot of study and discipline; furthermore, this requires that developers think of code in a way they are not naturally used to do (this often time generates resistance) starting by thinking and programming the test and working in very short cycles [Beck02]

The practices described above must be applied correctly and with discipline so the team can be able to produce clean code that can be put into production in very short periods of time, this can enable  immediate  feedback from users and stakeholders than can really see working software. The former is aligned with Lean thinking that says that the more that we incentivize the flow of parts the more that we are reducing the throughput time.

If we think in scaling and now we have multiple teams (more than eight teams and each team with seven to nine developers) it’s even more important that all teams follow XP practices like TDD, continuous integration and simple design so we can avoid the pitfall of ending up with a huge code base that nobody understands.


We live in an era where all simple software that could have been possible created by a solely developer has been already written, thus is important to acknowledge that software now and in the future will come from teams that need to discover how to collaborate more effectively.

Because software development requires a high level of creativity and that is tightly connected to motivation and commitment, it’s extremely relevant that the Scrum Master learn about techniques, tools and paradigms that can help her/him to better serve the team.

A final recommendation, discovering techniques, tools and paradigms shouldn’t be a path only the Scrum Master walks, on the contrary should be the whole team that embarks in this journey of learning.


Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw Hill

Pink11 Pink D., 2011. Drive: The Surprising Truth About What Motivates Us, Riverhead Books 

Pfeffer06 Pfeffer J., Sutton R., 2006. Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management, Harvard Business Review Press 

Larman10 Larman C., Vodde B., 2010. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison-Wesley Professional 

McBreen01 McBreeen P., 2001. Software Craftsmanship: The New Imperative, Addison-Wesley Professional 

Beck04 Beck K., Andres C., 2004. Extreme Programming Explained: Embrace Change, Addison-Wesley; 2nd edition 

Kim16 Kim G., Debois P., Willis J., Humble J., 2016. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations, IT Revolution Press

Kerievsky04 Kerievsky J., 2004. Refactoring to Patterns, Addison-Wesley Professional 

Fowler02 Fowler M., 2002. Patterns of Enterprise Application Architecture, Addison-Wesley Professional

Beck02 Beck K., 2002. Test Driven Development: By Example, Addison-Wesley Professional

Agile Coaching


One of the more popular titles out there is “Agile Coach” and prove of that is the number of job seekers that have it listed in her/his profile, but then there is a much smaller number of people that know what this implies and the qualifications of a good coach.

In Toyota a coach was a mentor that knew the different types of work so well that can teach others and even replace workers. Further, a coach needs to return frequently to the gamba to work and stay real and by doing this keep improving her/his technical skills [Ohno13].

From a different school of thought comes the notion that a “professional coach” doesn’t need to know the business domain in order to do an effective coaching intervention. This school of thought focuses in polishing coaching skills applicable to any context.

My personally postulate is that a Scrum Master must align with a coaching school or approach that allow her/him to know three facets: the work, the human and herself/himself.

Respecting the Client’s Agenda

A coach should prioritize the client’s agenda over hers/his, this means that the client’s problems, concerns, ideas and opinions take precedence over the coach’s [Kimsey11]. If the client is wrong, at least from the coach point of view, the job of the coach is help the client discover why she/he might be wrong and start exploring alternatives. 

I’ve encountered situations in which and Agile Coach or several of them got hired to transform an organization and they star by telling team members that everything they’ve been doing is plainly wrong, that they did Agile wrong. This approach not only generates resistance from the coachees but also contradicts the principle of respecting the client’s agenda. 

Furthermore, what stated above might create the illusion that there is only one good way to be Agile and the the Agile Coach holds the keys for true agility. Of course this is just illusion and even contradicts the agile principles that promotes discovery, experimentation and respect for humans. 

Maintaining  Neutrality

I’ve observed that in many cases the Agile Coaches became the new version of the  managers obsessed to get results at all cost, this maybe happened because organizations paid coaches for results and misunderstood Agile as a management tool good for getting faster results by putting extra pressure on people.  

Even if the client’s agenda might be about going faster, increasing productivity and get 110% of each team member; the coach’s job will be remain neutral and help the client discover other options for getting the result following different paths or even better helping the organization to better define its systemic goals.

Neutrality would also need to be present when the teams want to focus on technical work that not necessarily contributes value or keep insisting in using inefficient engineering practices;  again the idea is that the coach shouldn’t tell people that there’re wrong but help them instead discover that they could be others better ways to work.

Coaching Stances

Coaching stances are diferente operating modes for a coach, depending of the coachee and the situation the coach will need to change from one stance to another.

Lyssa Adkins [Adkins10] identified the following stances:

  • Coach as a Mentor 
  • Coach as a Facilitador
  • Coach as a Teacher
  • Coach as a Problem Solver
  • Coach as a Conflict Navigator
  • Coach as a Collaboration Conductor 

Each of these stances has its own characteristics that need to be know and master by a true Agile Coach.

Logically a coach has talents and personal preferences that will make her/him gravitate  more towards one stance but that is no excuse for not knowing, practicing and being proficient in all stances. 

In fact, a skillful Agile Coach will be able to naturally switch stances depending of the situation and the context.

Coaching Techniques

There are several professional coaching organizations that have identified and developed several techniques for one-on-on coaching, team coaching and even organizational coaching. Personally I consider that is a good thing to first have abroad knowledge of the discipline of coaching and then  specializing and excelling in a few things.

Some of my favorite coaching techniques are listed below:

  • Active Listening 
  • Powerful Questions
  • Reflection

Beyond those techniques I think that their effectiveness is directly correlated to the degree of self-awareness that the Agile Coach has been able to developed.


Coaching is an exiting field and has many applications in an agile team where individuals need to interacted frequently and effectively. Thus is expected that the demand for Agile Coaches tend to rise in the coming years as Agile will keep getting more and more traction. 

Nevertheless, embarking in the Agile Coach journey requires a lot of personal commitment and self discipline for first learning about yourself and then about coaching.

As Lao Tzu said it “Know yourself and you will win all battles”.


Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw Hill

Kimsey11 Kinsey-House H., Kinsey-House K., Sandahl P., Whitworth L., 2011. Co-Active Coaching: Changing Business, Transforming Lives, Nicholas Brealey; 3rd edition

Adkins10 Adkins L., Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, Addison-Wesley Professional

Agile Facilitation


The Scrum Master work often times requires that she/he facilitates discussion among developers and a key component of that is that the discussion stay focused, productive, short and in the right level of energy and respect.

The facilitator rol as such has a lot to do with helping the conversation flow without monopolizing it and imposing her/his own conclusions. Very frequently a facilitator has to resist the temptation to tell the team what to do and how.

Other times facilitation has more to do with breaking the silence by making a question that generates valuable discussions [Schein13]. In occasions facilitation implies making that uncomfortable question that no one wants to ask.

Whichever is the situations, the Scrum Master needs to be prepared and have in his toolbox techniques, tools and knowledge that allow she/he to act as facilitator of the communication both inside and outside the team.

To Be or Not To Be on Agreement

Often times a developer or several developers might not be on agreement about technical aspects of the work and in the best case scenario disagreement is voiced and worked out somehow; in a not so good scenario, disagreement is there but nobody says nothing about it and the team is a collection of individuals with fractured opinions.

When facing disagreement a very common reaction is to fear it and neglect or ignore it, this means trying to live in an “artificial harmony” state in which everybody seems to be on agreement and seems not to divergent opinions.  The problem with “artificial harmony” is that is a symptom of a dysfunctional team [LencioniI02]. 

Like in sports and other domains  having a dysfunctional team rarely conduces to productive work. Seems counterintuitive but actually talking about disagreements clears the air for the team and enables it to achieve better performance.

If we see it from a different angle, discomfort is part of team dynamics. In fact, discomfort is the basis upon which dialog emerges and that in time triggers creativity and buy in.

Expressing the former in a simple model:

Divergence ——-> Groan Zone ——-> Convergence

The job of the Scrum Master as a facilitator is not to prevent that the team enters the “Groan Zone”, on the contrary, the Scrum Masters helps the team to safely enters the zone, stay there for a while and then leaves with an agreement that was reached using converging thinking [Schwarz16].

It’s important to notice that convergence doesn’t necessarily  implies that the best solution has been found or that the team has all correct answers, it just creates a hypothesis or presents an idea that needs to be validated by trying it. Needless to say, if the hypothesis or idea doesn’t provide good results when implemented then the team repeats the cicle and tries one more time.

Techniques to Help Convergence

Often times teams can engage in heated debates that can last minutes and even hours; the conversation can be valuable but is still hypothetical until teams start actually working in implementing something. Speaking in Lean terms,  abstract conversations and debates are too far distant from the gemba.

These are some basic techniques that can be very useful to help the team converge and reach agreement:

  • Fist of Five where five fingers mean totally in favor, one finger means totally opposed and three fingers mean go with the room and support what the majority decides 
  • Dot Voting is a technique that requires that each individual on a team cast her/his vote using a dot next to the option or alternative that she/he supports; votes are casted on a easel pad or whiteboard
  • Majority Vote consist in allowing everybody to vote on options and whichever that get more that 51% of the votes wings, this technique can work well with large groups and even electronic tools can be used to cast votes. A general recommendation is not to have too many options 
  • Decider Protocol requieres that someone formulates a motion, someone else seconds it and then everybody needs to vote the motion raising hands; the team decides how many votes are needed to pass the motion

It is not advisable that the Scrum Master make business or technical decisions without deep knowledge about the discussion topic. However, there are exceptions in which the team can not decide regardless of several attempts and facilitation techniques.   In extreme situations like this the Scrum Master may decide to switch stances and vote to break the tie.

Listening Facilitation

Taking a step back, in many situations facilitation is needed because people in the team are just not listening to one another and even if they’re listening they’re not understanding what the others are trying to say.

Kaner [Kaner07] proposes several facilitation techniques that can help the team to better listening, these are some of them:

  • Stacking means defining a sequence for people to talk one after the other so not everybody try to talk at the same time
  • Paraphrasing someone talks using similar words and then asks the person who originally presented the idea if it has been well captured
  • Drawing people out helps not only who wants to propose and idea or voice an opinion but also who listens
  • Making the space for people in the team that hasn’t talked, talked too little or got interrupted. This technique is specially valuable to help introverts to ask questions or present ideas

Listening techniques are vary handy tools in the Scrum Master’s repertoire because they facilitate the communication process and help to build understanding.


It’s factual that one of the facets of a Scrum Master is being a facilitator but is also true that this is not the only facet and that even though is important should not consume all her/his time and energy. Ideally the Scrum Master should aspire to cultivate a culture of self facilitation inside the team. [Hackman02]. 

Facilitation starting from listening or even better from effective listening is one of the best tools that a Scrum Master can use to help the team converges on an idea, decides to experiment and ultimately validate it.


Schein13 Schein E., 2013. Humble Inquiry: The Gentle Art of Asking Instead of Telling, Berrett-Koehler Publishers; 1 edition

Lencioni02 Lencioni P., 2002. The Five Dysfunctions of a Team: A Leadership Fable, Jossey-Bass; 1st edition

Schwarz16 Schwarz R., 2016. The Skilled Facilitator: A Comprehensive Resource for Consultants, Facilitators, Coaches, and Trainers, Jossey-Bass; 3rd edition

Hackman02 Hackman R., 2002. Leading Teams – Setting the Stage for Great Performances, Harvard Business Review Press

Kaner07 Kaner S., 2007. Facilitators Guide to Participatory Decision-Making, Jossey-Bass; 2nd edition

Toyota, Lean, Agile and Scrum


Much has been said and written about Toyota and how its practices have influenced and sometimes revolutionized the working environment of companies from different sectors worldwide.

Toyota has been the cornerstone on which Lean principles were grounded and these in time have greatly influenced Agile and the Scrum framework.

We often times forget to go back to Scrum roots in order to understand why we do things. Scrum has become popular but many people continue to ignore the pillars on which it is based and this can brings negative consequences.

The Machine that Changed the World

Cars have had a great influence on the transformation of societies and their way of producing has been definitive when it comes to modernizing manufacturing.

In fact, no other machine in the modern era has had such a big influence on the way workers, materials, capital, knowledge and equipment have been organized [Womack07].

A more efficient form of organization −following Lean principles and  avoiding various forms of waste− leads to greater productivity, better aligned with the market and impacts positively the well-being of the teams: hence the recommendation that Scrum Masters know and try to apply Lean manufacturing principles.

The Essence of the Toyota Way

Taiichi Ohno [Ohno13] greatly summarized a fundamental principle: the misperception that comes from being too far away from the gemba. To clarify errors of perception Ohno suggests a simple “Go and see” practice.

Unfortunately, this principle is not frequently seen in Scrum Teams that intended to supervise or evaluate the work by just reading reports and seeing visual indicators. 

A second fundamental principle is “stop and fix” which literally meant for Toyota to stop the production line as soon as a quality problem was detected, apply the “five whys” technique to find the root cause of the problem, mitigate (not find the perfect solution) and then resume the production line.

The “stop and fix” principle also had a second purpose: to force continuous learning. In general, adults, or at least a great number of us, do not want to continue learning and therefore a practice like this forced Toyota developers to stop working, reflect on what was not working well, propose possible mitigations and experiment with them.

Contrary to the “stop and fix” principle many Scrum Teams out there frequently tend to pile up defects and even create a backlog for them where they got recorded but ultimately forgotten; this practice not only contradicts a Toyota principle but also doesn’t improve engineering practices nor contributes to expand developers’ knowledge. Doing more work that is lacking quality or doing it in a more predictive way won’t positively impact the product that will keep accumulating technical debt. 

The list of Toyota Principles includes many [Liker04] but here only one more will be mentioned: “kaizen at infinitum”. This principle is about people continuously learning and expanding their knowledge, that eventually greatly pays off in the form of higher quality products [Senge90].

Very frequently I encountered Scrum Masters that are after learning the “Scrum best practices” which in reality doesn’t exit, and if they do those are tightly connected to a particular context and for that reason can not be directly extrapolated. Instead of embarking on that imposible quest, the Scrum Master should turn her/his attention to uncover how to build an environment of constant learning in which people can experiment with different practices. Paraphrasing Senge [Senge90] the differentiator of an organization (and its teams) is the wealth of acquired knowledge and the willingness to keep learning.

Lean, Respect and Waste

The Lean approach for manufacturing could be simplistically expressed using the following formula [Ballé14]: 


Where RESPECT refers to respect for the workers and their creativity,  and the  upper management commitment to provide all the necessary conditions for workers to develop their maximum potential.

From a traditional Lean perspective the central theme is to maximize activities that contribute value and minimize activities that generates waste. Wasteful work then can be classified into to broad categories: urgent waste that has to be reduced inmidiatlye and identified waste for which there is no mitigation that can be applied immediately.

Waste can take many forms, some of the most common are:

  • Overburden and stressed workers
  • Bottlenecks
  • Waiting in queues
  • Handoff
  • Wishful thinking 
  • Dissemination of information 

And many others that are particular to individual teams and context.

Consequently, part of the job of the Scrum Master is to positively contribute to create a culture in the team that values respect, really embraces and uses it as a pillar to work collaboratively to identify forms of waste and possible mitigations.

The opposite would be a culture of no-respect where forms of waste are not identified and even if so no one in the team does anything about it; no-respect can also lead to demotivation and won’t help the team to improve its own practices.  

Agile: Decades After and There is Still Confusion

It is very common these days to hear the very popular term “Agile” as a prefix  of many things like Agile Coach, Agile Adoption, Agile Inception and many others. However there is a sustancial problem that remains unsolved: people and organizations are trying to copy and use something that they haven’t completely understood yet.

Because of this one of the big challenges for the Scrum Master is to educate others so there is an overall better understanding of what Agile really is. One valuable tool that can help with this is the Agile Manifesto but this could not be sufficient due to its concise and lightweight nature.

Another tool is to educate using terminology and concepts that are frequently used in the Agile space and connected to software development.

Notwithstanding, I’ve found in practice that people and organizations tend to better assimilate Agile when it’s presented from a historical perspective that describes its evolution starting from its roots in Toyota, the connection with software and the key influence of eXtreme Programming.

Furthermore, it’s very valuable to highlight the connection between Toyota and the current practices of DevOps [Forsgren18].

Whichever path you choose to explain Agile I think is important to recognize that Agile has a lot to do with things like:


Equally important to mention is that Agile keeps evolving as more and more agilist gain experience and take Agile to other domains, there are for instance two examples of agile evolution: Modern Agile and The Heart of Agile. I’m expecting that this evolution continues as Agile itself is an evolving concept.

And That is How We Arrived to Scrum

It is true that Scrum is an Agile lightweight framework that is team-centric and used by teams to collaboratively build products, but it’s also true that Scrum conceptual simplicity could led to be erroneously interpreted as a simple prescription of a set of meetings and the use of post-its on a taskboard.

Scrum needs then be understood from a more educated historical perspective and also in connection with other disciplines that complements it, more simplify put:


If we talk about lineage it’s vital to understand that Scrum is not a revolutionary framework; instead it comes from the influence of the Toyota Production System that originated Lean Manufacturing and both influenced in time Agile and  Scrum. 

And if we talk about intersections Scrum intersects with a long list of disciplines  such us:

  • Queueing Theory
  • Systems Theory
  • Industrial Empirical Process Control
  • eXTreme Programming
  • Caos Theory
  • Soft Skills
  • Team Building 
  • Facilitation
  • Coaching

The Scrum pragmatic goal is to create a continuous learning environment where is safe to experiment and fail. This type of environment fosters continuous improvement and benefits the Scrum Team, the Product Owner, the organization and the advancement of software development practices. 

A corollary of this is that the Scrum Master should focus in four areas: the Development Team, the Product Owner, the Organization and the software development practices [Larman17].


It’s been openly said that Scrum can and should be adapted and combine with other tools and approaches but that needs to occur respecting the Agile principles and also taking into account the connection with Lean and the Toyota Production System.

Making adaptations disconnected from the Agile principles frequently have lead to suboptimal results and/or failed Scrum adoptions. What is even worst, Scrum has been mistakenly seen as a new and improved tool for better control developers that now need to work harder to meet imposed deadlines.

The Scrum Master rol is fundamental to clarify this misunderstandings so Scrum can be all adopted and really benefits people as the Scrum creators really envisioned. 


Womack07 Womack J., Jones D., Ross D., 2007. The Machine That Changed the World: The Story of Lean Production– Toyota’s Secret Weapon in the Global Car Wars That Is Now Revolutionizing World Industry, Free Press; Reprint edition

Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw-Hill

Liker04 Liker J., 2004. The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer, McGraw-Hill

Senge90 Senge P., 1990. The Fifth Discipline: The Art & Practice of The Learning Organization, Doubleday

Ballé14 Ballé M., Ballé F., 2014. Lead With Respect A Novel of Lean Practice, Lean Enterprise Institute

Forsgren18 Forsgren N., Humble J, Kim G., 2018. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, IT Revolution Press

Larman17 Larman C., Vodde B., 2011. Large-Scale Scrum More with LeSS, Addison-Wesley

Recapping Agile 2019

I’ve attended to my seventh Agile Conference this year in Maryland and in this short post I’ll try to recap the most important things that have impacted me during this awesome week. Before going there I have to say that this is my last conference as an Agile Alliance Board Member and this makes me feel sad but grateful for the opportunity to have served the Agile community at large.

Let’s start with something that really passionates me these days: LeSS. For the first time in the history of the conference we had a booth run by the self-organized team of “Fans of LeSS“. In my opinion this group of volunteers made a great contribution to the community by bringing LeSS to a conference with thousands of attendees that now know what it is. I was pleasantly surprised that Bas Vodde, co-creator of LeSS, was also at the conference.

Bas is the getleman on the left

Another great thing that coincided with this conference was the announcement of the “Fans of LeSS” declarating that now is receiving signatories. This is a historic event because it unites many of us that have been loudly proclaiming that Agile and Scrum have been distorted by companies and consultants. I’m anticipating that this will help to bring back sincerity about the true meaning of Agile and Scrum.

Going back to the conference there were two sessions ran by James Shore in which he presented an interesting idea: providing all the necessary tools for non-technical coaches to coach developers on TDD. Before you start asking how a non-technical coach will be able to even answer basics questions on TDD let me tell you that James seems to have produced materials, in the form of videos and samples, that can guide developers in simple TDD exercises. Of course if developers got stuck you can always call James.

James Shore on the stage

It’s fair to say that out of all XP practices, TDD seems to be the most challenging one for several reasons, but then it is a practice that truly contributes to disseminate the knowledge and craft better software. For this reason I can say that I applaud James’ efforts to popularize this practice.

On the not so bright side James create all his material in Java/JavaScript that are not my pick of programming ecosystem. Of course, this is just a personal preference that can be easily counter backed just by looking out there to the number of companies that use Java.

James Shore and Arlo Belshee presented a very interesting session on leading a technical transformation at very large scale with hundreds of developers. These are my key takeaways from that session:

  • Centralized leadership is not well equipped for dealing with the high systemic complexity of millions of lines of legacy code
  • Empowered teams using XP practices are the best chance to approach a highly complex code base
James on the left and Arlo on the right

As I mentioned at the beginning of this post, this was meant to be short with just the three or four things that made my mind wonder and dream with a world in which better software products could be produced by happier developers.


Recientemente termine de leer el libro #noprojects A Culture of Continuous Value escrito por mi dilecto amigo Shane Hastie con quien tuve la suerte de servir varios años en el Board de Directores del Agile Alliance.

El valor continuo esta en contraposición de la noción de proyecto con alcance y fecha fija.

El libro en sí se base en un postulado que se viene escuchando ya desde hace bastante: que debemos pasar de la era de los proyectos a la era de los productos. Las razones detrás de este postulado son multiples pero una que para mí tiene mucho sentido es que los proyectos tienden a resultados inmediatistas en desmedro de la calidad y la cohesión de un grupo humano de individuos en un equipo de verdad.

El libro también hace una revision historia del origen y él porque se incluye el concepto de proyectos que a su vez dio origen a la profesión de Project Managers. Es interesante que en el contexto histórico los proyectos contribuyeron gran valor pero en la era del conocimiento simplemente son un anacronismo.

Rescato también del libro la inclusion de varios postulados, libros y teorías mas modernas como el Cynefin Framework y de Dude’s Law por nombrar solo uno cuantos. Interesantemente el libro presenta la idea de que diferentes fuentes, incluyendo la corriente agil, acaban convergiendo en que los proyectos no son la mejor manera para abordar el trabajo creativo que es lo que se require para crear disrupción en los competitivos mercados actuales.

Los casos de estudio incluidos en el libro son valiosos desde la perspectiva que validan la hipótesis de que es posible alcanzar valor para las organizaciones creando productos sin necesidad de caer en la pesada carga de verlos como proyectos multietapa y que requieren control centralizado. Sin embargo los casos de estudio, como es siempre cierto con ellos, son altamente dependientes del contexto dentro del cual ocurrieron.

Finalmente considero que la mera existencia de un libro como este indica que hay una evolución del conocimiento no motivada por la moda sino por la necesidad, evolución que con un poco de suerte y perseverancia nos acabara sacando de una vez por todas de la era de los proyectos y los recursos y nos llevara hacia la era de los productos creados por individuos motivados y respetados como seres humanos.

Memorias del primer curso de Certified LeSS Basics

Memorias del primer curso de LeSS en castellano

El 19 de junio tuve la suerte de dictar por primera vez el curso de Certified LeSS Basics en Ciudad de Mexico, de hecho esta fue la primera vez que este curso se enseña en castellano en un país hispano hablante. En este post trataré de recoger algunas de la ideas centrales que fueron discutidas.

LeSS es en esencia un marco de de trabajo que se puede aplicar para el diseño/re-diseño organizacional y el pensamiento sistémico es uno de sus herramientas de pensamiento

LeSS parte de la premisa que cualquier empresa debe ser conceptualizada como un sistema complejo en el cual existen diferentes actores interconectados, esta interconexión es la que hace que sea necesario analizar sistémicamente cualquier cambio y los efectos que pueda desencadenar. 

Una de las razones principales por las cuales LeSS es una alternativa viable para el rediseñó organizacional sistémico es que lidia adecuadamente con la alta complejidad inherente de una organización. 

La forma de LeSS de lidiar con esa alta complejidad sistémica inherente es no introduciendo más complejidad, es decir siendo un marco de trabajo minimalista que rescata la simplicidad del verdadero Scrum

Mas aun, si se tiene una empresa con una complejidad alta debido a factores como su tamaño, procesos, cantidad de empleados, ubicaciones geográficas y otros; al tratar de aplicar en ella un marco de trabajo complejo la complejidad de la empresa se volverá super lineal. Lo anterior viene de un postulado sistémico simple: sistemas complejos tienden a sobrecomplejizarse cuando en ellos se aplica una herramienta sistémica mas compleja

LeSS también parte de una noción fundamental: el rediseñó organizacional sistémico requiere compromiso sincero de la alta gerencia de una empresa.

La razón del postulado anterior es que simplemente no es acertado asignar un problema de amplitud sistémica a solamente un individuo cuyo poder de influencia y cognitivo no alcanzaría a impactar a toda una organización. Dejare para otro post la discusión de que en realidad no se necesita un Agile Coach que transforme una organización sino Pensadores Sistémicos que rediseñen organizaciones. 

Uno de los cambios sistémicos mas profundos es dejar de ser una organización que promueva la competitividad interna, el control y a las métricas; y pasar a ser una organización que realmente cree un ambiente de aprendizaje continuo donde la gente se pueda sentir segura aprendiendo y fallando.  

En este sentido LeSS enfatiza que no se trata de copiar mejores prácticas (he hecho la frase “mejores prácticas” se considera dañina pues nos aleja de la mejora continua) de otras organizaciones sino via experimentación descubrir cómo convertirse en una organización de aprendizaje constante. Dicho más resumidamente se trata de aspirar a ser una “learning organization” y no una “copying organization”.

Algunos de los cambios sistémicos profundos implican el identificar y eliminar formas de desperdicio; después de todo LeSS tiene a Lean como otra de sus herramientas de pensamiento.  Pensando Lean hay ciertos esquemas y prácticas que no tienen cabida dentro de una organización simplificada. 

La lamina anterior muestra algunas de las prácticas organizacionales/ingenieriles que no acaban contribuyendo y que por el contrario generan desperdicio. Como es de esperarse la sola mención de que deben eliminarse crea resistencia y temor, razon por la cual LeSS no es para cualquier organización. La lógica de los creadores de LeSS ha sido que en lugar de salir a tratar de convencer a los gerentes de una empresa de eliminar estas prácticas, mejor esperaran a que gerentes visionarios se aproximen a ellos en busca de ideas acerca de como rediseñar sus organizaciones de tal forma de evitar estas prácticas improductivas.

LeSS abraza una mentalidad de experimentación constante pero sin reinventar la rueda y caer en errores conocidos y documentados.

LeSS no es presprictivo al 100% pero sí tiene una reglas que deben ser seguidas, respetando esas reglas la experimentación en bienvenida. Desde luego habra quien diga que esas reglas no aplican para su contexto particular y que lo que a los creadores no les funciono a el/ella si le funcionará, creo que ante esto lo único que puedo decir es que es necesaria la amplitud de mente y la humildad intelectual para estar mejor preparados pasar sacar provecho del “secreto mejor guardado de la agilidad” (LeSS).

Finalmente agradezco de sobremanera a los colegas que salen en la siguiente fotografía por haber sido parte de este curso y espero escuchar de ellos a futuro historias acerca de su viaje de descubrimiento con LeSS. 

LeSS y las heridas autoinflingidas

Estaba pensando en LeSS mientras tomaba un cafe en un cowork, mis pensamientos fueron detonados por esta imagen:

Creo que la imagen metafóricamente ilustra lo que la mayoría de las veces acaba pasando cuando se quiere apresurar el desarrollo de software en detrimento de la calidad. Podríamos decir que en la imagen la oruga nunca se transforma en mariposa por completo ni tampoco vuela por lo pesada que se vuelve la deuda técnica.

En LeSS la metáfora es muy simple: hacer que la oruga se transforme en mariposa protegiendo su desarrollo y que luego vuele ligera. Si bien es una metáfora creo que es válida pues cosas como alcance expandiéndose sin final y la negación de la prácticas de XP acaban comprometiendo el producto.

El volar ligero en el mundo de LeSS implica el tener un producto sin toneladas de features que nadie usa o qué raramente son utilizadas. Cabe recordad que LeSS es Lean y por lo tanto trata de evitar todas las formas de desperdicio posibles.

LeSS no pretende resolver todos los problemas, solamente los más importantes que normalmente implican transformaciones sistemáticas profundas. Desde otra perspectiva LeSS apunta a dejar atrás las heridas que las organizaciones y equipos se infringen a sí mismas por ignorancia o masoquismo.

Si hablamos de este tipo de heridas estas de manera general segun mi criterio caen en cuatro categorías:

  • Heridas de conocimiento estático que se niega a evolucionar y actualizarse, es decir, gente que trata de resolver problemas ya resueltos con conocimiento inadecuado para el propósito.
  • Heridas de organizaciones anacrónicas que tratan de aplicar paradigmas de management que eran vigentes en pleno auge de la revolución industrial y cuando el trabajo manual y no el mental era el que predominaba.
  • Heridas de practicas de ingenieria que está probado que son anti-Lean o mejor dicho anti-sentido-común pero que la gente sigue insistiendo en emplear; la más dañina de ellas es escribir código que solo el desarrollador que lo escribió entiende.
  • Heridas personales de negación y queja pero que a la vez nos disparan el cambio personal ni tampoco el crecimiento. Esta es quizás la categoría donde el primer cambio hacia LeSS debe acaba ocurriendo pues del cuestionamiento personal profundo debe partir el aprendizaje sincero y sin descanso.

Finalmente me permito plantear un postulado: personas sin heridas forman equipos sin heridas dentro de organizaciones sin heridas y estas a su vez tienen mas chances de construir de manera armónica los productos que el mercado espera. Si lo anterior tiene sentido para ustedes la pregunta sistémicas se vuelve, ¿qué se necesita para empezar a sanar estas heridas?

Scrum y XP desde las trincheras, mis notas del libro

El fin se semana pasado termine de releer la segunda edición de este ya clásico libro de Henrik Kniberg. Fue muy refrescante leer en él los pensamientos del autor desde una mirada critica de su propio trabajo plasmado en la primera edición.

Voy resumiendo algunas impresiones que se me quedaron del libro :

  • El product backlog no es descubierto de manera solitaria por el Product Owner sino que debe venir de una activad grupal con stakeholders y/o developers. Técnicas como User Story Mapping resultan muy útiles para este fin.
  • Las historias de un backlog deben ser pensadas desde la perspectiva de cómo serán presentadas en un Sprint Review, el resultado de esa definición es el que puede (y de hecho debe) ser programado a través de criterios de aceptación automatizados .
  • El uso de Google Spreadsheets para mantener el Product Backlog es una alternativa válida que no solamente abarata y simplifica el juego de herramientas sino que también ofrece gran flexibilidad para moldear la herramienta al proceso evolutivo del equipo y no a la inversa.
  • El Sprint Retrospective es el evento más importante de Scrum pues es de hecho el único que permite inspeccionar la forma de trabajo del equipo en su conjunto e irla mejorando. Dejo para otro post la noción de que el Sprint Retrospective es un evento meta-circular.
  • El Backlog Refinement es un evento en el cual el Producto Owner junto con el equipo pueden incorporar su conocimiento más reciente acerca de los backlogs.
  • Scrum fue concebido como un “wrapper” de XP y de hecho fue Ken Schwaber quien convenció a Jeff Sutherland de no prescribir practicas ingenieriles para hacer Scrum más digerible y acelerar su popularización.
  • Los Feature Teams son una forma preferible de organización de múltiples equipos y ofrecen muchas más ventajas que los Component Teams.

Si bien hay muchos otros tópicos importante que el libro aborda creo que con lo anterior resumo la esencia y ayudo a provocar curiosidad en la gente. Recomendación final, léanse el libro 🙂