domingo, 8 de febrero de 2015

Inspiring agile teams

The Oxford Universal Dictionary defines music as, "That one of the fine arts which is concerned with the combination of sounds with a view to beauty of form and the expression of thought or feeling" (Little and Onions 1965, 1300).
In analogy, what if we define agile as, "That one of the fine arts which is concerned with the combination of interactions with individuals, with a view to beauty of form and expression of teamwork on developing cognitive skills and high performances“?
What effect is this metaphor making on you? Does it inspire you, to be an artist of a workplace?
Many independent research studies state that what really stimulates people to push forward and give their best isn’t knowledge, responsibility or even money, but it is the inspiration people feel towards their work.

By Steve Jobs

"Organizations that get this right will constantly beat their competitors," says Chris Roebuck, a visiting leadership professor at the Cass Business School in London.
In fact, today´s market competitiveness is not only driven by producing more and faster as decades ago, neither by responding to market changes quickly, but it is about responding quickly and steadily while adding value. This is what makes agile philosophy an art of being a key element to organizations survival.
So how should this art be performed? There are no rules to practice art in general once you reach the “Ha” or “Ri” stages. It is what allows us to reach the capability to improvise, discover and compose great practices. But if you are starting with agile in “Shu” phase, there are some basics concepts to assimilate in order to perform agile well, without failed test that would leave the student and others maimed or frustrated.
Are you curious about the meaning of Shu Ha Ri? Originally, the model was created to master martial arts. However, the application of Shu Ha Ri can be used to master anything (if that’s possible). A martial art student progresses through three stages of proficiency called Shu Ha Ri. These stages also describe Agile teams in their way to become good at being agile.
Shu: Follow the rule. In Shu student stresses the basics by copying the techniques as taught without modification and without yet attempting to understand the rationale. This gives the student a solid foundation for future learning.
Ha: Break the rule. After Shu comes Ha. At this stage, student has attained the basics and now spends time “reflecting on the truth of everything”. By this the student comes to a deeper understanding of the art than pure repetitive practice can allow.
Ri: Be the rule.Ri means to go beyond or transcend. In this stage, one must think originally and develop from background knowledge original thoughts about the art and test them against the reality of his or her background knowledge and conclusions as well as the demands of everyday life.
So, where do you find yourself right now and what are you heading towards? Do you manage to learn from others and making others gain knowledge in a relevant and pragmatic way? This is how teamwork should be in 21st century.
Shu Ha Ri should result in the student surpassing the master, both in knowledge and skill. This is a source of improvement for the art as a whole. If the student never surpasses the master,the art will stagnate. If the student never achieves the master ability, the art will deteriorate.
So what are you doing in order to continually improve and flourish the art of agile? Do you use metaphors to inspire your teams? Do you make them curious about their crafts? Do you stimulate them to learn? Do you learn from them? Do you trust them and support them? Do you let them break rules when non-fatal testing is possible? Do you brainstorm them, stimulating full divergence and then convergence? Do you guarantee a safety environment for them to express their ideas and uphold their experimentations? Do you challenge their performance? Do you encourage their self-organization? Do you let them own their decisions and make them committed? Do you care about their feelings? Do you help them recovering from group dynamics side effects? Do you build and share values with them? Do you make them aware that diversity makes us smarter? Do you enrich their practices, principles, values mind-set? Do you make their brilliance emerge?

The answers can be “Yes” or “No”. If you want to get to the next step towards high performance, it might be more fruitful contemplating this beautiful tree and answering its questions.

If the high performance tree drawing inspires you more than a list of questions not even formatted, then make use of the metaphors. Why not? Go further, design serious games. Inspire people around you. It is all about cooperative game of invention and communication.


lunes, 5 de mayo de 2014


Use the most adapted tools an technologies to your context:

viernes, 28 de marzo de 2014


Some situations that occurs more or less often depending on the work environement:

Discover some benefits of a daily meeting:

martes, 22 de octubre de 2013

Agile product ownership in a nutshell

Building the vision of the Product Owner:

viernes, 11 de octubre de 2013

The Clean Code Talks -- Unit Testing

Before you start testing the TOP, please make sure that the bases are solid.

Analogy: Is like TESTING A CAR directly driving it.

1. TEST each piece of the car separately and make sure it works right.
2. TEST that one piece fit and work fine with another.
3. TEST all the pieces of the car together

If you start testing all the pieces of the car together...

lunes, 3 de junio de 2013

MVC architecture dilemma.

One of the most known and used pattern of the presentation layer of web applications in many platforms and technologies is a Model View Controller pattern. I have worked as software developer in many projects building complex web applications based on JEE architecture, and the following dilemma was quite often present.

Having one controller, dealing with different logic, to satisfy a considerable range of views and models logic, with specific functions for each page, result on complex controller, that with time become error-prone, time consuming and hard to maintain.
On the other hand, building an entire new controller for each screen does not just mean lots of classes, it makes the application harder to extend. If we wanted to build a logging mechanism, for example, we would have to add logging code to each controller separately. In fact, there are lots of things we might need to do for every request: implement navigation, maintain session information, and gather statistics, to name a few.

A pair of patterns helps balance these two approaches. The Front Controller pattern advocates building a single controller that performs common functions on each request, but delegates other functions to a page-specific controller. 

The Decorator pattern then shows how to dynamically expand the front controller. The Front Controller pattern is stand for a controller that has a fairly simple role, it deals with common tasks, and then forward control on to a page-specific controller. 
The specific functions of updating the model and choosing the view are delegated to a page-specific controller