Legi, intellexi, condemnavi.

Caberia muito bem a frase do Apóstata Juliano II, para apresentar o Ágil para os gerentes da “escola normal”. Após oito anos trabalhando no desenvolvimento de software de missão crítica e num mundo ágil, ninguém me tirava da cabeça que aquela abordagem poderia de fato ir para o mundo corporativo, área para a qual “me mudei” após o Estado iniciar o processo de sucateamento das Armas.

Pergunto-me frequentemente os tantos “li, entendi, rejeitei” que ouvi ao explicar técnicas ágeis. Veio-me à mente meu próprio passado, onde tantas vezes me fiz um Juliano, quando me apresentavam um VSAM, com suas “trees”, DBase e Clipper e seus DBFs,… rejeitava-os por achar que sistemas de tempo real não combinava com Database (storages) e comecei a ter ojeriza dos coitados, e de fato comecei a usá-los em meados de 1994. Quase dez anos trabalhando em software de controle e automação industrial (PLC, Realtime, microkernel, assembler, C) e o Ágil (XP) era um companheiro, e, acredito piamente que ele nunca me traiu.

Normalmente os testes de missão crítica (sistemas de defesa, reatores nucleares e suporte à vida) são minuciosamente programados e visando o preditivo, que seria algo como “quando acontecer”, em oposição ao “se acontecer”. Normalmente um sujeito (observe que não uso a palavra desenvolvedor) treinado em ágil vai engolir sem mastigar qualquer outra técnica, e por que? Simples, o cérebro do agilista não questiona modelos, ele simplesmente age incondicionalmente; nesse momento todo um organismo, braços, olhos, cabeça, fala, se coordena automaticamente na solução; o agilista não pensa no problema. Um bom agilista sem nenhum esforço, atinge, num momento de crise qualquer um, pois sua abordagem deixa perplexos os observadores e “chama pra dentro” os capazes, todos querem de alguma forma dar sua contribuição, todos querem dar um pouco de si, todos estariam dispostos a sacar fora um pedaço de banha (pigs?) e também a quebrar os ovos (chickens?), afinal a atmosfera é funesta, estamos em risco de vida, ou acerta ou morre… e o tempo é pouco, e as penas vão literalmente pelos ares; comprometimento implícito. Assustados? A narrativa acima aconteceu, e tantas vezes me questiono se outra abordagem não Ágil, me deixaria agora escrever esse.

Ok, esqueçamos o drama ilustrativo e diminuamos a escala de perigo e demo-nos somente os últimos quatro anos, assim a gente começa um cenário Ágil mais ameno, moderno. Continuo afirmando que existe espaço para todos e uma futura convergência é inevitável e já acontece (PMI Ágil), e isso é bom. Isso mostra que estamos sempre errados, já que buscamos sempre uma melhora nesses processos.

Agora a célebre frase seria “li, não compreendi, rejeitei” – e fico triste -, “li, compreendi, fiquei com medo”… do modismo, dessa inferência a olhos vistos?

Ao surgir uma ideia nova que simplifica e funciona, que agiliza, e principalmente porque simplifica e agiliza, encontra uma resistência compreensível, pois implica quase que afirmar a obviedade, e o óbvio é uma coisa muito, mas muito complexa de entendimento. Pior, o óbvio implica uma aceitação de uma cultura, de um novo modus operandi, e isso não é pouco. Absorver uma cultura nova implica em mudança de hábitos, aquilo que nos faz, aquilo que nos identifica, isso é o que nos indica a conformidade, uma aliança, uma aceitação. Ao aceitar, passa-se a compreensão, logo em seguida procura-se os preceitos, para em seguida iniciar o processo de incorporação puro e simples. Agora você acredita, é um converso, faz parte de sua crença, com seus acertos e erros, está “doutrinado”. Incorporado então, ele começa um processo de maturação, e logo em seguida iniciar um processo preditivo individual, ora, isso implica em busca, em pesquisa, em treinos, simulações, ele se prepara para o “quando”.

