lunes, mayo 18, 2020

Trabajando en Cuarentena

De: https://its-ok.clearleft.com/

It hasn’t been easy, working in lockdown and juggling family life, client projects and everything else in between. So we wanted to say…

It's OK.

  • to turn your camera off if you want to.
  • to turn off Slack for a few hours.
  • not to respond to Slack messages immediately.
  • to use Slack calls over video calls.
  • if your pets/kids/partners are wandering around in the background.
  • to step away from a call if your delivery arrives.
  • to do excercise or go for a walk during the day.
  • to take a nap in the afternoon.
  • to feel like you're not being as productive as normal.
  • to work asynchronously if your project can handle it.
  • to ask for a phone call instead of a video call.
  • to say you’ve had too many video calls and need a break.
  • to say you need some down-time.
  • to take a mental health day if you need one.
  •  
  • to say you’re not OK.
 

miércoles, agosto 14, 2019

7 diferencias entre un líder y un champiñón

Yo no soy un experto en liderazgo, ni pretendo iluminar a nadie con este artículo porque no sabría. Seguramente harían falta muchos manuales para definir todo lo que necesita una persona para ser un buen líder, y yo me limitaré sólo a hacer algunas reflexiones sobre un aspecto concreto, su actitud; y no son consideraciones fruto de mi experiencia personal, solo faltaría!, sino de lo que he aprendido trabajando con muchos líderes de diferentes organizaciones. He tenido la suerte de conocer a todo tipo de fauna: merluzos, melones, ciruelos pero también he conocido a personas a las que he admirado muchísimo por su capacidad de liderazgo. Últimamente he tenido la suerte de compartir mucho tiempo con Mikel, uno de ellos. Observándolo y reflexionando he podido identificar 7 aspectos que diferencian a los líderes absolutamente espectaculares de los champiñones que pretenden dirigir personas.



1a. Diferencia: tienen el chip de estar al servicio de los demás. Hay personas que sirven para liderar y hay otras que nunca servirán por mucho que se lo propongan. Hay jefes chusqueros que piensan que liderar es decirle a los demás lo que tienen que hacer y verificar que está hecho en tiempo y forma adecuados, como si fuera el ejercito, pero los líderes saben que su trabajo consiste en ayudar a los demás para que sean mejores personas y mejores profesionales. Tener ésta mentalidad, esta obsesión para ayudar a los demás, es un requisito imprescindible. ¿Cuántas personas con equipos a su cargo lo tienen? Por desgracia son minoría, porque casi todos piensan en sus objetivos y ven a los demás como un recurso que les ayuda a conseguirlos. El liderazgo basado en esta premisa se caracteriza por el control y la supervisión, el egoísmo, la rigidez, la falta de confianza y la mediocridad, sintiendo como una amenaza a todo aquel que pueda ser mejor que uno mismo. Cuando uno se centra en ayudar y servir a los demás para que crezcan y se desarrollen como personas, entonces es un trabajo brutal y muy gratificante, porque logra sacar lo mejor de cada persona para que además de “saber” hacer las cosas, “quieran” hacerlas poniendo sus mejores esfuerzos en ello. La Responsabilidad Social Corporativa esta de moda, pero muchas empresas la han entendido como hacer una donación o publicitarla; la verdadera responsabilidad social empieza por cuidar, tratar bien y preocuparse por las personas que trabajan en una empresa. Aquello de que el accionista es lo más importante, muy predicado en las mejores escuelas de negocio, a mi me parece un cuento chino, una irresponsabilidad catastrófica. Primero las personas, luego los clientes y por último el accionista.



2a. Diferencia: Influyen por su manera de ser. La diferencia entre una persona grande y una persona mediocre no está en sus conocimientos ni en su experiencia, está en su manera de ser. Los cracks saben que para poder ayudar a otros a ser mejores, primero tienen que hacer un trabajo interior enorme para mejorar ellos. Su papel es el de influir, inspirar, transmitir, motivar y por eso tienen una manera de ser marcada por unos valores y unas virtudes humanas que admiramos. No conozco ni un líder espectacular del que no me haya asombrado su manera de ser. No se trata de estudiar un master o tener un cargo en la tarjeta, se trata de actitud y manera de ser; sin valores humanos, el líder es un déspota, un tirano, un dictador. Mark Zuckerberg tiene una frase genial que dice: “sólo contrato a alguien para trabajar directamente conmigo si pienso que yo trabajaría para él”.



3a. Diferencia: saben lo que es más importante en la vida
. Hay una fase del Dr. Stephen Covey que me encanta: “lo más importante en la vida es que lo más importante sea lo más importante”. No es sólo un juego de palabras, que evidentemente lo es; es también una frase que si uno piensa durante unos minutos, tiene mucho fondo. El requisito básico para que las personas trabajen bien es que sean felices. Puede parecer una afirmación superficial o poco sofisticada, pero es una verdad como un piano. Vivimos en la sociedad de las prisas, del ya, del consumo, de lo artificial, del envoltorio, en el que el parecer es más importante que el ser y es una carrera que nos acaba atrapando a todos y desquiciando a muchos porque olvidamos muchas veces lo que es importante y acabamos corriendo a toda pastilla hacia ninguna parte. Para que las personas sean felices tienen que poner en el centro de su vida lo que es más importante para ellos. Personalmente pienso que nuestro Proyecto con mayúsculas en esta vida es nuestra familia y, en una época de máxima exigencia laboral, necesitamos tiempo para equilibrar nuestra vida profesional con la personal. Los líderes fantásticos lo saben porque ellos son los primeros en hacerlo y, entendiendo que el trabajo es importante pero nunca lo más importante, generan y promueven entornos laborales que ayudan a sus equipos a equilibrar su vida personal y profesional.



