sábado, julio 14, 2018

Documento Online

"Abrimos un drive y todos vamos editando, no hay necesidad de reunirnos".



domingo, diciembre 03, 2017

Como Mantener al Equipo Técnico Motivado

Les dejo unas partes de un artículo de Marty Cagan del SVPG (recomiendo que lo lean todo) como hacer para que todo el equipo motivado:
1. Provide engineers business context
Your engineers need to understand the business context.  So many CEO’s and product managers think they need to shelter their engineers from the ugly details and angry customers.  Nothing could be further from the truth.  These are the people that will save you.  But they need the context.  So share with them the vision, strategy, analytics, business goals, contractual requirements, and legal issues.  Anything that might impact the product.  They can handle it, and they will appreciate it.
2. Connect engineers with customer pain
The magic so often happens when the actual engineers are able to witness the customer pain first hand.  Very little is actually more motivating to an engineer.  They truly want to help fix that pain.  Again, you’re not there to ask the customer what they want built.  But rather, observe them using (or trying to use) your new prototypes or your current product, or whatever they are using today.  Your goal is to understand if the customer can figure out how to do what they need to, and if they love this solution enough to buy it (or more likely, all the reasons they might not buy it).
3. Understand constraints vs. requirements
Lots of people in the company as well as your customers will try to “help” by providing the engineers “requirements.”  This is not helpful.  Requirements are rarely truly required.  Rather, the job of the product manager is to identify the underlying constraints – legal, financial, sales, marketing, manufacturing, etc. – and then providing the engineers with these constraints.  The result is significantly more degrees of freedom for the engineering team in solving the underlying customer or business problem.
4. Give engineers time in discovery
So many teams are essentially running like a little software factory.  Product manager loads up a product backlog and the engineers constantly strive for improved velocity in implementing that backlog.  It’s beyond the scope of this article to talk about all the reason this is not how good product companies work, but it is key to realize that you must give your engineers some time to prototype solutions and test them with actual customers before deciding to spend the time and money to build an actual product.  Giving engineers some time in discovery is easily one of the best ROI things you can do.  Most experienced engineers will tell you that a few hours including them up front can save weeks and month of waste later in the cycle.
5. Measure product team as a whole
Some teams make the big mistake of measuring engineers by one yardstick and product managers by another.  This shows up as a common problem with OKR’s, where the engineers have one set of quarterly objectives and key results, and the product managers another.  This is exactly the wrong approach for product teams.  The team needs to be exactly aligned in terms of their work.
6. Competent and confident product managers
Finally, everything here depends on providing the engineers with a competent, technology and business savvy product manager or co-founder.  The product manager brings deep knowledge of the customer, deep knowledge of the data, deep knowledge of the industry and deep knowledge of the many aspects of your company that impact the product – sales, marketing, legal, finance and more. The product manager also needs to have the confidence to be collaborative with their engineers.  Strong product managers actively engage and seek out the opinions of the engineers versus feeling like they have to know everything.  So many teams don’t get the value out of their engineers because they don’t provide the team with a capable product manager.  Just note that if you think the product manager is someone with a product owner certification, you almost certainly have this problem.
Now it’s important to acknowledge that not all engineers are interested in engaging at the level I’m describing, although it is fairly common that this level of engagement is necessary to achieve the level of a tech lead.  That’s fine.  But you do need at least one engineer on every product team that is willing and able to engage at this level.  And I will also admit that my favorite product teams are those where every engineer is this engaged, but that requires a culture where this is highly valued and specifically recruited for.  It’s the best example of a team of missionaries.
So if you are not seeing the level of innovation your business needs, I hope you’ll give this way of working a try and see for yourself what a team of missionaries can accomplish.

domingo, noviembre 12, 2017

Project Postmortem Survey

