Loading...

Follow Scrum.org | Scrum Masters Blog on Feedspot

Continue with Google
Continue with Facebook
or

Valid
TL; DR: 28 Product Backlog Anti-Patterns

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 28 Product Backlog anti-patterns — including the Product Backlog refinement process — that limit your Scrum Team’s success.

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 anti-patterns:

General Product Backlog Anti-Patterns
  1. 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.)
  2. 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?)
  3. Over-sized: The Product Backlog contains more items than the Scrum Team can deliver within three to four sprints. (This way the Product Owner creates waste by hoarding issues that might never materialize.)
  4. 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.)
  5. 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.)
  6. 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 user stories.)
  7. Missing acceptance criteria: There are user stories 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. In the end, however, all user stories need to meet the definition of ready standard, and acceptance criteria are a part of that definition.)
  8. No more than a title: The Product Backlog contains user stories that comprise of little more than a title. (See above.)
  9. Issues too detailed: There are user stories 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.)
  10. Neither themes nor epics: Themes or epics do not 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.)
  11. 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.)
Anti-Patterns at Portfolio and Product Roadmap Level
  1. 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 from the product roadmap. If those are not available, the product backlog is likely to granular.)
  2. 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.)
  3. 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. )
  4. 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 user stories will probably be a waste.)
Product Backlog Anti-Patterns of the Product Owner
  1. 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.)
  2. Part-time 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.)
  3. Copy & paste PO: The Product Owner creates user stories 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.)
  4. Dominant PO: The Product Owner creates user stories 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.)
  5. INVEST? The Product =wner is not applying the INVEST principle by Bill Wake to user stories. 
  6. Issues too detailed: The Product Owner invests too much time upfront in user stories 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.)
  7. 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).
  8. ‘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 Anti-Patterns
  1. 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?)
  2. 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.)
  3. 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 Anti-Patterns of the Scrum Team
  1. 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.)
  2. Too much refinement: The team has too many refinement sessions, resulting in a too detailed backlog. (Too much refinement isn’t healthy either.)
  3. 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 user stories as well as the general way of working as a team.)
Watch the Replay of the Product Backlog Anti-Patterns Webinar

The replay of the webinar on Product Backlog anti-patterns is available on Youtube:

