Welcome to the Home of Scrum! ™

We are going towards the "Agile" Transformation. One of our goals is to increase velocities across all our teams by X%. Have you heard this? Marc Andreessen’s adage that “Software is eating the world” is becoming the differentiator for Industries that were previously thought to be more manual. A company known for developing “Agile” products surveyed more 18,000 customers and Software development professionals, which is what they discovered. 77% practice Agile Development. -Atlassian Survey,2016. The well-known Contributor of this game-changer is “Scrum” – A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Velocity is just a Complementary & Optional Practice in Scrum When you start adopting Scrum, the total work remaining to reach a goal can be summed at any point in time. Various projective practises upon trending have been used to forecast progress like burn-downs charts or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. Especially, agile frameworks like Scrum doesn’t mandate any practices to be used. However, these are Complementary practices that are found to be useful. These practices are used to build “Dashboards” to make decisions. But the Agile development does not necessarily lend itself to the kind of dashboards and reports beloved by managers. The few metrics it produces make little sense outside of the context of team planning. Given this shortage of usable information, it can be tempting to re-purpose velocity to measure productivity. After all, it’s a measure of team capacity, so it follows that changes over time could be used to indicate overall shifts in productivity? “Velocity is an option to Measure progress” not the value! Alongside these complementary practices, the biggest risk with this approach is that a velocity is a planning tool rather than a specific measurement. It’s an estimate of relative capacity that tends to change over time, and these changes don’t necessarily indicate a shift in productivity. It’s also an arbitrary measure that varies wildly between Organizations, teams and Products. There are no credible means of translating it into a normalized figure that can be used for meaningful comparison. What is Velocity then? Velocity is an indication of the ability to turn Product Backlog into releasable functionality across time, or for a specified price. I want to increase my team velocity == my goal. Given that velocity is such an arbitrary measure, it is easy to game, Inflate it or Deflate it. By equating velocity with productivity, you create a “perverse incentive” to optimize velocity at the expense of developing quality software. Consciously or not, teams will start trying to demonstrate an increase in productivity by massaging velocity upwards. If the goal is set as Increase in Velocity is directly proportional to the productivity. Worse still, they may start cutting corners to deliver things. This can lead to a build-up of technical debt, and the product they create will be brittle. Magic Moment- Open the team’s burn-down charts. Suppose you distribute burn-down charts to senior management. Every sprint, the progress line magically starts to intersect with the delivery target. The shape of the line may vary wildly, but somehow there’s a speeding up or slowing down in the second half of the sprint to meet the expectation. Velocity is a measure of the amount of work that a team can do. This is not the same as measuring the value or impact of this work. Velocity may actually be relatively stable in a successful and well-established team as the amount of raw effort available for each sprint remains constant. In this case, putting artificial upwards pressure on velocity will only serve to distort estimates. Can you really measure software productivity? Productivity is determined by looking at the inputs and outputs of an activity. It’s easy enough to measure the inputs for software development, but it’s actually challenging to measure the outputs in any consistent way. Most importantly, it is Outcome that Matters, not the Output. A raw, quantitative measure such as numbers of lines of code does not provide any reasonable guide. It is too dependent on wildly variable factors such as coding style, development language and implementation approach. It can also be counter-intuitive as well-written code that has taken time in crafting often requires fewer lines of code. How do we Measure Value? If you derive a measure of productivity from velocity, then you will see a statistical improvement. This is not the same as a successful development. Ultimately, Agile Frameworks like “Scrum” process framework relies on the empirical approach. The empirical process relies on Inspection, adaptation and transparency, enabling continuous feedback loop between development teams and the commercial context. A more meaningful measure of success should consider and focus on real-world benefits rather than abstract measures of normalized indicators. But remember, A release is required to realize the Value. So, Am I saying metrics are bad? No, I am not saying “metrics” are useless. They are not just management indulgence. They help you gather information, decide on corrective action, and, most importantly, figure out how to evolve. If you tend to satisfy on-going Management hunger for reports, you end up creating meaningless overhead. End of the day, Software is Complex, and that can’t be predicted, but only forecasted! Then, what do I measure? Measure the value of your Investment, One of the ideas that Ken Schwaber put across is known as "Evidence-based Management "- He says, Evidence-Based Management for Software Organizations is the first useful method for transforming software from an expense into a profitable asset. Especially the, The Agility Index™ software enables you to measure the improvement in business outcomes and track your investment return. Covering EBM is out of this article's scope, I would recommend going through the below link for more Information on EBM, https://www.scrum.org/resources/evidence-based-management-guide. Source of References www.atlassian.com www.scrum.org/resources www.benmorris.com www.hbr.org