Antes de la reunión Postmortem de un proyecto, sin importar que actividad se lleve a caso en la misma, una buena práctica es enviar a todos los participantes las siguientes preguntas (en un Google Form o cualquier otra herramienta) para ir recolectando información y lograr que los participantes vayan pensando de lo que pasó en el proyecto:

  • What do you think went well on the project?
  • What was the single most frustrating part of the project?
  • How would you do things differently next time to avoid these frustrations?
  • Were the goals of the project clear to you?
  • Were you given the adequate resources to achieve those goals?
  • Was the schedule realistic for the deliverables?
  • Are you proud of the project deliverables?
  • What was the most gratifying or professionally satisfying part of the project?
  • If you could change anything from the project, what would you change?
  • Was project communication handled efficiently and effectively?

No olvidar recordar la retrospective prime directive cuando uno envía el form :)

miércoles, septiembre 20, 2017

Porque Eliminar las Evaluaciones de Desempeño

Les dejo un árticulo muy interesante de porque las empresas deberían alejarse del sistema de evaluaciónes de desempeño anual. Leer.

La solución es dar feedback continuamente!

lunes, mayo 09, 2016

La Seguridad Psicologica es Clave para un Equipo de Alto Rendimiento

Google descubrió que la seguridad psicologica es la base de un equipo de Alto rendimiento. Los miembros se tienen que sentir seguros de tomar riesgos sin preocuparse de que el resto del equipo los juzgue. Les dejo una imagen con el resumen de la nota y la fuente para quien quiera verlo en profundidad.

domingo, abril 03, 2016

Características de un Gran ScrumMaster