Scrum Product Backlog Anti-Patterns (Hands-on Agile Webinar #3) - YouTube
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 anti-patterns.

Are Product Backlog anti-patterns missing that you have observed? Please share with us in the comments.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

En Nexus no se requiere una reunión “Scrum of Scrums” ya que se usa el Nexus Daily Scrum. El Nexus Integration Team tiene la responsabilidad de gestionar las dependencias de un Nexus y es un equipo dedicado a esta labor entre otras responsabilidades.

El Nexus Daily Scrum es un evento del Framework Nexus de Scrum.org que sirve fundamentalmente para gestionar las dependencias entre varios equipos Scrum y analizar el impacto de las mismas. Este evento se usa cuando se escala Scrum y se realiza todos los días antes del Daily Scrum de cada equipo. Es importante el orden ya que si cada equipo no se encuentra al tanto del estado de las dependencias no las va a considerar en su propio Daily Scrum y podrían asumir un plan del día basado en información de las dependencias desactualizada. En este evento los representantes de cada equipo inspeccionan el progreso hacia el Nexus Sprint Goal. Es importante considerar que cuando varios equipos trabajan en un mismo producto y forman un Nexus los criterios de terminado representan el incremento integrado de todos los incrementos de cada equipo de Scrum.

Pueden asistir a este evento miembros de cada equipo de Scrum elegidos idealmente de una forma auto organizada. 

Durante algunas implementaciones he visto que hay una tendencia inicial a que sea el Scrum Master o la persona más experimentada de cada equipo quien represente al equipo en esta reunión. Si bien es cierto el Scrum Master puede ser parte del Nexus Integration Team y asistir, se debería buscar que sean los mismos miembros de cada equipo Scrum los que asistan porque eso les permite interactuar con parte del equipo de Integración y mejorar el trabajo en equipo más allá de su propio equipo Scrum.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

For years, I’ve fulfilled the role of Scrum Master for many different organizations and Scrum Teams. These teams were mostly focused on software development. I’ve been in the fortunate position of having worked for some great organizations. These organizations were able to attract the smartest developers and create products customers loved. Everyone enjoyed going to work and looked forward to learning new stuff, helping each other solve tough problems and engage with the users of the product.

I’ve also worked for organizations where people struggled to create such a culture. For them, it was difficult to keep the high potential developers on board and hire new ones. Often, after only having worked shortly for such an organization, I already felt what the problem was: they lacked a “Developer Culture”. In the beginning, it was only the smell of the place that made me conclude this. However, over time more tangible examples popped up. Everyone agreed on how serious this was. The organization was full of people discussing “what” needed to be built, the problem was that there weren’t any people that could actually build the product. For these organizations, creating a Developer Culture isn’t a nice to have, it’s the only way to survive!

“Creating a Developer Culture isn’t a nice to have, it’s the only way to survive!”

In this blog post, I’ll share examples of how I experienced a Developer Culture. Now, what I don’t want to do is write a vague article about culture full of fluffiness that might sound interesting but doesn’t provide any clarity. I’m simply going to share my perspective as a Scrum Master working closely with developers. That’s not going to be a technical perspective. Although I did try being a developer, I failed miserably… To be clear, whenever I write “developer” in this article, I mean everyone involved in writing software and building products. So this can be a developer, analyst, tester, designer or architect etc.

Sprint Review at Schiphol Airport with lot’s of stakeholders

Examples of a Developer Culture

Examples that I’ve experienced and consider part of a Developer Culture are…

  • Development Teams are considered the most important part of the organization. Everyone that’s not part of the Development Team is there to support them. Not the other way around. HR, Finance, Sales and Management should be focused on making the life of developers as convenient as possible. Don’t let Development Teams get lost and stuck in the organization’s hierarchy.
  • Developers are paid really well. I’ve always considered it strange that in organizations everyone agreed that developers were crucial for the organization’s existence, but were nevertheless paid poorly (compared with others in the organization). If you truly consider developers that important, put your money where your mouth is. It seems however that whenever the work being done becomes more tangible, the salary decreases. Wherever the work becomes vaguer, it’s the other way around.
  • It’s about the outcome, not output. It’s about building valuable software for the customer, using the least amount of time. Not about finishing as many tasks as possible, of which the value isn’t clear. Also, involve the Development Team in determining the value. This will help them build the rights things, and build it right.
  • Development Teams choose their own metrics to measure progress.These metrics are focused on the outcome. Examples are cycle time, customer satisfaction, team happiness, innovation rate, return on investment, and total defects. Avoid metrics that focus on utilization and efficiency. They encourage local optimization, are easy to manipulate and are often used to control individuals.
  • Everyone is in contact with the customer. The real customer. Not (only) stakeholders that know a customer. I mean the person using the product. If this means that developers need to leave the office to visit a customer: awesome! I’ve once hired a mini-van and took the entire team to a customer. This proved to be a nice team-building activity as well.
  • They can choose and purchase their own gear. With gear, I mean screens, desks, chairs, headsets etc. I’ve experienced organizations where developers we’re doing multi-million projects, however having two screens or a decent headset wasn’t possible. This was against company policies. The result: unhappy developers that try to sneak in their own gear from home. This created a culture of fear, secrets, and fighting “the system”. I can’t imagine this is the culture organizations want to have.
  • A budget is provided for having some fun. How & when they spend it: that’s up to them! It might be visiting an escape room, organizing a LAN-party, having a bbq, playing paintball or going on a boat trip. As long as it helps them gel as a team. Nothing beats a good team activity!
  • A suitable environment is offered in which they can do complex work.Many organizations still use “flex-desks” and “open-office space” where everyone is sitting together. For developers, this is often a nightmare. Lack of focus, no feeling of having a team space and continuously being distracted doesn’t help with solving complex problems or doing innovative work. If they want, give them their own team room. Let them decorate the room however they want. Provide whiteboards. Lot’s of whiteboards. If a team room isn’t possible or necessary, simply involve them in creating their own environment in which they feel comfortable.

Random pictures of our PHP Elephant collection, walls of transparency, team manifesto, baking pancakes for my team

  • Development Teams take responsibility for hiring new team members. In The Netherlands, within the development community, everyone knows each other. They know exactly when someone becomes available and if they would fit in the team. This is a far more powerful approach compared to what a recruiter can achieve. Sure, a recruiter a network as well, but the really good developers have already switched jobs/assignments before a recruiter is aware of this. They’ve already been approached by another developer during a local meetup. Really, developers can be your best recruiters!
  • Tools like JIRA, TFS or any other work-tracking system are only used if the Development Teams considered it useful themselves. Not because it is such a convenient tool for others in the organization to track the progress. This will only create a culture of fear in which Development Teams feel they are being monitored.
  • Developers are encouraged to contribute to the wider community. This can be by writing articles for tech sites, speaking at seminars, attending meetups, offering to coach and/or mentoring. Every community depends on the contributions of its members. Being part of a thriving community, will help developers gain innovative ideas, solve problems with peers and expand their individual networks.
  • They take care of their own “HR Process” by given each other feedback, provide tips for personal growth opportunities. I’ve worked with teams that even took care of salary increases and how a bonus should be divided. Although this didn’t always work out ideally, the signal the organization provided, “we trust you”, did create a culture of ownership where self-organization more easily occurred.
  • Attending training and workshops is strongly encouraged. Taking days off for this wasn’t a painful and even humiliating procedure by asking for permission. I’ve always encouraged developers to attend public workshops and classes. Instead of in-company training. By participating in public classes they meet other developers, learn about software development in a different context and opened up for new ideas.
  • There is sufficient time for R&D. This could be jointly reading a book or watching a video and share findings among each other. Organizations that have Development Teams fully scheduled with “customer work” will eventually pay the price. Stress-levels increase, quality drops, and innovation will fall apart. We’ve always scheduled roughly 1 day per week for R&D. Sometimes we used a fixed day for this, for example, the Friday. I’ve also been part of teams that preferred R&D weeks.
  • Pair programming is stimulated and not considered a waste of time. Pair programming has lots of benefits. For example, it stimulates collaboration, shared understanding and improves the quality of the code. In my experience, by doing pair programming you deliver better products even faster because you’ve got less re-work or bug fixing afterward. So it’s definitely a practice I strongly recommend.
  • They choose to use Scrum themselves. Or Kanban. Or XP. Whatever supports them the best in doing their work. The framework or methodology should never be the goal of itself. It should be an enabler. Involve the Development Team in creating a way-of-working that benefits them the most.
  • They have fun. Lot’s of fun. This should be part of any kind of culture. Some organizations have become so serious nowadays. Have a bit of fun. We’re spending so many hours together at work, why don’t just have an awesome, fun and useful time with each other?

Random pictures of close collaboration with the customer, pair +1 programming, team activities, doing a Sprint Planning

These are examples that in my experience help grow a Developer Culture. The order is completely random, it’s how it appeared in my mind. As mentioned earlier, if software products are your core business, growing such a culture isn’t optional. It’s crucial for the existence of your organization!

What’s your view on the importance of growing a Developer Culture? What are the examples you have experienced?

In February 2020 we will host a 2-day workshop on “Developer Culture” with Darcy DwyerJeroen de JongPeter Gotz, and Thomas Schissler. We will be using Liberating Structures to engage a large group of developers to share stories just like the ones in this post and to develop and build strategies to create “Developer Cultures” in your team and organization. If you’re interested in joining, you can already sign up here. Take as many members of your Development Team with you as you can.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

As CEO and Product Owner for Scrum.org I get the amazing opportunity to visit lots of different companies. Recently I spent a week in Brazil visiting some amazing companies and talking about agility. The visit was fantastic for many reasons, but one thing did strike me as I toured many team rooms and looked at a large number of Scrum and Kanban boards. The walls lack any mention of the customer or mission. And then I realized that my team room also was lacking any mention of the customer as well! 

Scrum is an amazing framework, but it does nothing without a mission. The intent of Scrum is not to be agile; it is to deliver value and because the value is hidden behind complexity Scrum is required. Scrum encourages the empirical process, self-organization and continuous improvement to solve complex problems and deliver value. Each complex situation has a customer. Our recently released Professional Scrum with User Experience spends two days providing Scrum Teams with a set of ideas of how to unlock the customer, and encourages that customers, their motivations and needs are made TRANSPARENT.

I can hear a Scrum Myth coming on, “Isn’t the Product Owner responsible for the customer?’” Yes, the Product Owner often has a deep knowledge of the customer and the market they live in, but it is EVERYONE’S responsibility to know thy customer! It would not be very agile if every time we had to make a decision about the customer, we had to talk to the Product Owner.  The Product Owner makes decisions about value, which things to focus on and which things to do instead of other things. The Product Owner concentrates on economics. The team has to deliver value. They have 10000 decisions to make in pursuit of the economic value defined by the Product Owner. They need to understand the 'why', they need to understand the context, they need to have the motivation and desire to provide that value to the customer.

But there are still Scrum Teams that don’t know their customer! Or they have forgotten.

“A fictional character created to represent a user type that might use a product in a similar way.”

One approach to keeping the customer front and center is using customer personas. And when I say customer I do not mean people that pay, I include anyone that consumes the Product being built, this includes users, buyers, admins, etc. A persona is:

Alan Cooper is widely credited in using the term in his groundbreaking book, The Inmates are Running the Asylum. The book, as the title suggests encourages “creators” to take control of their work and engage the customer. Personas provide a tool for talking about customers in an abstract but practical fashion. They help inform the team by helping them ask questions like, “what would Bob do?” at Sprint Reviews or other inspection moments. They encourage healthy debate at Sprint Planning as we focus on outcomes for a particular persona. And, like everything in Scrum they enable us to inspect and adapt our understanding of them via delivering ‘stuff’. But perhaps the most important thing that personas give us is they help motivate the team because, though abstract they are about real people who need us to improve their lives! Personas connect the abstract product work to real human beings. Dan Pink described the value of knowing the context of the word in his amazing book Drive, the Surprising Truth that Motivates us as Purpose. Purpose along with Autonomy and Mastery are key ingredients to extrinsic motivation.  

“But we don’t know our customer and it seems silly to be creating these fictional characters,” I hear you shout. After all, we are professional teams focused on doing stuff, personas sound like a fluffy nice to have!

The reality is that teams can get going quickly and just spending an hour looking at the customer and the types of customers the product serves can really expose assumptions and misunderstandings. Everyone has their own view of who the customer is and by making it explicit and on the wall those views can be exposed and then reviewed. Once the first version is ‘up’ we can regularly refine it adding additional ideas, thoughts, and assumptions as we deliver value to real customers and get feedback.

The other great thing about hanging up your personas is visitors can provide some really valuable perspective. For instance, when another team visits on their way to the pub they see the persona and say, “wow I did not know you served that role, did you know we did X or Y?”. Also, when the boss comes down from their gold-plated office it provides a reason to talk. Personas are great conversation starters. And it is amazing what you learn when you make your customer and their pains transparent.

And at the very least it makes your team room and walls look cool :-) 

