La tecnología nivela el campo: La Hora de los Más Chicos

umbrellaID-10023846

En el libro “El Arte de la Guerra” de Sun Tzu, el capítulo “Configuraciones de Terreno” contiene un párrafo muy relevador:

“Si podemos avanzar y el enemigo también puede avanzar, se llama ‘accesible’. En la configuración ‘accesible’, primero ocupa las alturas y el lado yang (soleado), y mejora las rutas para transportar provisiones. Luego, cuando nos trabemos en batalla, será ventajoso”.

Sun Tzu, en este párrafo, destaca a la vez que el terreno alto y soleado ofrece ventajas innegables al ejército que las ocupa, y que las posiciones niveladas no ofrecen ventajas diferenciales a ninguno de los contrincantes, y por lo tanto, el resultado de la batalla no está garantizado, sin la intervención de muchos otros factores cuyo orden de magnitud y combinación son tales que puedan desbalancear el resultado en favor del lado poseedor de los mismos.

Este párrafo es muy relevante respecto al panorama actual de tecnologías, redes sociales y software open source. Justamente, todas estos elementos dan lugar a un campo de batalla que presenta un terreno accesible, es más, totalmente nivelado, por lo tanto, el terreno es a la vez accesible y sin puntos elevados, por lo tanto, no hay lugares altos y a la vez, todos los sectores son lados yang (soleados).

En este contexto, la ventaja juega claramente a favor de los players más chicos, las PyMES, las empresas regionales, y definitivamente no juega a favor de las multinacionales, ni siquiera de las empresas nacionales más grandes.

Esta ventaja es concreta y posible, pero no puede realizarse si “los más chicos” no toman las medidas necesarias para hacer de estas ventajas una realidad.

Esas medidas necesarias implican un plan estratégico y una implementación de tal estrategia.

Tanto el plan estratégico como su implementación requieren claramente de una Arquitectura Empresarial y de un sistema de plataformas técnicas de negocios capaz de dar soporte a tal arquitectura, todos ellos alineados con el plan estratégico mencionado.

Saludos, GEN

Las redes sociales no aumentarán sus ventas por si mismas: debe alinear su arquitectura empresarial a su estrategia de negocios

BuildingID-10076694

Es interesante analizar brevemente como, en su gran mayoría, las empresas usan las redes sociales, las plataformas técnica de negocios y demás tecnologías para lograr sus objetivos de negocios.

A simple vista, el grueso de las empresas no sacan buenas calificaciones en esta área. Es más, resulta inclusive frustrante como espectador (y me imagino que para las mismas empresas debe ser aún más frustrante!) ver como el uso que hacen de estas tecnologías es correcto desde el punto de vista técnico, pero muy deficiente desde el punto de vista de estrategia de negocios.

Si bien es cierto que cada caso de cada empresa admite un análisis profundo para identificar los drivers de semejantes fallas sistemáticas, se destaca una falla por encima de todas las demás, en particular por su presencia generalizada en todo tipo de industrias, orígenes y tamaños de organización: fallas a nivel de arquitectura empresarial (en general, el caso más frecuente de falla es “Ausencia de una Arquitectura Empresarial”).

Sin una arquitectura empresarial que comande y guíe el despliegue de plataformas técnicas de negocios alineadas con las estrategias de negocios de la organización, las empresas seguirán obteniendo el mismo orden de resultados frustrantes provenientes del empleo de Twitter, Facebook, Youtube, Pinterest, Google Search, Google Maps y el combo que tenga ganas de agregar a esta lista.

Mientras las organizaciones no amplien las perspectivas y horizontes que orientan a los equipos de negocios que definen las arquitecturas empresariales vigentes, es poco probable que se perfilen cambios drásticos favorables en este sentido.

Saludos, GEN

 

Agile and Estimates (I): the nature of projects that require the use of agile

Clock

Estimates are very important for any kind of project, including those projects  that require the use of agile, there is no question about that, but this brings to the foreground another set of important questions:

  • how do we use estimates in an agile project?
  • are there differences in the use of estimates with agile projects (when compared to the use of estimates in “traditional” projects)?

To be able to answer these questions, we need to explore some important characteristics of the nature of the projects that require the use of agile.

So, what’s the deal with the nature of certain types of projects that require the use of agile? Well, the kinds of projects that may need the use of agile have at least one of the following characteristics:

  • The company is exploring and developing an entirely new business model, so, business rules for this new business model are being explored and understood along with the project.
  • The company is developing a new type of product or service based on a new type of technology, so, there are no experts as this is a new field.
  • The company is using new software tools and technologies, or is adapting and customizing open source tools to its own needs, so the dev team has no experts on these tools and technologies.

If the company in question is a startup, the project will have all these characteristics, but even if the company is not as startup and/or the project has only one of these characteristics, it clearly will benefit from the use of agile.

So, the main factor in each one of these characteristics is uncertainty in a very high order of magnitude, very much in line with the kind of uncertainty you would expect in a typical Research and Development project.

In fact, agile projects and R&D projects share enough elements in common pertaining to the impact of uncertainty, that some of the project management tools and techniques that apply to R&D projects may also apply to agile projects.

One such tool that is useful for agile, just as it is useful for R&D projects, is the PERT estimation formula. Even though the historic background of the development of the project management tools collectively known as PERT is really interesting, it makes more sense to focus our attention on the estimation formula itself.

