»
S
I
D
E
B
A
R
«
The good is the enemy of the good enough
Jan 3rd, 2011 by Joca

Everybody knows the phrase “the perfect is the enemy of the good” attributed to Voltaire. But sometimes even “good” is way too much for what is needed, i.e., “the good is the enemy of the good enough”.

The

The search for quality

The search for quality can go on forever because there’s always space for improvement. In software development we know this and that’s why we have agile methodologies, which have the terms “early and frequent delivery” in two of their principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

source: Principles behind the Agile Manifesto

There are other two quotations, from Coding Horror blog, that remind us why “the good is the enemy of the good enough”:

Version 1 sucks, but ship it anyway.

If you aren’t embarrassed by v1.0 you didn’t release it early enough.

Fast iterations give us rapid feedback, so we can correct course and make the software as close as possible to customer requirements

Lessons learned

  • Version 1 sucks, but ship it anyway.
  • If you aren’t embarrassed by v1.0 you didn’t release it early enough.
  • The good is the enemy of the good enough.
1 person likes this post.

Let's use the "reduce, reuse, recycle" motto when writing software
Nov 2nd, 2010 by Joca

When my 4 years old daughter likes a song, she asks me to repeat the song over and over. I believe this is no news for any parent… 😛

This weekend’s song was “Reduce, Reuse, Recycle” by Jack Johnson. Below is a clip of the music where Jack sings the song with some children. I set the video to start at the beginning of the music:

Whenever I hear this music I think about code and how the “reduce, reuse, recycle” motto should be applied to writing software:

  • reduce: as written by the 37signals guys in their Getting Real book, “Less software is easier to manage. Less software reduces your codebase and that means less maintenance busywork (and a happier staff). Less software lowers your cost of change so you can adapt quickly. You can change your mind without having to change boatloads of code. Less software results in fewer bugs. Less software means less support.”
  • reuse: as defined in Wikipedia, “is the use of existing software, or software knowledge, to build new software.” and includes the use of libraries, frameworks and design patterns.
  • recycle: in the physical world “recycling involves processing used materials (waste) into new products to prevent waste of potentially useful materials, reduce the consumption of fresh raw materials, reduce energy usage” (source: Wikipedia). When I read this definition of recycle it immediately reminds me of another R used in software development, refactor. “Code refactoring is the process of changing a computer program’s source code without modifying its external functional behavior in order to improve some of the nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve the maintainability of the source code, as well as a more expressive internal architecture or object model to improve extensibility.” (source: Wikipedia).

Lessons learned

  • So the next time you are writing software, don’t forget to “reduce, reuse, recycle“! 🙂

Reuse, reduce, recycle

Reuse, reduce, recycle

9 people like this post.

Qual a diferença entre gerir um projeto e gerir um produto?
Aug 2nd, 2010 by Joca

Nos meus posts recentes sobre acompanhamento de projetos ágeis e o uso de burnups acabei me deparando com algumas questões mais “filosóficas” sobre produtos, projetos, gestão de produtos e de projetos e os papéis de PO (product owner) e scrum master nas metodologias ágeis.

Projetos e produtos

Projetos e produtos

Definições

Primeiro algumas definições básicas:

A project in business and science is a collaborative enterprise, frequently involving research or design, that is carefully planned to achieve a particular aim.

Fonte: http://en.wikipedia.org/wiki/Project

The noun product is defined as a “thing produced by labor or effort” or the “result of an act or a process”, and stems from the verb produce, from the Latin prōdūce(re) ‘(to) lead or bring forth’.

Fonte: http://en.wikipedia.org/wiki/Product_(business)

Ou seja, enquanto o projeto é um processo com começo, meio e fim, o produto é o resultado de um processo, de um esforço.

Então gerir projetos e gerir produtos são duas funções distintas?

Parece que sim. Enquanto se está gerindo um projeto, a preocupação é com o processo e com tudo o que o cerca, ou seja, se está no prazo, se tem os recursos necessários e se está sendo feito conforme esperado (qualidade e escopo).

Por outro lado, quando se gere um produto, a maior preocupação é, ou pelo menos deveria ser, garantir que produto resolve um problema do cliente a quem esse produto é destinado.