Scrum On. 

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

En Nexus no se requiere una reunión “Scrum of Scrums” ya que se usa el Nexus Daily Scrum. El Nexus Integration Team tiene la responsabilidad de gestionar las dependencias de un Nexus y es un equipo dedicado a esta labor entre otras responsabilidades.

El Nexus Daily Scrum es un evento del Framework Nexus de Scrum.org que sirve fundamentalmente para gestionar las dependencias entre varios equipos Scrum y analizar el impacto de las mismas. Este evento se usa cuando se escala Scrum y se realiza todos los días antes del Daily Scrum de cada equipo. Es importante el orden ya que si cada equipo no se encuentra al tanto del estado de las dependencias no las va a considerar en su propio Daily Scrum y podrían asumir un plan del día basado en información de las dependencias desactualizada. En este evento los representantes de cada equipo inspeccionan el progreso hacia el Nexus Sprint Goal. Es importante considerar que cuando varios equipos trabajan en un mismo producto y forman un Nexus los criterios de terminado representan el incremento integrado de todos los incrementos de cada equipo de Scrum.

Pueden asistir a este evento miembros de cada equipo de Scrum elegidos idealmente de una forma auto organizada. 

Durante algunas implementaciones he visto que hay una tendencia inicial a que sea el Scrum Master o la persona más experimentada de cada equipo quien represente al equipo en esta reunión. Si bien es cierto el Scrum Master puede ser parte del Nexus Integration Team y asistir, se debería buscar que sean los mismos miembros de cada equipo Scrum los que asistan porque eso les permite interactuar con parte del equipo de Integración y mejorar el trabajo en equipo más allá de su propio equipo Scrum.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