Les dejo 28 características de un gran ScrumMaster, de un muy buen artículo escrito por Barry Overeem:

  1. Involves the team with setting up to process. A great Scrum Master ensures the entire team supports the implemented Scrum process. The daily Scrum for example is planned at a time that suits all team members. A common complain about Scrum is the amount of ‘meetings’, involving the team with the planning of the events will prevent at least some resistance.
  2. Understands team development. A great Scrum Master is aware of the different phases a team will go through when working as a team. He understands Tuckman’s different stages of team development: forming, storming, norming, performing and adjourning. The importance of a stable team composition is therefore also clear.
  3. Understands principles are more important than practices. Without a solid, supported understanding of the agile principles, every implemented practice is basically useless. It’s an empty shell. An in-depth understanding of the agile principles by everyone involved will increase the chances of successful usage of practices drastically.
  4. Recognizes and acts on team conflict. A great Scrum Master has read the book ‘The 5 Dysfunctions of a Team’ by Patrick Lencioni. He therefore recognizes team conflict in an early stage, can apply different activities to resolve it, and even better, he knows how to prevent conflict.
  5. Dares to be disruptive. A great Scrum Master understands some changes will only occur by being disruptive. He knows when it’s necessary and is capable to be disruptive enough to enforce a change, but without causing irreparable damage.
  6. Is aware of the smell of the place. A great Scrum Master can have an impact on the culture of the organization so that the Scrum teams can really flourish. He therefore knows the movie ‘The Smell of the Place’ by Prof. Sumantra Ghoshal and can also apply the related workshop.
  7. Is both dispensable and wanted. A great Scrum Master has supported the growth of teams in such a manner they don’t need him anymore on daily basis. But due his proven contribution he will get asked for advice frequently. His role has changed from a daily coach and teacher to a periodical mentor and advisor.
  8. Let his team fail (occasionally). A great Scrum Master knows when to prevent the team from failing but also understands when he shouldn’t prevent it. The lessons learned after a mistake might be more valuable than some good advice beforehand.
  9. Encourages ownership. A great Scrum Master encourages and coaches the team to take ownership of their process, task wall and environment.
  10. Has read… A great Scrum Master has read all the stuff produced by e.g. Geoff Watts, Lyssa Adkins, Tobias Mayer, Henrik Kniberg, Growing Agile and Gunther Verheyen. Basically he knows whom to follow in his area of study.
  11. Has studied… A great Scrum Master has studied the Trello board that Growing Agile has published. The Shu-Ha-Ri levels offer a very useful structure to a knowledge base for every Scrum Master.
  12. Is RE-TRAINED. A great Scrum Master recognizes himself in the acronym made up by Geoff Watts, RE-TRAINED:
    1. Resourceful, is creative in removing impediments
    2. Enabling, is passionate about helping others
    3. Tactful, is diplomacy personified
    4. Respected, has a reputation for integrity
    5. Alternative, is prepared to promote a counter-culture
    6. Inspiring, generates enthusiasm and energy in others
    7. Nurturing, enjoys helping teams and individuals develop and grow
    8. Empathic, is sensitive to those around them
    9. Disruptive, breaks the status quo, help create a new way of working
  13. Has faith in self-organization. A great Scrum Master understands the power of a self-organizing team. “Bring it to the team” is his daily motto. Attributes of self-organizing teams are that employees reduce their dependency on management and increase ownership of the work. Some examples are: they make their own decisions about their work, estimate their own work, have a strong willingness to cooperate and team members feel they are coming together to achieve a common purpose through release goals, sprint goals and team goals.
  14. Values rhythm. A great Scrum Master understands the value of a steady sprint rhythm and does everything to create and maintain it. The sprint rhythm should become the team’s heartbeat, which doesn’t cost any energy. Everyone knows the date, time and purpose of every Scrum event. They know what is expected and how to prepare. Therefore a complete focus on the content is possible.
  15. Knows the power of silence. A great Scrum Master knows how to truly listen and is comfortable with silence. Not talking, but listening. He is aware of the three levels of listening and knows how to use them. He listens carefully to what is said, but also to what isn’t said.
  16. Observes. A great Scrum Master observes his team with their daily activities. He doesn’t have an active role within every session. The daily Scrum for example is done by the team itself. He observes the session and hereby has a more clear view to what is being discussed (and what isn’t) and what everyone’s role is during the standup.
  17. Share experiences. Great Scrum Masters share experiences with peers. This might be within the organization, but also seminars and conferences are a great way to share experiences and gather knowledge. Of course writing down your lessons learned is also highly appreciated. And yes, for the attentive readers, this is exactly the same as for the Product Owner and the Development Team.
  18. Has a backpack full of different retrospective formats. A great Scrum Master can apply lots of different retrospective format. This ensures the retrospective will be a fun and useful event for the team. He knows what format is most suitable given the team’s situation. Even better: he supports the team by hosting their own retrospective. To improve involvement this is an absolute winner!
  19. Can coach professionally. A great Scrum Master understands the power of professional coaching and has mastered this area of study. Books like Coaching Agile Teams and Co-Active Coaching don’t have any secrets for him. He knows how to guide without prescribing. He can close the gap between thinking about doing and actually doing. And he can help the team members understand themselves better so they can find news ways to make the most of their potential. And yes, these last sentences are actually an aggregation of several coaching definitions, but it’s sound quite cool!
  20. Has influence at organizational level. A great Scrum Master knows how to motivate and influence at tactic and strategic level. Some of the most difficult impediments a team will face occur at these levels; therefore it’s important a Scrum Master knows how to act at the different levels within an organization.
  21. Prevent impediments. A great Scrum Master not only resolves impediments, he prevents them. Due his experiences he is able to ‘read’ situations and hereby act on them proactively.
  22. Isn’t noticed. A great Scrum Master isn’t always actively present. He doesn’t disturb the team unnecessary and supports the team in getting into the desired ‘flow’. But when the team needs him, he’s always directly available.
  23. Forms a great duo with the Product Owner. A great Scrum Master has an outstanding partnership with the Product Owner. Although their interest are different, the Product Owner ‘pushes’ the team, the Scrum Master protects the team. A solid partnership is extremely valuable for the Development Team. Together they can build the foundation for astonishing results.
  24. Allows leadership to thrive. A great Scrum Master allows leadership within the team to thrive and sees this as a success of their coaching style. They believe in the motto “leadership isn’t just a title, it’s an attitude”. And it’s an attitude everyone in the team can apply.
  25. Is familiar with gamification. A great Scrum Master is able to use the concepts of game thinking and game mechanics to engage users in solving problems and increase users’ contribution.
  26. Understands there’s more than just Scrum. A great Scrum Master is also competent with XP, Kanban and Lean. He knows the strengths, weaknesses, opportunities and risks of every method/framework/principle and how & when to use them. He tries to understand what a team wants to achieve and helps them become more effective in an agile context.
  27. Leads by example. A great Scrum Master is someone that team members want to follow. He does this by inspiring them to unleash their inner potential and showing them the desired behavior. At difficult times, he shows them how to act on it; he doesn’t panic, stays calm and helps the team find the solution. Therefore a great Scrum Master should have some resemblance of Gandalf. The beard might be a good starting point :)
  28. Is a born facilitator. A great Scrum Master has facilitation as his second nature. All the Scrum events are a joy to attend, and every other meeting is well prepared, useful and fun, and has a clear outcome and purpose.

