Slide 15 - Mais por menos

Isto requer um processo iterativo, requer permitir que o cliente mude os requerimentos e requer permitir que nossa solução venha à tona através da auto-organização. Vou falar um pouco sobre isto porque esta é uma coisa difícil para a gerência, especialmente em uma empresa que tenha um tipo de hierarquia autoritária, de cima para baixo. “Você quer dizer que temos que deixar as pessoas fazerem o que quiserem e o software irá emergir, a arquitetura irá se auto-organizar. Você deve estar louco!”. Estamos loucos como a Toyota. Vou mostrar a vocês até onde a loucura pode levá-los! (risos)

Este é o diagrama que utilizamos no treinamento de certificação de ScrumMasters. Para um produto que irá necessitar de várias iterações até que seja lançado, temos uma fase inicial de planejamento e depois temos ciclos mensais (estes círculos verdes são os nossos ciclos mensais) e durante cada ciclo mensal temos reuniões diárias. Ao final de cada ciclo nós temos algum tipo de demonstração do software em funcionamento, na qual o cliente é envolvido e neste momento podemos tomar decisões que podem mudar nosso rumo. Em cada ciclo as pessoas que não estão envolvidas com o projeto devem ser mantidas longe dos desenvolvedores. Particularmente os gerentes não devem incomodá-los. Eles não podem molestá-los, atrapalhá-los ou minar sua produtividade. O que este slide mostra é o primeiro Scrum, que teve seis ciclos. Seis meses era o objetivo. Garantimos que a entrega seria feita a tempo e que o último email seria mais para o fechamento do produto. Uma vez que toda a funcionalidade estava lá, tudo estava funcionando, geraríamos o disco de ouro que seria enviado a milhares de clientes. Precisávamos realmente pisar no acelerador, fazer a documentação, o produto, mantendo a qualidade extrema neste último ciclo.

And that requires an iteractive process, it requires letting the customer change requirements, and it requires allowing our solution to emerge through self organization. I'm gonna talk a lot about that because this is a very hard thing for management, particularly in a hierarchical, authoritative, top down company. “You mean, we gotta let people do what they want and the software is going to emerge, and the architecture is going to self organize. You must be crazy!”. Ok? We're crazy like Toyota. We'll show you where crazy gets you! (laughs)

This is the diagram we use at the certified ScrumMaster training. We say, Ok, for a product that's gonna take several iterations to get out, we have a planning phase, initially, and then we have monthly cycles (these green circles are our monthly cycle), and during that monthly cycle we have daily meetings. And at the end of that cycle we have some kind of demonstration of working software that the customer is involved in and we can make decisions that change our direction at that time. And inside of those cycles, people who are not involved with the project are to keep out of the way of the developers. Particularly the managers, they can't bug them. They can't harass them, they can't disrupt them and they can't undermine their productivity. So, this one shows, this was the first Scrum actually, it had this six cycles. Six months was a goal. It was guaranteed to be delivered on time, and the last cycle was more of a packaging cycle. Once we got all of the functionality there, once it was all working, then for that product, we had to generate the gold disk that was gonna go out to thousands of customers. So we really needed to turn the heat up, making the documentation, the product, the quality air tight in that last cycle.