4a. Diferencia: trabajan con las personas sabiendo que son voluntarias. Muchos trabajos se han convertido en una forma de esclavitud moderna en el que las personas ven sus actividades como una penosa obligación en la que no se divierten ni disfrutan, en la que se sienten tristes, quemadas, estresadas y tienen una taza con la frase “por fin es viernes”. Muchos líderes no han entendido que trabajan con personas que son voluntarias, como si fuera una ONG, al menos en parte. Todos tenemos un comportamiento “normativo” por el que hacemos todo lo que tenemos que hacer para que no nos llamen la atención: una forma de ir vestido, un horario de entrada y salida, unas metodologías y procesos de trabajo, etc. Es un comportamiento “obligatorio”. Pero las personas también tenemos un comportamiento “espontáneo”, que es el cariño que le ponemos a lo que hacemos, las ganas, la pasión, la alegría, el esfuerzo para querer hacer las cosas lo mejor que podemos. Y este comportamiento es 100% voluntario, no se puede exigir, el líder se lo tiene que ganar, se lo tiene que merecer, porque los demás se lo dan sólo si les da la gana. Nadie puede exigir a una persona de su equipo que ponga el 100% de sus ganas y alegría en el trabajo, que se deje la piel o que le pregunte al jefe si necesita ayuda cuando le vea apurado; eso te sale o no te sale, y si el jefe es un mamón, es normal que no salga.



5a. Diferencia: son personas amables, agradables, que practican la regla de oro.
En todas las religiones, desde el cristianismo al budismo, pasando por el hinduismo, el judaísmo o el islam, absolutamente todas, se predica el siguiente corolario: “trata a los demás como te gustaría que te trataran a ti”. Puede parecer simple e incluso demagógico, pero es una verdad descomunal. La vida es simple, no fácil, pero simple; lo que ocurre es que muchas veces nos encanta complicárnosla o que nos la compliquen. Seguro que hay sofisticadísimos modelos de liderazgo muy útiles, pero también lo es esta frase tan simple que casi nunca aplicamos. Hay quien piensa que es muy genérica, poco concreta. Pues te doy otra, de la Madre Teresa de Calcuta: “que nadie se acerque jamás a ti sin que al irse se sienta un poco mejor y más feliz”; aplicarla en cada instante es algo muy práctico que a veces requiere cuidar las formas al hablar, o tener paciencia para escuchar, o ser justo con alguien cuando no hay afinidad. Si esta frase se te pudiera aplicar a ti serías una persona absolutamente apoteósica, pero lo mejor de todo es que para que esta frase se te pueda aplicar a ti no dependes de nadie, sólo de tu decisión y compromiso personal. Seríamos mejores personas, mejores padres, mejores parejas, mejores amigos y mejores líderes. Las personas que admiramos y que nos ayudan a ser mejores tienen un trato cercano, agradable y alegre, son educadas y cuidan siempre las formas. Son cosas básicas, lo sé, pero es que las estamos perdiendo. Por suerte, quedan algunas personas maravillosas, de esas que conoces y por dentro piensas, “ole, ole y ole!, yo quiero ser como ella”. Cuando lo piensas, estas delante de un líder.



6a. Diferencia: hacen sentir importantes a los demás. Confían en las personas, por eso delegan en ellas, las involucran, les preguntan, les hacen participar y logran su compromiso. Les hacen sentir importantes también porque consiguen que hagan un trabajo estratosférico. Nadie es bueno para todo, pero tampoco nadie es inútil para todo. Ayudar a las personas y hacerlas sentir importantes requiere primero conocerlas para saber cuales son sus dones y en qué actividad puede desarrollarse mejor. Y paciencia, mucha paciencia! Hay personas que entienden que los bebés tardan 9 meses en nacer por mucho que te esfuerces y otros son como el chiste que decía, “Señor dame paciencia, dame paciencia, pero dámela ya!”” Los líderes tiene paciencia y forman, los jefes chusqueros van con prisas y deforman. Los cracks tienen una obsesión por buscar lo bueno que tienen los demás, porque saben que lo tienen, y cuando lo encuentran, les ayudan, les motivan y les exigen, confían y ponen todos los medios para lograr que tengan un desempeño brutal. Y cuando lo logran, se lo reconocen y les elogian, porque saben que en el fondo de todas las personas existe el anhelo de hacer cosas importantes, de aportar algo, de sentir que contribuyen y que se les aprecia. Reconocer el trabajo bien hecho de manera sincera es el mayor chute de motivación que alguien puede recibir. Entonces, esa persona se siente valorada, comprometida, agradecida, y su rendimiento mejora, es un círculo virtuoso. Hay jefes que creen que hay personas a las que es imposible motivar; lo que deberían pensar es que hay personas que estaban muy motivadas hasta que les conocieron a ellos.



7a. Diferencia: sonríen. Su trato agradable empieza por su cara. Sonreír es una virtud enorme que no valoramos suficiente, como el sentido del humor y la alegría. Las personas que sonríen y son alegres son mucho más productivas y generan entornos mucho más eficientes. Hay un proverbio chino que dice, “el hombre cuya cara no sonríe, no debería abrir una tienda”. Es de cajón! ¿Cuántas tiendas cerrarían en este país?, empezando por las de los chinos, que no lo han entendido tampoco! Deberíamos fichar a las personas por su alegría y despedirlas por su mal carácter, empezando por los líderes. Hemos perdido el sentido común, ¿cómo se puede pretender ser un buen líder con cara de sepia?

Fuente: De Teo Alcorta: https://www.linkedin.com/pulse/7-diferencias-entre-un-l%C3%ADder-y-unchampi%C3%B1%C3%B3n-teo-alcorta/

sábado, julio 14, 2018

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.