Capítulo 2 - As origens do scrum
Naquela época eu era apenas um jovem piloto rezando para sobreviver às missões designadas a mim. Eu não sabia que a minha experiência nessa função e o treinamento que recebi sobre como pensar e agir em situações de vida ou morte definiriam o modo como eu trabalharia pelo resto da vida. p. 14 - Acerca da Guerra do Vietnã
A história do autor como pano de fundo. A guerra, sua formação acadêmica em Stanford
Para isso, passei anos tentando descobrir o que acontecia quando uma célula se tornava cancerosa. Aprendi muito sobre teoria de sistemas e como um sistema apresenta apenas determinados estados estáveis. Quando uma célula evolui, ela passa de um estado estável para outro. Dediquei quase dez anos para descobrir as regras para transpor um sistema adaptativo complexo de um estado para outro, e como fazer com que o próximo estado fosse positivo em vez de negativo. Ibid
Anos mais tarde, ocorreu-me que organizações, equipes e pessoas constituem sistemas adaptativos complexos. Os elementos que fazem com que uma célula passe de um estado a outro são os mesmos que movem as pessoas. Para mudar uma célula, é necessário, primeiro, injetar energia no sistema. Primeiro temos o caos — parece não haver regras, tudo está no fluxo. Quando você faz isso em organizações como uma tentativa de mudança, as pessoas costumam se apavorar, não conseguem entender o que está acontecendo e não sabem como agir. No entanto, de forma bastante rápida, assim como ocorre com as células, a organização entra em um novo estado estável. A única questão é se o novo estado é melhor do que o antigo. A célula é cancerosa ou saudável? Eu me perguntava como podemos descobrir algumas regras simples que possam guiar as equipes a entrar em um estado mais produtivo, feliz, incentivador, divertido e arrebatador? Passei os quinze anos seguintes tentando descobrir a resposta. p. 15
Uma das coisas que precisam ficar claras é que precisamos filtrar o que é storytelling do que não é. Isso são histórias de condução a um determinado assunto
Durante o governo Reagan, as verbas destinadas à pesquisa científica foram drasticamente cortadas, incluindo as destinadas ao estudo do câncer realizada pelos National Cancer Centers, onde eu trabalhava como analista dos dados coletados nos estudos clínicos e epidemiológicos do Colorado Regional Cancer Center. Enquanto eu pensava no que fazer, uma empresa chamada MidContinent Computer Services entrou em contato comigo porque ouviram dizer que eu era o principal especialista na área da mais nova tecnologia da empresa. A MidContinent trabalhava prestando serviços para 150 bancos na América do Norte e seu mais novo e desejável produto chamava-se “Caixa Automático de Autoatendimento” (ATM, na sigla em inglês), ou caixas eletrônicos. Estávamos em 1983, quando sacar dinheiro significava ficar em uma fila no banco ou passar de carro em um drive-through bancário, quando você precisava preencher um cheque para “sacar” a quantia que queria e entregá-lo ao caixa. Os caixas eletrônicos seriam a solução, mas, naquela época, a empresa enfrentava problemas para fazer suas redes se comunicarem entre si. Eles precisavam de alguém que conhecesse sistemas, então me fizeram uma proposta lucrativa para ser o vice-presidente de sistemas avançados. As máquinas que formavam a rede de computadores eram iguais às que eu passara anos rodando os meus programas de doutorado, então, eu era uma boa opção. Ibid
É importante notar aqui as motivações que levam a um novo estado. Hoje um caixa eletrônico aqui no Brasil é quase desnecessário visto que o Pix substitui isso. Mas em 1983 com pouca informatização do sistema, o dinheiro era sacado direto no caixa ou num drive through (no melhor estilo McDonalds!).
Decidi que a melhor opção seria mudarmos tudo. A operação estava defeituosa demais para ser consertada de forma gradual; assim, decidi criar uma empresa dentro de uma empresa. Pedi ao nosso CEO, Ron Harris, que me deixasse montar uma organização separada com todos que estavam envolvidos nas redes ATM. Teríamos a nossa própria equipe de vendas, nossa própria equipe de marketing e nosso próprio departamento financeiro. Ron era um CEO brilhante e criativo que confiava no meu trabalho. Talvez sob a direção de outra pessoa, isso nunca tivesse contecido. Depois de ouvir a minha ideia, ele disse: “Sutherland, se você quer uma dor de cabeça dessa, fique à vontade”. Ibid
A ideia é pegar o que não está funcionando e transformar.
Então, comecei a dirigir uma pequena empresa como uma equipe dividida em subequipes. Os bônus não tinham como base o desempenho individual, mas sim o desempenho da empresa como um todo. Descobrimos ferramentas que abriram o caminho até o Scrum dez anos mais tarde — por exemplo, os conceitos de Dono do Produto (Product Owner), Pendências do Produtor (Product Backlog) e Sprints semanais, os quais abordarei em mais detalhes mais adiante. Em seis meses, éramos a divisão mais lucrativa da empresa, e a receita era 30% mais alta do que os custos. Os nossos sistemas Nonstop Tandem constituíram os primeiros computadores de transações on-line que os bancos tiveram confiança o suficiente para usar, então nós os distribuímos por toda a América do Norte. Hoje, você encontra caixas eletrônicos praticamente em qualquer lugar do país, e cada um deles sabe exatamente quanto dinheiro você tem. A minha equipe teve muito a ver com isso. E, sim, você pode agradecer. Ibid.
Isso significa que ele só conseguiu desenvolver a ideia a partir de um novo tipo de conceito.
Depois da minha experiência na carreira militar seguida pela carreira acadêmica, eu me considerava meio que um intruso no mundo dos negócios. No entanto, aquela perspectiva constituiu um dos meus ativos mais valiosos. Desde o primeiro dia, eu não conseguia entender por que as pessoas insistiam em trabalhar de uma forma que sabiam que era ineficiente, destrutiva, desumanizadora e depressiva. Acho que elas imaginam que, se todo mundo trabalha assim, então essa deve ser a melhor forma de se trabalhar. Ibid
Eu tenho um amigo que fala que depois de ver não dá pra desver!
E, em 1993, levei aquelas ideias comigo para uma empresa chamada Easel, que me contratara como vice-presidente de tecnologia. Os executivos queriam que a minha equipe desenvolvesse uma nova linha de produtos em seis meses, a qual seria oferecida a alguns dos seus maiores clientes — como a Ford Motor Company, que usava o software deles para desenvolver e construir aplicações internas. Reuni-me com a minha equipe de desenvolvimento e disse que sabia que eles não conseguiriam fazer aquilo usando o mesmo modelo antigo de desenvolvimento de software. p. 17
Então, eu disse a ele que entregaria um software em perfeito funcionamento no final do mês, em vez de um digrama de Gantt não cumprido. Ele mesmo poderia testá-lo para verificar se estávamos no caminho certo. E teríamos de estar se quiséssemos cumprir nosso prazo. Ibid
Já é a ideia da Sprint
The New New Product Development Game - Hirotaka Takeuchi e Ikujiro Nonaka (artigo)
Fiquei tão animado com as possibilidades dessa nova forma de gerenciamento de projetos que todo o meu trabalho futuro se concentrou no refinamento do Scrum para as empresas. Em 1995, apresentei um artigo com Ken Schwaber, intitulado “SCRUM Development Process” [Processo de desenvolvimento SCRUM], o qual sistematizava tais práticas em uma conferência de pesquisa da Association for Computing Machinery. Ibid
SCRUM Development Process - Ken Schwaber (artigo abaixo)
Uma vez que o Scrum se baseia em técnicas utilizadas na indústria japonesa, vale a pena conhecer um pouco sobre onde os japoneses a aprenderam. Ironicamente, muitas delas foram ensinadas por um americano: W. Edwards Deming, que trabalhava para o General Douglas MacArthur durante a ocupação americana no Japão depois da Segunda Guerra Mundial. A abordagem de MacArthur para reconstruir a economia consistia em demitir a maioria dos altos gerentes nas empresas japonesas, promover os gerentes de produção e importar dos Estados Unidos especialistas em operações de negócios, como Deming.
A influência de Deming na indústria japonesa foi incrível. Ele treinou centenas de engenheiros no que chamamos de “controle de processo estatístico” baseado em uma ideia simples de medir exatamente o que estava sendo feito, sua qualidade e lutar por um “aprimoramento contínuo”. Não basta melhorar uma vez, é preciso fazê-lo constantemente. Sempre procure algo que possa ser aprimorado. Nunca, jamais, conforme-se com o lugar onde está. A maneira como você atinge seus objetivos é sempre experimentar, até que consiga perceber se atingiu um ponto mais alto. Se eu tentar esse método, o resultado será melhor? E quanto a esse outro? E se eu mudar esse pequeno detalhe? p. 18
O Scrum é bem parecido com isso. Exige prática e atenção, mas também um esforço contínuo para chegar a um novo estado no qual as coisas apenas fluem para que todo o resto aconteça. Se você já assistiu a um grande dançarino ou ginasta, sabe que seus movimentos parecem ser realizados quase sem esforço, como se não estivessem fazendo nada, apenas existindo. Melhor, a impressão que se tem é que eles não poderiam ser nada além daquilo que são naquele momento. Eu passei por uma experiência assim quando um pequeno mestre de aikido me lançou facilmente no ar e de uma forma que fez com que eu caísse gentilmente no tatame, como seu eu fosse um bebê sendo colocado, com carinho, em um berço. Ibid
Artigo - SCRUM Development Process - Ken Schwaber (paper PDF)
SCRUM assumes that the systems development process is an unpredictable, complicated process that can only be roughly described as an overall progression. SCRUM defines the systems development process as a loose set of activities that combines known, workable tools and techniques with the best that a development team can devise to build systems. Since these activities are loose, controls to manage the process and inherent risk are used. SCRUM is an enhancement of the commonly used iterative/incremental object-oriented development cycle. [p.1 Abstract]
O scrum adiciona colaboração entre partes ao invés de contratos fechados.
SCRUM is a management, enhancement and maintenance methodology for an existing system or production prototype. It assumes existing design and code which is virtually always the case in object-oriented development due to the presence of class libraries. [p. 3]
Systems are developed in a highly complicated environment. The complexity is both within the development environment and the target environment. For example, when the air traffic control system development was initiated, three-tier client server systems and airline deregulation did not have to be considered. Yet, these environmental and technical changes occurred during the project and had to be taken into account within the system being built. [Ibid]
Many of the development processes are uncontrolled. The inputs and outputs are either unknown or loosely defined, the transformation process lacks necessary precision, and quality control is not defined. Testing processes are an example. [p. 4]
O modelo cascata
O modelo espiral
Aqui dá pra ver que antes do SCRUM já existia um esforço em resolver um problema crônico da industria sobre insatisfação com desenvolvimento de software.
Given the complex environment and the increased reliance on new "state-of-the-art" systems, the risk endured by system development projects has increased and the search for mechanisms to handle this risk has intensified. [p. 7]
One can argue that current methodologies are better than nothing. Each improves on the other. The Spiral and Iterative approaches implant formal risk control mechanisms for dealing with unpredictable results. A framework for development is provided. [Ibid]
The system development process is complicated and complex. Therefore maximum flexibility and appropriate control is required. Evolution favors those that operate with maximum exposure to environmental change and have optimised for flexible adaptation to change. Evolution deselects those who have insulated themselves from environmental change and have minimized chaos and complexity in their environment. [p.8]
The primary difference between the defined (waterfall, spiral and iterative) and empirical (SCRUM) approach is that The SCRUM approach assumes that the analysis, design, and development processes in the Sprint phase are unpredictable. A control mechanism is used to manage the unpredictability and control the risk. Flexibility, responsiveness, and reliability are the results. [p. 10]
The Sprint phase is an empirical process. Many of the processes in the sprint phase are unidentified or uncontrolled. It is treated as a black box that requires external controls. Accordingly, controls, including risk management, are put on each iteration of the Sprint phase to avoid chaos while maximizing flexibility.
Sprints are nonlinear and flexible. Where available, explicit process knowledge is used; otherwise tacit knowledge and trial and error is used to build process knowledge. Sprints are used to evolve the final product. [p. 10]
Página 11 - Tabelas de diferenças entre metodologias
Planning Development of a comprehensive backlog list. Definition of the delivery date and functionality of one or more releases. Selection of the release most appropriate for immediate development. Mapping of product packets (objects) for backlog items in the selected release. Definition of project team(s) for the building of the new release. Assessment of risk and appropriate risk controls. Review and possible adjustment of backlog items and packets. Validation or reselection of development tools and infrastructure. Estimation of release cost, including development, collateral material, marketing,training, and rollout. Verification of management approval and funding.
Architecture/High Level Design Review assigned backlog items. Identify changes necessary to implement backlog items. Perform domain analysis to the extent required to build, enhance, or update the domain models to reflect the new system context and requirements. Refine the system architecture to support the new context and requirements. Identify any problems or issues in developing or implementing the changes Design review meeting, each team presenting approach and changes to implement each backlog item. Reassign changes as required.
Development
Meeting with teams to review release plans. Distribution, review and adjustment of the standards with which the product will conform. Iterative Sprints, until the product is deemed ready for distribution.
Sprint Review
The whole team and product management are present and participate. The review can include customers, sales, marketing and others. Review covers functional, executable systems that encompass the objects assigned to that team and include the changes made to implement the backlog items. The way backlog items are implemented by changes may be changed based on the review. New backlog items may be introduced and assigned to teams as part of the review, changing the content and direction of deliverables. The time of the next review is determined based on progress and complexity. The Sprints usually have a duration of 1 to 4 weeks
Scrum Controls
Controls in the SCRUM methodology are: Backlog: Product functionality requirements that are not adequately addressed by the current product release. Bugs, defects, customer requested enhancements, competitive product functionality, competitive edge functionality, and technology upgrades are backlog items. Release/Enhancement: backlog items that at a point in time represent a viable release based on the variables of requirements, time, quality, and competition. Packets: Product components or objects that must be changed to implement a backlog item into a new release. Changes: Changes that must occur to a packet to implement a backlog item. Problems: Technical problems that occur and must be solved to implement a change. Risks: risks that effect the success of the project are continuously assessed and responses planned. Other controls are affected as a result of risk assessment. Solutions: solutions to the problems and risks, often resulting in changes. Issues: Overall project and project issues that are not defined in terms of packets, changes and problems.
O paradigma da estimativa de projetos ⚠️
Models of empirical processes are derived categorizing observed inputs and outputs, and defining controls that cause them to occur within prescribed bounds. Empirical process modeling involves constructing a process model strictly from experimentally obtained input/output data, with no recourse to any laws concerning the fundamental nature and properties of the system. No a priori knowledge about the process is necessary (although it can be helpful); a system is treated like a black box. [p. 20]
In practice, at multiple companies over multiple projects within some companies, SCRUM has been observed to provide a viable solution these problems. Projects are delivered on time and often exceed the expectations of both users and management. While working on a SCRUM development team is intense, developers are rewarded by high team spirit, a deep sense of accomplishment, and a feeling that development can be an enjoyable and satisfying experience. [p. 21]
The new new product development Process
Hirota Takeushi, Ikujiro Nonaka
The rules of the game in new product development are changing. Many companies have discovered that it takes more than the accepted basics of high quality, low cost, and differentiation to excel in today's competitive market. It also takes speed and flexibility. [p.1]
This new emphasis on speed and flexibility calls for a different approach for managing new product development. The traditional sequential or "relay race" approach to product development exemplified by the National Aeronautics and Space Administration's phased program planning (PPP) system-may conflict with the goals of maximum speed and flexibility. Instead, a holistic or "rugby" approach-where a team tries to go the distance as a unit, passing the ball back and forth-may better serve today's competitive requirements. [ibid]
Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish. Rather than moving in defined, highly structured stages, the process is bom out of the team members' interplay (see Exhibit I). A group of engineers, for example, may start to design the product (phase three) before all the results of the feasibility tests (phase two) are in. Or, the team may be forced to reconsider a decision as a result of later information. The team does not stop then, but engages in iterative experimentation. This goes on in even the latest phases of the development process. [p.2]
A project team takes on a self-organizing character as it is driven to a state of "zero information"-where prior knowledge does not apply. Ambiguity and fluctuation abound in this state. [p.3]
Self-transcendence. The project teams appear to be absorbed in a never-ending quest for "the limit." Starting with the guidelines set forth by top management, they begin to establish their own goals and keep on elevating them throughout the development process. By pursuing what appear at first to be contradictory goals, they devise ways to override the status quo and make the big discovery. We observed many examples of self-transcendence in our field work. The Canon AE-1 project team came up with new ideas to meet the challenging parameters set forth by top management. The company asked the team to develop a high-quality, automatic exposure camera that had to be compact, light-weight, easy to use, and priced 30% lower than the prevailing price of single-lens cameras. To reach this ambitious target, the project team achieved several firsts in camera design and production: an electronic brain consisting of integrated circuits custom-made by Texas Instruments; modularized production, which made automation and mass production possible; and reduction in the number of parts by 30% to 40%. "It was a struggle because we had to deny our traditional way of thinking," recalled the head of the AE-1 team.
"But we do that every day in the ongoing parts of our business," responded another Canon executive. The entire organization makes daily, incremental improvements to strengthen what the president calls "the fundamentals": R&D, production technology, selling prowess, and corporate culture. [p.4]
The self-organizing character of the team produces a unique dynamic or rhythm. Although the team members start the project with different time horizons-with RSLD people having the longest time horizon and production people the shortest-they all must work toward synchronizing their pace to meet deadlines. Also, while the project team starts from "zero information," each member soon begins to share knowledge about the marketplace and the technical community. As a result, the team begins to work as a unit. At some point, the individual and the whole become inseparable. The individual's rhythm and the group's rhythm begin to overlap, creating a whole new pulse. This pulse serves as the driving force and moves the team forward.[ibid]
The sashimi system requires extensive interaction not only among project members but also with suppliers. The FX-3500 team invited them to join the project at the very start (they eventually produced 90% of the parts for the model). Each side regularly visited the other's plants and kept the information channel open at all times. This kind of exchange and openness-both within the project team and with suppliers -increases speed and flexibility. Fuji-Xerox shortened the development time from 38 months for an earlier model to 29 months for the FX-3500. [p. 5]
Multilevel learning. Learning at the individual level takes place in a number of ways. 3M, for example, encourages engineers to devote 15% of their company time to pursuing their "dream." Canon utilizes peer pressure to foster individual learning. A design engineer for the PC-10 project explained, "My senior managers and some of my colleagues really study hard. There is no way I can compete with them in the number of books they read. So whenever I have time, I go to a department store and spend several hours in the toy department. I observe what's selling and check out the new gadgets being used in the toys. They may give me a hint or two later on." [ibid]
These examples show the important role that multileaming plays in the company's overall human resource management program. It fosters initiative and learning by doing on the part of the employees and helps keep them up to date with the latest developments. It also serves as a basis for creating a climate that can bring ahout organizational transition. [p. 7]
Selecting the right people for the project team while monitoring shifts in group dynamics and adding or dropping members when necessary. "We would add an older and more conservative member to the team should the balance shift too much toward radicalism," said a Honda executive. "We carefully pick the project members after long deliberation. We analyze the different personalities to see if they would get along. Most people do get along, thanks to our common set of values." [ibid]
Tolerating and anticipating mistakes.Engineers at Honda are fond of saying that "a 1% success rate is supported by mistakes made 99% of the time." A Brother executive in charge of R&D said, "It's natural for young engineers to make a lot of mistakes. The key lies in finding the mistakes early and taking steps to correct them immediately. We've taken steps to expedite the trial production cycle for that reason." A 3M executive noted, "I helieve we learn more from tnistakes than from successes. That's not to say we should make mistakes easily. But if we do make mistakes, we ought to make them creatively." [ibid]
The drive to accumulate knowledge across levels and functions is only one aspect of learning. We ohserved an equally strong drive on the part of the project memhers to transfer their learning to others outside the group. Transfer of learning to suhsequent new product development projects or to other divisions in the organization takes place regularly. In several of the companies we studied, the transfer took place through "osmosis"-hy assigning key individuals to subsequent projects. A Honda executive explained, "If the factory is up and running and the early-period claims are resolved, we dismantle the project team, leaving only a few people to follow through. Since we have only a limited numher of unusually ahle people, we turn them loose on another key project immediately." [p.8]
It requires extraordinary effort on the part of all project memhers throughout the span of the development process. Sometimes, team members record monthly overtime of 100 hours during the peak and 60 hours during the rest of the project. [p.9]
Fim do Capítulo 2