Não há nada errado com os líderes, mas algumas vezes me preocupa que o pessoal do Ágil sinta um nervosismo em relação a liderança, porque eles tem medo que isso se torne uma pessoa dizendo a outra: faça isso e depois aquilo, então com certeza não vamos querer um líder técnico porque ele pode começar a dizer as pessoas como as coisas tem que ser feitas.
O problema aí é que não existe um bom treinamento de liderança naquela organização e se existem esses tipos de organizações (e não tenho dúvida de que existem), eles tem problemas e falta de bom treinamento, não só para o pessoal, mas também para os gerentes, mas eu não vou gastar meu tempo e energia me preocupando com esse tipo de organização, eu creio que o mercado irá cuidar delas. Entende?
O que eu realmente procuro são organizações saudáveis e o que elas deveriam estar pensando em fazer. E quando entro em uma empresa não gosto de imaginar que é uma bagunça. Quando entro em uma empresa gosto de pensar que é uma organização saudável com uma boa liderança e eu encontro muito isso.
Eu não tenho tanta certeza de que existem todas essas organizações disfuncionais, ou talvez eu tenha as pessoas certas conversando comigo, não sei. Mas eu não faço essa presunção, eu acho errado dizer que um ScrumMaster nunca deveria codificar e que ele não deve ser nenhum tipo de líder; que ele não deve dar nenhuma orientação, ajuda ou assistência. Apenas jogar um grupo de pessoas numa sala e dizer: “organizem-se”...
Ok, você sabe que fizemos isso no início dos anos 90, no movimento pela qualidade, havia todos aqueles times de auto-gestão e aprendemos muito. Aprendemos que eles às vezes funcionam, por um curto período de tempo, mas eles não são um ambiente sustentável, porque não há um mecanismo para lidar com “e se eles não funcionarem?”, você entende, o que fazer com isso?
Não há um mecanismo para fornecer orientação e liderança que são muito importantes para o pessoal Junior.
Então eu acho que definitivamente não gosto dos papéis que o SCRUM tem. Não gosto do papel do ScrumMaster porque ele interfere com outros papéis importantes: o líder técnico e o líder funcional.
Não gosto do papel do dono do produto (Product Owner) porque ele fica de fora, ele é um intermediário entre o time de desenvolvimento e o cliente, então não gosto de nenhum desses papéis. É isso.
Eu gosto de conceitos gerais, mas gosto de ver o verdadeiro processo clássico de aperfeiçoamento de processos.
Em todas essas áreas o que eu acho que precisamos fazer é imaginar isso, olhar para o que uma boa empresa pode fazer e não para o que precisamos fazer para empresas ruins. De qualquer modo é o que eu prefiro fazer
Tom Poppendieck: Existem três palavrões: um deles é negócios, como Mary disse na mesa-redonda, negócios significam que o grupo de desenvolvimento não é parte do negócio, está separado, e isso na verdade quer dizer que nós não entendemos nada de negócios. Nós deveríamos pensar sobre o nosso negócio, não sobre “negócios”, que é o primeiro palavrão.
O segundo é projeto. Um projeto, por definição, tem um início e um fim e deve trazer um resultado. Ele é estabelecido inicialmente, e quando alguém te dá um monte de dinheiro vai querer saber o que vai obter por esse dinheiro, então você é forçado a fazer uma projeção em um momento quando está mais ignorante sobre o que é necessário fazer com o problema que está tentando resolver. Pensar no projeto leva a uma grande fração da disfunção que sofremos no desenvolvimento de softwares; deveríamos pensar em termos de produto não em termos de projeto. Produtos não terminam se forem bem sucedidos, eles continuam, permanecem, são aperfeiçoados, o time do projeto fica com o produto. A medida de sucesso de um produto é sua quota no mercado e seu rendimento, isso importa.
A medida de sucesso de um projeto é a projeção de custo, que é totalmente irrelevante. Você pode estar totalmente dentro de sua projeção de custo e não vender nada – será um desastre. Você pode ultrapassar muito o orçamento, vender uma quantidade tremenda, e o gasto extra será irrelevante. Assim, esse comportamento métrico não tem nada a ver com os verdadeiros objetivos de organização da nossa organização.
O terceiro palavrão é requisito. Requisitos não existem. Bem, existem as leis matemáticas e a legislação, talvez, mas no sentido que a maioria de nós usa a palavra requisito, eles não existem. Requisitos são decisões determinadas por alguém que não deixa que as pessoas que irão implementá-los tenham nenhuma participação, e dessa forma eles são disfuncionais, porque as pessoas que os implementam tem contribuições importantes e valiosas.
Se as pessoas que estão implementando, os desenvolvedores, tiverem um conhecimento de primeira mão do problema que estão tentando resolver eles farão escolhas diferentes, irão influenciar, farão que o que for colocado no produto seja diferente do que o que uma pessoa sem competência técnica faria.
E isso é levado para todo o time, todo o time deve estar envolvido na descoberta do produto, não apenas alguém que define os requisitos, não apenas o dono do produto, mas todos devem contribuir com sua perspectiva.
Agora isso não quer dizer que não hajam pessoas mais focadas em uma ou outra área, mas todos devem estar envolvidos, e é nesse envolvimento que você encontra paixão, esse envolvimento é a compreensão da diferença que você faz nas pessoas para quem trabalha, é de onde vem a paixão, é de onde vem o orgulho que faz o trabalho valer a pena.