Tenho visto uma onda de pensamentos modernos sobre como iniciar uma transição ágil. Modernos se estivéssemos na década passada. Parece que voltou a "moda" de que o Scrum seria uma boa porta de entrada dos métodos ágeis nas empresas. Apesar de respeitar quem pense dessa forma, eu tenho as minhas dúvidas. Para esse post, chega de rapidinhas.
quinta-feira, 11 de julho de 2013
quarta-feira, 3 de julho de 2013
Transição Ágil x Evolução Ágil
Muito tenho discutido ultimamente sobre o uso do termo transição para indicar um processo de mudança do processo tradicional para o processo moderno de desenvolvimento de software.
Como transição entendemos uma mudança do estado A para o estado B. No nosso caso, da cultura tradicional para a cultura moderna de gerenciamento de softwares.
Os defensores do termo "evolução" argumentam que não conseguimos definir um ponto B claro. Que na verdade o processo é mais evolutivo que transicional. Como eu já disse em alguns fóruns de discussão (e em discussões de mesa de bar), não acho que essa abordagem esteja incorreta. Mas também não acho que usar o termo transição esteja. O motivo é bem simples: eu costumo definir de forma clara o ponto B.
O ponto B, na minha visão, ocorre quando a empresa tem consciência de que é um sistema complexo, valoriza a descentralização, a auto-organização e tem clara ciência do processo de melhoria contínua evolutivo, de como ele ocorre e o que precisa fazer para fomentá-lo. E neste momento, acontece a mágica, aconteceu a transição.
A empresa não precisa mais de um consultor para indicar que é necessário um diagnóstico contínuo do processo. Não precisa de um consultor para dizer que precisa identificar a restrição no sistema. Não precisa mais de um consultor para dizer que é preciso submeter o sistema à restrição. A empresa, como "entidade" se tornou um Jonah. Existe um capítulo inteiro no livro do Goldratt, Theory of Constraints, sobre como se tornar um Jonah. Estou pensando em escrever sobre esse capítulo, pois procurei referências para linkar aqui e não encontrei. Se algum leitor desse singelo espaço conhecer/encontrar, fique a vontade para colocar nos comentários.
Como a transição, na maioria dos casos, acontece como uma evolução do ponto A para o B, os conceitos se intercalam. Eu não passo a adotar o termo evolução em vez de transição porque transição me remete a algo infinito e, na minha visão, o trabalho de um bom consultor/consultoria deve ser finito. O consultor precisa ser capaz de deixar a empresa independente, sendo capaz de conduzir a sua própria evolução, seu próprio processo de melhoria contínua. Quando a empresa acordar para o kaizen e souber como conduzi-lo, a transição estará terminada e teremos apenas a evolução.
Enfim esta é a justificativa do motivo pelo qual uso o termo transição e vou continuar usando, pois ninguém ainda me convenceu a não usar.
Como transição entendemos uma mudança do estado A para o estado B. No nosso caso, da cultura tradicional para a cultura moderna de gerenciamento de softwares.
Os defensores do termo "evolução" argumentam que não conseguimos definir um ponto B claro. Que na verdade o processo é mais evolutivo que transicional. Como eu já disse em alguns fóruns de discussão (e em discussões de mesa de bar), não acho que essa abordagem esteja incorreta. Mas também não acho que usar o termo transição esteja. O motivo é bem simples: eu costumo definir de forma clara o ponto B.
O ponto B, na minha visão, ocorre quando a empresa tem consciência de que é um sistema complexo, valoriza a descentralização, a auto-organização e tem clara ciência do processo de melhoria contínua evolutivo, de como ele ocorre e o que precisa fazer para fomentá-lo. E neste momento, acontece a mágica, aconteceu a transição.
A empresa não precisa mais de um consultor para indicar que é necessário um diagnóstico contínuo do processo. Não precisa de um consultor para dizer que precisa identificar a restrição no sistema. Não precisa mais de um consultor para dizer que é preciso submeter o sistema à restrição. A empresa, como "entidade" se tornou um Jonah. Existe um capítulo inteiro no livro do Goldratt, Theory of Constraints, sobre como se tornar um Jonah. Estou pensando em escrever sobre esse capítulo, pois procurei referências para linkar aqui e não encontrei. Se algum leitor desse singelo espaço conhecer/encontrar, fique a vontade para colocar nos comentários.
Como a transição, na maioria dos casos, acontece como uma evolução do ponto A para o B, os conceitos se intercalam. Eu não passo a adotar o termo evolução em vez de transição porque transição me remete a algo infinito e, na minha visão, o trabalho de um bom consultor/consultoria deve ser finito. O consultor precisa ser capaz de deixar a empresa independente, sendo capaz de conduzir a sua própria evolução, seu próprio processo de melhoria contínua. Quando a empresa acordar para o kaizen e souber como conduzi-lo, a transição estará terminada e teremos apenas a evolução.
Enfim esta é a justificativa do motivo pelo qual uso o termo transição e vou continuar usando, pois ninguém ainda me convenceu a não usar.
terça-feira, 2 de julho de 2013
Rapidinha - Será que você sabe o que é um silo?
Hoje vi algo que me deixou preocupado. Em uma comunidade que fala de agilidade, vi o assunto silo surgir de uma forma estranha. Silos em nada se parece com divisão de frentes de trabalho. Silos não se comunicam, silos são isolados. Divisão em frentes de trabalho é uma forma de lidar com a complexidade: descentralização.
Quando estamos lidando com sistemas complexos, quanto mais centralizamos decisões e ações, caminhamos a passos largos para o caos. Da mesma forma, se você acredita que ser multidisciplinar é ter um bolo de atividades e um bolo de pessoas "puxando", você também me parece caminhar a passos largos para o caos.
Multidisciplinaridade pode (e deve) acontecer com frentes de trabalho. Trazendo um pouco dos conceitos do Kanban para este post, se temos um limite ideal do work-in-progress, alguém ficou ocioso e não pode puxar mais nenhuma atividade, esse alguém vai ajudar na etapa do processo onde o gargalo apareceu. Essa técnica também tem um pé na teoria das restrições:
Como eu prometi, esse post seria uma rapidinha. Discussões serão muito bem vindas nos comentários.
Até a próxima.
Quando estamos lidando com sistemas complexos, quanto mais centralizamos decisões e ações, caminhamos a passos largos para o caos. Da mesma forma, se você acredita que ser multidisciplinar é ter um bolo de atividades e um bolo de pessoas "puxando", você também me parece caminhar a passos largos para o caos.
Multidisciplinaridade pode (e deve) acontecer com frentes de trabalho. Trazendo um pouco dos conceitos do Kanban para este post, se temos um limite ideal do work-in-progress, alguém ficou ocioso e não pode puxar mais nenhuma atividade, esse alguém vai ajudar na etapa do processo onde o gargalo apareceu. Essa técnica também tem um pé na teoria das restrições:
- Identify the system's constraint(s) (that which prevents the organization from obtaining more of the goal in a unit of time)
- Decide how to exploit the system's constraint(s) (how to get the most out of the constraint)
- Subordinate everything else to the above decision (align the whole system or organization to support the decision made above)
- Elevate the system's constraint(s) (make other major changes needed to increase the constraint's capacity)
- Warning! If in the previous steps a constraint has been broken, go back to step 1, but do not allow inertia to cause a system's constraint.
Como eu prometi, esse post seria uma rapidinha. Discussões serão muito bem vindas nos comentários.
Até a próxima.
Assinar:
Postagens (Atom)