Agilidade é algo inverso a uma zona de conforto,… por que mudar? As pessoas tendem a associar agilidade com adrenalina, com correria, com sandices e outras aberrações. É o inverso, acreditem. Como dito acima, o preditivo no Ágil, aquilo que era esperado, “quando acontecer”, aconteceu, eu estava preparado, esperando, não foi uma fatalidade… já existia algo, uma carta na manga, esperando o acontecimento, estava em hot stand by, não somente em stand by. O agilista observa o ecossistema, procurando algo que “encaixe” na sua cultura e até incorpora técnicas em artes marciais (dojo, kata), o inesperado é absorvido com impacto reduzido, concentrando esforço não no ataque, mas na defesa, o mais certeiro possível, rápido e preciso.

Aprecio essa pluralidade agilista, com suas adjetividades, que esbraveja jovialidade, criatividade e vontade de mudanças, de sair da mesmice, de um sistema ou modelo completamente comprometido com formalidades. Alguns itens devem ser ajustados ou melhor compreendidos, como o foco nos desejos do cliente, em detrimento à engenharia e arquitetura de software,… estamos focando o cliente e deixando esquecido o desenvolvimento de software? Não espero isso para o Scrum, por exemplo. Acho que alguns itens de qualidade deveriam ser incorporados, como um simples 5S, visando a organização pessoal e do próprio framework ágil. Algumas boas ideias estão se mantendo, outras sendo engolidas ou enquadradas por conjunto de conhecimentos em gerenciamento de projetos (PMI), que é algo mais abrangente em gerência de projetos, enquanto que o Ágil (quase) se limita ao desenvolvimento de software, apesar de ter raízes no Lean.

As vezes penso que o mal maior do agilista é o entusiasmo pela “religião” que ele agora é um converso e, qualquer afobação gera desconfiança para seus reais resultados. Também espero que essa exposição demasiada do Scrum não o deixe tão extasiado, levando-o a sucumbir sob o peso da própria agilidade, que é afinal, seu grande mérito. Leia, compreenda, aceite-o, mas deixe alguma água no poço, mostre-o como uma alternativa.

Wooof!

10 Suggestions for the Architect of an Agile Team

Tom Hollander, a Solutions Architect at Microsoft Australia, held a presentation entitled The Role of an Architect in an Agile Team at TechEd Australia where he discussed  what he does as an architect leading an agile team.

When talking about the role of an architect, Hollander means a “solution architect’ or an application architect. He does not refer to an enterprise architect or a specialist one (specialized on a specific field like messaging or infrastructure).

Hollander’s team has a 4 week iteration process with a stabilization period – code freeze for a few days – at the end, practices daily stand-up meetings, continuous integrations with daily builds followed by automated tests, and is employing a number of roles:

  • PjM – is the Project Manager, similar to a Scrum Master, making sure the team is following the process.
  • PdM – is the Product Manager, also known as the Customer or the Product Owner, determining what the product is supposed to be
  • Architect – a solution/application architect
  • Dev – the development team
  • Test – the test team
  • UX – the User Experience team
  • Release – the Build and Release role taking care of the building process

