Going Agile

So you’ve gone Agile – How is that working for you?

With increased exposure, many organizations are trying to become more “Agile”. But what does that mean exactly? How the term “Agile” is interpreted can lead to different processes even within one organization. In many cases, “going Agile” can mean as little as “we will do what we want to do” to “we have no discipline or process whatsoever”. These are extreme cases, however with most organizations legitimately trying to change the way they think about or do software development. For our purposes, let’s assume that “going agile” means we are trying to find a way to develop software that is "better" than what we are doing now, as we try to address organizational pain points.

On Leadership

Blogging is interesting - so many things to say, all of which can get you in trouble. In a sense, you can convey lots of thoughts - but in a professional environment....

Take leadership for example. One of the things a ScrumMaster concerns himself with is team development, and to a lesser degree team leadership. A wise person would understand that a mix of both is necessary for the betterment of the team members. But may Scrum advocates live so far into the ideals that they can sometimes sacrifice the team to their concepts.

I was listening to an interview from Pollyana Paxton, one of my favorite thought leaders where she explained the highest ideal of leadership in a collaborative environment. But towards the end, she flat out labels Jack Welch as "the worst leader ever". In looking at the statement, and the following clarification (did not provide an environment for collaboration and instilled one of fear) one can see where she would look at Jack this way. But, in our environment (this is AMERICA, many would argue) Jack's method - as cold and cruel as it may seem - yielded results. And this is why a lot of people seek his advice.

In my own experience, a good leader is one that understands the concept of leadership and it's styles - and is able to use them to benefit the team. Personally, my goal is to make sure the members of any team that I am chosen to lead are able to grow professionally, so that we all succeed at the end. Sometimes this is a technical growth, others a simple change in communication or the ability to look outside their silo. This is a personal goal, and has served my projects very well.

In today’s college coaching environment, people are finding that a softer style is preferred over an old school type of approach. The old school is invariable tied to "command and control", and certainly it works (look at Mike Leach). But others, like Mack Brown and others have followed a softer approach for a while - with great results. In this day and age, a leader has to understand what his goal is (team growth, project success, financial gain or personal glorification) and be able to choose the adequate tool to get him there.

As for me - we'll see how it turns out with the "helping your team members grow" thing. I am heavily relying on the fact that Mack Brown is right - but only time will tell!

"Cuando usted hace las cosas comunes en la vida de un modo poco común, usted mandará la atención del mundo." George Washington Carver


Innovación: La frontera sin limites


Una de las cosas mas preciadas de el proceso Scrum es un resultado indirecto del implemento de el proceso. Los resultados directos son el incremento en la calidad de la code, el acortamiento del tiempo de desarrollo, y la reducción del costo de desarrollar nuevos programas. Pero tiene otros resultados, uno importante siendo que el equipo técnico generalmente se siente mucho mejor yendo a el trabajo cada día. Los miembros del equipo se encuentran con mas tiempo, mejor balance de vida y se sienten como si tuvieran real importancia en la organización. Esto quizás sea un poco raro en Latinoamérica, pero en EEUU el sentimiento mayor de la gente de IT es que no se da la importancia o respeto al trabajo.

Cuando los miembros del equipo se sienten razonablemente cargados, y un poco cómodos, y además un poco felices – entonces una de las mejores partes de Scrum puede empezar a dar flor. Con el tiempo adecuado, y por las herramientas y el sistema (retrospectiva e “inspect and adapt”) los miembros de el equipo deberían de tener tiempo para innovar. Mucho valor se pone acá para la innovación, pero muy poca preparación se da para ello. Muchas compañías se valoran dependiendo a su innovación, y las que no se inventan directamente pro esto, cuando menos ven el valor de tener varios productos nuevos para ofrecer a sus clientes. Entonces, que se puede hacer para poder fomentar el medioambiente adecuado para la innovación? He aquí mi receta:

1. Correr Retrospectivas robustas
2. Hacer tiempo en cada sprint para pensar
3. Poner en lugar una área para que los equipos convivan en este modo de pensar
4. Deje que miembros de otros equipos participen cuando sea posible
5. Valore los resultados
6. Deje que los equipos se guíen solos

1. Por que las retrospectivas? Porque es aquí donde el equipo aprende a observarse y a pensar en la solución que ayudara a el equipo a salir a un nivel mas alto. Esto requiere los principios de la innovación, y guiar a el equipo en una propia retrospectiva lo ayudara muchísimo a poder pensar adecuadamente para innovar.

2. El Sprint siempre estará bajo el ataque. Si no es el ataque de sacar lo mas que se puede a el tiempo dado, o bajo el brazo pesado de un PO que quiere conocer los métricos o el equipo propio tratando de sacar código perfecto – es facilísimo destruir el sprint. Pero, si en el propio sprint se da un poco de tiempo para pensar sobre la innovación (ya sea reducción de deuda técnica, o pensar en nuevos productos, o nuevas herramientas) se da un paso muy fuerte adelante para el equipo y la compañía. Este paso se debe de tomar con el primer paso en efecto – si el equipo nada mas usa la retrospectiva para llorar y sentirse mal, este tiempo es “waste”!

3. 4. y 6. De los puntos este es mi favorito! Y tiene dos posibilidades – una mucho mas divertida que la otra. En mi trabajo de Scrum Coach, tuve el placer de trabajar con dos jefes que sabían valorar Scrum y la innovación. También tuve la oportunidad de añadir mis ideas en conjunto con las de mis jefes para ver un resultado muy bueno. Mi CIO empezó a dar valor a la innovación en la compañía al comenzar dos iniciativas, ambas caen en la primera categoría: La área de innovación dentro del trabajo.