In agile projects as well as in R&D projects we may have a group of experienced professionals exploring how to solve a problem while “navigating through uncharted waters”. Under such circumstances, when trying to work out estimates, they will offer a range of values for any given task, from optimistic to pessimistic, and with some intermediate values being the most frequently proposed.

Taking this into consideration, the PERT estimation formula is based on a skewed distribution, the Beta Distribution, that properly takes into consideration the nature of such processes. Duration estimates are always positive, and it makes sense to use a balanced approach capable of compensating for overly optimistic or overly pessimistic values used in the estimation process.

The PERT estimation formula is very useful to provide “good enough” task duration estimates provided by experts under conditions of high uncertainty.

For this case, the estimation value is based on the median for this skewed distribution.

The PERT estimation formula expression is the following:

Te = (To + 4Tmp + Tp)/6

Where Te is the estimation for the duration of a given task, To is the most optimistic value for the duration of the given task, Tmp is the most probable value for the duration of the given task, and Tp is the most pessimistic value for the duration of the given task.

This estimation formula offers a balanced approach based on a weighted average, giving more importance (4 times more importance) to the most probable value, while still taking into account both optimistic and pessimistic values.

In an agile project, how do we get the values to apply to this formula?

It would be in meetings like the Planning Game, or in a Sprint Planning Meeting where the team can obtain estimates from the team members for each task, and out of the range of estimate values for each task it would be easy to determine the 3 input values for each given task needed for this estimation formula.

For each given task, the most optimistic and most pessimistic values are easy to determine, but the most probable value is not that obvious to determine. The most probable value is the mode, and the team must create a histogram for each task with the value of all the estimates for each given task. The mode corresponds to the class of the histogram that has the tallest bar. Sometimes, histograms for estimates look kind of weird, like with more than one hump (that’s a multimodal histogram): we will discuss about that in a follow-up post.

It is very easy to determine the mode for any list of values with a tool like Excel or Open Office.

This sheds some light on what approach to use for task duration estimation out of the range of values that the team proposes for each task during any planning meeting, but it does not offer many clues regarding the differences (if any) on how to handle estimates in an agile project. We will discuss this in a follow-up post.

Kind regards, GEN

Any Agile project is an ongoing conversation with the customer

Image

In my previous post, I mentioned that when in doubt on what to do to fix a problem in your agile process, think of The Agile Manifesto as your inspiration and guide on what to do.

But, as the Manifesto offers a list of guiding concepts, it may turn out a little tricky when a given problem to fix puts you in a dilemma between at least two of these concepts that may seem at odds.

Let’s suppose a situation to give an example to make the point more clear: in the next sprint, the customer is asking to add a new feature to the solution. Some of the existing functionality must be able to support that new feature (**)

From the experience in previous sprints, you have already learned that the customer is adamant about the idea of “retrofitting” as the way to give existing functionality the ability to support new features, specially if that retrofit (which looks a lot like re-work!), may require a substantial amount of the person-hours of a sprint.

 After you navigate these reqs with the customer, you realize that they feel oriented towards adding new routines, similar to the existing, that include the new feature, so, for any given functionality, you will have two versions of the routine: one version is the existing routine, and the second version will be a similar routine that also supports the new feature.

It is clear to you that this approach does not sit very well with quality attributes like Maintainability or DRY (Don’t Repeat Yourself), just to name a few (and Separation of Concerns, and Single Responsibility Principle, and …)

Besides this, you perceive that these reqs put you in a contradiction between “Working Software” and “Customer Collaboration“.

So, the Agile Manifesto, instead of helping you on how to find a solution to a problem, seems to be part of the problem. So, what should you do?

As I have already stated in (another) previous post, Agile is all about “giving value to the customer”, so, we should not find any contradiction at all, since “value to the customer” means that “Customer Collaboration“, first and foremost, will be your beacon that will lead you out of the woods.

If, after you explain to your customer all the pros and cons of each proposal, including the ones that do not seem OK but are more pleasing to them, the customer still insists on their idea, well, you should be flexible enough to accept their proposal for the time being, implement, and let them use this (not so perfect) implementation, so that they may eventually realize what you were talking about.

THE concept here is that any agile project has to evolve as an ongoing conversation with the customer: to be able to give value to your customer, you must understand your customer, and to be able to do so, you must keep that conversation open and flowing.

Kind regards, GEN

(**): An existing digital dashboard web app, with a set of charts that allowed drill down into tables with detailed info. The original dashboard had monetary figures in just one currency, and the customer wanted to include support for multiple currencies.

When in doubt, think of The Agile Manifesto as your inspiration

Image

You are the leader of an agile team, in the middle of a sprint, facing a problem with the process. You need to figure out a fix to the problem, but can’t find a clear solution. You reviewed many books and web pages on agile, but still can’t find a clear path to solve this problem.

It may sound like a deja vu situation to many readers simply because is a very frequent situation.

When we find ourselves in such a predicament, where do we turn to for council?

Well, when in doubt, look for inspiration in The Agile Manifesto, but focus your attention on the concepts on the left, that is:

Individuals and interactions  as it is people and their interactions that may be able to detect and solve the problems.

Working software“, as it is the main deliverable that represents real value to the customer.

Customer collaboration“, as the true approach to fix things up is “all together against the problem”.

Responding to change“, as change is the name of the game nowadays.

Kind regards, GEN

Video

Django Unchained: if you are a Tarantino fan, you gotta watch this movie; if you love movies, you gotta watch this movie

Video

Lincoln: a “must see” movie, by a long shot