La aceptación de los PBIs en Scrum es algo que suscita dudas en los equipos. En realidad es muy fácil.

En Scrum tenemos cuatro eventos y un metaevento. Los eventos son el Sprint Planning, Daily Scrum, Sprint Review y Retrospectiva. El metaevento es el Sprint, que es un contenedor para todos los demás.

Durante el Sprint Planning, seleccionamos los PBIs que queremos completar durante ese Sprint y trazamos un Sprint Goal que marcará la dirección de lo que queremos conseguir en ese Sprint. Una vez que vayamos trabajando en ellos, colaboramos con el Product Owner para que los validarlos. Los entregámos de acuerdo con nuestra Definition of Done tan pronto como estén validados.

En algunas organizaciones es más difícil, porque dependen de un proceso manual auditado de subida a producción, pero en aquellas que utilizan DevOps, tan pronto como se cumplen los criterios que tengamos establecidos, será un sistema automatizado el que se encarga de subir a producción. Una vez que esté hecho, los PBIs son aceptados.

Lo que no hay que hacer nunca es esperar hasta el Sprint Review para entregar los PBIs. Esto provoca una espera innecesaria. En cuanto el Product Owner los valida, deberían entrar en el pipeline de puesta en producción.

Poner en Producción y hacer una release

¿Que ocurre si los PBIs que hemos seleccionado en el Sprint no queremos ponerlos en producción? Esta es una cuestión de configuración. En Scrum, el concepto de "En Producción" y "Released" son distintos. El uso de herramientas que permitan hacer toggling feature permite tener software en producción y configurarlo a gusto del Product Owner.

Puede ser que hoy estemos haciendo elementos para la próxima campaña de Navidad. Este Software puede estar terminado y subido a producción pero no activado a ojos del usuario, lo cual nos permite también ver como se comporta y hacer cuantas modificaciones necesitemos sin correr tanto riesgo como en un sistema de despliegue tradicional.

Además, esta estrategia nos permite tener una Definition of Done más completa que incluya "puesta en producción" aunque sigamos trabajando en los elementos durante más tiempo, haciendo el desarrollo iterativo e incremental. Ante la duda, no, esperar a tener toda una nueva funcionalidad para ponerla en producción no es iterativo e incremental. Es más Waterfall.

En Scrum los PBIs se entregan tan pronto están finalizados, independientemente de si hemos llegado al Sprint Review o no. Nos permite desacoplar la entrega de los eventos. Así éstos se centren más en la estrategia de nuestro producto en lugar de en el funcionamiento técnico. O una demo.

Para validar el valor del Software realizado, esta vez sí, el Product Owner debería de buscar hacer una release cuanto antes.

Puedes leer más sobre como conseguir un buen Sprint Review en este artículo del blog.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Scrum Masters, ask yourself - Are you a natural servant leader, or do you struggle to be the inspiring coach that creates high-performing teams? If you have a real desire to change and are ready for some tough self-reflection, this article may inspire you, and give you hope that you can influence major changes, by starting with things that are within your control. 

You might find that focusing on how your own behavior is impacting others can change the emotional climate in your team – and positively impact your career. (Do you secretly think the issues on your team are all about the Product Owner? Share my Emotional EQ for Product Owners article.)

