Welcome to the Home of Scrum!

DevOps es un área de mi interés desde hace varios años. En Diciembre de 2014, en la CAS de Barcelona, di una charla en Inglés sobre la experiencia haciendo que DevOps fuera uno de los pilares de la agilidad en la DVLA -Una suerte de DGT británica-. Hace un año y medio también publiqué un artículo introductor al tema de DevOps y Scrum. Tres años después, veo que DevOps y su convergencia con Scrum sigue sin arrancar. Me encuentro con profesionales de ambas áreas que en lugar de colaborar, tienden a ensanchar aún más sus diferencias. Los motivos que encuentro son: Resentimiento de la comunidad técnica hacia el éxito de Agile y Scrum, Incapacidad para entender que operaciones forma parte del proceso de desarrollo y un conflicto personas vs procesos. Resentimiento en la comunidad de operaciones hacia el éxito de Agile y Scrum A pesar de que ahora pensemos que hemos reinventado todo, la comunidad de operaciones lleva muchos años manteniendo a raya los sistemas críticos de organizaciones grandes y pequeñas. Se trata de profesionales muy especializados que han visto como el número de Agile Coaches, unos mejores y muchos peores, de pronto cobraba un protagonismo muy importante en las organizaciones que se habían encargado de mantener. Una pena. Y una fuente de frustración Eso ha hecho que se crearan castas dentro de las propias organizaciones. Desarrollo tiene un papel muy importante mientras que operaciones siguen siendo los tipos del sótano que se encargan de seguir las instrucciones que mandan los de arriba. En ocasiones bajo las mismas restricciones presupuestarias. Todo esto, unido a la baja calidad de muchos profesionales de Agile, muchos de los cuales no sólo carecen de conocimientos técnicos sino que los minusvaloran, ha creado una brecha todavía más grande entre las dos comunidades profesionales, haciendo que DevOps fuera casi un enemigo para Scrum. Y viceversa. Incapacidad para entender que operaciones forma parte del proceso de desarrollo Sorprendentemente, sigue existiendo una incapacidad para querer entender que en el ciclo de vida del desarrollo de Software, la programación pura y dura no suele suponer más de un 12% o un 15% del mismo. Ese software debe de ser diseñado, mantenido y puesto en producción, y a pesar de eso seguimos empeñados en que lo importante es programar, no tener productos terminados y usables por parte del cliente. Cuando trabajamos usando Scrum, el objetivo no es el proceso, es el producto terminado. Los Sprint Reviews no son compuertas a la siguiente fase -operaciones-, sino que son herramientas para inspeccionar y adaptar nuestra táctica en función de la estrategia. Operaciones debe ser parte del Sprint y de los equipos Scrum. Dependiendo del contexto, puede que trabajen permanentemente dentro de un equipo o que vayan haciendo de consultores que están completamente disponibles para los equipos. Conflicto personas vs procesos Mientras que la tendencia en la comunidad ágil es hacia las personas, en la comunidad de operaciones es más hacia los procesos. Esta dicotomía es sólamente resultado de las diferencias que existen en el trabajo de ambas áreas. Mientras el trabajo en desarrollo esta más orientado a descubrir, el trabajo de operaciones está más orientado a ejecutar. Permíteme explicar eso. El desarrollo de Software es complejo, y continuamente tenemos que descubrir soluciones a problemas que no habíamos previsto. El trabajo de operaciones se enfoca en optimizar todo el proceso de puesta en producción y mantenimiento de ese software en producción. Mientras que la variabilidad es inherente al desarrollo y podemos obtener beneficios de la misma (por ejemplo, cuando descubrimos que optando por una librería en lugar de un diseño ad-hoc ganamos en rendimiento y mantenibilidad), la variabilidad es algo a evitar en operaciones. Hay que estandarizar el proceso. Si además le unimos la baja calidad de algunos profesionales en Agile, eso provoca una desconexión total entre desarrollo y operaciones. DevOps tiene que orientarse a converger con Scrum, y es donde mejor resultado obtienen ámbos. No todos los sabores funcionan en todas las organizaciones ¿Como resolvemos estos problemas? En primer lugar, adoptando una mentalidad crítica hacia Scrum y DevOps y luego entendiendo el contexto de la organización. No podemos cambiar organizaciones a martillazos, diciéndoles que lo que tienen que hacer es sustituir a todo su equipo de operaciones y dejar ese trabajo a los equipos de desarrollo. No es viable. No es una solución. En lugar de eso, hay que intentar introducir una cultura que cierre las brechas que se explican más arriba para posteriormente ir mejorando nuestra capacidad de automatización. Un gran banco no puede, de la noche a la mañana, automatizarlo todo. Y es que eso no es DevOps. Es NoOps. NoOps puede funcionar perfectamente en una pequeña startup, pero en el momento que hay que cumplir requisitos regulatorios, de negocio, seguridad, no es tan fácil automatizarlo todo. El reto está en volver a los orígenes, a la Agile Infraestructure que asentó las raíces de DevOps en sus comienzos. Muchos profesionales de operaciones insisten en que DevOps es automatización, cuando no lo es. Es mucho más. Si quieres leer más sobre la convergencia de DevOps y Scrum, te recomiendo que eches un vistazo al whitepaper que hemos publicado conjuntamente con el DevOps Institute en Scrum.org