"Como tirar o PSM I?" Como sou um Trainer oficial da Scrum.org, recebo essa pergunta constantemente, e por isso resolvi colocar todos meu conhecimento nesse artigo. Importante: essas dicas foram escritas em Dez/2020. Se algo mudar, tentarei deixar atualizado. Sobre a certificação A PSM I da Scrum.org é uma das mais valorizadas certificações do mercado, quando falamos de Scrum. Isso por que a prova é relativamente difícil, e além disso a Scrum.org é uma organização mantida por um dos criadores do Scrum – Ken Schwaber. Não é necessário fazer o curso oficial para fazer a prova – não tem pré-requisitos. Porém quem faz o curso oficial, ganha 2 chances de fazer a prova (veja abaixo). Se você fizer um curso oficial da Scrum.org, assim que terminar o curso você é convidado para fazer o cadastro na Scrum.org. No seu cadastro (no seu perfil), vai aparecer que você fez um curso oficial – isso é bom, pois tem empresas que buscam pessoas que fizeram o curso e possuem a certificação). Em seguida você recebe um voucher para fazer a prova. Se você fizer a prova em até 14 dias e não passar na prova, você ganha outro voucher gratuito, automaticamente. Esse benefício só existe para quem faz o curso oficial. A prova é feita somente em inglês, mas já vi muitas pessoas que não sabiam nada de inglês e que conseguiram tirar a certificação, usando o Add-on da tradução automática no Google Chrome. Você faz a prova da sua casa, precisando apenas um computador com acesso a internet. São 80 questões para serem respondidas em 60 minutos de prova. Você precisa de pelo menos 85% de acerto, o que equivale a cerca de 68 questões Tanto a PSM I quanto a PSM II, são perguntas de escolhas. A PSM III tem algumas perguntas dissertativas. Para fazer a prova, você pode comprar o voucher direto da Scrum.org por $150, ou fazer um treinamento oficial. Você não precisa renovar essa licença. Uma vez feita a prova e obtido o certificado, ele não expira e é seu pra sempre. Uma vez que você compra o voucher para fazer a prova, esse voucher não tem data de validade, ou seja, você pode comprar o voucher hoje e fazer a prova daqui 2 anos. 15 dicas para quem vai fazer a prova Leia o Scrum Guide, algumas vezes, pelo menos 2 vezes. Mas de preferência, leia mais do que 2 vezes. Estude o Scrum Guide. Imprima o guia, anote dúvidas, releia, rabisque. Leia o Glossário do Scrum – https://www.scrum.org/Resources/Scrum-Glossary pelo menos 1 vez. Veja os fóruns de conteúdo da Scrum.org. Evite buscar conteúdos fora, em outros sites, pois ele pode te ensinar algo que te atrapalhe. Se você está com mais tempo, aqui tem ótimos conteúdos direto da Scrum.org Lembre-se que você precisa ser um bom fazedor de prova. Entre na prova, tentando entender o que a questão quer te avaliar. Tem muita gente que sabe Scrum, mas é um mal fazedor de prova. Não contextualize durante a prova. Ele não quer saber como você faz no seu dia a dia o Scrum. Ele quer saber se você entendeu de verdade o Scrum. Por isso, não contextualize. Muitos times fazem o Scrum Zumbi, com disfunções no dia a dia. Por exemplo "Eu faço Scrum mas não tenho Product Owner" – chamamos isso de um time disfuncional, ou Scrum Zumbi. E o Scrum Zumbi é um caminho para chegar ao Professional Scrum. Mas na prova, ele quer saber se você conhece o Professional Scrum e não se você pratica o Scrum Zumbi. Faça o a prova Open Assessment da Scrum.org. É gratuita. Faça várias vezes essa prova, até conseguir tirar 100%, 3 vezes seguidas. Isso vai fazer você entender como funciona o modelo de perguntas da Scrum.org. Ao final de cada Open Assessment, você consegue ver os acertos e erros, e aprender com isso. Para quem não entende muito de inglês, usar o Addon do Google Chrome que traduz automaticamente a página. Por exemplo, entre no ScrumGuide em inglês, usando o Browser Google Chrome. Clique com o botão direito na página e vai aparecer a opção Traduzir. A tradução feita pelo Google Chrome é muito boa na minha opinião. Se você planeja fazer a prova dessa maneira, então: leia o Scrum Guide desse jeito, e faça o Open Assessemnt assim também. Ou seja, se prepare usando essa técnica de traduzir a página automaticamente, e depois faça a prova assim também Sugiro muito você fazer o curso oficial da Scrum.org, por alguns motivos 1) Você vai ganhar 2 voucher para fazer a prova (se fizer a primeira tentativa em até 14 dias e não passar, ganha a segunda chance gratuita); 2) Você vai aprender o Scrum direto de um Trainer da Scrum.org. Vai aprender com alguém “de lá de dentro”. 3) Você vai aprender o Scrum de verdade também. Não basta ter o PSM1, você precisa saber aplicar ele, e isso você só aprende no curso. Já vi muitas pessoas tirando a certificação por contra própria, e depois vindo fazer o curso oficial, pois está tendo problemas no mercado e no trabalho. Tome cuidado com simulados disponíveis por ai. Muitos deles, tem perguntas até parecidas com a prova oficial, mas muitas vezes com respostas erradas. Eu recomendo muito esse simulado aqui, pois é feito por um PST da Scrum.org. Os demais simulados, eu não recomendo, pois as vezes vai até te confundir. Garanta que você estará 60 minutos tranquilo e com internet. Uma vez que você começou a prova, você não pode parar. de preferência, deixe um celular com internet roteando, caso precise de um backup para sua internet você não é monitorado durante a prova, mas não dá tempo para acessar sites ou consultar. Ou você sabe ou não sabe. Ao final da prova, na hora, você já sabe se passou ou não. Ele não te fala quais perguntas você errou. Ele apenas te mostra um relatório consolidado com as áreas de conhecimento, e o % de acerto em cada área. As principais áreas são – Scrum Framework, Teorias e Princípios, Auto Organização e Coaching e Facilitação Em cada pergunta, você pode marcar para “Revisão” (bookmark em inglês). Se no final da prova, você tiver com algum tempo sobrando, você pode voltar nessas questões marcadas para Revisão, e tentar reler e rever a pergunta. Atenção ao número de respostas solicitadas. As vezes têm perguntas de múltipla escolha, solicitando 3 opções por exemplo, e a pessoa escolhe apenas uma opção como resposta. Acaba errando de bobeira a pergunta. Se está em dúvida, elimine as respostas erradas, antes de tentar achar a resposta certa. Não escondi nenhuma informação – deixei meu conhecimento bem transparente. Boa sorte na prova, e vamos mudar o mercado, criando melhores Produtos!

On today’s episode of YOUR DAILY SCRUM: Why won’t the Developers attend the Daily Scrum? A past student left us a comment in our Slack channel asking how to get the Developers on their Scrum Team to attend the Daily Scrum. This is a common issue that many Scrum Masters face. Fortunately, it is an easy problem to solve. Watch as Todd and Ryan break down this situation and expose many common reasons that Developers do not attend the Daily Scrum. One reason is that the Scrum Team had allowed the Daily Scrum to become a status meeting. Status meetings are boring. We’d skip them too! {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/qf0tVl6ttdY.jpg?itok=nUyKebFd","video_url":"https://youtu.be/qf0tVl6ttdY","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Ryan Ripley and Todd Miller are the author of Fixing Your Scrum: Practical Solutions to Common Scrum Problems. They are the co-founders of Agile for Humans, the premiere Scrum and Kanban training organization.

On today's episode of YOUR DAILY SCRUM: Where does a Project Manager fit on a Scrum Team? We get this question pretty often,..