The following blog is inspired by Scott Watson’s work, an emotional intelligence speaker and trainer. I hope they will complement what you are already doing well and help you create a tactical plan to improve your own emotional intelligence and the emotional climate in your team.

1. Physician, Heal Thyself WE TEACH PEOPLE HOW TO TREAT US

As a leader, you must overcome any of your own emotional insecurity and speak up, even if you might have a personality that shies away from conflicts. It’s not about standing up to others; it’s about finding your voice. If you cannot speak up for yourself, how can you defend your team?

An easy practice to check-in with your emotional self, is to track the amount of times you re-run your memory of a particularly uncomfortable scenario that occurs on a regular basis.

For example, you might have a friend or teammate who consistently shows up late to an appointed meeting, abusing your efforts, or those of your teammates, to arrive on time. They might slide in, late again, and say something like “Oh, so sorry I am late. I ran into traffic.” Do you find yourself asking them to honor your time by planning for the traffic, or do you give them an easy out with the casual “Oh, that’s okay. It happens.” And then re-run the scenario in your head with the prefix “I should have said ….”

If your team does not witness you standing up for yourself, or for them, when the stakes are low, imagine how they might anticipate your ability to confront a more difficult scenario.

2. Create a safe environment BUILD EMPATHY WITH EACH OTHER

If your emotional climate needs some warming up, the empathetic Scrum Master will notice this and immediately spring into action. They know to ask good questions, get some rapport going, perhaps some laughs, then get the team focused on the event.

If you are not a natural empath, it’s okay. Empathy is more about you than your team members. You will know when you are an empathetic leader if your team wants to work with you, rather than against you.

Don’t confuse empathy with sympathy. Empathy is the ability to listen and understand with thoughtful consideration. Empathy can be done assertively. Those of you who may be command and control may be getting complaints. Use these as opportunities to improve your nuances in language. Often, particularly if people are upset, it’s not what you are saying – it’s what the person hears.

Bookmark this easy 20-minute team exercise that can help build the emotional intelligence in your team by learning about themselves and their teammates. Even if your teams have been working together, it’s still a good idea to pause to reflect and adapt at a personal level.

EVALUATE THE STRESS IN YOUR TEAM

Stress interferes with the ability to learn, therefore it impedes the ability to innovate and solve problems. When team members get stressed, it manifests with negative emotions. The team can actually stop looking for solutions and start to withdraw from participating in events. Take note of disengaging behaviors.

ENGAGE COLLABORATION AND INVOLVEMENT WITH INTERACTIVE EXERCISES

Ever heard the saying that “the worst you can be is wrong?” Use www.tastycupcakes.org for a large variety of games and interactive sessions you can share with your team to get them talking.

LEARN TO ASK OPEN-ENDED QUESTIONS

When people are upset, don’t just ask ask, “Why are you upset?” This will just make them more upset. Try phrases like:

“Why did this happen?”

“What can I do to resolve this matter so you can return to the team and get on with our event?”

Practice replacing the direct, and possibly intrusive phrase “What are you thinking?” with these nuances:

“What are your thoughts on this? Please share them with us.”

“May I share my thoughts and then hear yours?”

People respond more openly to requests than demands. Small nuances in our language can help the tone feel more collaborative. My favorite source to increase emotional EQ with open ended questions is the book “Coaching Questions” by Tony Stoltzfus. Each chapter has scenarios you can practice with a friend and a variety of techniques to use to achieve different outcomes with your audience. This is a natural for some, but can be a learned skill for those of us (myself included) who need this regular practice.

Wait 8 seconds!

According to scientists, the human attention span is so short that goldfish can pay attention longer than we can. The results of a Canadian research study showed the average human attention span has fallen from 12 seconds in 2000 (around the time we all started reaching for our smart phones) to eight seconds.

Goldfish, meanwhile, can focus for nine.

However, most facilitators just do not give people time to think. They ask a question and want an answer. Your job is to resist the temptation to jump in. Switch off your brain from “I need to speak” to “let me listen.”

Give your team 8 seconds to give them time to think and understand. Even better, give them time to problem solve: “I’ll come back to you in two minutes.”

Pause now and write this down as a prompt that you can see when you facilitate next: “Does it need to be said? Does it need to be said, right now? Does it need to be said, right now, by me?” It takes me 8 seconds to say those three phrases with a slight breath in between. How long does it take you?

In conclusion… PRACTICE!
  1. Write out one scenario that you will script out and practice to be comfortable delivering next time it comes up.
  2. Pause here and write down the names of three people on your team whom appear disengaged to you in some way.
  3. Write down three ideas to show them support in a collaborative manner.

This blog is not about not trying to change anyone. It’s about helping others to explore different ways to behave or communicate that is more effective for them as individuals and their team. If you show your vulnerability and willingness to improve your emotional EQ, perhaps others will too. Everyone on the team should be invested in furthering the safe environment that fosters innovation.

I’m interested to know… what will you do differently as a result of reading these 3 tips? How did waiting 8 seconds change the emotional climate in your team?

~Julee Everett

Live your truth; hone your craft; show your thanks

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

The map above illustrates a classic problem with the common use of 'velocity' as a metric.