El Sprint Backlog suele generar bastantes dudas en cuanto a su gestión. En ocasiones se convierte en un arma arromadiza que los stakeholders, el Product Owner o incluso el Scrum Master utilizan para controlar el equipo. ¿Es esta su función?

TL; DR: Ideas on How to Improve Your Product Backlog Management Techniques Scrum is a simple, yet sufficient framework to build emerging products, provided you identify in advance what is worth building. But even after a successful product discovery phase, you may struggle to make the right thing in the right way if your Product Backlog is not up to the job; garbage in, garbage out—as the saying goes. The following article points at ideas on how to improve your product backlog management techniques — including the Product Backlog refinement process. The Product Backlog According to the Scrum Guide First of all, let’s have a look at the current issue of the Scrum Guide on the Product Backlog: “Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion. Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above-described refining activities. The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.” Source & Copyright: ©2016 Scrum.Org and ScrumInc. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible here and also described in summary form. Common Product Backlog Anti-Patterns Despite being relatively straightforward, the process of creating and refining a Product Backlog often suffers from various anti-patterns. I have identified five different categories for Product Backlog techniques: General Product Backlog Techniques Prioritization by proxy: A single stakeholder or a committee of stakeholder prioritize the Product Backlog. (The strength of Scrum is building on the strong position of the Product Owner. The PO is the only person to decide what tasks become Product Backlog items. Hence, the Product Owner also decides on the priority. Take away that empowerment, and Scrum turns into a pretty robust waterfall 2.0 process.) 100% in advance: The Scrum Team creates a Product Backlog covering the complete project or product upfront because the scope of the release is limited. (Question: how can you be sure to know today what to deliver in six months from now?) Over-sized: The Product Backlog contains too many items. (This way, the Product Owner probably creates waste by hoarding issues that might never materialize. Depending on the specific context, many products might benefit from limiting the Product Backlog to three, possibly four Sprints, particularly in highly competitive markets.) Outdated issues: The Product Backlog contains items that haven’t been touched for six to eight weeks or more. (That is typically the length of two to four sprints. If the Product Owner is hoarding backlog items, the risk emerges that older items become outdated, thus rendering previously invested work of the Scrum Team obsolete.) Everything is estimated: All items of the Product Backlog are detailed and estimated. (That is too much upfront work and bears the risk of misallocating the Scrum Team’s time.) Component-based items: The Product Backlog items are sliced horizontally based on components instead of vertically based on end-to-end features. (This may be either caused by your organizational structure. Then move to cross-functional teams to improve the team’s ability to deliver. Otherwise, the team – and the Product Owner – need a workshop on writing items.) Missing acceptance criteria: There are items in the Product Backlog without acceptance criteria. (It is not necessary to have acceptance criteria at the beginning the refinement cycle although they would make the task much more manageable.) No more than a title: The Product Backlog contains items that comprise of little more than a title. (See above.) Issues too detailed: There are items with an extensive list of acceptance criteria. (This is the other extreme: the Product Owner covers each edge case without negotiating with the team. Typically, three to five acceptance criteria are more than sufficient.) Neither themes nor epics: Neither themes or epics do structure the Product Backlog. (This makes it hard to align individual items with the “big picture” of the organization. The Product Backlog is not supposed to be an assortment of isolated tasks or a massive to-do-list. Please note that both themes and epics are not elements of the Scrum Guide.) No research: The Product Backlog contains few to no spikes. (This often correlates with a team that is spending too much time on discussing prospective problems, instead of researching them with a spike as a part of an iterative item creation process.) Techniques at Portfolio and Product Roadmap Level Roadmap? The Product Backlog is not reflecting the roadmap. (The Product Backlog is supposed to be detailed enough only for the first two or three sprints. Beyond that point, the Product Backlog should rather focus on themes and epics — see above — from the product roadmap. If those are not available, the product backlog is likely to granular.) Annual roadmaps: The organization’s portfolio plan, as well as the release plan or product roadmap, are created once a year in advance. (If the Product Backlog stays aligned to these plans, it introduces waterfall planning through the backdoor. Agile planning is always “continuous.” At the portfolio level, the plan needs to be revised be least every three months.) Roadmaps kept secret: The portfolio planning and the release plan or product roadmap are not visible to everybody. (If you do not know where you are going any road will get you there. This information is crucial for any Scrum Team and needs to be available to everybody at any time. ) China in your hands: The portfolio planning and the release plan or the product roadmap are not considered achievable and believable. (If this is reflected in the Product Backlog, working on items will probably be a waste.) Product Backlog Techniques of the Product Owner Storage for ideas: The Product Owner is using the Product Backlog as a repository of ideas and requirements. (This practice is clogging the Product Backlog, may lead to cognitive overload and makes alignment with the ‘big picture’ at portfolio management and roadmap planning level very tough.) Part-time or busy PO: The Product Owner is not working daily on the Product Backlog. (The Product Backlog needs to represent at any given time the best use of the Development Team’s resources. Updating it once a week before the next refinement session does not suffice to meet this requirement.) Copy & paste PO: The Product Owner creates items by breaking down requirement documents received from stakeholders into smaller chunks. (That scenario helped to coin the nickname “ticket monkey” for the product owner. Remember: item creation is a team exercise.) Dominant PO: The Product Owner creates items by providing not just the ‘why’ but also the ‘how,’ and the ‘what.’ (The team answers the ‘how’ question – the technical implementation –, and both the team and the PO collaborate on the ‘what’ question: what scope is necessary to achieve the desired purpose.) INVEST? The Product Owner is not applying the INVEST principle by Bill Wake to items. Issues too detailed: The Product Owner invests too much time upfront thus making them too detailed. (If an item looks complete, the team members might not see the necessity to get involved in further refinement. This way, a “fat” item reduces the engagement level of the team, compromising the creation of a shared understanding. By the way, this didn’t happen back in the days when we used index cards given their physical limitation.) What team? The Product Owner is not involving the entire Scrum Team in the refinement process and instead is relying on just the “lead engineer” (or any other member of the team independently of the others). ‘I know it all’ PO: The Product Owner does not involve stakeholders or subject matter experts in the refinement process. (A Product Owner who believes to be either omniscient or a communication gateway is a risk to the Scrum Team’s success.) Development Team Techniques Submissive team: The Development Team submissively follows the demands of the Product Owner. (Challenging the Product Owner whether his or her selection of issues is the best use of the Development Team’s time is the noblest obligation of every team member: why shall we do this?) What technical debt? The Development Team is not demanding adequate resources to tackle technical debt and bugs. (The rule of thumb is that 25% of resources are allocated every sprint to fixings bugs and refactor the code base.) No slack: The Development Team is not demanding 20% slack time from the Product Owner. (This is overlapping with the sprint planning and the team’s forecast. However, it cannot be addressed early enough. If a team’s capacity is always utilized at 100 %, its performance will decrease over time. Everyone will focus on getting his or her tasks done. There will be less time to support teammates or to pair. Small issues will no longer be addressed immediately. And ultimately, the ‘I am busy’ attitude will reduce the generation of a shared understanding among all team members why they do what they are doing.) Product Backlog Techniques of the Scrum Team No time for refinement: The team does not have enough refinement sessions, resulting in a low-quality backlog. (The Scrum Guide advises spending up to 10% of the Scrum Team’s time on the Product Backlog refinement. Which is a sound business decision: Nothing is more expensive than a feature that is not delivering any value.) Too much refinement: The team has too many refinement sessions, resulting in a too detailed backlog. (Too much refinement isn’t healthy either.) No DoR: The Scrum Team has not created a ‘definition of ready’ that Product Backlog items need to match before becoming selectable for a sprint. (A simple checklist like the ‘definition of ready’ can significantly improve the Scrum Team’s work. It will increase the quality of both the resulting item as well as the general way of working as a team. Please note that the SG only mentions “ready” in the following sense: "Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning.”) Conclusion Even in the case, you have successfully identified what to build next, your Product Backlog, as well as its refinement process, will likely provide room for improvement. Just take it to the team and address possible Product Backlog techniques. Are Product Backlog techniques missing that you have observed? Please share with us in the comments.

In this blog post, I’ll share examples of how I experienced a Developer Culture, being a Scrum Master working with Development Teams.