El tenia una “junta” con todos los miembros de IT. Esta “junta” era un tiempo se 30 minutos cada semana, y estaba diseñada específicamente para tener el tiempo necesario para pensar y someter ideas inovativas para el concurso. El concurso se corría cada mes, y tenia premios medianos pero muy útiles. Esto funciono muy bien para un grupo selecto y pequeño de la organización. La mayoría de las personas en IT no entendían ni estaban cómodas con la estructura, ya que dependía en el individualismo.

Para mi, el mejor resultado salió de mantener esta área Fuera del trabajo, la que representa la segunda opción. No solo se presta para divertirse mas (Margaritas, Tapas, Sangría) pero se permite que personas de diferentes equipos se junten, y que hablen abiertamente de el trabajo y de sus ideas. De esta junta informal (los Jueves se mantenía la junta “Scrumarita”) salió la idea de un proyecto mediano que ahorro a la compañía unos 700 mil dólares mensuales, al formarse un equipo “pirata” de dos miembros con un ScrumMaster. En esta manera informal, muchas mas gentes estaban interesadas.

Con el ejemplo anterior, se puede ver el valor del punto 6. Dejando que se organicen a si mismo resulto en la identificación de intereses comunes, y rápidamente se resolvió una área que necesitaba atención. Generalmente, tener un intercambio que requiere pensamiento de resolución de problemas para el trabajo necesita que la localidad este fuera de el edificio de trabajo – ya que se remueven muchos obstáculos mentales.

5. Finalmente hay que encontrar manera de reconocer a las ideas que se sugieren por los equipos. Claro, no todo es posible de implementar, pero cuando menos se debería tener un programa de reconocimiento – quizás un poco de dinero, o un concurso para la mejor idea. A algunas gentes les agrada el tiempo libre – de alguna manera se debería de cultivar el proceso, para asegurarse que los equipos estén siempre pensando en ideas nuevas.


To keep this small, here goes in English:


"When you do the common things in life in an uncommon way, you will command the attention of the world." George Washington Carver

Innovation - the frontier without boundries

One of the most prized things that happen with the Scrum process is a side effect of implementation. The direct benefits of Scrum implementation include improvement on the quality of the code, the decrease of development time and the reduction of cost in the development of new programs. But there are other results, one of the more important ones is that a technical team will feel much better going to work each morning, having a better life/work balance and the team feels like they matter in the organization. This may be slightly different in Latin America, but in the US the majority of people in IT feel that they do not matter all that much and are not well respected.

When the members of the team feel reasonably tasked, and a bit comfortable, and possibly a little happy – then one of the best parts of Scrum can start to happen. With the right time, and the proper tools (retrospective) and due to the nature of the process (inspect and adapt) the team should have enough time to be able to start innovating. Although innovation is seemingly very valued here in the states. Very little preparation is taken to enable it. Many companies value themselves based on their innovations, and those that do not have this as a calling card at least see the value in bringing new products to market to offer their clients. So what can be done to modify the environment so it is adequate for innovation to take place? Here is my recipe for this:

1. Run Robust Retrospectives
2. Make time each sprint for thinking
3. Set aside a location for team members to collaborate while thinking (or their thoughts)
4. Allow members of other teams to also participate
5. Value the results
6. Let the teams manage themselves

1. Why Retrospectives? Because the retrospective is where the team learns to observe itself and provide a solution to help itself to higher levels of performance. This requires the basic principles of innovation, and guiding the team in a proper retrospective will help lots toward allowing them to think about innovation properly.

2. The sprint is always under attack. If it’s not trying to cram all we can in as little time as possible, or working under a heavy handed PO that wants to know the metrics or the team itself trying to develop “perfect code” – it is very easy to disrupt a sprint. But, finding time within the sprint to think about innovation (whether Technical Debt reduction, new product development or new tool development) you take a strong step forward for the team and the company to foster innovation. This string step needs to be taken only after step 1 is in place – if the team only uses retrospectives as a complaining session or to feel sorry for themselves, this time cam be classified as “waste” (Muda)!

3. 4. & 6. Of all the points this is my favorite! And it has two possible implementations – one much more fun than the other. In my role as a Scrum Coach, I had the pleasure of working with two bosses that valued Scrum and innovation. I also had the opportunity to add my ideas in conjunction with those from management to ensure a positive result. Our CIO started to value innovation at our company by starting two initiatives, both of which fit in the first category: A space for innovation within the work environment.

Our CIO called a “meeting” for all the people within IT. This “meeting” was a 30 minute window set aside each week and was specifically designated to think about and submit innovative ideas for the contest he ran. This contest was run monthly, and had mid range prizes that were neat and useful. This worked well for a select group of individuals within the organization. The majority of people within IT either did not understand or were not comfortable with the structure, however; as it relied heavily on individual contributions.

For me, the best result with this approach is to have a meeting outside of work – off site – which represents the second option. Not only can this meeting be a lot more fun (Margaritas, Appetizers, Sangria) but it allows for people from different teams to participate, and openly talk about work and their ideas. From this informal meeting (we had a Thursday meeting, “Scrumarita”) we had an idea for a mid size project that ended up saving the company 700K monthly, as we formed a pirate team of two members with a ScrumMaster. Many more people were interested in this informal forum.

With the last example, you can see the value of point 6. Leaving the team to self organize resulted in the identification of common interests and an area that sorely needed attention was tackled. Generally speaking, having an interchange of ideas that requires though for resolution of a problem with work requires a location outside of the work environment – because a lot of mental blocks are inadvertently removed.

5. Finally, you have to find a way to recognize the ideas that are suggested by the teams. Of course, not everything is worth pursuing, but at least there should be some sort of recognition program – maybe a small amount of money, or a contest to determine the best idea. Some people are motivated by time off – in some manner the process of innovation should be cultivated, so that you can ensure the teams will be thinking about new ideas.