Em um post de 2007 do blog How To Be A Good Product Manager, o autor Jeff Lash lembra alguns pontos importantes que não devemos esquecer quando pensamos em gestão de projetos e gestão de produtos:

  • Just like every product needs a product manager, every project needs a project manager.
  • Just because product managers think they can manage their own projects does not mean they should.
  • The skills, talents, and traits involved in project management are very different from those involved in product management.
  • Just like it is hard to find one single person who can fill the product management role and the product marketing role, it is hard to find one person who can be successful at both the product management and the project management role.
  • Project management is not a stepping stone to product management, nor vice versa.
  • Good project managers are just as valuable as good product managers.
  • Finding a good project manager to manage your projects will help you be an even better product manager.
  • The less time product managers spend on project management, the more time they will be able to spend on product management.
  • To avoid conflicts between product management and project management, product managers, project managers, and project teams should all agree on shared goals and objectives as much as possible.

Marty Cagan deixa claro a necessidade de separação desses papéis em um de seus posts:

For Internet services companies, it really is important that the roles be separate. You’ll thrash in release management if you don’t, and releases will consistently be delayed and take longer than they should.

E como as metodologias ágeis vêem essas funções?

As metodologias ágeis, mais especifcamente o Scrum, tem dois papéis claros no time, um focado mais no projeto, o Scrum Master e outro focado mais no produto, o Product Owner (PO):

[Scrum] Roles:

Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.
ScrumMaster: The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits.
Team: A cross-functional group of people responsible for managing itself to develop the product.
Scrum Team: Product Owner, ScrumMaster and Team

Fonte: http://en.wikipedia.org/wiki/Scrum_(development)

Há um artigo na InfoQ com o título “Can Product Owner and Scrum Master be Combined?” em que o tema de ter um única pessoa gerindo projeto e produto é discutido. Tanto nas opiniões que compõem o texto e que incluem testemunhos de pessoas como Mike Cohn e Ken Schwaber, quanto nos comentários do texto é unânime que apesar de ser possível combinar as duas funções e, se o time for muito pequeno, ser até aceitável, o mais recomendado é que essas funções sejam desempenhadas por pessoas diferentes.

Resumindo

  • Gerir um projeto é garantir que o processo está fluindo da melhor forma possível, dentro do prazo, com os recursos disponíveis e atingindo os objetivos de escopo e qualidade definidos. Ou seja, gerir projetos é olhar para dentro da organização.
  • Gerir um produto é garantir que o resultado de um processo satisfaça as necessidades do cliente. Ou seja, gerir produtos é olhar para fora da organização.
  • É possível e, se o time for muito pequeno (até 5 pessoas), pode ser até aceitável combinar as duas funções. Contudo, o mais recomendado é que essas funções sejam desempenhadas por pessoas diferentes.
2 people like this post.

Protótipos de baixa fidelidade, croquis, simplicidade, Gantt e burnup
Jul 26th, 2010 by Joca

Essa semana tive a oportunidade de conversar com Gil Barros, um profissional muito experiente de design de interação e de arquitetura da informação, que está fazendo doutorado na FAU-USP sobre prototipação e o uso de croquis.

…croquis (palavra francesa eventualmente aportuguesada como croqui ou traduzida como esboço ou rascunho) costuma se caracterizar como um desenho rápido, feito com o objetivo de discutir ou expressar graficamente uma idéia…

O que costuma ser mais importante no croquis é o registro gráfico de uma idéia instantânea, através de uma técnica de desenho rápida e descompromissada.

fonte: http://pt.wikipedia.org/wiki/Croquis

Ele comentou que vê pouca gente se valendo do desenho feito à mão para mostrar ideias e que, por achar essa opção como uma das formas mais ágeis de comunicacão, resolveu dedicar seu doutorado a esse tema.

Eu já havia comentado sobre a importância dos rascunhos, ou protótipos feitos à mão, no post “Protótipo: primeira impressão” e no post “Mais um exemplo de protótipo de baixa fidelidade“.

O que me atrai nos protótipos de baixa fidelidade e em croquis de forma geral é sua simplicidade inerente. Quem me conhece sabe que sou fã da simplicidade, tanto que já escrevi sobre o tema no post “Simplicidade” e em um outro post onde comento sobre um site de 1 única página.

Semana passada, quando escrevi sobre as vantagens do uso dos gráficos de burnup como opção aos Gantt Charts para acompanhamento do andamento de projetos, acabei não comentando de uma das vantagens mais óbvias do burnup: o burnup é mais simples que o Gantt Chart pelo simples fato de que burnups podem ser feitos à mão. Já o Gantt Chart é muito difícil de ser feito à mão.

A prova disso é a busca de imagens do Google. Experimente pesquisar por Gantt Chart e por burnup chart.

Logo na primeira página da pesquisa por imagens de burnup chart são 4 gráficos feitos à mão. Já na pesquisa por Gantt Chart, não encontrei nenhum…

Burnup

Burnup feito à mão

Outro exemplo de burnup

Outro exemplo de burnup feito à mão

Burn down que aparece na busca por imagens de burnup

Burn down feito à mão que aparece na busca por imagens de burnup

Mais um exemplo de burnup

Mais um exemplo de burnup feito à mão


Be the first to like.

Acompanhamento de projetos ágeis
Jul 19th, 2010 by Joca

Na gestão de projetos tradicional existe o famoso Gantt Chart que permite saber com precisão quanto tempo um projeto vai levar, quanto tempo demorará cada tarefa do projeto, que tarefa depende de qual tarefa e se alguma atrasar, o que acontece com o projeto.

Gantt chart

Gantt chart


O Gantt Chart não se aplica a contento para projetos de software que usam metodologias ágeis pois ele pressupõe o conhecimento completo de todas as tarefas e fases do projeto antes de seu início, enquanto que nas metodologias ágeis “responder às mudanças tem mais valor que seguir um plano”, ou seja, as metodologias ágeis entendem que mudanças sempre vão acontecer e que o melhor a fazer é estar preparado para as aceitá-las.

O cone da incerteza

Já que mudanças sempre vão acontecer, como podemos acompanhar um projeto ágil, saber qual é o prazo de entrega desse projeto e, ao longo do projeto, saber se ele está dentro do prazo? Mesmo antes das metodologias ágeis já existia o conceito do cone da incerteza que diz que a precisão das estimativas de prazo de um projeto é muito pequena no início do projeto e aumenta ao longo do tempo. Aliás, não só a precisão das estimativas de prazo, como também de custos e de escopo que, juntos com o prazo, são os três limitadores de todo projeto.

Cone da incerteza

Cone da incerteza

O cone da incerteza se aplica a qualquer projeto, quer ele use metologias ágeis ou metodologias de gestão de projetos mais tradicionais. Ou seja, mesmo tendo um Gantt Chart, no início do projeto não teremos precisão sobre seu prazo. O Gantt Chart passa uma falsa impressão de que está tudo sob controle, mesmo com todas as incertezas que existem no início de qualquer projeto.

Mas eu tenho que ter um prazo…

Contudo, mesmo levando em conta o cone da incerteza, é possível ter uma estimativa de prazos, nem que seja algo como “esse projeto vai ficar pronto em setembro” o que significa que ele pode ficar pronto em qualquer um dos 30 dias de setembro, ou “esse projeto será entregue no terceiro trimestre de 2011” o que dá 45 dias para mais ou para menos de margem de erro! 🙂

Prazos têm que existir e te que ser respeitados.

E não raro há casos em que prazo é fixado por quem pediu o projeto (“o site dessa promoção tem que ser publicada até 15 de julho pois nesse dia teremos uma campanha direcionando para esse site”). Nesses casos nos sobram escopo e recursos para mexer sendo que às vezes adicionar mais recursos não faz o projeto andar mais rápido.

De qualquer forma, tanto tendo um prazo fixo (“15 de julho”) quanto podendo dar estimativas um pouco mais abertas (“em setembro”, “terceiro trimestre de 2011”), é preciso saber se estamos dentro do prazo para podermos tomar decisões (trazer mais gente? reduzir escopo? negociar mais prazo?).

Como fazer acompanhamento de projetos ágeis?

Projetos ágeis podem fazer uso de gráficos burnup para podermos ter melhor visibilidade de seu andamento. Não estou falando dos gráficos burnup de cada iteração, que interessam apenas à equipe que está tocando o projeto, mas sim um burnup do projeto inteiro que trará informações úteis para todas as pessoas interessadas nesse projeto.

Veja o exemplo do gráfico abaixo:

Burnup

Burnup

Nesse exemplo temos uma definição inicial do esforço necessário para terminar um determinado projeto que teria começado em 7/1/2008. O esforço necessário para concluir esse projeto é de quase 100 “xpto”, que está marcado na linha verde. Esse “xpto” pode ser pontos ou horas ou features ou o que quer que usemos para medir progresso de desenvolvimento.

Note no exemplo que nos dias 4/2, 18/2 e 31/3 houve aumentos do esforço necessário. Se não fossem esses aumentos o projeto estaria concluído até 24/3. Com os aumentos passou para 21/4, quase um mês de atraso.

A linha vermelha mostra a velocidade do time. A inclinação dessa linha é o indicativo da velocidade: quanto menor a inclinação, mais devagar o time e, consequentemente, o projeto está andando.

Por que um gráfico burnup como esse é importante?

Ele vai ajudar o time e todos os interessados no projeto a entender seu andamento. Esse gráfico deve andar junto com uma espécie de log para entendermos porque aumentou o esforço necessário, ou porque o projeto está andando mais devagar.

Não é necessário nenhum software especial para fazer esses gráficos. Uma planilha pode dar conta do recado, ou mesmo o bom e velho papel e lápis!

Normalmente o esforço necessário para entregar um projeto pode aumentar porque aumentou o número de funcionalidades a ser entregue (aumento de escopo) ou apareceram dificuldades técnicas não previstas. Esse esforço pode diminuir quando há diminuição do escopo do projeto.

Razões comuns para diminuição de velocidade do projeto são o surgimento de dificuldades técnicas não previstas ou a entrada de um projeto extra que está divergindo esforços da equipe ou ainda a saída de um ou mais membros da equipe antes do término do projeto.

Enfim, a idéia é conseguir ter maior visibilidade e, consequentemente, mais informações para que se possa intervir quando necessário para garantir a entrega dos projetos dentro do prazo estimado.

3 people like this post.

Gestão Ágil de Produtos
Jun 1st, 2009 by Joca

Acabou de ser publicado hoje, na InfoQ, um whitepaper que escrevi sobre Gestão Ágil de Produtos:

http://www.infoq.com/vendorcontent/show.action?vcr=581

Update: como o artigo não está mais disponível na InfoQ, estou disponibilizando-o aqui no blog.


gestaoagildeprodutos

Be the first to like.

Agile methodologies are processes, agile is culture
May 10th, 2009 by Joca

Posted originally in Portuguese at Locaweb’s AgilBlog

I recently read about agile culture and how some teams use only the processes embedded into the agile methodologies without absorbing the agile culture:

Doing some research on Wikipedia, I found:

  • Culture is “an integrated pattern of human knowledge, belief, and behavior that depends upon the capacity for symbolic thought and social learning”. It is also “the set of shared attitudes, values, goals, and practices that characterizes an institution, organization or group”.
  • Process is a “collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers. It often can be visualized with a flowchart as a sequence of activities”.

which means that while process is “how things get done”, culture explains “why things should be done that way”.

What matters the most is the culture, since without knowing “why” something should be done in some way it is very difficult to follow and maintain that way – the “how” to do those things.

We can have an agile culture without any methodologies. If we present the Agile Manifesto and its principles to someone who never heard of agile methodologies, is very likely that she end up creating some processes which enable the agile culture.

picture-23

On the other side, given an agile methodology like Scrum or XP, it is not easy to understand why this process should be followed. We can even see some benefits in the daily routine of software development but without knowing why we should follow this process, the probability that the process continues to be followed or, even more important, that the process evolves, are minimum.

scrumlargelabelled

That’s why it is so important to understand the agile culture before implementing any agile methodology

But culture change is a long term task, slow and difficult to measure. And any long term, slow and difficult to measure task is of little attractiveness. People look for the culture change benefits but are not willing to spend what is necessary to get to the results. That’s why we see the recipes.

Implementing methodologies and process changes are short term tasks, with great impact and easy to measure (graphs, points, etc.). That’s why we naturally prefer methodologies, the recipes.

It is very important to coordinate the methodology implementation and the process change in order to be sure they are not performed mechanically and that they are gradually inserted as a new organizational culture.

Coordinating the methodology implementation and the process change is not about knowing a lot about the topic and answering questions like “what should I do with the story points of this unfinished story?” or “should we estimate stories in points or hours?” or “should we use kanbam, lean, XP, scrum, …?” or …

This coordination must be in the direction of “agile thinking”. Agile methodologies are supposed to helps us think agile but many times it makes us stop thinking. :-/

Culture can only be changed through thinking, arguing, listening, experimenting.

Following recipes without thinking, arguing, listening and experimenting is a sure recipe for a mechanical implementation of the methodologies and a good chance of failure.

As mentioned in Outliers and in a very interesting Scientific American article, in order to be a specialist in anything we must practice in a thoughtful way and understanding what we are practicing and never execute the “blind practice”.

So in your next revision and planning meeting, or even during your daily stand up meeting, remember that prior to the methodologies comes the agile culture. Re-read with your team the agile manifesto and its principles and discuss the following topics:

  • why these principles are important to us?
  • what have we done to follow these principles?
  • are there any principles we do not follow? why?

Agile is culture, agile methodologies are the processes that help create this culture.

Would you like to read more about this topic? Please check other posts on agile and agile methodologies.

2 people like this post.

Metodologias ágeis são processos, agilidade é cultura
Apr 26th, 2009 by Joca

Publicado originalmente no AgilBlog da Locaweb

Recentemente li dois posts sobre a questão da cultura ágil e como alguns times usam apenas os processos embutidos nas metodologias ágeis sem absorver a cultura da agilidade:

Pesquisando na Wikipedia, encontrei as definições abaixo:

  • Cultura é um padrão integrado de conhecimento, crença ou comportamento humano que depende da capacidade de pensamento simbólico e de aprendizado social de um determinado grupo de pessoas. É também um conjunto de atitudes, valores, objetivos e práticas compartilhadas que caracterizam esse grupo de pessoas.
  • Processo é um cojunto de tarefas e atividades relacionadas que produzem um determinado produto ou serviço para um ou mais clientes de uma empresa. Pode ser visualizado com um fluxograma.

Ou seja, o processo é o “como” enquanto a cultura é o “porquê”.

Sem dúvida o que mais importa é a cultura, já que sem o “porquê” é muito mais difícil seguir e manter o respectivo “como”.

As metodologias ágeis, ou seja, os processos de desenvolvimento de software que as metodologias ágeis definem, são consequência da cultura ágil.

A cultura ágil consegue existir sem as metodologias ágeis. Se falarmos apenas no manifesto ágil e em seus princípios para alguém que nunca ouviu falar nas metodologias ágeis, é muito provável que essa pessoa acabe criando os processos necessários para viabilizar a cultura ágil.

picture-23

Por outro lado, dado o processo ágil, por exemplo o Scrum, é difícil entender o “porquê” esse processo deve ser seguido. Dá até para perceber que esse processo melhora o dia-a-dia do desenvolvimento de software, mas sem saber o “porquê” de o seguir, as chances de que o processo se mantenha ou, mais importante, de que o processo melhore, são bem baixas.

scrumlargelabelled

Daí a importância de entender a cultura ágil antes de implementar as metodologias ágeis.

Só que mudar cultura é tarefa de longo prazo, gradual e de difícil mensuração. E como toda tarefa de longo prazo, gradual e de difícil mensuração, é pouco atraente. As pessoas querem os resultados da mudança de cultura, mas não querem gastar o que é necessário para se chegar ao resultado. Daí a busca por receitas de bolo.

Implementar metodologias e mudar processos são tarefas de curto prazo, de impacto e de fácil mensuração (gráficos, pontos, etc.). Daí a preferência natural que temos pelas metodologias, pelas “receitas de bolo”.

É fundamental orientar a implementação das metodologias e as mudanças de processo para garantir que elas não se transformem em atos mecânicos e para que sejam gradualmente absorvidos como cultura da organização.

E orientar a implementação das metodologias e as mudanças de processo não é conhecer muito sobre o tema e fornecer respostas para perguntas do tipo “o que eu faço com os pontos dessa história que não acabamos nesse sprint?” ou “devo pontuar as histórias com pontos ou com horas?” ou “será que devo usar kanbam, lean, XP, Scrum, …?” ou …

A orientação que deve ser dada está em ensinar a “pensar ágil”. As metodologias ágeis são um auxílio para nos ajudar a pensar ágil mas muitas vezes, ao invés de nos ajudar a pensar ágil, nos faz não pensar. :-/

Só se muda uma cultura pensando, discutindo, argumentando, ouvindo, experimentando.

Seguir “receitas de bolo” sem pensar, discutir, argumentar, ouvir e escutar é receita certa para uma implementação mecanizada das metodologias e consquente fracasso.

Como dito no Outliers e em um artigo bem bacana de Scientific American, para ser um especialista em algo, devemos praticar de forma consciente, ou seja, sempre questionando e entendendo o que estamos praticando e nunca executar a “prática cega”.

Por isso, em sua próxima reunião de revisão e planejamento de sprint, ou mesmo na sua reunião diária, lembre-se que antes da metodologia ágil deve vir a cultura ágil. Releia junto com o seu time o manifesto ágil e seus princípios e discutam:

  • por que esses princípios são importantes para nosso time?
  • o que tem sido feito para seguir esses princípios?
  • onde não seguimos esses princípios e por que?

Agilidade é cultura, as metodologias ágeis são os processos que ajudam a sedimentar essa cultura.

Quer ler mais sobre o tema? Então veja outros posts sobre agilidade e métodos ágeis.

Be the first to like.

O papel da gerência em times ágeis
Apr 7th, 2009 by Joca

Há quase um ano atrás eu comentei sobre a mudança do papel do gerente em um time que resolveu adotar metodologias ágeis. Na London QCon 2009 foi apresentada a palestra Managers in Scrum de Roman Pichler, um consultor inglês especializado em gestão ágil de produtos.

A apresentação completa pode ser vista em:

http://www.infoq.com/presentations/managers-in-scrum

Quem quiser ver só os slides, pode baixá-los aqui.

Vou destacar 4 slides que resumem a apresentação. Primeiro um slide que mostra como funciona a gerência tradicional:

Em seguida um slide que ilustra como deve ser a gerência em um ambiente ágil:

Uma comparação entre o processo de padronização antes e depois do uso de metodologias ágeis e o papel do gerente nesse processo:

E, por último, um resumo:

Vale conferir essa apresentação.

Be the first to like.

Como ter times super produtivos?
Mar 20th, 2009 by Joca

Texto muito interessante da infoQ sobre como ter times super produtivos:

http://www.infoq.com/news/2009/03/hyper-productive-team

Aliás, esse texto é um resumo de 4 artigos sobre Group Coherence de Joanna Zweig e Cesar Idrovo publicados Agile Journal baseados em uma pesquisa feita por eles:

Ao contrário do que reza a lenda, não basta só ter certeza que a máquina de café esteja funcionado…

Vou fazer como a infoQ e vou colocar abaixo um resumo do resumo! 🙂

Primeiro a motivação:

“Group characteristics and group dynamics are invisible to most of us. We are not trained to detect them, let alone manage them. Our work is influenced by much more than what we see. This can make project success (and failure) sometimes appear to be random.”

Em seguida, uma definição:

“Group Coherence is the shared state reached by a group of people that allows them to perform one or more tasks in perfect rhythm and harmony with great energy to overcome obstacles. This simplistic interpretation is a starting point for discussion and we acknowledge that it doesn’t begin to do justice to all the interdisciplinary components of Group Coherence that include behavioral, psychological, spiritual and sociological.”

E depois vêm as constatações (os destaques são meus):

“In our continuing search for Hyper-Productivity, we have observed that a strong and highly adaptable shared sense of Common Purpose can increase the group’s ability to execute on the project vision or enterprise strategy.”

“The hyper-productive teams we have observed apply high rates of practical collaboration. We believe that fostering Collaborative Interaction leads to increases in productivity, yet performance is recognized at the individual rather than team level. In environments where collaboration is required, managers should avoid assigning project work and accountability to individuals.”

“Creative achievement is typically associated with individual effort. Think of Newton, Edison, or Leonardo Da Vinci. Until not very long ago, creativity and design were the focus of a few, while the work of the masses was broken down into repeatable steps. Creativity was perceived to undermine the result of mass-production.

Today, the work depends on the design and creative skills of the knowledge workers that perform it. In this post, we explore the different ways in which Agile methods foster individual creativity and allow for something far less commonly acknowledged: group creativity. We discuss four attenuators and five amplifiers of group creative activity.”

Abaixo estão os 4 atenuadores:

  1. Specialization “blinders”
  2. Micromanagement
  3. Chaos avoidance
  4. Pre-determined truth

E os 5 amplificadores:

  1. Create Opportunities for Practice
  2. Reward Teams
  3. Tolerate Chaos
  4. Socratic questioning
  5. Shared Leadership

E a conclusão:

“In hyper-productive teams there are high levels of group creativity despite functional specialization. These are groups that are willing and allowed to experiment. Group Coherence can help understand the ingredients that can be observed when this happens. In the research these include Trust and Respect, Bonding, Loosening Boundaries, Shared Leadership, Agreement on a Shared Goal and Tolerance for Chaos. These formed the basis for this post. They cannot guarantee an earlier or more dynamic occurrence of group creativity, but their absence can prevent or delay its emergence.

They are also all available to Agile teams.”

Be the first to like.

»  Substance: WordPress   »  Style: Ahren Ahimsa