Hollander has come up with a top 10 list of things for a solution architect to be successful in an agile team:

  1. “Just enough” upfront design – except for very simple projects, a certain amount of upfront design – 1-2 weeks – is absolutely needed based on what type of application is – web app, smart client, mobile or batch –, what are the basic functionality requirements, a long term solution or an intermediary, temporary one. The purpose of the upfront design is to decide: what technology to use – for example, ASP.NET or MVC –, what type of application – a 2-tier, a 3-tier or a service-oriented application –, accessing the DB – stored procedures, Entity Framework, LINQ, DI. All that can be contained in a short document for reference.
  2. Start with a vertical slice – means starting with a small piece of functionality – a logon page, for example – which cuts as many vertical layers as possible in order to tie together all the technology pieces decided during the previous phase. This will demonstrate that the design decisions are correct and all pieces are working together, and will represent a pattern for developers to follow when developing the additional code. If the initial design decisions turn out to be inappropriate, now it is a good time to change them.
  3. Just-in-time design each iteration – At the middle of a 4-week iteration, the project manager, the product manager and the architect should meet to discuss the requirements to be addressed during the following iteration, to make sure they all agree on them, what is more important is put up in front, and everything is understood. That discussion goes on for a week in the background of the current iteration. The following week, the last of the current iteration, the architect reviews the requirements for the next iteration, making the necessary design decisions so the team can start working on them the following week. If the requirements are quite different from previous ones, then the architect does some prototyping, writing some code as a proof of concept, writing some diagrams and putting it all together in a 5-page document for reference. This is not meant to do detailed design decisions made for the developer, but rather to make sure the new requirements fit into the big picture.
  4. Trust your team… but be there for them – this has to do with the relationship architect-developer. The architect needs to make sure he does not overstep his role, making the developer’s job boring by taking all the fun of decision making. In the same time, the architect needs to be a mentor for the team, solving difficult problems that might bog down the developers. The architect should be in contact with every developer each day, knowing what they are doing and helping them if there is a coding problem. This is especially needed when dealing with developers that don’t like to ask for help and try to solve problems on their own with the price of spending an entire week with that. This kind of relationship also applies to the PjM and test/build/release team.
  5. Write code! – The architect should know what’s in the code in order to have a better idea on the impact of his decisions. He can also figure out when a refactoring is needed. A code writing architect has better credibility with the development team. That being said, Hollander does not believe in role dissolution. He still thinks an architect remains an architect, and he’s not necessarily as good at writing code as a regular developer.
  6. Be involved in everything – It is good for the architect to be involved in all meetings related to his project: design, development, code reviews, requirements planning, etc., because he can have a larger and more clear perspective on what is going on, and he can help the product manager to avoid making wrong decisions in an early stage by informing him/her on their possible outcome.
  7. Drive a culture of quality – A successful team, one that anyone would like to be part of is one built on a culture of quality: nobody cuts corners, nobody checks-in sloppy code, if there is a major flaw in the design it won’t pass unnoticed, all are honest and open, looking for the best outcome of the entire team. Hollander admits that it is hard to build such a team, but it is possible. Firstly, the architect should establish some rules in the beginning, rules are are not going to change over time because a developer happens to not like them. One example is the decision to write unit tests. Another is having a code review before each check-in, including the code submitted by the architect. If the code is not accepted by the reviewer, which can be anybody in the team, the code is not checked-in.
  8. Know when changes are required – The architect should be very flexible and ready to make design changes when they are required. It may be that an early solution is no longer appropriate, or new requirements demand a different approach.
  9. Shield the team from external randomization – While this is usually the job of a project manager/Scrum master, the architect can get involved in protecting the team from external requests that tend to divert the team’s focus and take time from actual work. One example could be various requests coming from the operations team wanting certain things to be done in a certain way, and their requests are not always reasonable or something that has to be implemented.
  10. Write docs … but only if someone needs to read them – Hollander is not the adept of documenting everything, nor one of writing no documentation. He thinks there is necessary to have a balance, writing the amount of documentation that is actually helpful and is read by someone. Documents are good to remember detailed design decisions like a data model. Iteration design decisions, while they are discussed with the team at the beginning of the iteration, it is recommended to be saved in a 5-pages document for the developers to go to if one of them does not remember what the architect said. This also helps new people working on the project long after the initial developers and architect moved to another project to understand why some of the decisions were made.

As a conclusion, Hollander said the architect should make sure he is part of the team in theory and in practice. The architect is not supposed to write all the code, only a small portion, he is not testing or deploying it, but he is rather making sure the entire process runs smoothly.