martes, marzo 01, 2016

Caracteristicas de un Gran Equipo de Desarrollo de Software Ágil

Les dejo 25 caracteristicas de un gran equipo de desarrollo de software ágil:
  • Pursue technical excellence. Great Development Teams use Extreme Programming hereby as a source of inspiration. XP provides practices and rules that revolve around planning, designing, coding and testing. Examples are refactoring (continuously streamlining the code), pair programming, continuous integration (programmers merge their code into a code baseline whenever they have a clean build that has passed the unit tests), unit testing (testing code at development level) and acceptance testing (establishing specific acceptance tests).
    Apply team swarming. Great Development Teams master the concept of ‘team swarming’. This is a method of working where a team works on just a few items at a time, preferably even one item at a time. Each item is finished as quickly as possible by having many people work on it together, rather than having a series of handoffs.
  • Use spike solutions. Great Development Teams uses spike solutions to solve challenging technical, architectural or design problems.
  • Refine the product backlog as a team. Great Development Teams consider backlog refinement a team effort. They understand that the quality of the product backlog is the foundation for a sustainable development pace. Although the Product Owner is responsible for the product backlog, it’s up to the entire team to refine it.
  • Respect the Boy Scout Rule. Great Development Teams use the Boy Scout Rule: always leave the campground cleaner than you found it. This means they always check a module in cleaner than it was before.
  • Criticise ideas, not people. Great Development Teams criticise ideas, not people. Period.
  • Share experiences. Great Development Teams share experiences with peers. This might be within the organisation, but also seminars and conferences are a great way to share experiences and gather knowledge. Of course writing down your lessons learned is also highly appreciated. And yes, for the attentive readers, this is exactly the same as for the Product Owner.
  • Understand the importance of having some slack. Great Development Teams have some slack within their sprint. Human beings can’t be productive all day long. They need time to relax, have a chat at the coffee machine or play table football. They need some slack to be innovative and creative. They need time to have some fun. By doing so, they ensure high motivation and hereby maximum productivity. But slack is also necessary to handle emergencies that might arise, you don’t want your entire sprint to get into trouble when you need to create a hot-fix. Therefore: create some slack! And when the sprint doesn’t contain any emergencies: great! This gives the team the opportunity for some refactoring and emergent design. It’s a win-win!
  • Have fun with each other. Great Development Teams ensure a healthy dose of fun is present every day. Fostering fun, energy, interaction and collaboration creates an atmosphere in which team will flourish!
  • Don’t have any Scrum ‘meetings’. Great Development Teams consider the Scrum events as opportunities for conversations. Tobias Mayer describes this perfectly in his book ‘The Peoples Scrum’: “Scrum is centered on people, and people have conversations. There are conversations to plan, align, and to reflect. We have these conversations at the appropriate times, and for the appropriate durations in order to inform our work. If we don’t have these conversations, we won’t know what we are doing (planning), we won’t know where we are going (alignment), and we’ll keep repeating the same mistakes (reflection).”
  • Know their customer. Great Development Teams know their real customer. They are in direct contact with them. They truly understand what they desire and are therefore able to make the right (technical) decisions.
  • Can explain the (business) value of technical tasks. Great Development Teams understand the importance for technical tasks like e.g. performance, security and scalability. They can explain the (business) value to their Product Owner and customer and hereby ensure its part of the product backlog.
  • Trust each other. Great Development Teams trust each other. Yes, this is obvious. But without trust it’s impossible for a team to achieve greatness.
  • Keep the retrospective fun. Great Development Teams think of retrospective formats themselves. They support the Scrum Master with creative, fun and useful formats and offer to facilitate the sessions themselves.
  • Deliver features during the sprint. Great Development Teams deliver features continuously. Basically they don’t need sprints anymore. Feedback is gathered and processed whenever an item is ‘done’; this creates a flow of continuous delivery.
  • Don’t need a sprint 0. Great Development Teams don’t need a sprint 0 before the ‘real’ sprints start. They already deliver business value in the first sprint.
  • Act truly cross-functional. Great Development Teams not only have a cross-functional composition but also really act cross-functional. They don’t talk about different roles within the team but are focused to deliver a releasable product each sprint as a team. Everyone is doing the stuff that’s necessary to achieve the sprint goal.
  • Update the Scrum board themselves. Great Development Teams ensure the Scrum/team board is always up-to-date. It’s an accurate reflection of the reality. They don’t need a Scrum Master to encourage them; instead they collaborate with the Scrum Master to update the board.
  • Spend time on innovation. Great Development Teams understand the importance of technical/architectural innovation. They know it’s necessary to keep up with the rapidly changing environment and technology. They ensure they have time for innovation during regular working hours, and that it’s fun and exciting!
  • Don’t need a Definition of Done. Great Development Teams deeply understand what ‘done’ means for them. For the team members, writing down the Definition of Done isn’t necessary anymore. They know. The only reason to use it is to make the ‘done state’ transparent for their stakeholders.
  • Know how to give feedback. Great Development Teams have learned how to give each other feedback in an honest and respectful manner. They grasp the concept of ‘impact feedback’. They give feedback whenever it’s necessary, and don’t postpone feedback until the retrospective.
  • Manage their team composition. Great Development Teams manage their own team composition. Whenever specific skills are necessary, they collaborate with other teams to discuss the opportunities of ‘hiring’ specific skills.
  • Practice collective ownership. Great Development Teams understand the importance of collective ownership. Therefore they rotate developers across different modules of the used applications and systems to encourage collective ownership.
  • Fix dependencies with other teams. Great Development Teams are aware of possible dependencies with other teams and manage these by themselves. Hereby they ensure a sustainable development pace of the product.
  • Don’t need story points. Great Development Teams don’t focus on story points anymore. They’ve refined the product backlog in such a manner, the size for the top items don’t vary much. They know how many items they can realise each sprint. Counting the number of stories is enough for them.

