Microblog de nodoTIC.com

Extensión del blog www.nodoTIC.com

Anotaciones sobre tendencias en sistemas de información de gestión y ... algunas cosas más

Push vs Pull, nunca lo había visto tan bien explicado
Fuente: Priming Kanban de Jesper Boeg

Push vs Pull, nunca lo había visto tan bien explicado

Fuente: Priming Kanban de Jesper Boeg

Infografía de Scrum - Wow!
Fuente: ZenAgile

Infografía de Scrum - Wow!

Fuente: ZenAgile

El pensamiento socrático del buen Scrum-Master

El rol de ScrumMaster, como Angel Medinilla, entre otras características, lo definia en presionblogosferica:

El SM es un maestro de la escucha. Nunca decide ni sugiere soluciones: hace preguntas. pero son las preguntas correctas. Respeta las decisiones del equipo, pero hace al equipo responsable de ellas. ayuda al equipo a identificar problemas, descubrir soluciones e implementarlas por ellos mismos.

Y aún más semejanza a la definición del ScrumMaster como “Facilitador”, que aprendí de Alan Cyment en el curso de CSM,

Es necesario que el SM se aguante las ganas de solucionar los problemas. El SM ha de ayudar en las soluciones haciendo preguntas incomodas. En muchos casos, el SM se debe comportar como “una mosca en una pared”. Lo más importante es el grupo.

(Source: blog.agilmedia.com)

Infografía historias de usuario. Vía Agilmedia

Infografía historias de usuario. Vía Agilmedia

Mis 25 puntos de autoridad en Scrum… certificados

Mis 25 puntos de autoridad en Scrum… certificados

Cuadro de mandos para el seguimiento de uno de los proyectos en los que estoy

Cuadro de mandos para el seguimiento de uno de los proyectos en los que estoy

Introduction to Agile and Scrum, Part 1 | Agile Development

How to think like a Scrummy

How to think like a Scrummy
August 25th, 2009 · No Comments · English, Good to know, Ideas, Professional Software Delivery, Roles, Scrum, Scrum Basics

Garr has again a very great article about how to think as a designer. He shows us, what we need to do to come up with cool ideas. The 10 points he mention [1] I changed it for us as Scrum Thinkers:

(1) Embrace constraints. A ScrumMaster understands that Scrum needs constraints. The Timebox, the Sprint, the defined Scope of Sprint Planning. Constraints are helpful. They guide us towards our goals. All management technologies uses the idea of constraints to create focus.

(2) Practice restraint. A Scrum teams needs to understand what they can do. They need to focus and they need to explain to everybody what they can do. And then they focus and do.

(3) Adopt the beginner’s mind. A ScrumMaster helps the team to understand they are again and again developing new teritory. The retrospective helps people to understand that they do learn new approaches, that it is good to be clear about that they are again in a learning mode. Only if you have the humbleness to understand that you do not know everything you can improve.

(4) Check your ego at the door. This needs to be said for the team members and for the ScrumMaster. Leave you ego out. Well — this is said much earlier as it is done. A ScrumMaster can easily start to be bossy, a team member might be seducted to make clear that he is a cool programmer. And … make clear: You do work for the customer and user, you do not work for you. The feedback from the customer gives you the credit.

(5) Focus on the experience of the design (development).Be not sofisticated about the development process. Sure you can talk for hours about the cool new way, the cool new language, the cool new tool. At the end the result (4) is important.

(6) Become a master storyteller. What is the story of you application. What is the design? What is the metaphor? What story tell you to yourself about you new cool solution, what do you tell to the outer world?

(7) Think communication not decoration. Run your Scrum as communicative as possible. The most simple tool is most of the time the right thing. Do not overdo things. Do things that are fun for you. How can you improve the communication, how can you make the things more simple.

(8) Obsess about ideas not tools. Software Development is not about tools, it is about creating a solution. I have seen developers using simple VIs to create super cool applications, I have seen developers using cool IDEs to develop crab.

(9) Clarify your intention. Your solution to your way of working and the solution to your design of the applicaton will be as best when the intention is clear. Why do you things the way you do them? Do them not because a consultant said it makes sense. Do them because after using the new ideas they created a benefit for you.

(10) Sharpen your vision & curiosity and learn from the lessons around you. This is very true for good Scrum Teams. Why are you doing your application? What is the purpose. Do the details that you develop make sense in the whole picture. The team as a whole works here together. Scrum Teams are NOT based on workers who left their brain at home.

(11) Learn all the (Scrum )”rules” and know when and why to break them. “Over the centuries, those who came before us have established useful and necessary guidelines — these are often called rules or laws and it’s important to know them. Yet, unlike other kinds of laws, it may be acceptable to break them at times so long as you know why.” But first learn the Basics, till you really know them and then change them, only if you really know why!

[1] http://www.presentationzen.com/presentationzen/2009/08/10-tips-on-how-to-think-like-a-designer.html