It is also a great illustration of the assertion I made in my previous article: A Scrum Team Increases Their Velocity by Doing Less Work. The popularity of that article has surprised me as it's been syndicated by numerous e-zines and blogs. I think it struck a chord but my explanation was rather academic — the image above simplifies the argument. I'll explain.

Scenario

Your family travels each weekend to a nearby lake. You have identified at least these 3 possible routes. Which route is fastest?

That question is a trick. It's the trick which baffles many teams and managers.

  • The shortest route is 67 kilometers and will take 68 minutes given known current traffic conditions.
  • The longest route is 91 kilometers and will take 90 minutes. This route has the highest velocity!

It is obvious the shortest route is the best. It's the most direct and we'll arrive at our destination sooner. The trouble is, we'll have go a little slower.

If a manager is with us looking at the same map, if they understand the terrain the same way we do, when they can see the options before them I'm (almost) certain they'd agree to take the route with the lowest velocity.  It is the most direct route. But if that manager does not understand the terrain, they are apt to demand the route with the highest velocity. After all, they want the team to go as fast as possible!

Please use this example when:

  • You are explaining to stakeholders why TDD appears to be slower but is in fact more direct.
  • You find yourself trying to justify building quality in.
  • Your stakeholders are confused why technical debt needs to be repaid as soon as possible.

