tag:blogger.com,1999:blog-33567248936636181122024-03-20T04:44:13.727-07:00Agile BooknoteNotes from someone that loved Agile at first sight and now is trying to understand whyFederico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.comBlogger82125tag:blogger.com,1999:blog-3356724893663618112.post-33930707494837635382013-04-02T05:13:00.001-07:002013-04-02T05:13:27.143-07:00Son las estimaciones tan malas?<br />
Una de las charlas que mas me gusto del Bolivian Scrum Day 2013 es la de Thomas Wallet "No estimarás" - Mensaje fuerte, no? Y creo que esta bueno para mover el bote (como dicen en 10 Pines), pero, como siempre, tenemos que tomar el mensaje con cuidado y no echarle la culpa a la herramienta, como escuche alguna vez decir a Henrik Kniberg. Es estimar realmente malo? Existen muchas situaciones donde claramente no lo es. Si yo tengo que tomar un vuelo en Viru Viru y quiero saber cuando es que debería estar en el aeropuerto, realizo una estimación de cuanto voy a tardar y cuando tendría que levantarme. Hablando de software, muchas veces necesito o me es útil tener una 'estimación' del costo de una feature (para saber si me va a alcanzar la plata - poder planear - o para saber si las voy a construir o voy a construir otra - poder priorizar -). Entonces cuando la estimación es mala o se convierte en un problema?<br />
<br />
- Si lo voy a hacer si o si: tiene sentido estimar algo que si o si tengo que completar? Piensen en sus tareas personales? Se ponen a pensar cuanto van a tardar en hacer algo si lo tienen q hacer si o si? Perder tiempo en estimar en estos casos es realmente eso, perderlo.<br />
<br />
- El otro gran problema con las estimaciones es cuando se toman como un contrato y no se tiene en cuenta que son estimaciones!! Y que es díficil estimar. Y que mientras menos se entienda el problema, peor se va a estimar!!<br />
<br />
Entonces, yo que soy un poco más moderado propongo que entendamos porque estamos estimando y que tengamos en cuenta el retorno de inversión de esta estimación. Que quiero decir con esto? Si de esta estimación no depende absolutamente nada importante de la empresa, no perdamos mucho tiempo!! (y tampoco perdamos el tiempo haciendo tests). Si por el contrario, para la empresa es muy importante, entonces 'invirtamos' más tiempo en la estimación. Preocupemosnos un poco más!!<br />
<br />
Otro de los puntos que me llamó la atención de la charla es que el modo talibán de dejar las estimaciones es básicamente intentar tener items de mas o menos el mismo tamaño y abandonar las iteraciones, midiendo el throughput y el ciclo... Esto también me hace ruido. Yo no creo que este cambio en el ciclo de vida del proceso este relacionado con las estimaciones y si con la no utilidad de las iteraciones. Este punto me va a ser mucho más díficil de fundamentar (será porq no lo tengo tan claro), pero voy a intentarlo. Tener items del mismo tamaño siempre es bueno, en Scrum, Kanban, XP o donde quieras. Permita calcular cualquier métrica mas facilmente, permite encajar los items dentro del sprint backlog, etc. Otro punto (no relacionado, pero bueh.. lo tiro!): Samuel Crescencio dijo que en su opinion, las retrospectivas son el componente mas importante de Scrum (quizás lo dijo para exagerar la importancia de las retrospectivas..). Bueno, pues para mi el componente más importante de Scrum son las iteraciones (timeboxedas). Por que? Porque las iteraciones son las q mantienen el foco, crean el pulso del proyecto, permiten calcular la velocidad y son el enabler de la inspeccion y adaptación. Adonde voy con todo eso? (ni yo se). A q si queres dejar de estimar usando Scrum podes hacerlo. Simplemente pone un numero (aleatorio) de ítems en una iteración y dps. ajustalo en las iteraciones subsiguientes (si tenes ítems del mismo tamaño, esto debería ser muy fácil). Pero debe haber otras razones mas importantes para eliminar la iteración (o para no hacer iteraciones o Scrum si nunca hiciste). Mucha variabilidad en la capacidad del equipo.. Un equipo de desarrollo que comparte responsabilidades de producción.. hasta podría enumerar una diferencia grande en el tamaño de los ítems (haciendo q algunos no entren en la iteración), pero partimos de la base q el tamaño de los ítems es similar..Entonces quizás es a mi q se me mezcló un poco la ultima opción o no se que, pero me cuesta ver la opción de ítems del mismo tamaño + Kanban como una opción para dejar de estimar. Para mi, dejar las iteraciones tiene que tener que ver con otra cosa.<br />
<br />
<br />
En conclusión creo que las estimaciones sigue siendo buenas, cuando se las usan para lo que son y cuando existe confianza entre las gente que realiza las estimaciones y la gente que las va a usar. Desde que leí a Alistair Cockburn, siempre dije que creo q tenemos que ser críticos y entender el porque de cada uno de los componentes/tecnicas que usamos en nuestra metodología para tener la metodología más liviana que resuelva nuestros problemas (componentes que no aportan valor o son mal usados son desperdicio). Las estimaciones pueden ser un componente que agrega valor o no. Evaluemosló.<br />
<br />
<br />
<br />Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-62274043493471243702013-03-08T06:53:00.002-08:002013-03-08T06:53:56.900-08:00Daré una charla en el Scrum Bolivia Day 2013!!Si, estoy muy contento porque a fin de mes tendré la oportunidad de asistir al <a href="http://scrumbolivia.com/">Scrum Bolivia Day</a> en Santa Cruz de la Sierra, un lugar que hacer mucho tiempo quería ir! Gracias Juan por la invitación y nos vemos pronto!!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOfgSpCwS1AyEEJ2axT97SgcL_3nRaHRaozCDTYV0WuuMFpYd4B7Igpx4Znh5XQ1GyQrvwaAoby1Qiyv1_0CMiHajT4tu-BbG2ee5zqaDDc_LHEVIH6jrV49PMqmR2IDYWlpSh2VxLQDMG/s1600/Insignia+SBD+2013+I'm+speaking+@.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOfgSpCwS1AyEEJ2axT97SgcL_3nRaHRaozCDTYV0WuuMFpYd4B7Igpx4Znh5XQ1GyQrvwaAoby1Qiyv1_0CMiHajT4tu-BbG2ee5zqaDDc_LHEVIH6jrV49PMqmR2IDYWlpSh2VxLQDMG/s320/Insignia+SBD+2013+I'm+speaking+@.png" width="320" /></a></div>
<br />
<br />
<div style="background-color: white; border: 0px; color: #606060; font-family: Arial, Helvetica, sans-serif; font-size: 12px; line-height: 1.8em; margin-left: auto; margin-right: auto; outline: none; padding: 0px 0px 1.3em;">
<strong style="border: 0px; margin: 0px auto; outline: none; padding: 0px;">Descripción</strong></div>
<div style="background-color: white; border: 0px; color: #606060; font-family: Arial, Helvetica, sans-serif; font-size: 12px; line-height: 1.8em; margin-left: auto; margin-right: auto; outline: none; padding: 0px 0px 1.3em;">
La revolución ágil introdujo grandes cambios en todas las áreas del desarrollo de software y el area de management no fue una excepcion. Pero cuales fueron estos cambios? Cuales son los desafíos del manager en la era ágil? En esta charla abordaremos estos tópicos con el objetivo de entender mejor las responsabilidades de un manager ágil y brindaremos herramientas que los ayudaran en sus desafíos diarios. Entre los puntos incluidos están: teoría de sistemas adaptativos complejos, como crear equipos motivados y como delegar responsabilidades.</div>
Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-41357603172042483182012-12-10T05:13:00.000-08:002012-12-10T05:13:44.221-08:00Agile Knowledge Repository<h3>
Summary
</h3>
This area deals with knowledge acquisition and knowledge management in an organization. One of the main points of CMMI is to maintain a process repository (as expressed in the <a href="http://agilebooknote.blogspot.com.ar/2011/01/is-organizational-process-definition.html">Organization Process Definition Area</a>) that enables the organization to acquire and maintain its knowledge. Agile Organizations should maintain this repository, by creating an Agile Culture (I expressed my doubts about being able to create a documented knowledge repository in an agile software organization, as I think software development is a craft). Therefore, processes and techniques live inside the people's brains of the organization and is acquired and maintained by practicing and teaching those process and techniques. Knowledge is maintained using the model used in the past by guilds.<br />
<br />
<h3>
Goals</h3>
- There is a knowledge path that people follow inside the organization, starting from apprentice (someone that is learning, does exercises, pair programs with someone and has a lot of time to educate himself) to Journeyman (which is someone that knows the craft and is able to teach it).<br />
- Knowledge is shared openly and collaboratively inside the organization. Culture is strong. More senior software craftsmen lead and teach the rest of the group on "how we do things inside here". Values float in the air.<br />
<br />
<h3>
Standard Practices</h3>
I have taken these practices from <a href="http://www.8thlight.com/">8thlight</a>, a company I visited a few months ago. In 8thlight:<br />
<br />
- Employees start as apprentices. Their job at that moment is to learn how to develop software and how the company manages their projects. They do exercises and pair programming with more senior craftsmen.<br />
- Software craftsmen have one or more apprentices in charge. So their responsibility is to teach apprentices the processes and techniques used inside the organization.<br />
- Knowledge is shared and maintained by practicing together. Employees do code retreats or katas together. The philosophy is programmers need to practice their craft and this practice is performed on code that is not business oriented.<br />
<br />
<br />
<br />
<br />
<br />
<br />Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-57799520414646563872012-10-29T06:46:00.001-07:002012-12-10T04:12:18.173-08:00Presentation in Agiles 2012<div class="prezi-player"><style type="text/css" media="screen">.prezi-player { width: 550px; } .prezi-player-links { text-align: center; }</style><object id="prezi_wam-t-cack4j" name="prezi_wam-t-cack4j" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="550" height="400"><param name="movie" value="http://prezi.com/bin/preziloader.swf"/><param name="allowfullscreen" value="true"/><param name="allowFullScreenInteractive" value="true"/><param name="allowscriptaccess" value="always"/><param name="wmode" value="direct"/><param name="bgcolor" value="#ffffff"/><param name="flashvars" value="prezi_id=wam-t-cack4j&lock_to_path=0&color=ffffff&autoplay=no&autohide_ctrls=0"/><embed id="preziEmbed_wam-t-cack4j" name="preziEmbed_wam-t-cack4j" src="http://prezi.com/bin/preziloader.swf" type="application/x-shockwave-flash" allowfullscreen="true" allowFullScreenInteractive="true" allowscriptaccess="always" width="550" height="400" bgcolor="#ffffff" flashvars="prezi_id=wam-t-cack4j&lock_to_path=0&color=ffffff&autoplay=no&autohide_ctrls=0"></embed></object><div class="prezi-player-links"><p><a title="Transforming Cultures" href="http://prezi.com/wam-t-cack4j/transforming-cultures/">Transforming Cultures</a> on <a href="http://prezi.com">Prezi</a></p></div></div>Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-29759730452272682502012-10-11T05:19:00.001-07:002012-10-11T05:19:54.112-07:00Agile Collaboration Area<h3>
Summary</h3>
<br />
<span style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;">The Agile Manifesto says "Business people and developers must work together daily through the project". Everyone, within the organization and beyond it (i.e. clients) must </span><span style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;">work jointly towards a shared objective, help each other, have good intentions, share all the information and ultimately to do what's best for the everyone involved.</span><br />
<span style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;"><br /></span>
<br />
<h3>
<span style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;">Goals</span></h3>
<span style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;">- Collaboration between the organization and its clients is enabled financially. Contracts should enforce collaboration.</span><br />
<span style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;">- Collaboration among team members in a project and among different departments of the organization should be enforced. </span><br />
<span style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;">- All stakeholders should be involved throughout the duration of a project.</span><br />
<span style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;"><br /></span>
<br />
<h3>
<span style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;">Standard Practices</span></h3>
<span style="color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif;"><span style="font-size: 15px; line-height: 20px;">Clients work with team members to specify the requirements and prioritize them in a backlog that will be used continually during the project. Features are presented to these clients early in the life of the project to be able to receive feedback and change according to it. This change should be enabled in the contract (if the contract penalizes delays, the team won't be willing to accept any changes during the life of the project). Everyone in the team should share the same objectives. Therefore, policies and rewards should be devised with this in mind.</span></span><br />
<span style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;"><br /></span>
<span style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;"><br /></span>
<span style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;"><br /></span>
<span style="background-color: white; color: #333333; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 15px; line-height: 20px;"><br /></span>
Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-17458016386207571902012-09-26T06:01:00.003-07:002012-09-26T06:13:30.671-07:00Agile Communication Area<h3>
Summary</h3>
Communication is key in an Agile organization. Developing software is a communication problem. Communication needs to flow as fast and clear as possible among all members of the organization. An environment that enables and enforces communication should be built.<br />
<br />
<h3>
Goals</h3>
- There is an environment that allows interactions among all members in the organization freely.<br />
- All members of the organization can easily communicate with each other.<br />
- There is complete transparency to everyone about the goals, status, direction of the project/organization.<br />
<br />
<h3>
Standard Practices</h3>
- The office is an open space, where all members share the same information. There are visual radiators in many places of the office that allow members of a project and all members in the organization to understand the status and direction of the different projects.<br />
- Team members in a project interact as much as possible to synchronize and make sure there is a shared understanding of what needs to be built. In Scrum, there are different meetings that enable and enforce this communication: 1) Planning meeting at the beginning of each iteration 2) Daily Standup every day 3) Demo and Retrospection at the end of the iteration. Besides this, practices like pair program or code review sessions push the members to interact even more. Understanding the effectiveness of the different types of communication types helps devise a communication strategy. When is possible, face to face communication is the most effective type of communication but there are situations when the team is distributed geographically and therefore other communication methods should be used. Increasing the communication to its highest level should be the direction in these cases.<br />
<br />
<br />
<br />
<br />Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-12611975680955454852012-09-25T15:17:00.004-07:002012-09-26T06:13:23.507-07:00Self Organization Area<h3>
Summary</h3>
<div>
This area's goal is to create an environment where all members feel empowered to contribute all their knowledge and energy for the organization's benefit. Leaders and more experienced individuals should guide less experienced ones and set constraints and directions.</div>
<h3>
Goals</h3>
- Team members are empowered<br />
- The team self organizes to create the best solution to the specified problems.<br />
- Leaders create and maintain an environment where self-organization can thrive<br />
<h3>
Standard Practices</h3>
- Within a project, a cross functional team self organizes to develop the best solution to the problem.<br />
- Managers are servant leader that teach through example and help other members to grow within the organization and to give the best of them.<br />
<br />
<br />
<br />
<br />Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-15766384263342085472012-09-23T15:41:00.003-07:002012-09-26T06:13:16.699-07:00Agile Process Development Lifecycle Area<h3>
Summary</h3>
<div>
The process should be an enabler of the objectives the organization needs to fulfill. It should allow the organization to deliver value fast and sustainably. It should be revised and improved continually (Kaizen).</div>
<h3>
Goals</h3>
<br />
- The process enables incremental delivery of features. In other words, the process should allow to slice the functionality to be delivered in multiple chunks, that when delivered allow the business to receive the most valuable/important functionality sooner.<br />
- Process should be light and empiric. All artifacts in the process should give value to the product creation process.<br />
- Process should be empiric. The team should continually introspect on the process and change it to function better within the specific context.<br />
<br />
<h3>
Standard Practices</h3>
- Common methodologies/frameworks like Scrum and Extreme Programming use iterations to deliver features incrementally and iteratively. Features should be potentially shippable at the end of each iteration. This doesn't mean that they could be shipped, as a feature could be part of a larget minimum viable feature.<br />
- At the end of each iteration, the team can show to all business stakeholders the business functionality that was completed. If requirements are sliced vertically and provide business value, they can be shown. Stakeholders can provide their feedback, which could be incorporated in the product backlog through the product owner.<br />
- The team should inspect the process (among other things) at the end of each iteration. Usually, the team tries to find what is working with the current process and isn't, devising action items that can improve its performance.<br />
<br />Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-60661518786321984432012-09-21T07:57:00.000-07:002012-09-26T06:13:09.307-07:00Agile Project Monitoring Area<h3>
Summary</h3>
All members of the organization are in charge of monitoring the progress of the project, suggesting corrective actions and making sure they are completed. There is complete transparency and a lot of communication among everyone, thus ensuring that everyone understand the current status of the project.<br />
<h3>
Goals</h3>
- The team monitors the actual progress of the project at timeboxed intervals. It should be measured the actual completion of requirements, risks tackled and discovered, changes in business requirements (i.e. changes in scope), etc.<br />
- The team monitors the progress daily, trying to discover blockers (things that prevent the team from doing progress) and synchronization points (e.g. among dependent requirements)<br />
- The team and business stakeholders agree on corrective actions or adaptions to the plan and execute them.<br />
<br />
<h3>
Standard Practices</h3>
- After each iteration, there is a demo that allows the team to show the business side the actual progress made on requirements. There is a great deal of knowledge won in this meeting as the business people get a feeling of the actual product being constructed. This knowledge gained should be reflected in the plan, as the horizon should be clearer after each iteration. The team should have also gained a clearer understanding of what it takes to develop the requirements and the amount of work remaining.<br />
- Daily, the team introspects on the progress (compared to the expect one) and blockers trying to complete all work they have committed to and remove all impediments as fast as possible. In Scrum, this meeting is called "daily scrum" and it is usually the ScrumMaster who is in charge of removing any impediment that might prevent the team from doing progress.<br />
- Each action item detected during either the daily scrum or the review should be completed to end. It is a good practice for one of the team members to be hold accountable.<br />
- Visual Radiators should be hanged in various places of the open space the team works on. One of the tenets of Agile is transparency, and therefore everyone should be as aware as possible of the actual progress.Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-55300674954810155032012-09-18T12:13:00.000-07:002012-09-26T06:13:02.519-07:00Agile Project Planning Area<h3>
Summary</h3>
<div>
Initial planning sets up the initial direction, which is continually updated based on new discoveries (business and technical). Therefore, planning is a continuous work that endures the whole project.</div>
<h3>
Goals</h3>
- A plan is built when the project starts and updated it continually throughout the project.<br />
- Estimations are performed for all requirements. The time invested in estimation should be directly proportional to the level of approval and understanding of the requirement (A greater lever of understanding and approval enables a greater level of detail on the estimation)<br />
- All involved members should be involved in estimations, aware of the plan and committed to the success of the project.<br />
<br />
<h3>
Standard Practices</h3>
- In the 'Release Planning' meeting, a backlog that contains all stories known so far is constructed. As there is a great deal of uncertainty and unknowns, stories are estimated roughly, to have a first approximation to the dimension of the project.<br />
- If the project is too big, it is a common practice to slice the project in releases. First release should contain the most important business functionality, what is needed more urgently or what lets the company enter a field.<br />
- During the execution of the project and as more is learned about the project, estimations and forecasts are updated to reflect the gained knowledge in the plan.<br />
- A common technique for doing the estimation is the Poker Planning, where all members of the project contribute their wisdom (this technique relies on the <a href="http://en.wikipedia.org/wiki/The_Wisdom_of_Crowds">Wisdom of Crowds</a>)<br />
- Involvement and transparency enable full commitment of the team.<br />
<br />Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com3tag:blogger.com,1999:blog-3356724893663618112.post-18468619679795533992012-09-17T06:28:00.003-07:002012-09-26T06:12:54.348-07:00Agile Requirements Management Area<h3>
Summary</h3>
<div>
Requirements are built by business owners and technical members and refined through all the duration of the project.They should be prioritized based on their value and technical risk to maximize the probabilities of success of the project.</div>
<h3>
Goals</h3>
- At all times, a project backlog is maintained with all requirements prioritized by their business values and technical risk. This backlog might have different levels of understanding and approval. The highest priority requirements should have a greater level of detail, understanding and approval.<br />
- The backlog should be easy to maintain and light. The product owner should be able to modify and re-prioritize it at all times.<br />
- All requirements should have a set of acceptance automated tests up to date at all times. If there are changes to the already implemented requirements, the acceptance tests need to be modified to reflect that.<br />
<br />
<h3>
Standard Practices</h3>
- A product backlog is created at the beginning of the project and maintained through out it. The main input should come from the product owners, who understand the business needs and the value of the requirements and from the development team, who should advise about the technical risks.<br />
- A common practice is to write the requirements as user stories. A user story is written using the business lingo, it has an actor (someone that will use the system) and it provides some (ideally measurable) business value.<br />
- Acceptance tests should be defined and validated with the product owner and implemented for all stories. These acceptance tests act as an scaffold that assures all requirements are being met at all times and also as a traceability tool.<br />
- An Agile Management Tool is needed in case the project is considerably big and/or geographically distributed. This tool should allow anyone to make modifications on the stories and to reprioritize them.Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-92024812553241645932012-09-16T07:23:00.000-07:002012-09-26T06:12:47.823-07:00Agile Maturity Model Categories & AreasA time ago I did a post about the <a href="http://agilebooknote.blogspot.com.ar/2010/02/agile-architecture.html">Agile Architecture</a> which contains what I think are the most important 'components' (architecturally speaking) of Agile:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3SEfzjKo8yhhhxFNmn5cIiwTWD4CoyaQxGv7F4KRa76oWNL3xabzQAmeuDn8WdDv8vOQFNfkQMEY22RAVTlW8ODuxm3ISzcnt4A2YtSqiD__SO5DoE5GlFv-pWHvBNJH3iLUmEkkNWru2/s400/sGh0-LvLuqN8ljIIwCKT0Vg.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="434" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg3SEfzjKo8yhhhxFNmn5cIiwTWD4CoyaQxGv7F4KRa76oWNL3xabzQAmeuDn8WdDv8vOQFNfkQMEY22RAVTlW8ODuxm3ISzcnt4A2YtSqiD__SO5DoE5GlFv-pWHvBNJH3iLUmEkkNWru2/s640/sGh0-LvLuqN8ljIIwCKT0Vg.png" width="640" /></a></div>
<div style="text-align: center;">
<br /></div>
<br />
I believe this is a good start to define the areas that will make up this maturity model.<br />
<br />
Process<br />
<br />
In the process category, I will group all areas related to the process development lifecycle. I am tempted to call this category the methodology one, but the methodology encompasses much more elements than just the process ones. The methodology is everything you do in your organization to develop software (with this definition, methodology and culture are almost the same thing?). Some of the areas in this category include<br />
<br />
- Requirements Management<br />
- Process Development Lifecycle Management<br />
- Project Planning<br />
- Project Monitoring (or execution)<br />
<br />
Human<br />
<br />
- Self-Organization and Self-Discipline (I moved this to the human category in the original diagram)<br />
- Communication<br />
- Colllaboration<br />
- Develop Competence<br />
- Creating an Agile Culture?<br />
<br />
Technical<br />
<br />
- Technical Excellence<br />
- Iterative Architecture and Emergent Design<br />
- Verification & Validation<br />
- SCM<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-1955226928203543982012-09-12T06:41:00.000-07:002012-09-26T06:12:40.321-07:00First steps towards an Agile Maturity Model<span style="font-family: Arial, Helvetica, sans-serif;">I wonder how a model for maturing in an Agile context should be thought. Let's see some examples of previous attempts:</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<br />
<h3>
<a href="http://www.pmtoolbox.com/project-management-news/the-agile-process-maturity-model-apmm.html"><span style="font-family: Arial, Helvetica, sans-serif;">Agile Process Maturity Model</span></a></h3>
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">"<span style="background-color: white; line-height: 17px;">The goal of the Agile Process Maturity Model (APMM) is to provide a framework which provides context for the plethora of agile methodologies and practices out there today. The APMM defines three levels, each of which build upon each other, for agile processes and practices."</span></span><br />
<span style="background-color: white; line-height: 17px;"><span style="font-family: Arial, Helvetica, sans-serif;"><br /></span></span>
<br />
<div style="background-color: white; line-height: 17px; padding: 0px 0px 15px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><b>APMM Level 1: Core Agile Development</b><br /><br />Level 1 agile processes address a portion of the <a br="" href="http://www.ambysoft.com/essays/agileLifecycle.html" style="color: #2255aa; text-decoration: none;">system life cycle (SDLC)</a>. Examples of Level 1 agile processes include Scrum, Extreme Programming, Agile Modeling and Agile Data.</span></div>
<div style="background-color: white; padding: 0px 0px 15px;">
</div>
<div style="line-height: 17px; padding: 0px 0px 15px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><b>APMM Level 2: Disciplined Agile Delivery</b><br /><br />Level 2 agile processes extend Level 1 to address the full system delivery life cycle (SDLC). As the <a br="" href="http://www.ibm.com/developerworks/blogs/page/ambler?entry=agile_criteria" style="color: #2255aa; text-decoration: none;"><br />criteria for disciplined agile development </a>suggests they also tend to dial up certain aspects of agile development, such as testing, measurement, and process improvement. Furthermore, they include explicit mechanisms to support effective (ideally lean) governance. Examples of Level 2 agile processes include Hybrid Processes (Scrum@XP), Rational Unified Process, Open Unified Process, Harmony ESW and Dynamic System Development Method.</span></div>
<div style="line-height: 17px; padding: 0px 0px 15px;">
</div>
<div style="padding: 0px 0px 15px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><b>APMM Level 3: Agility at Scale</b><br /><br />In the early days of agile, the applications where agile development was applied were smaller in scope and relatively straightforward. Today, the picture has changed significantly and organizations want to apply agile development to a broader set of projects. Agile hence needs to adapt to deal with the many business, organization, and technical complexities todays software development organizations are facing. This is what Level 3 of the APMM is all about explicitly addressing the complexities which disciplined agile delivery teams face in the real world.</span></div>
<div style="padding: 0px 0px 15px;">
<span style="font-family: Arial, Helvetica, sans-serif;">The goal of the APMM is "to define a framework which can be used to put the myriad agile processes into context. </span></div>
<br />
<h3>
<a href="http://whattodowearelikethatonly.blogspot.com.ar/2008/08/agile-maturity-model.html"><span style="font-family: Arial, Helvetica, sans-serif;">Agile Maturity Model</span></a></h3>
<div style="line-height: 17px; padding: 0px 0px 15px;">
<span style="color: #333333; line-height: 19px; text-align: justify;"><span style="font-family: Arial, Helvetica, sans-serif;">The AMM, "tries to quantify degree of responsiveness of a team to an organization's business needs. The philosophy being that i<b>ncreasing the discipline and proficiency of executing some best practices will increase the degree of responsiveness</b>."</span></span></div>
<div style="line-height: 17px; padding: 0px 0px 15px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><span style="color: #333333; line-height: 19px; text-align: justify;">The AMM primarily focuses on application development activities; the dimensions of the AMM are</span></span></div>
<ul style="color: #333333; line-height: 19px; list-style-image: initial; list-style-position: initial; margin: 0.5em 0px; outline: none; padding: 0px 0px 0px 2em; text-align: justify;">
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Testing</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Source code management</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Collective code ownership</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Collaboration</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Responsiveness to business</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Assurance and governance</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Story formation</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Design simplicity</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Build process</span></li>
</ul>
<span style="font-family: Arial, Helvetica, sans-serif;"><br style="color: #333333; line-height: 19px; text-align: justify;" /><span style="color: #333333; line-height: 19px; text-align: justify;">For each of the above dimensions, the AMM lists <b>behavioral patterns exhibited by teams</b>. Teams can use the AMM as a reference to identify and compare the behavior that they currently exhibit and plan to alter and tailor them.</span></span><br />
<div style="padding: 0px 0px 15px;">
<span style="font-family: Arial, Helvetica, sans-serif;"><span style="color: #333333; font-weight: bold; line-height: 19px; text-align: justify;">Testing</span></span></div>
<ol style="color: #333333; line-height: 19px; list-style-image: initial; list-style-position: initial; margin: 0.5em 0px; outline: none; padding: 0px 0px 0px 2em; text-align: justify;">
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Acceptance testing in lieu of all other tests</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">No unit testing framework, ad hoc testing (Manual testing of individual components/ controls)</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Unit testing, manual functional testing; application has a testable architecture</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Unit testing integrated into build process, testing automated as much as reasonable given application</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Developers write unit tests before writing functional code</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Test are identified and produced as part of a story creation</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Automated functional testing (e.g.. GUI testing); stories remain in development until all bugs are fixed or deferred</span></li>
</ol>
<span style="font-family: Arial, Helvetica, sans-serif;"><span style="color: #333333; font-weight: bold; line-height: 19px; text-align: justify;">Source Code Management</span></span><br />
<ol style="color: #333333; line-height: 19px; list-style-image: initial; list-style-position: initial; margin: 0.5em 0px; outline: none; padding: 0px 0px 0px 2em; text-align: justify;">
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Traditional schemes based on fire-locking and time-sharing</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">SCM supports version of code</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">IDE(s) integrate with SCM; developers include meaningful comments in commits</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">SCM support merging; optimistic check-ins</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">SCM support atomic commits</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">All development collateral is in SCM</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">SCM is transparent to delivery team, behind build process</span></li>
</ol>
<span style="font-family: Arial, Helvetica, sans-serif;"><span style="color: #333333; font-weight: bold; line-height: 19px; text-align: justify;">Collective code ownership</span></span><br />
<ol style="color: #333333; line-height: 19px; list-style-image: initial; list-style-position: initial; margin: 0.5em 0px; outline: none; padding: 0px 0px 0px 2em; text-align: justify;">
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Knowledge held by specific team members; people work in isolation</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">No pairing, people work alone, some informal process for keeping people informed</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Pairing; no code locking</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Pairing scheme ensures rotation</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Team signs up for functionality rather than assignment to individuals</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Within an sprint, functionality delivery is signed up for just in time</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Old (bugs) and new functionality is queued, development team pops the stack in real time</span></li>
</ol>
<span style="font-family: Arial, Helvetica, sans-serif;"><span style="color: #333333; font-weight: bold; line-height: 19px; text-align: justify;">Collaboration</span></span><br />
<ol style="color: #333333; line-height: 19px; list-style-image: initial; list-style-position: initial; margin: 0.5em 0px; outline: none; padding: 0px 0px 0px 2em; text-align: justify;">
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Regular progress updates from management to the delivery team (as opposed to the other way around); irregular team meetings</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Project collaboration tools (wiki, mailing list, IM) in place and used throughout project team; project status published and visible to all</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Daily stand-ups and sprint meetings; problem solving is bottom-up as opposed to top-down; team sets sprint objectives and agrees on estimates.</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Integrated, continuous build process, with build status notification to the team and collective responsibility for state of the build</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Business is part of the team, stakeholders accept working software at reviews in lieu of other tracking or progress metrics</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Frequent (near-real time) prioritization of old and new functionality</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Build automatically deploys to QA environment available to any interested party</span></li>
</ol>
<span style="font-family: Arial, Helvetica, sans-serif;"><span style="color: #333333; font-weight: bold; line-height: 19px; text-align: justify;">Responsiveness to business</span></span><br />
<ol style="color: #333333; line-height: 19px; list-style-image: initial; list-style-position: initial; margin: 0.5em 0px; outline: none; padding: 0px 0px 0px 2em; text-align: justify;">
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Frozen specification, unresponsive to business value</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Team tries to accommodate new requirements by ad hoc change requests ("pile it on")</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Iterative process with sprints of length short enough to respond to business change</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Showcases per sprint; business prioritizes functionality per sprint</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Continuous involvement of the business on the team: business certifies story complete out of dev; involved in (rather than approval of) story definition and acceptance tests</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Business writes high-level stories for all requests; organizational story queue exists; prioritization decisions made from full story backlog</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Development process is integral to business initiatives; development teams work as a part of the business unit rather than as a service to the business unit</span></li>
</ol>
<span style="font-family: Arial, Helvetica, sans-serif;"><span style="color: #333333; font-weight: bold; line-height: 19px; text-align: justify;">Assurance and Governance </span></span><br />
<ol style="color: #333333; line-height: 19px; list-style-image: initial; list-style-position: initial; margin: 0.5em 0px; outline: none; padding: 0px 0px 0px 2em; text-align: justify;">
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Status reports document progress; schedule acts as plan</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Concept of release planning is introduced</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Sprint planning is introduced</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Plan becomes communication and tracking tool rather than an exception report</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Every sprint review examines value delivered and assesses next sprint by need, priorities (and delivery)</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Organizational adoption: Introduction of Portfolio Planning and global optimization of resources (use of metric and standard measures)</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Business review of value and return helps teams on regular basis based upon status</span></li>
</ol>
<span style="font-family: Arial, Helvetica, sans-serif;"><span style="color: #333333; font-weight: bold; line-height: 19px; text-align: justify;">Story Formation (Requirements)</span></span><br />
<ol style="color: #333333; line-height: 19px; list-style-image: initial; list-style-position: initial; margin: 0.5em 0px; outline: none; padding: 0px 0px 0px 2em; text-align: justify;">
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Development tasks extracted from voluminous, frozen requirements artifacts</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Production of lightweight artifacts (e.g. panel flows) to drive high-level requirements development</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Mapping granular requirements (e.g., use cases) in high level user requirements</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Marshaling use cases into discreet statements of functionality that can be delivered in time boxed development sprints</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Stories are an expression of end-to-end functionality to be developed, including testable acceptance criteria and a statements of value</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Spontaneous story development provided by business for in-flight projects; stories not derived from extant sources but are immediate expressions of customer demand/need</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Global repository of functional requirements for stories developed by business for any business requirements, including a formal measure of business value delivered</span></li>
</ol>
<span style="font-family: Arial, Helvetica, sans-serif;"><span style="color: #333333; font-weight: bold; line-height: 19px; text-align: justify;">Simplicity</span></span><br />
<ol style="color: #333333; line-height: 19px; list-style-image: initial; list-style-position: initial; margin: 0.5em 0px; outline: none; padding: 0px 0px 0px 2em; text-align: justify;">
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Big up-front design that attempts to accommodate all potential future needs</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Application of fundamental design patterns</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Structural refactoring to decouple application architecture</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Doing only what needs to be done</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Aggressive and constant refactoring to improve code quality/simplicity extant code</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Spiking solution with each release to introduce new ideas and challenge architectural decision</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Technical design decisions taken with each story</span></li>
</ol>
<span style="font-family: Arial, Helvetica, sans-serif;"><span style="color: #333333; font-weight: bold; line-height: 19px; text-align: justify;">Build</span></span><br />
<ol style="color: #333333; line-height: 19px; list-style-image: initial; list-style-position: initial; margin: 0.5em 0px; outline: none; padding: 0px 0px 0px 2em; text-align: justify;">
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Ad-hoc build requests; scripting and component marshalling performed manually</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Consistent, repeatable build process with durable artifacts executed manually with each release</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Build is automated, executed on a timed basis</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Unit tests are integrated with the automated build; team is constantly notified of the status of the build; build triggered by SCM updates</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Test and metrics (e.g., code quality, complexity, check style, etc.) are integrated as gatekeeper events; build data archived and reported in build portal/dashboard</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">All product components advertise dependencies; master repository established</span></li>
<li style="margin: 0px; outline: none; padding: 0px;"><span style="font-family: Arial, Helvetica, sans-serif;">Product integration tests included; build process executes automatic deployment to QA testing environment</span></li>
</ol>
<div style="text-align: justify;">
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 19px;"><br /></span></span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 19px;">This approach ressembles in a way to how CMMI is expressed as a model. It lists dimensions (key process areas) and then different maturity levels for each one. The model's scope is very narrow and well expressed (IMO) and it could be useful for an organization to define how responsive in agile terms is the development department to the business.</span></span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 19px;"><br /></span></span></div>
<h3>
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 19px;"><a href="http://analytical-mind.com/2010/07/12/yet-another-agile-maturity-model-the-5-levels-of-maturity/">The 5 levels of Maturity</a></span></span></h3>
<div style="text-align: justify;">
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 19px;"><br /></span></span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 19px;">Martin Proulx sketch this agile maturity model:</span></span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 19px;"><br /></span></span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://danossia.files.wordpress.com/2010/07/agile-maturity-model-0011.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><span style="font-family: Arial, Helvetica, sans-serif;"><img border="0" height="478" src="http://danossia.files.wordpress.com/2010/07/agile-maturity-model-0011.png" width="640" /></span></a></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 19px;"><br /></span></span></div>
<div style="text-align: justify;">
<h2 style="border: 0px; color: #333333; font-weight: normal; margin: 0px; outline: 0px; padding: 20px 0px 10px; text-align: left; vertical-align: baseline;">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: small;">Level 1 – Team Level Maturity</span></h2>
<div style="border: 0px; color: #333333; line-height: 1.8em; margin-bottom: 15px; outline: 0px; padding: 0px; text-align: left; vertical-align: baseline;">
<span style="font-family: Arial, Helvetica, sans-serif;">At this level, team members have decided to adopt Scrum and/or software engineering practices without asking for approval from their manager. Some of the well known practices are used but without consistency.</span></div>
<h2 style="border: 0px; color: #333333; font-weight: normal; margin: 0px; outline: 0px; padding: 20px 0px 10px; text-align: left; vertical-align: baseline;">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: small;">Level 2 – Department Level Maturity</span></h2>
<div style="border: 0px; color: #333333; line-height: 1.8em; margin-bottom: 15px; outline: 0px; padding: 0px; text-align: left; vertical-align: baseline;">
<span style="font-family: Arial, Helvetica, sans-serif;">At this level, the practices adopted by the team members have started to be imitated by other teams within the software development department. Some of the managers have noticed the positive results of adopting the Agile approach and are tempted to replicate what they observed.</span></div>
<div style="border: 0px; color: #333333; line-height: 1.8em; margin-bottom: 15px; outline: 0px; padding: 0px; text-align: left; vertical-align: baseline;">
</div>
<h2 style="border: 0px; font-weight: normal; margin: 0px; outline: 0px; padding: 20px 0px 10px; vertical-align: baseline;">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: small;">Level 3 – Business Level Maturity</span></h2>
<div style="border: 0px; line-height: 1.8em; margin-bottom: 15px; outline: 0px; padding: 0px; vertical-align: baseline;">
<span style="font-family: Arial, Helvetica, sans-serif;">At this level, the solution teams have integrated the business people in the model. Collaboration (and trust) has increased and a partnership relationship is increasing.</span></div>
<br />
<div style="border: 0px; margin-bottom: 15px; outline: 0px; padding: 0px; text-align: left; vertical-align: baseline;">
</div>
<h2 style="border: 0px; color: #333333; font-weight: normal; line-height: 1.8em; margin: 0px; outline: 0px; padding: 20px 0px 10px; vertical-align: baseline;">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: small;">Level 4 – Project Management Level Maturity</span></h2>
<div style="border: 0px; color: #333333; line-height: 1.8em; margin-bottom: 15px; outline: 0px; padding: 0px; vertical-align: baseline;">
<span style="font-family: Arial, Helvetica, sans-serif;">At this level, the project management approach is modified to include some of the Scrum practices. Although the department still mostly relies on the traditional PMBOK recommendations, Scrum has been integrated in the project management approach.</span></div>
<div style="border: 0px; margin-bottom: 15px; outline: 0px; padding: 0px; vertical-align: baseline;">
</div>
<h2 style="border: 0px; color: #333333; font-weight: normal; line-height: 1.8em; margin: 0px; outline: 0px; padding: 20px 0px 10px; vertical-align: baseline;">
<span style="font-family: Arial, Helvetica, sans-serif; font-size: small;">Level 5 – Management Level Maturity</span></h2>
<div style="border: 0px; color: #333333; line-height: 1.8em; margin-bottom: 15px; outline: 0px; padding: 0px; vertical-align: baseline;">
<span style="font-family: Arial, Helvetica, sans-serif;">At this level, managers have adapted their management style to support an Agile organization. Organizational structures and reporting mechanisms are better adapted for collaboration and improved for increased performance.</span></div>
<div style="border: 0px; margin-bottom: 15px; outline: 0px; padding: 0px; vertical-align: baseline;">
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 1.8em;">This model measures basically how spread are the Agile values throughout the organization, starting from the team level with certain practices until reaching the maximun level, where the whole organization shares the same values and </span><span style="line-height: 23.399999618530273px;">behaviors</span><span style="line-height: 1.8em;">. </span></span></div>
<div style="border: 0px; margin-bottom: 15px; outline: 0px; padding: 0px; vertical-align: baseline;">
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 1.8em;"><br /></span></span></div>
<h3>
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 1.8em;">How to measure Agile maturity then?</span></span></h3>
<div style="border: 0px; margin-bottom: 15px; outline: 0px; padding: 0px; vertical-align: baseline;">
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 1.8em;">It seems there are 2 dimensions to be included when measuring the Agile maturity:</span></span></div>
<div style="border: 0px; margin-bottom: 15px; outline: 0px; padding: 0px; vertical-align: baseline;">
</div>
<ul>
<li><span style="font-family: Arial, Helvetica, sans-serif;"><b style="color: #333333; line-height: 23.399999618530273px;">How mature are the Agile practices and process</b><span style="color: #333333; line-height: 23.399999618530273px;">: this is basically the 2nd approach listed above and applies mainly at the project level (or team level using the 3rd model above). How mature are you to do testing? You do all testing manually (or not do it at all!) or you have a solid testing strategy that includes a great deal of automation. How mature are you programming? How mature are you managing your requirements? In all these dimensions, it can be defined an agile way of doing things. The 2nd approach uses behavioral patterns. Another option would be to use objectives and key practices. </span></span></li>
<li><span style="font-family: Arial, Helvetica, sans-serif;"><b style="color: #333333; line-height: 23.399999618530273px;">How spread are these Agile practices and processes throughout the organization</b><span style="color: #333333;"><span style="line-height: 23.399999618530273px;">: Basically this point says that a mature Agile organization does business in an Agile way. It is fast to deliver business value, it adapts, there is a good level of communication and collaboration throughout the company, etc. A model that encompasses this dimension is much mode ambitious. But probably it is the only way of making Agile work in an organization. The way the software is constructed needs to fit with the way the organization does business around it. The structure of the organization should enable and encourage the right connections that make communication smart and effective throughout the organization. The organization needs to have also the structure to learn and maintain this Agile culture.</span></span></span></li>
</ul>
<div>
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 23.399999618530273px;"><br /></span></span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://docs.google.com/drawings/pub?id=18XnRTq3zMDQN_syfeOdUrdYN3IgYxG_gg_GauFn8wk4&w=960&h=720" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="480" src="https://docs.google.com/drawings/pub?id=18XnRTq3zMDQN_syfeOdUrdYN3IgYxG_gg_GauFn8wk4&w=960&h=720" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
CMMI follows a similar approach as it starts with the practices dimensions (level 2) and follows towards a standarized process in the organization (level 3). This seems the natural projection to follow when seeking maturity. Starting with mastering Agility at the team level and then managing the whole organization with the same values and principles.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
For both dimensions, a means of measuring maturity is needed. A first attempt using the Shu-Ha-Ri scale will be used.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://docs.google.com/drawings/pub?id=1gxIIvJ7IpKGiIBlMdeYo27sJJ4BXeJYb2EiXM1WvbAo&w=960&h=720" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="480" src="https://docs.google.com/drawings/pub?id=1gxIIvJ7IpKGiIBlMdeYo27sJJ4BXeJYb2EiXM1WvbAo&w=960&h=720" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
A very inmature Agile organization would then be an organization where the practices are in the SHU-SHU level at the practices dimension and organization dimension. A RI-RI organization is one that has mastered the Agile practices at the team level and that manages its whole business with Agility.</div>
<div>
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 23.399999618530273px;"><br /></span></span></div>
<div>
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 23.399999618530273px;"><br /></span></span></div>
<div>
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 23.399999618530273px;"><br /></span></span></div>
<br />
<div style="border: 0px; margin-bottom: 15px; outline: 0px; padding: 0px; vertical-align: baseline;">
<span style="color: #333333; font-family: Arial, Helvetica, sans-serif;"><span style="line-height: 1.8em;"><br /></span></span></div>
<div style="border: 0px; color: #333333; font-family: 'Droid Serif', Georgia, Times, serif; font-size: 13px; line-height: 1.8em; margin-bottom: 15px; outline: 0px; padding: 0px; vertical-align: baseline;">
<br /></div>
<br /></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: Helvetica Neue Light, HelveticaNeue-Light, Helvetica Neue, Helvetica, Arial, sans-serif;"><span style="font-size: 14px; line-height: 19px;"><br /></span></span></div>
<div style="text-align: justify;">
<span style="color: #333333; font-family: Helvetica Neue Light, HelveticaNeue-Light, Helvetica Neue, Helvetica, Arial, sans-serif;"><span style="font-size: 14px; line-height: 19px;"><br /></span></span></div>
<br />
<div style="font-family: Arial, Tahoma, Verdana; font-size: 12px; line-height: 17px; padding: 0px 0px 15px;">
<span style="color: #333333; font-family: 'Helvetica Neue Light', HelveticaNeue-Light, 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px; line-height: 19px; text-align: justify;"><br /></span></div>
<div style="font-family: Arial, Tahoma, Verdana; font-size: 12px; line-height: 17px; padding: 0px 0px 15px;">
<span style="color: #333333; font-family: 'Helvetica Neue Light', HelveticaNeue-Light, 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px; line-height: 19px; text-align: justify;"><br /></span></div>
<div style="font-family: Arial, Tahoma, Verdana; font-size: 12px; line-height: 17px; padding: 0px 0px 15px;">
<span style="color: #333333; font-family: 'Helvetica Neue Light', HelveticaNeue-Light, 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 14px; line-height: 19px; text-align: justify;"><br /></span></div>
<div style="font-family: Arial, Tahoma, Verdana; font-size: 12px; line-height: 17px; padding: 0px 0px 15px;">
<br /></div>
<br />Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com1tag:blogger.com,1999:blog-3356724893663618112.post-67244153566067600612012-09-04T06:30:00.000-07:002012-09-12T04:41:38.370-07:00Agile Capability Maturity Model<br />
<h2>
<span class="s1">Agile Capability Maturity Model</span></h2>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p1">
<span class="s1">After all the differences we have talked about, the question arises. Does it make sense to have a Capability Maturity Model for Agile? How would it be? Let’s analyze the semantics of the words again, but in an Agile context.</span></div>
<div class="p2">
<span class="s1"></span><br /></div>
<h3>
<span class="s1">What does it means to be capable, in an agile context?</span></h3>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p1">
<span class="s1">In the CMMI model, Capability was defined as “the inherent ability of a process to produced the planned results. As the capability of a process improves, the process becomes predictable and measurable, the quality of the result product augments and the productivity of the teams too”. Thus, an organization gets more capable when it has defined and implemented a set of processes throughout the organization that enables it to be predictable, measurable, and continuously improving.</span></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p1">
<span class="s1">Does the word have the same meaning in an agile context? Agility is more like a mindset or culture than a set of processes. Thus, in Agile you are capable when you have the mindset and the organization is capable when it has the mindset. The semantics of the word changes considerably and worst of all, it makes it unmeasurable. How would you measure how much of the mindset the organization has? Nonetheless, and perhaps very subjectively, one can recognize a team/organization that is more Agile than another. You do it because it adheres better to the Agile values (communication, collaboration, technical excellence, etc). Using this subjectivity, perhaps we can define the meaning of capable in an Agile context. One is capable when it has grasped the Agile values, when you are at the Ri level (in the Shu-Ha-Ri scale) or, as some people say, when you ARE agile. </span></div>
<div class="p2">
<span class="s1"></span><br /></div>
<h3>
<span class="s1">How do you get more mature?</span></h3>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p1">
<span class="s1">Using CMMI, you get more mature as you implement the different processes that conform the model throughout the organization, you can measure them and draw conclusions out of the metrics that allows the organization to improve. </span></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p1">
<span class="s1">If we follow the definition of capability in an Agile context given above, the definition of maturity falls in the subjective side as well. An organization is more mature when it can communicate better, it can collaborate better, is able to produce its products with the required quality sustainably, etc. </span></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p1">
<span class="s1">Senge talks about the intelligent organization. A mature Agile organization is an intelligent organization. It’s an organization where its members are smart agents that collaborate among them to solve problems and improve continuously. Today’s knowledge organization need to mature in this direction.</span></div>
<div class="p2">
<span class="s1"></span><br /></div>
<h4>
<span class="s1">The Schneider Culture Model</span></h4>
<div class="p1">
<span class="s1">This diagram is taken from <a href="http://www.amazon.ca/Reengineering-Alternative-William-Schneider/dp/0071359818"><span class="s2">The Reengineering Alternative: A plan for making your current culture work</span></a>, the book by William Schneider. In it, there are 4 cultures. Each has its name, picture and some words that characterized the quadrant.</span></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVSZ5f7RIxxQvSG2m5slz4Tf1Q_Bngx0V6bwtrullsTeBJrs4RRuavU4PtAtkCjVSGgf0CyAjY7Nt9lv0qX0CKfcL7vDbBKUXH7Up7sG6K5s7RNzw2D3y1ZyLOk4SN2mZuCitZAL_ZWcqZ/s1600/Screen+Shot+2012-09-04+at+9.40.02+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="436" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVSZ5f7RIxxQvSG2m5slz4Tf1Q_Bngx0V6bwtrullsTeBJrs4RRuavU4PtAtkCjVSGgf0CyAjY7Nt9lv0qX0CKfcL7vDbBKUXH7Up7sG6K5s7RNzw2D3y1ZyLOk4SN2mZuCitZAL_ZWcqZ/s640/Screen+Shot+2012-09-04+at+9.40.02+AM.png" width="640" /></a></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p2">
<br /></div>
<div class="p3">
<span class="s1">There are also two axis that indicate where the focus or an organization is:</span></div>
<ol class="ol1">
<li class="li5"><span class="s1">Horizontal: People Oriented (Personal) vs. Company Oriented (Impersonal)</span></li>
<li class="li5"><span class="s1">Vertical: Reality Oriented (Actuality) vs. Possibility Oriented</span></li>
</ol>
<div class="p1">
<span class="s1">And if we map the Agile values and principles to this model...</span></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYhAYWWzbuJLxQ_S1O04qTEnk5GeM_0xKQ24vu-dlekgTEtVji-I9K6nTDYbC9vBWIPDK9Y4POuT4dW-nIv6xXEU_bncyv-4Pod1YRyDe_yD2STZj8YKFw_eIg9w_tXDu28p_rNIbV_lbL/s1600/Screen+Shot+2012-09-04+at+10.20.51+AM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="520" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYhAYWWzbuJLxQ_S1O04qTEnk5GeM_0xKQ24vu-dlekgTEtVji-I9K6nTDYbC9vBWIPDK9Y4POuT4dW-nIv6xXEU_bncyv-4Pod1YRyDe_yD2STZj8YKFw_eIg9w_tXDu28p_rNIbV_lbL/s640/Screen+Shot+2012-09-04+at+10.20.51+AM.png" width="640" /></a></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p1">
<span class="s1">We can see how Agile mainly falls into the collaboration and cultivation cultures. I believe that the introduction of CMMI in an Agile Culture moves the culture to the “Control” quadrant. Many people believe this is the way to scale agile and therefore it could be argued that CMMI could be a good way to scale Agile. I don’t feel very comfortable with this idea, as I believe that a good maturity framework should allow the organization to mature without losing its values, its heart. In other words, I believe the maturity needs to happen in the collaboration/cultivation quadrant mainly and the competence one. </span></div>
<div class="p1">
<span class="s1"><br /></span></div>
<h3>
<span class="s1">Conclusion</span></h3>
<div class="p1">
A capability maturity framework for Agile needs to redefine the meanings of capability and maturity to suit the context as being capable and mature have very different semantics in the CMMI world and the Agile one. An Agile Capability Maturity Model should make the organization mature towards a collaboration/cultivation culture. The Agile definitions of capable and mature makes introduce a lot of subjectivity. Could we still measure the results?</div>
<div class="p1">
<span class="s1"><br /></span></div>
Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-42394178700025257832011-10-11T12:47:00.000-07:002011-10-11T12:47:55.611-07:00CMMI desde una Perspectiva AgilMi presentación en #agiles2011<br />
<br />
<iframe frameborder="0" height="401" scrolling="no" src="http://app.sliderocket.com:80/app/fullplayer.aspx?id=A9A9AB55-B656-1C15-1A56-DEBA89C8BF72" width="500"></iframe>Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-47318607324103982052011-09-03T09:59:00.000-07:002011-09-03T09:59:33.817-07:00CMMI = Control & Agile = {Collaboration/Cultivation}Pete Behrens gave a talk on <a href="http://trailridgeconsulting.com/culture-of-agility.html?view=slide">The Culture of Agility</a> @Agile2011 that left me thinking on the topic of my latest posts, the relationship between CMMI and Agile.<br />
<br />
In his presentation, he shows a quadrant which contains 4 different types of cultures:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_FNaN80q-H4RsXU3Aw6CYoUS94VcAtJdv-WSv1P7a_umBnbOR4faemmwe1V8WuD_Sc83lXAnSiE4g7bQUG3FtxuSx6MJTZxYxIc0bG45QyD1qhXzl-oDcQEZ2qchyqv6_nDDQhR16UY1f/s1600/aLanguageForCulture.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="256" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_FNaN80q-H4RsXU3Aw6CYoUS94VcAtJdv-WSv1P7a_umBnbOR4faemmwe1V8WuD_Sc83lXAnSiE4g7bQUG3FtxuSx6MJTZxYxIc0bG45QyD1qhXzl-oDcQEZ2qchyqv6_nDDQhR16UY1f/s400/aLanguageForCulture.jpg" width="400" /></a></div>
<br />
And he defined certain characteristics for each culture. Look the characteristics for a control culture:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjx3yx6dwhca0Tr1qtVelgS1sPHWsYrdd1pAJfzCmGnOn0jn1MHytIHjtaj5-QkiDsrmnjVRsVzNfvoAWaywAQbNaxS2NgqaV_GPxdoGbbdRUCBPgFTRw-B7-CExNRenEARZDAH3ifW5ozv/s1600/controlculture.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="420" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjx3yx6dwhca0Tr1qtVelgS1sPHWsYrdd1pAJfzCmGnOn0jn1MHytIHjtaj5-QkiDsrmnjVRsVzNfvoAWaywAQbNaxS2NgqaV_GPxdoGbbdRUCBPgFTRw-B7-CExNRenEARZDAH3ifW5ozv/s640/controlculture.jpg" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
This really looks like CMMI, right?. "Policy and procedures are extremely important", "The system is more important than people" (these phrases really sound as the explanation that CMMI gives as to why processes are so important "What holds everything together? It is the processes used in your organization. Processes allow you to align the way you do business. They allow you to address scalability and provide a way to incorporate knowledge of how to do things better. Processes allow you to leverage your resources and to examine business trends.")<br />
<br />
Look now the characteristics of a Collaboration Culture:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCSehoOY72wDoZ-zl_m6ZikkdlrBXE7J-9_ebX9i0A4mV68tapNvI0NGLk8zcZUwA8rszJ85tK3gUJwcz95Qo06qJV66hJb6w5I39ngtpt5n0zfg8bwwpfk3tWiRIvPL_alzGGgGuhwqQf/s1600/collaboration.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="458" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCSehoOY72wDoZ-zl_m6ZikkdlrBXE7J-9_ebX9i0A4mV68tapNvI0NGLk8zcZUwA8rszJ85tK3gUJwcz95Qo06qJV66hJb6w5I39ngtpt5n0zfg8bwwpfk3tWiRIvPL_alzGGgGuhwqQf/s640/collaboration.jpg" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
And the Cultivation Culture:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEipTbH_GsRCxzn5ePRNYgYAag90K7jR71P7ipQtJoU48pY0IiPLIbebBz-5INXRUfc-MwXMH7aBa_9ldD-pUBcoj2ERaojVFpoT5ES9bSNdnJ4lWiMDsG6x3aFDoOk4_8eAEPYifKYP9iKS/s1600/cultivation.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="230" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEipTbH_GsRCxzn5ePRNYgYAag90K7jR71P7ipQtJoU48pY0IiPLIbebBz-5INXRUfc-MwXMH7aBa_9ldD-pUBcoj2ERaojVFpoT5ES9bSNdnJ4lWiMDsG6x3aFDoOk4_8eAEPYifKYP9iKS/s640/cultivation.jpg" width="640" /></a></div>
<br />
These really look like Agile, right?<br />
<br />
Look now the characteristics of personal and impersonal cultures:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgaSfmYycE91omT-cDsuBaczjL0xZ5S5D3QUQbt0frD9SARS5kjPqVcbgUEpckkphSe1N9TPvrwjwOPfGuyM_k8aBugizIxKhLEvS8mr3BSgAP75IZj0wl2c8db1zHTaGa_fKgA_KgXJtp5/s1600/personal-impersonal.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="436" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgaSfmYycE91omT-cDsuBaczjL0xZ5S5D3QUQbt0frD9SARS5kjPqVcbgUEpckkphSe1N9TPvrwjwOPfGuyM_k8aBugizIxKhLEvS8mr3BSgAP75IZj0wl2c8db1zHTaGa_fKgA_KgXJtp5/s640/personal-impersonal.jpg" width="640" /></a></div>
<br />
These one's REALLY looked like Agile on the left side and CMMI on the right side. It is clear that CMMI would fit a control culture much better than a collaboration/cultivation culture and , inversely, Agile fits perfectly on collaboration/cultivation cultures. It's clear how Agile is "Personal", while CMMI is "Impersonal".<br />
<br />
<span class="Apple-style-span" style="font-size: large;">So what about compatibility. From the perspective of culture, what is the result of combining them?</span><br />
<br />
I can imagine a couple of scenarios. In a collaboration/cultivation culture, applying CMMI would push the organization culture towards a more Control/Impersonal culture. From the other side, a control organization (which may be CMMI certified, as it's totally compliant) and wants to become more Agile may encounter a CMMI an obstacle.<br />
<br />
So in the culture context, I see the 2 forces going in opposite directions.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZO_XRbsbU7gRSe-_4-FkZjkJZm9PyHJiK4zDw_fn2RSu8AKNds8egl_q8mlh4pdVYsgkmhqGTGl1mAGfx4J7U3ccJ0dmRaDgfR4pKd8Pm2JmH8WMA_7vopJx_IG7hnVmIL-KXSeZfJ5cN/s1600/AgileCMMIForce.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="206" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZO_XRbsbU7gRSe-_4-FkZjkJZm9PyHJiK4zDw_fn2RSu8AKNds8egl_q8mlh4pdVYsgkmhqGTGl1mAGfx4J7U3ccJ0dmRaDgfR4pKd8Pm2JmH8WMA_7vopJx_IG7hnVmIL-KXSeZfJ5cN/s640/AgileCMMIForce.jpg" width="640" /></a></div>
<div style="text-align: center;">
<br /></div>
Could this be synergetic or complementary or the effect would be the total opposite? Could this lead to an undefined culture or to an organization where employees are confused on their culture and values?<br />
<br />Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com7tag:blogger.com,1999:blog-3356724893663618112.post-62847472945639434762011-07-24T15:27:00.000-07:002011-07-24T15:28:00.781-07:00Software Craftsmen MovementWhen software development started, perhaps I guess about 50 years ago (probably more), I believe programming was the most important task in all software development life-cycle. Other tasks or phases probably didn't exist. They were embedded in what they called programming (right, the old ones?). After a few years, we started learning how to develop software better. This learning derived in methodologies that were created. In these methodologies, new phases such as analysis and designed appeared and in many of them, those phases became more important than programming itself. This was weird because the actual task of building the software lost importance. In heavyweight waterfall methodologies, analysis and design took most of the work. Programming was just a translation work that could be performed (probably by anyone) when all the important work had already been done. <br />
<br />
<br />
Changing the subject, I usually asked myself: How do we, programmers, know that we do our work correctly? Programming is one of those jobs where anyone, with google's help, can combine a few frameworks, throw a few lines of code and create a basic software system. But does that make you a good programmer? Another circumstance which perhaps is different than in other areas, is that our job market has been in need of professionals for many years, absorbing most or all the people in the field. So for many of use, getting a job as a programmer as been an easy thing. We just got off from University and they were waiting for us. But does that make us good programmers? I believe I can speak on behalf of lots of people when I say that we go from receiving very theoretical classes of Computer Science at University to try to resolve down to earth problems using a programming language. And this happens, a lot of times, without guidance (because supossedly we learned this at University?). Or isn't it true that lots of us have throw our first few thousands of lines of code to production without anyone checking them? I wonder: who teaches us how we should do our job as programmers, the day to day tasks. I'm not talking about learning a programming language. I'm talking about how to use it to resolve a problem, which is the best process to do it, what are the techniques. This lack of guidance, of someone that verifies our first steps, of someone that shows us the way, makes it difficult for us to understand how we progress in our career. The leap from finishing University to becoming a good programmer is huge. And how do we fill it? How are we supposed to know what it takes to be a good programmer? Is there any curricula we could follow? Is there a career path somewhere? For sure, I wasn't aware of one.<br />
<br />
I believe those are the 2 main reasons that fueled the creation of the software craftsmanship movement. Agile was in part a revolution against the essence of heavyweighted methodologies. A revolution that put the programming task as the most important task in all software development life-cycle again. The software craftsmanship movement took this revolution a step further. The actual task of coding the software is the most important task and it is not by any means a simple task. It is a task that requires understanding the business problem to solve, model it in the best possible way, program it using a programming language and by many programmers who all need to agree and implement the same model. To add more complexity, many times the business scenarios change and software needs to change, to adapt to those changes. University doesn't prepare us for this job and companies need developers developing as soon as possible.<br />
<br />
The Software Crafstmanship Manifesto states the following:<br />
<br />
<blockquote>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><i>As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:</i></span><br />
<ul>
<li><span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><i>Not only working software, but also well-crafted software</i></span></li>
</ul>
<ul>
<li><span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><i>Not only responding to change, but also steadily adding value</i></span></li>
</ul>
<ul>
<li><span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><i>Not only individuals and interactions, but also a community of professionals</i></span></li>
</ul>
<ul>
<li><span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><i>Not only customer collaboration, but also productive partnerships</i></span></li>
</ul>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><i><br />
That is, in pursuit of the items on the left we have found the items on the right to be indispensable.</i></span></blockquote>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><br />
</span><br />
The first important thing to note in this manifesto is that it treats software programming as a craft. A craft is by the dictionary "an art, trade, or occupation requiring special skill, especially manual skill". A clear example of a craft is a carpenter. And how do you learn the carpenter's craft? First you start besides a carpenter as an apprentice and follow him, for a lot of time. Then you start doing small things on your own. And after a long time you master that craft and are able to perform it on your own. Look how different it looks from the path that many of us have followed. Also note that a craft is something that needs to be practiced. Software craftsmen practice their profession not only daily at work, but also through code katas and getting together to improve their craft in code retreats.<br />
<br />
Look at the values now. Not just software, but well crafted software. Although some people may say that well crafted software is not the goal (producing value is), software craftsmen know that the best way of producing value is to produce good software,software that is robust, adaptable and can keep growing and producing value for a long period of time. I believe the third value indicates what should be the way to achieve this. A community of professionals. Through the software craftmanship community, I believe that now it's possible to follow a career path that takes you from apprentice to good developer. Professionals on this community are very open to teach what they know and help others become good professionals.<br />
<br />
The software craftsmanship movement provided a new perspective to our profession of software programmers. It stressed the importance of programming and also of becoming a good programmer. And it also indicated the way to achieve this. A programmer should start as an apprentice who learns from someone that knows the craft. With practice, and more practice, this apprentice will learn the craft and become a good programmer.<br />
<div>
<br /></div>
Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com2tag:blogger.com,1999:blog-3356724893663618112.post-44185009307727515312011-07-04T06:02:00.000-07:002011-07-04T06:02:34.076-07:00Code & Beyond: Video: ¿Qué esperas de Agile? con Federico Zuppa<a href="http://www.codeandbeyond.org/2011/07/video-que-esperas-de-agile-con-federico.html?spref=bl">Code & Beyond: Video: ¿Qué esperas de Agile? con Federico Zuppa</a>: "Este video es de una de las reuniones mensuales de Agiles @ Buenos Aires , pero me había quedado en el tintero procesarlo y publicarlo, así..."Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-18368363065248362612011-06-15T15:13:00.000-07:002011-06-15T15:13:40.280-07:00The Lean TribeThe Agile Manifesto triggered the growth of "the so called until that moment lightweight methodologies". Scrum and XP became very popular and the tribes associated to them grew with them. However, not long after the Agile Manifesto was signed a new actor entered the scene with outreagous strength. His friends use to call him "Lean" :-)<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiyd46MvamALo2H5G1BDVBJSULtAasCfXOq3LzpSC9fyMqXQtnCeh4BGfRXiJTPPi5EyG4vUen7vKVLYkSu_naisxJBfJEfilD93O3dn7QLykTw3ffnYvfhY7Ma_pBVDFAJzRZlzc7aDofQ/s1600/super-lean.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiyd46MvamALo2H5G1BDVBJSULtAasCfXOq3LzpSC9fyMqXQtnCeh4BGfRXiJTPPi5EyG4vUen7vKVLYkSu_naisxJBfJEfilD93O3dn7QLykTw3ffnYvfhY7Ma_pBVDFAJzRZlzc7aDofQ/s320/super-lean.jpg" width="320" /></a></div><div style="text-align: center;"><br />
</div><br />
<br />
<br />
So what is Lean? Lean has its roots in the Toyota Production System developed by Taichi Ohno. Its core idea is to maximize customer value while minimizing waste.<br />
<br />
Lean was brought into the Agile world by Mary and Tom Poppendieck who in their book "Lean Software Development: An Agile toolkit" translated 7 lean principles used in manufacturing to software development language.<br />
<br />
Although Lean and Agile share many of the same values and principles as they both are people centric and empower people and they both try to adapt/improve the process continually, they also have some differences as well. The main one in my opinion is its main objective: Agile was developed mostly by software developers and therefore its main objetive is "to uncover better ways of developing software". Lean has in its essence a broader objective (and a broader target) as it seeks to improve the flow of value and this could only happen at an organizational level.<br />
<br />
The Agile world was greatly modified by the entrance of Lean. So much that probably now it is an Agile/Lean world.<br />
<br />
So who are the referents of this new Lean tribe. Where do they get together. Do they breed with Agile folks? :D I know I may be missing many of the referents of the manufacture industries but these are the ones I know:<br />
<br />
- Mary and Tom Poppendieck<br />
- Eli Goldratt (RIP)<br />
- David Anderson<br />
- Karl Scotland<br />
- Alan Shalloway<br />
<br />
These folks get together in conferences like "Lean Software and Systems" (in its <a href="http://lssc11.crowdvine.com/speakers">website</a>, you'll be able to find all the speakers that attended in 2011)<br />
<br />
In the last few years, the Lean tribe grew incredibly fast. Particularly, a lean tool called Kanban has gained a great deal of attention and is becoming the new "Scrum" of the moment (or the new star of the moment).<br />
<br />
How is the relationship between Agile and Lean? Well, I believe that although there have been some fights (or discussions should I say) because sometimes tribes defend their interests, the Agile community has a lot to learn from the Lean community. Although in the Agile world, Lean is new, it really is much older than Agile.Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-32869666684996931122011-05-31T08:19:00.000-07:002011-05-31T08:19:06.554-07:00Agile TribesThe people that got together 10 years ago in Salt Lake City had different backgrounds, specialties, positions, etc.There were some folks already working on their own methodologies, such as Beck with XP, Schwaber and Sutherland with Scrum and Cockburn with Crystal. Some of them were more technical, specializing in OO, programming and testing while some others were managers or people more interested in the methodology aspects of software development. This is more or less what I believe were the backgrounds that depict the folks that were there:<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://docs.google.com/drawings/pub?id=1MIu-wixuIbtbJ8kpsTsYDrTpnc5nIn2qt-VjbktAVgE&w=936&h=468" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://docs.google.com/drawings/pub?id=1MIu-wixuIbtbJ8kpsTsYDrTpnc5nIn2qt-VjbktAVgE&w=936&h=468" width="640" /></a></div><br />
<br />
Now I wonder how these 'tribes' (or communities or subfields of interests - I wonder what is the best name) develop over the years. How did they grow or mutated? Which are the new tribes that make up the Agile world?. Who are the new referents of these tribes? Will you help me create this map?<br />
How do I define what a tribe is? Let's list some items that define a tribe:<br />
<ul><li> They share the same values and principles (which should enter the big Agile umbrella)</li>
<li>They work with a certain methodology or method</li>
<li>They have some referents</li>
<li>They get together in one of more congresses (this could be a consequence of the previous)</li>
</ul>Am I missing something to define a tribe? Hummm, yeah for sure. Will see it as we go (iteratively). For the moment, I will research for each tribe the following items:<br />
<ul><li>Reason to be (values/principles they share, objectives)</li>
<li>History</li>
<li>Referents</li>
<li>Present/Future?</li>
</ul>Now I just need to select the most important tribes in today's Agile map. I will start with these ones:<br />
<ul><li>Kanbaners</li>
<li>Software Craftsmen</li>
<li>Lean-startupers</li>
<li>Scrumers </li>
<li>XPs</li>
</ul><br />
I will focus on the first 3 groups, as the last 2 exist since the beggining of Agile.<br />
I'd love to receive suggestions/corrections, etc.Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-24246226542302033322011-05-23T13:40:00.000-07:002011-05-23T13:40:20.242-07:00log4jdbc: Una herramienta muy útil en desarrolloMe estaba preguntando si existía una herramienta que permita ver los queries que se ejecutan contra la DB cuando se usa <a href="http://static.springsource.org/spring/docs/3.0.x/api/org/springframework/jdbc/core/simple/SimpleJdbcTemplate.html">SimpleJdbcTemplate</a> en Spring. Y.. existe. Se llama <span id="goog_686015515"></span><a href="http://draft.blogger.com/">log4jdbc<span id="goog_686015516"></span></a> y la instalación es sencillisima.<br />
Una vez instalado, en el log de la aplicación se podrán ver los queries y también el tiempo de ejecución. <br />
<div style="font-family: "Courier New",Courier,monospace;"><span style="font-size: x-small;"><br />
</span></div><span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">( 45728) [http-8400-3 ] INFO s<b>elect DISTINCT location_code from PURCHASE_LINES where number = 'XXX'</b> </span><br style="font-family: "Courier New",Courier,monospace;" /><span style="font-family: "Courier New",Courier,monospace;"> | at net.sf.log4jdbc.Slf4jSpyLogDelegator(Slf4jSpyLogDelegator.java:223) [2011-05-23 21:32:21,341]</span><br style="font-family: "Courier New",Courier,monospace;" /><span style="font-family: "Courier New",Courier,monospace;">( 46995) [http-8400-3 ] INFO <b>select DISTINCT codes from </b></span></span><b><span style="font-size: x-small;"><span style="font-family: "Courier New",Courier,monospace;">PURCHASE_LINES</span></span></b><span style="font-size: x-small;"><b><span style="font-family: "Courier New",Courier,monospace;"> where po_number = 'XXX' </span></b><br style="font-family: "Courier New",Courier,monospace;" /><span style="font-family: "Courier New",Courier,monospace;"> {executed in 1267 msec} | at net.sf.log4jdbc.Slf4jSpyLogDelegator(Slf4jSpyLogDelegator.java:322) [2011-05-23 21:32:22,608]</span><br style="font-family: "Courier New",Courier,monospace;" /><span style="font-family: "Courier New",Courier,monospace;">( 46997) [http-8400-3 ] INFO 5. ResultSet.new ResultSet returned | at net.sf.log4jdbc.Slf4jSpyLogDelegator(Slf4jSpyLogDelegator.java:158) [2011-05-23 21:32:22,610]</span><br style="font-family: "Courier New",Courier,monospace;" /><span style="font-family: "Courier New",Courier,monospace;">( 46998) [http-8400-3 ] INFO 5. PreparedStatement.executeQuery() returned net.sf.log4jdbc.ResultSetSpy@159d796 | at net.sf.log4jdbc.Slf4jSpyLogDelegator(Slf4jSpyLogDelegator.java:158) [2011-05-23 21:32:22,611]</span><br style="font-family: "Courier New",Courier,monospace;" /><span style="font-family: "Courier New",Courier,monospace;">( 46999) [http-8400-3 ] INFO 5. ResultSet.next() returned true | at net.sf.log4jdbc.Slf4jSpyLogDelegator(Slf4jSpyLogDelegator.java:158) [2011-05-23 21:32:22,612]</span><br style="font-family: "Courier New",Courier,monospace;" /><span style="font-family: "Courier New",Courier,monospace;">( 47000) [http-8400-3 ] INFO 5. ResultSet.getMetaData() returned oracle.jdbc.driver.OracleResultSetMetaData@19e80b1 | at net.sf.log4jdbc.Slf4jSpyLogDelegator(Slf4jSpyLogDelegator.java:158) [2011-05-23 21:32:22,613]</span><br style="font-family: "Courier New",Courier,monospace;" /><span style="font-family: "Courier New",Courier,monospace;">( 47001) [http-8400-3 ] INFO 5. ResultSet.getString(1) returned 10176 KKKKKK | at net.sf.log4jdbc.Slf4jSpyLogDelegator(Slf4jSpyLogDelegator.java:158) [2011-05-23 21:32:22,614]</span><br style="font-family: "Courier New",Courier,monospace;" /><span style="font-family: "Courier New",Courier,monospace;">( 47002) [http-8400-3 ] INFO 5. ResultSet.next() returned true | at net.sf.log4jdbc.Slf4jSpyLogDelegator(Slf4jSpyLogDelegator.java:158) [2011-05-23 21:32:22,615]</span><br style="font-family: "Courier New",Courier,monospace;" /><span style="font-family: "Courier New",Courier,monospace;">( 47003) [http-8400-3 ] INFO 5. ResultSet.getMetaData() returned oracle.jdbc.driver.OracleResultSetMetaData@113126e | at net.sf.log4jdbc.Slf4jSpyLogDelegator(Slf4jSpyLogDelegator.java:158) [2011-05-23 21:32:22,616]</span><br style="font-family: "Courier New",Courier,monospace;" /><span style="font-family: "Courier New",Courier,monospace;">( 47004) [http-8400-3 ] INFO 5. ResultSet.getString(1) returned SSSSSSS | at net.sf.log4jdbc.Slf4jSpyLogDelegator(Slf4jSpyLogDelegator.java:158) [2011-05-23 21:32:22,617]</span><br style="font-family: "Courier New",Courier,monospace;" /><span style="font-family: "Courier New",Courier,monospace;">( 47005) [http-8400-3 ] INFO 5. ResultSet.next() returned true | at net.sf.log4jdbc.Slf4jSpyLogDelegator(Slf4jSpyLogDelegator.java:158) [2011-05-23 21:32:22,618]</span></span><br />
<br />
<br />
Pretty cool, ah?Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-4698189194107179282011-04-08T08:57:00.000-07:002011-04-08T08:57:37.466-07:00Inyectando un Spring Service con PowerMock + Mockito<span style="font-size: small;">Ayer a la tarde estaba intentando hacer un test para nuestra aplicaci</span>ó<span style="font-size: small;">n que usa Spring en el backend. Una de las cosas que me di cuenta que cambiaron desde la ultima vez que use Spring es que todos los beans son inyectados automagicamente con la anotaci</span>ó<span style="font-size: small;">n @Autowire, por lo que no es necesario ni tener un constructor ni un setter para inyectar una dependencia. La pregunta ahora es como hago para testear estos beans? (para inyectar mocks en estos beans). Dps. de investigar un rato encuentro la libreria <a href="http://code.google.com/p/powermock/">PowerMock </a>que permite hacer cosas locas, como stubbear un metodo est</span>á<span style="font-size: small;">tico u obtener/setear el estado interno de un bean (rompiendo asi la encapsulaci</span>ó<span style="font-size: small;">n). Por ejemplo, la sintaxis para setear una variable privada es la siguiente:</span><br />
<span style="font-size: small;"> </span><br />
<div style="font-family: "Courier New",Courier,monospace;"><span style="font-size: x-small;">UserRepository userRepositoryMock = mock(UserRepository.class); // declaro el mock, usando mockito</span></div><div style="font-family: "Courier New",Courier,monospace;"><span style="font-size: x-small;">when(userRepositoryMock.safeGetLoggedUser()).thenReturn(adminUser); // seteo las expectativas<br />
Whitebox.setInternalState(invoiceRepository, "userRepository", userRepositoryMock); // inyecto el mock, usando Powermock</span></div><br />
Cual es el problema con el que me tope? Spring utiliza proxies para manejar las transacciones via AOP y estos proxies implementan la interfase del servicio, que no contiene los setters para sus campos. Osea que si quisieramos hacer lo mismo para un servicio (en vez de un repositorio como en el ejemplo),<br />
<br />
<span style="font-size: x-small;">Whitebox.setInternalState(scannedFileService, "userRepository", userRepositoryMock); // inyecto el mock, usando Powermock</span> <br />
<br />
PowerMock se quejaría (porque estamos queriendo llamar un método en una clase que no tiene ese metodo). La exception que arroja es la siguiente:<br />
<br />
<span style="font-family: "Courier New",Courier,monospace; font-size: x-small;">Caused by: java.lang.RuntimeException: You want me to set value to this field: 'userRepository' on this class: 'Object' but this field is not declared withing hierarchy of this class!<br />
at org.mockito.internal.util.reflection.Whitebox.getFieldFromHierarchy(Whitebox.java:40)<br />
at org.mockito.internal.util.reflection.Whitebox.setInternalState(Whitebox.java:25)<br />
... 31 more</span><br />
<br />
Esto se podría arreglar agregando el setter a la interfase del servicio, pero la verdad es q no me parecia limpio tener q modificar la interfase publica solamente a efectos de testear. Por suerte, existe una solución. Investigando un poco mas, encontre <a href="http://forum.springsource.org/showthread.php?t=10902">este</a> foro que indica como hacer con Spring para obtener el objeto 'aconsejado' (advised) desde el proxy.<br />
<br />
<div style="font-family: "Courier New",Courier,monospace;"><span style="font-size: x-small;">Advised advised = (Advised) scannedFileService;</span></div><div style="font-family: "Courier New",Courier,monospace;"><span style="font-size: x-small;">ScannedFileService target = (ScannedFileService)advised.getTargetSource().getTarget();</span></div><div style="font-family: "Courier New",Courier,monospace;"><span style="font-size: x-small;">Whitebox.setInternalState(target, "userRepository", userRepositoryMock);</span></div><div style="font-family: "Courier New",Courier,monospace;"><span style="font-size: x-small;"><br />
</span></div>et voila! Una vez obtenido el objeto aconsejado, powermock se encarga del resto. Espero sus comentarios (les parece un overkill? Agregarian los setters directamente? etc.)<br />
<br />
Agrego dependencias de powermock en maven para aquellos que son lentos como yo y les cuesta encontrar las dependencias :-). <br />
<br />
<span style="font-family: "Courier New",Courier,monospace; font-size: x-small;"> <dependency><br />
<groupid>org.powermock.modules</groupid><br />
<artifactid>powermock-module-junit4</artifactid><br />
<version>1.3.9</version><br />
<scope>test</scope><br />
</dependency><br />
<dependency><br />
<groupid>org.powermock.api</groupid><br />
<artifactid>powermock-api-mockito</artifactid><br />
<version>1.3.9</version><br />
<scope>test</scope><br />
</dependency></span><br />
<span style="font-family: "Courier New",Courier,monospace; font-size: x-small;"><dependency> </dependency></span><br />
<span style="font-family: "Courier New",Courier,monospace; font-size: x-small;"><dependency> </dependency></span>Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-46255954765087749122011-02-22T06:04:00.001-08:002011-02-22T06:04:47.173-08:00Are Level 5 CMMI Process Areas compatible with Agile?<h1 id="internal-source-marker_0.7423651322196264"><span style="font-size: large;"><span style="background-color: transparent; color: black; font-family: Arial; font-style: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">Introduction</span></span></h1><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">After a quantitatively manage organization, the next objective is an optimizing quantitatively managed organization. An organization that is constantly improving. CMMI level 5 process areas deal with this. Improvement, change, should be done (otherwise, the organization is left behind by others) but it should be managed with care, not to overwhelm the organization. </span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">The first process area is Organizational Innovation and Deployment (OID). Its goals and practices represent a measured way of selecting and deploying improvements. The second process area is called Causal Analysis and Resolution (CAR) and aims at resolving the root causes of defects for ever. </span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">The specific goals and practices for OID are:</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SG 1 Select Improvements</span><br />
<div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.1 Collect and Analyze Improvement Proposals</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.2 Identify and Analyze Innovations</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.3 Pilot Improvements</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.4 Select Improvements for Deployment</span></div><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SG 2 Deploy Improvements</span><br />
<div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 2.1 Manage the Deployment</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 2.3 Plan the Deployment</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 2.2 Measure Improvement Effects</span></div><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">and for CAR are:</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SG 1 Determine Causes of Defects</span><br />
<div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.1 Select Defect Data for Analysis</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.2 Analyze Causes</span></div><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SG 2 Address Causes of Defects</span><br />
<div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 2.1 Implement the Action Proposals</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 2.2 Evaluate the Effect of Changes</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 2.3 Record Data</span></div><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<h2 style="font-weight: normal;"><u><b><i><span style="font-size: small;"><span style="background-color: transparent; color: black; font-family: Arial; font-style: normal; text-decoration: none; vertical-align: baseline;">Observations</span></span></i></b></u></h2><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Both of these processes are designed to work in a quantitatively managed organization. CMMI states that if it isn’t quantitatively managed, it would work, but it wouldn’t be as effective. I wondered when I started reading the book if optimization wasn’t left for too late in CMMI. In one side, how would you optimize if you can’t measure? On the other, my experience with Agile is that optimization comes from the very first moments, at the standup and in the retrospective meetings where opportunities for improvement are detected. Of course all these optimizations are really subjective, as the improvement they provide can’t really be measured.</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Another point that I wanted to make is that CMMI mentions that everyone should be empowered to propose optimizations. This goes very much in line with the lean approach to optimization.</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<h1><span style="font-size: large;"><span style="background-color: transparent; color: black; font-family: Arial; font-style: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">Conclusion</span></span></h1><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">I didn’t see any point of incompatibility in these areas. Having a framework in the organization to do Kaizen is very important for the organization as it allows to optimize with the organization’s objectives (i.e. with everyone aligned) , it allows to do it in an orderly fashion and it allows to really know what is been optimized and how much. </span>Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-79658795862352040362011-02-19T05:11:00.000-08:002011-02-19T05:11:17.939-08:00Are Level 4 CMMI Process Areas compatible with Agile?<h1 id="internal-source-marker_0.6636455072658582"><span style="font-size: large;"><span style="background-color: transparent; color: black; font-family: Arial; font-style: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">Introduction</span></span></h1><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">I merged the process areas in level 4, because they are really inter twinned and probably don’t make sense to do one and not the other. The first one, the Organizational Process Performance aims at “establish and maintain a quantitative understanding of the performance of the organization’s set of standard processes”. Based on these baselines, the Quantitative Project Management process area sets the objectives and “quantitatively manage the project’s defined process to achieve the project’s established quality and process-performance objectives.</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">The Organizational Process Performance goals and practices are listed below:</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SG 1 Establish Performance Baselines and Models</span><br />
<div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.1 Select Processes</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.2 Establish Process-Performance Measures</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.3 Establish Process-Performance Baselines</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.5 Establish Quality and Process-Performance Objectives</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.4 Establish Process-Performance Models</span></div><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">The Quantitative Project Management goals and practices are listed below:</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SG 1 Quantitatively Manage the Project</span><br />
<div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.1Establish the Project’s Objectives</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.2 Compose the Defined Process</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.3 Select the Subprocesses that Will Be Statistically Managed</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.4 Manage Project Performance</span></div><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SG 2 Statistically Manage Subprocess Performance</span><br />
<div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 2.1 Select Measures and Analytic Techniques</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 2.2 Apply Statistical Methods to Understand Variation</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 2.3 Monitor Performance of the Selected Subprocesses</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 2.4 Record Statistical Management Data</span></div><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">Metrics? What metrics?</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">In CMMI Level 4, the organization reaches a level where the existing processes can be quantitatively measured. Objective objectives can be set based on these measures. Being able to measure is vital to being able to manage and optimize. Jurgen published a </span><a href="http://www.noop.nl/2011/01/manage-yourself-with-measures.html"><span style="background-color: transparent; color: #000099; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: underline; vertical-align: baseline;">post</span></a><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"> recently that states “You cannot manage what you don’t measure”. </span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">A very important point to keep in mind when selecting what to measure is that these metrics need to be compatible with the Agile values and practices. Wrongly selected metrics may create dysfunctional behaviours, detrimental to the organization’s objectives. Dave Nicolette has a very nice </span><a href="http://davenicolette.wikispaces.com/Agile+Metrics"><span style="background-color: transparent; color: #000099; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: underline; vertical-align: baseline;">presentation</span></a><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"> regarding Agile metrics. Some of the metrics he discusses are “Running Tested Features”, “Hard Financial Value” and “Earned Business Value”. I wonder, with these metrics, how to handle at the organizational level the context differences among the projects. I mean, each project is different, runs under different circumstances, will deliver business value in a different way, etc. All these factors need to be considered to draw conclusions from the metrics.</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">These metrics need to provide the picture needed by upper management to take decisions and manage risk appropriately. Being able to visualize the processes used, detect and resolve problems is of utmost importance in mature organizations.</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">Can everything be measured?</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">There’s a nice quote by Albert Einstein in Dave’s presentation that says “Not everything that counts can be counted, and not everything that can be counted counts.”. Is there place for subjectivity in a mature organization? How and where would it work? Agile methods stimulate optimization since the very beginning and this is performed, in most cases, subjectively. Teams introspect on the previous iteration, try to determine how they feel and propose ideas that would optimize the process. At upper levels, it would be impossible to optimize this way. Managers need to see the broad view and the only way seems to be through measures.</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">Keep it light!</span><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">I must confess that after reading both process areas in level 4, I ended up a bit scared. It really sounds difficult and requirements seem pretty heavy. Agile processes are characterized by their minimum overhead. The machinery required to measure and optimize processes shouldn’t increase this overhead significantly. For this, measures should be taken in the most automatic way, only what is needed should be measured and when it’s not needed anymore it should be dropped. There should be constant improvement in the improvement processes. </span><br />
<h1><span style="font-size: large;"><span style="background-color: transparent; color: black; font-family: Arial; font-style: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">Conclusion</span></span></h1><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Being able to measure, to understanding where it is standing allows an organization to set improvement objectives. These measures need to be align with the Agile philosophy. The improvement machinery should be kept light.</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span>Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0tag:blogger.com,1999:blog-3356724893663618112.post-61037922812076050002011-02-16T05:19:00.000-08:002011-02-16T05:22:42.799-08:00Is the Decision Analysis and Resolution Process Area compatible with Agile?<h1 id="internal-source-marker_0.2530109693366074"><span style="background-color: transparent; color: black; font-family: Arial; font-size: large; font-style: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">Introduction</span></h1><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">The Decision Analysis and Resolution process area, a process area at level 3, aims at “formal evaluation process that evaluates identified alternatives against established criteria.”</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">Below are the specific goals and practices:</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SG 1 Evaluate Alternatives</span><br />
<div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.1 Establish Guidelines for Decision Analysis</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.2 Establish Evaluation Criteria</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.3 Identify Alternative Solutions</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.4 Select Evaluation Methods</span></div><div style="margin-bottom: 0pt; margin-top: 0pt; text-indent: 36pt;"><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">SP 1.5 Evaluate Alternatives</span></div><div><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"> SP 1.6 Select Solutions</span></div><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">Inclusive and Fair</span><br />
<br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">The process should be inclusive and fair.</span><br />
<br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">Inclusive</span><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">: All stakeholders should be involved in the decision. With this, I am not saying that all stakeholders need to agree on the solution. Probably this is impossible or too costly. I am just saying that everyone should be able to participate in the decision process, express their opinions, being heard. A good facilitator will increase the chances of everyone being heard and of taking a good decision. Being included in the decision process provides great encouragement to follow through the selected paths. Collaborative decision making is of utmost importance in Agile.</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">Fair</span><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">: the process should be fair. Every person in the team should feel that it was not an arbitrary decision imposed. The decision was taken using a process that they understand and consider fair. Of course, not everyone will agree, even if a very fair process is used. However, even not agreeing, if they consider that the process was fair, they will accept. On the contrary, if the feeling is the decision was imposed through a not so transparent process, the decision taken will be very difficult to accept. An excellent paper regarding this topic can be found </span><a href="http://hbr.org/2003/01/fair-process/ar/1"><span style="background-color: transparent; color: #000099; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: underline; vertical-align: baseline;">here</span></a><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">.</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<h1><span style="background-color: transparent; color: black; font-family: Arial; font-size: large; font-style: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">Conclusion</span></h1><span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">I believe it would be very beneficial to have a defined formal process that can be used to take difficult decisions. To be more Agile, the process should be inclusive and fair (which are really very inter twinned)</span><br />
<span style="background-color: transparent; color: black; font-family: Arial; font-size: 11pt; font-style: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span>Federico Zuppahttp://www.blogger.com/profile/13346754761957313175noreply@blogger.com0