Fuente: http://blog.scrum.org/the-25-characteristics-of-a-great-development-team/

domingo, diciembre 27, 2015

Manifiesto ágil actualizado

Navegando por internet encontré un interesante árticulo con una visión distinta del manifiesto de software ágil, cambiado y explicando en más detalle los puntos que enuncia la autora, Katrina Kolt. Disfrutenlo!

1. People and conversations over ambiguity and assumptions
  • We seek to understand requirements, resolve problems and collaborate through conversations, not emails or IM.
  • We recognise that conversation is the most effective way to disclose assumptions, clear ambiguity, share information and create common understanding.
  • We speak up when we perceive a simpler way of doing something.
2. Partnership collaboration over hierarchy and silos
  • We create partnerships between groups to work on customer centric solutions.
  • We use collaboration as a way of ensuring we are delivering the right outputs.
  • We commit to both stakeholders and delivery teams being involved for the duration of projects.
  • We strive to achieve organisation-wide strategic solutions that deliver shared value, rather than specific purpose implementations.We trust individuals tasked with completing work, regardless of where they sit in the organisation’s hierarchy.
3. Quality and value of work over quantity
  • We recognise that limiting the amount of work in progress is the most efficient way for us to manage throughput.
  • We use a limited work in progress approach to prioritise delivery of the most valuable work within resource availability.
  • We ensure that we deliver the desired quality output by limiting work in progress and reviewing progress with stakeholders along the way.We analyse our output to ensure our productivity and quality leads to continual improvement.