(Please share your own examples in the comments below. I'd love to hear your stories about how velocity is misused and how this article has helped you.)

Important End Note

Do make sure however that you are always focused on the most direct route. To use this example to justify any sort of gold-plating or pre-optimization is inappropriate.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
TL;DR: Technical Debt & Scrum

If technical debt is the plague of our industry, why isn’t the Scrum Guide addressing the question of who is responsibly dealing with it? To make things worse, if the Product Owner’s responsibility is to maximize the value customers derive from the Development Team’s work, and the Development Team’s responsibility is to deliver a product Increment (at least) at the end of the sprint adhering to the definition of “Done,” aren’t those two responsibilities possibly causing a conflict of interest?

This post analyzes the situation by going back to first principles, as laid out in the Scrum Guide to answer a simple question: Who is responsible for keeping technical debt at bay in a Scrum Team?

What Is Technical Debt?

According to Wikipedia,

“Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.”

The issue is that there is not just the typical hack, the technical shortcut that is beneficial today, but expensive tomorrow that creates technical debt. (A not uncommon tactic in feature factories.)

There is also a kind of technical debt that is passively created when the Scrum Team learns more about the problem it is trying to solve. Today, the Development Team might prefer a different solution by comparison to the one the team implemented just six months ago. Or, the Development Team upgrades the definition of “Done,” thus introducing rework in former product Increments.

No matter from what angle you look at the problem, you cannot escape it, and Scrum does not offer a silver bullet either.

Technical Debt & Scrum — The Scrum Guide

First of all, the Scrum Guide does not mention technical debt.

According to the Scrum Guide:

  • The Product Owner is responsible for the maximizing of the value of the work of the Development Team.
  • Product Owners do so by managing the Product Backlog, visible in its content and ordering of Product Backlog items.
  • The Product Backlog represents the only set of requirements the Development Team will work on and shall comprise of everything the product requires to be valuable.
  • The Scrum Team never compromises on quality.
  • The definition of “Done” is either provided by the engineering organization or the Development Team.
  • During the Sprint Planning, the Product Owner discusses Product Backlog items suitable to achieve the Sprint Goal.
  • However, only the Development Team picks the Product Backlog items it deems necessary to achieve the Sprint Goal.
  • If necessary, the Development Team adds new Product Backlog items to the Sprint Backlog as more is learned.
  • If the Development Team improves the definition of “Done,” rework of former product Increments may become necessary.

Therefore, I believe the Scrum Guide is deliberately vague on the question who is responsible for the technical debt to foster collaboration and self-organization, starting with the Scrum values–courage, and openness come to mind—leading straight to transparency and Scrum’s inherent system of checks & balances.

How to Deal with Technical Debt as a Scrum Team

I am convinced that dealing with technical debt should be a concern of the whole Scrum Team. There are a few proven techniques that will make this task more manageable:

  1. Be transparent about technical debt. Visualize existing technical debt prominently so that everyone is constantly reminded of the nature of your code-base. Also, address technical debt at the Sprint Review events regularly so that the stakeholders are aware of the state of the application.
  2. Use code metrics to track technical debt, for example, cyclomatic complexity, code coverage, SQALE-rating, rule violations. (There are numerous tools available for that purpose.) At least, count the number of bugs.
  3. Pay down technical debt regularly every single sprint. Consider allocating 15 to 20 percent of the Development Team’s capacity each Sprint to handle refactoring and bug fixing. (Learn more: 19 Sprint Planning Anti-Patterns.)
  4. Make sure that all tasks related to deal with technical debt are part of the Product Backlog—there is no shadow accounting in Scrum.
  5. Adapt your definition of “Done” to meet your understanding of product quality, for example, by defining code quality requirements that contribute to keeping technical debt at a manageable level in the long run.
  6. Create a standard procedure on how to handle experiments that temporarily will introduce technical debt to speed up the learning in a critical field.

In my experience, dealing with technical debt becomes much simpler when you consider transparency to be the linchpin of any useful strategy.

Technical Debt & Scrum — Conclusion

Given that solving a problem in a complex environment always creates new insights and learnings along the way that will make past decisions look ill-informed, creating technical debt is inevitable.

Handling technical debt, therefore, requires a trade-off. The longterm goal of achieving business agility cannot be reached as a feature factory churning out new features. At the same time, an application in a perfect technical condition without customers is of no value either.

Consequently, dealing with technical debt in Scrum is a responsibility for the Scrum Team as a whole and as such an excellent example of Scrum’s built-in checks & balances.

How are you handling technical debt in your daily work? Please share with us in the comments.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Writing code is like finding your path through a dark forest. Behind each tree can lurk a monster, a treasure or a pit. Or there is no path at all. You don’t know until you look. For me, this attitude encapsulates the essence of writing software empirically.

A developer culture is one where this kind of thinking is enabled and encouraged. It values an empirical approach to every level of development. It encourages the active exploration of ways to shorten the feedback-loop even further and deliver value even faster.

I know this sounds very nice in theory. But how does it translate into the practice of writing code? In this post, I share five questions — or cognitive strategies — that I find helpful to ask before starting development of a feature, a piece of functionality or fixing a bug.

 

1. “What is the purpose, really?”

I strongly believe that you shouldn’t write code before you at least understand the purpose of what you intend to create. Although this might seem obvious, a lot of developers practice a style of “Gung-Ho”-coding that leaves little time for this. And this includes me. In my eagerness to write code, I often forgot to take a step back and look at the big picture first.

It's a bit like starting to write a book without first having at least a basic sense of the story you want to tell. Or indeed, venturing into a dark forest without first considering why. If you don’t take this step back, you will end up writing a lot of code that isn’t necessary or useful.

Now, I’m not suggesting you should analyze until you have every detail nailed down. Writing code, even fixing a simple bug, is complex work and involves loads of assumptions and setbacks that you can only discover and validate as you do the work. You don’t know what's behind the tree until you look. So you have to allow yourself to explore how to achieve the purpose as you write the code.

“You have to allow yourself to explore how to achieve the purpose as you write the code.”

Before writing code, I always want to make sure I can comfortably and easily complete the following two sentences in layman’s terms:

  • “This feature/Product Backlog Item/code exists in order to …”;
  • “I will know that I’ve implemented it successfully when I …”;

This is also an excellent reason why pairing up with someone else is so valuable, as it allows you to actually have this conversation. And if you don’t have that opportunity, you can always explain it to your plant, cat or rubber duck. The mere act of explaining it to someone else — even if that someone doesn’t exist — helps your mind makes sense of things.

Pairing up with someone else is a great way to have this conversation

Once you have an understanding of the purpose — what it is that you intend to achieve — you can start thinking about the steps that you know of right now that are required to achieve that purpose.

2. “What steps are involved in achieving that purpose?”

In order to discover the steps required for a purpose, I find it helpful to tell or draw the story of a feature in terms of its timeline: “First … Then … After which … Followed by …. Finally … (and so on)”. Again, this is something that works best when you pair up with someone.

For example, we recently implemented a feature that automated the process of editing a video to have a nice intro and outro (from a set of variations) and uploading it to YouTube. Our initial understanding of the timeline was:

  • First, a user should be able to upload a video through a web-based form (Angular) for further processing;
  • Then we have to pick one of five intros and one of four outros;
  • After which we have to merge the uploaded video with the intro (before) and the outro (after);
  • Which is followed by uploading the merged video to YouTube using an API token;
  • Finally, we have to inform the user when the merge and upload was successful (or not);

Additional steps emerged while writing the code, such as:

  • First, an upload has to be registered with YouTube to receive a URL to upload the video too;
  • Then we have to upload the video that URL;
  • After which, we have to clean up temporary files left-over by the merge to avoid the server from clogging up;

As you can see, thinking about a feature in terms of its timeline helps to break down a larger piece of functionality into a series of connected bits of functionality. Some of these could even be implemented on their own, while others can be skipped completely. And this is where the next question becomes invaluable.

3. “What steps are most critical to the purpose and nag you the most?”

In a “Gung-Ho”-world, we would go ahead and start writing code. But writing code is fraught with unpredictable problems that can heavily impact the feasibility and the time it takes to write it. Inspired by the Cynefin Framework, it is helpful to write small bits of code that act of as “probes”, each illuminating as much of the dark forest as possible.

Inspired by the Cynefin Framework, it is helpful to write small bits of code that act of as “probes”, each illuminating as much of the dark forest as possible.

In order to find what lurks in the darkness of the code you still have to write, it is helpful to consider which steps nag you the most. Behind which tree is it most likely you will find a monster or a pit? These are the steps that I often find myself revisiting on autopilot while taking a shower of before trying to fall asleep.

In my example, we found ourselves thinking about two things most of the times; How do you merge three videos with C# code on Linux? And how do you upload a (large) video to YouTube? We considered the first to be the most critical. If we couldn’t pull that off within a short period of time and with relatively few lines of code, the amount of effort involved in the entire feature probably wouldn’t be worth it.

As it turned out, it took only two hours to write a prototype that could run ‘ffmpeg’ and merge three videos into one. Initially, this was just a simple console application with about 100 lines of code — way too long. But once we knew that the code worked, we started to refactor it out into smaller, specialized classes.

Probes don’t have to involve writing code. For uploading a video to YouTube, we were most worried about authentication and the complexity of YouTube’s API, and not so much about writing C# code to talk with their REST-API. So instead we fired up Postman to talk directly to their API and get a sense of what was involved. When we got that working, it was easy to translate the message-exchange into C# code that did the same thing.

You’ll notice that each of these probes are essentially short feedback loops. And this leads to the next question.

4. “What is the smallest piece of functionality that you can deploy to production to achieve (part of) the purpose?”

It's tempting to keep running local probes. But one of the most important probes we have for illuminating the “dark forest” of the code we still have to write is to actually deploy something to a production-environment and make it available to users. This is the most realistic, most complete feedback-loop we can achieve. And the faster we do it, the faster we learn about what else is necessary.

Each probe represents a feedback loop

So I always ask myself which steps represent the smallest piece of well-designed, high-quality functionality that can be deployed to production.

For my example, the purpose of the feature was to automate a manual process. The most tedious part of that process was the merging of three video’s, which required specialized video-editing software on the laptops of users. So we started by first building a form that allowed users to upload and submit a video for merging. Because this process took quite some time, we made it asynchronous. When the merge was done, users received an email with a link to download the merged video. From here, the user still had to manually upload the merged video to YouTube. But this already resolved 75% of the manual work. We implemented the rest later. Building this first part required about 4–5 hours; after which value was delivered to users and a lot was learned about what else was needed.

Once we had deployed this first full-cycle probe, we started to refactor the codebase. The (working) code was separated into more specialized classes and projects. Code that was initially duplicated for the purpose of rapid development was removed or moved into shared NuGet-packages. We also improved the architecture by pulling the code for merging videos into its own microservice that connected with the other services through a message queue that made it more robust to intermittent failures. Every commit on the Git-repository was automatically deployed to production, provided all tests passed. Each iteration of refactoring took about at most one hour followed by an automated deployment of a couple of minutes. In the rare instances where we noticed unusual behavior in the microservice, a fix was deployed soon after.

Now, this is just an example. The steps are entirely contextual and dependent on the feature and the application. But there are some commonalities that I think apply everywhere:

  • What is the smallest bit of functionality that we can safely deploy to production?
  • What is the simplest-yet-flexible architecture that allows us to achieve the purpose?
  • When this functionality is successfully deployed, what is the first thing we should refactor to improve the code and/or the architecture?
  • In case of disaster, how can we recover as quickly as possible?
5. “How can we make our feedback-loop even simpler, faster and more robust?”

It is immediately obvious that this empirical approach to writing software requires automation to be feasible. If testing and deployment have to be done manually each time, we are bound to start making excuses for not doing it (‘I’ll do it tomorrow’, ‘I want to add just this one thing…’). And by not sending out small probes, we don’t learn nor limit the risk of wasting time and effort on something that turns out to be too difficult or not useful to users. So I’m always looking for ways to make it easier, simpler and safer to deploy to production.

A couple of years ago, I was working with a team on connecting an application to a remote API for exchange information that resulted in financial payouts. This remote API was not under our control, and the people responsible for it were generally hard to reach. It could take hours, on occasion even days, to receive feedback on whether or not our message had been processed correctly or what caused an error to be returned. What worried me most was that this slow build-test-feedback-refactor cycle would take too much time, meaning we would probably skip certain tests or improvements for convenience (or laziness). So as an experiment, I spent one weekend to write a simple facade over the remote API that implemented the same protocols for the handful of messages we were already exchanging. Instead of talking directly to the remote API, we configured our applications to talk to the facade instead. A simple web interface showed traffic and allowed us to relay messages to the remote API, repeat them when an initial attempt failed, receive responses and send ‘mocked’ responses to our applications for testing purposes. Over time, this facade proved so helpful that it grew into a gateway of its own with support for many kinds of messages, advanced routing and a management interface that was very helpful during Sprint Reviews (hint: make something like this when your team does a lot of technical API-based work).

Concluding thoughts

In this post, I shared five questions that I find helpful before venturing into the dark forest of code-yet-to-write. In a developer culture, asking these questions is encouraged and supported. Let me know if you find them helpful. And perhaps you have other questions that you feel add to these. Let me know in the comments.

If you like this post, and want to learn more strategies like this, we happily invite you to join our upcoming workshop on ‘Developer Culture’ in Amsterdam. Together with a large group of experienced developers, we will develop and share more strategies like the ones in this post. And we will explore what else is required to create a “developer culture” in your organisation that values asking these questions and creating the opportunities to put them into practice. Because Scrum and Agile are just words when developers don’t know how to do this.

“Scrum and Agile are just words when developers don’t know how to do this.”

Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview