Tagged: ágil

Investing on Knowledge: Scaled Agile by empowering people

I start this post based on SAFe problem with over-standardization in my linkedin post. So to not lock-in your company in a “comercial-methodology” I will share my vision regarding agile adoption and scale. In my vision if you want to scale your agile adoption to the enterprise level you have to invest on knowledge and empowering people. Just copy and past a method can harm your organization by frustrating people, lock-in vendors, and limiting the knowledge creation.

. “Scale can be about people” – Nilofer Merchant

You know what knowledge is but lets revise the term knowledge, according to dictionary knowledge is: Facts, information, and skills acquired through experience or education; the theoretical or practical understanding of a subject. So knowledge is something we can create everyday from our experiences and it need to be address by the company as a high valuable asset.

Important:

“Value is not what you know; it’s how what you know benefits someone else”  – Dave Ulrich

I mean by invest on knowledge are:

  • Create knowledge: Make your organization think about methodologies not only agile but lean, axiomatic, waterfall. Make collaboration teams!  Look beyond word documents by enabling people to create create blogs, papers, documents, procedures, flows, workflows,  talks, videos, discussions, brownbags, meetings.
  • Share knowledge: Enable Social experience! All information need to be shared across the entire organization. People need to have all sorts of tools to do it. Incentive the modification and adaptation of the knowledge.  Stop to use only email to propagate information. Emails as main communication channel is a dead end. Confluence and Yammer are options.
  • Free knowledge: Open the knowledge silos. Open the policies to all non sensitive document be viewed inside the company. Share to other teams. Create a blog space for employees. Incentive the creative ones to speak publicly about it. Send cases to conferences. Some companies manage to open to general public some of their knowledge.
  • Keep knowledge: People will produce a lot things, some are valuable assets for the company. Try to classify the information and check the potential value for the efforts produced. Some maybe turn to patents $$$. why not? So understand the knowledge produced is a key learning activity for the company.
  • Recycle knowledge: Experience new approaches and suggestions. Ask for cross groups reviews. Don’t put only one person to handle the decisions or print all the information in a heavy branded document. It need to be organic. Try to mashup things, fire emails, send updates via conference calls, make data sheets, games. Be multimedia.

I hope in the future I will have time to study the scientific background of knowledge in organizations, however I know it is another MSc or PHd subject.

Rotina do Product Owner

PProduct Owners (Donos do Produto ou PO) tem responsabilidades diárias com o time de desenvolvimento como revisão, planejamento, detalhamento, e discussões. Product Owner são responsáveis pelos requisitos de software (Epics, Features, Stories). Esta responsabilidade é de ponta-a-ponta do ciclo de vida do software. Os requisitos de software mais granulares são chamados Stories  em um projeto que utiliza metodologia ágil (Scrum, SAFe, DaD, …).

Neste post vou comentar sobre a rotina de um PO. Os exemplos são reais e mostram como é a prática em um ambiente de projetos ágeis. Você terá que adaptar para o seu contexto. Aqui temos o conceito como MVP, Scrum, SAFe, Comunicação Assíncrona, Times remotos e multiculturais. Vou tentar explicar cada um deste pontos.

O primeiro tópico é sobre a rotina do PO. Mais especificamente a rotina de acompanhamento das Stories sendo desenvolvidas pelo time.

Rotina Matinal do PO

Minha rotina quando estou usando o chapéu de PO é a sequinte:

  1. Verificar se existe alguma dúvida ou impedimento (On Hold or Blocked). 
    1. Caso Exista, responder ou direcionar a melhor forma de resolver o assunto.
    2. Indicar prioridade da Story (On Hold) sobre novas Stories no backlog, caso necessário.
  2. Verificar o que está pronto (In Review).
    1. Caso o teste resulte em Bugs ou Comportamentos não esperados então é indicado para o Dev o cenário.
    2.  Caso o teste resulte em novos casos não especificados anteriormente é criado novas Stories para o proximo Sprint.
    3. Caso tudo está como esperado é respondido um OK :-) .
  3. Verificar Backlog
    1. As prioridades continuam as mesmas?
      1. Caso Sim, então não é necessário mexer nas prioridades.
      2. Caso Não, então é necessário mover as Stories mais importantes para o topo da lista do backlog.
    2. Existem tarefas até o fim do Sprint?
      1. Caso sim, garanta que estas Stories tem os detalhes necessários.
      2. Caso não, Verifique com a equipe se é importante adicionar mais stories no backlog.

Com os passos comentados você garante que o time pode iniciar o dia sem impedimentos e alinhados com os objetivos comuns. O proximo passo é a preparação das próximas iterações (Sprints), vou escrever sobre isto na próxima alteração.

Preparando as Próximas Stories

… próximo tema …

Cenários Esperados ou Erros Comuns

… próximo tema …

 

Ultima alteração: 27 Out 2015

Gostou? útil? Então por favor faça um Like, Retweet, Share ou comentário no Twitter,  ou LinkedIn.