4. Delivering iterative business value over big bang roll-outs
  • We deliver incrementally to reduce the risk of big bang delivery that no longer aligns with customer expectations, current technology or market conditions.
  • We use iterative delivery to validate our assumptions, learn, and recalibrate as required.
  • We iterate to quickly deliver a minimum viable product, knowing that what we learn from this will ultimately create the most customer centric solution.
5. Continuous planning over inflexible planning
  • We prioritise planning the most important components, so we can deliver them first.
  • We see high value in targeted planning of the components being delivered first.
  • We accept that planning of subsequent features needs to happen once we have customer response to rollout of initial components
  • We see less value in planning components that have less certainty of being developed.

sábado, noviembre 28, 2015

Enterprise Scrum

Mike Beedle es uno de los creadores de Scrum y participo de la creación del manifiesto de ágil. Mike está desarrollando Enterprise Scrum. Inicialmente lanzó un paper como resumen, y pronto va a lanzar un libro del tema. Este paper comienza comentando los puntos que se valoran en gestión ágil:
  • Satisfacción del cliente vs. Prioridades internas o “números”.
  • Entregar valor de negocio en vez de hacer tareas que no suman valor.
  • Cambiar a través del feedback en vez de planes a largo plazo.
  • Cooperación en todas partes en vez de silos funcionales
  • Maximizar el valor de las acciones a través de innovación disruptiva en vez de lograr innovación sostenida o eficiencias operacionales. De este último punto se tiene el dato que de las 20% empresas con mayor facturación, el 70% de sus ingresos viene por venta de productos nuevos en 2014, mientras en 1975 los productos nuevos traían solo el 20% de los ingresos a estas mismas empresas. Esto demuestra que hubo un cambio.
Los siguientes puntos ilustran el panorama actual en los negocios:
  • Tiempos de reacción y predicción exponencialmente más cortos
  • Tenemos que procesar información y feedback más rápidamente
  • La competencia está más afilada
  • Hay que innovar y encantar al cliente más rápidamente
  • Necesitamos planes más certeros
  • Es necesario mejorar el manejo del portafolio
  • Fallar rápidamente es preferible a fallar tardíamente.
El autor continúa enunciando que para gestionar y liderar las empresas para ser exitosas en el siglo 21, necesitamos innovación más rápida, eficiente y enfocada en el cliente para obtener mayores ganancias y sobrevivir en este ámbito tan competitivo. El foco de Enterprise Scrum es reinventar las empresas, con todos sus productos, servicios y procesos.

Históricamente, hace decenas de años que se vienen optimizando los procesos definidos (manufactura, sistemas de información cerrada) en las organizaciones con metodologías lean. Lamentablemente no se ha trabajado con tanto énfasis en mejorar los procesos empíricos, los cuales son ejecutados oportunisticamente, analizando el contexto a través de transparencia, inspección y adaptación, y son los que más impacto tienen en el éxito o fracaso de una empresa.

Scrum es una técnica de gestión lean compacta, fácil de entender, y bien probada que provee gestión de procesos empíricos para cualquier proceso de negocio. En los procesos empíricos hay incertidumbre por las siguientes razones:
  • Nueva información entra al Sistema
  • Cambios aparecen frecuentemente (negocio, tecnología, mercado)
  • Entender la información existente o nueva es difícil: Malentendidos
  • Las salidas no pueden predecirse con anticipación
  • La gente y los equipos cambian con el tiempo
La gestión de procesos empíricos se basa en:
  • Transparencia: Para que todo sea visible y entendible
  • Inspección: Para determinar el estado actual
  • Adaptación: Para cambiar, mejorar y aprender
El propósito de Enterprise Scrum no es redefinir Scrum, sino extender, generalizar y parametrizar Scrum. Enterprise Scrum es la aplicación de Scrum extendida, generalizada y parametrizada para distintos procesos de negocio, de una manera genérica (para distintos niveles y procesos de la organización) en un modo escalable (distribuido o cooperativo).

Scrum es una metodología ágil de gestión de proyectos probada y de adopción creciente. Enterprise Scrum propone extender el éxito que brinda Scrum a los proyectos, a distintos procesos de negocios empíricos, que se vienen gestionando incorrectamente con la experiencia acumulada de gestión de procesos predictivos. 

Parece interesante el enfoque, a estar atentos!

viernes, octubre 09, 2015

Body Language: How To Read Others Thoughts By Their Gestures

"Body Language: How To Read Others Thoughts By Their Gestures" de Allan Pease es un libro muy interesante que me hizo dar cuenta de lo importante que es la comunicación no verbal en la vida. La primera edición de este libro se lanzó en 1981. La verdad es que nunca le había prestado demasiada atención a este tema, solo había leído ciertos consejos de como sentarse en entrevista, pero este libro me llevo a otro nivel, logrando estar consiente de cómo me comunico de manera no verbal en la vida laboral y fuera de la oficia también, y también puedo ver ciertas maneras de gente al comunicarse con uno.

El lenguaje corporal nos revela en muchas ocasiones que lo que una persona dice no tiene nada que ver con lo que en realidad piensa o siente. Por ejemplo, si alguien está aseverando algo pero se rasca las orejas o se tapa la boca parcialmente, puede llegar a estar mintiendo. Si alguien está escuchando una clase o una exposición con la cabeza apoyada sobre el brazo y con las piernas cruzadas, esta aburrida y no está de acuerdo con lo que se dice. Alguien que se sienta para atrás y pone las manos detrás de la cabeza, se cree superior. Existen muchos más ejemplos que el autor explica y demuestra con dibujos, y realmente tienen sentido.

El libro está bueno, es un clásico, es entretenido y corto. Realmente me abrió la cabeza y voy a seguir investigando de este tema porque es muy interesante y sirve para el día a día en casa o en la oficina.

sábado, septiembre 26, 2015

Influence: The Art of Persuasion

Influence: The Art of Persuasion de Robert B. Cialdini es un interesante libro donde el autor nos comenta sobre seis principios psicológicos que dirigen nuestro comportamiento y permiten a personas decir si ante estas tácticas de influencia y persuasión. Los principios son: la coherencia, la reciprocidad, la conformidad social, la autoridad, la simpatía y la escasez. 

El autor examina estos principios y su utilización por los “profesionales del consentimiento”: todas aquellas personas cuyo trabajo consiste en obtener compras, donaciones, concesiones, votos y aceptaciones de cualquier otro tipo. Por ejemplo, el principio de la escasez nos impulsa a comprar algo que tiene el rótulo de "Solo por hoy", y esta reacción ante este estimulo nos inhibe pensar si realmente necesitamos o no el ítem, y lo compramos solo por el miedo de que en el futuro no podamos acceder a eso. Otro ejemplo es la simpatía, ya que según estudios, damos una respuesta favorable instantánea y automática a todas las proposiciones de una persona si detectamos en ella un rasgo positivo dominante, tal como el atractivo físico. 

La evolución tecnológica ha demostrado ser mucho más rápida que nuestra evolución biológica. Por eso nuestra capacidad natural de procesar información será cada vez más inadecuada para gestionar el exceso de opciones y desafíos de la vida moderna.  A la hora de tomar decisiones, dispondremos cada vez menos del lujo de un análisis completo de la situación y tendremos que concentrarnos en aquellas características que nos parezcan más fiables. Cuando de verdad podemos confiar en la certeza de estas características, no hay nada malo en bajar la guardia y dar una respuesta instantánea a una situación. No obstante, el problema surge cuando algo nos lleva a tomar decisiones y emprender acciones equivocadas, tal como las inducciones de los “profesionales del consentimiento” nos conducen a aceptar sus proposiciones.

El libro es muy interesante y está repleto de ejemplos que nos hacen pensar. Una crítica es que el autor nos propone utilizar el boicot, la amenaza, la confrontación o la censura como armas legítimas ante la gente que utilicen datos falsos para hacernos reaccionar de esta manera. No está bueno que nos engañen, pero me parece exagerado la forma de encararlo del autor. Tenemos que estar atentos y preparados a usar la cabeza en vez de dejarnos guiar por nuestros atajos psicológicos.

lunes, septiembre 21, 2015

sábado, agosto 22, 2015

Mejores Retrospectivas

El objetivo de una retrospectiva es ver que salió bien durante un sprint y reforzar eso para que no se pierda y  ver que salió mal para lograr definir acciones que posibiliten que el equipo evolucione y mejore continuamente. Clásicamente en una retrospectiva uno trata de dividir un pizarrón en dos y que el equipo aporte frases o palabras de ambas situaciones positivas y negativas del sprint. 

Para sumar agilidad a las retrospectivas, evitar que el equipo se aburra, lograr más dinamismo y tratar de obtener la mayor cantidad de información que sirva para mejorar, les recomiendo dos sitios con cientos de actividades para que sus retrospectivas valgan la pena:
  • Fun Retrospectives contiene un gran número de actividades, separadas en distintas categorías, con descripción, fotos y ejemplos. Tenemos actividades de check in para comenzar, actividades de check out para cerrar, actividades que energizan al equipo, actividades de team building, actividades para ver hacia atrás y también para ver hacia adelante.
  • Retromat es un sitio que contiene un montón de actividades pero lo novedoso es que te arma al azar un plan con actividades ordenadas por tipo para hacer en una misma retrospectiva. Al principio te indica una actividad para armar el escenario, luego otra para recolectar datos, siguiendo con otra para indagar, una para decidir qué hacer y finalmente otra para cerrar la retrospectiva.

viernes, abril 17, 2015

Coaching para la transformación personal

Hace bastante que vengo escuchando mucho sobre programación neurolingüística (PNL) y coaching ontológico. Tenía ganas de hacer algún curso o leer algo y este libro de Lidia Muradep fue mi primer acercamiento al tema. El título completo del libro es: "Coaching para la transformación personal: Un modelo integrado de la PNL y la ontología del lenguaje".

Por lo interesante del libro no va a ser lo último que lea del tema. La PNL es un modelo para lograr mejorarse a uno mismo y maximizar el potencial que tiene uno para desempeñarse en cualquier situación de la vida. Esto está muy relacionado con el lenguaje. Luego de mejorar uno mismo, la idea es aplicar este conocimiento para hacer coaching y ayudar a otros a alcanzar ese potencial. 

La autora es argentina y es la directora de la escuela Argentina de PNL y coaching. En su escuela hay varios cursos del tema. El libro es de nivel introductorio, se los recomiendo a los que quieran comenzar a abordar este tema, como lo hice yo.

viernes, abril 10, 2015

De la Motivación a la Acción

Una compañera de trabajo me regalo hace poco el libro de Mark Alexander Peale titulado "De la Motivación a la Acción". Es un libro corto, de lectura fácil y entretenido que termine rápidamente. 

El autor se cuestiona que motiva a la gente a actuar, que las impulsa a salir tras sus metas y no darse por vencida hasta verlas realizadas. Lo que enuncia es que el enemigo número uno del éxito no es el fracaso, ni la falta de oportunidades, talento, dinero, educación o apoyo, sino la falta de acción. Peale nos muestra como todas las personas actúan impulsadas por diferentes motivos, y este impulso interior que nos estimula a actuar puede ser un deseo, un estado de ánimo, una necesidad, un sueño, una pasión o una meta. 

El libro presenta la historia de 12 hombres y mujeres que entraron en acción para lograr sus objetivos. Para algunos su motivación fue la oportunidad de influir en las demás personas. Otros actuaron motivados por el logro de metas personales que les permitieran avanzar y crecer, impulsados por la necesidad de realización personal, de ser lo que podían ser, de aprovechar plenamente su capacidad y su potencial.  A pesar de sus diferencias, sus logros dejan en claro una de las mayores verdades acerca de la motivación. La mayor fuerza motivacional que opera en el ser humano es el deseo de ver sus sueños hechos realidad.