Open Agile Iasi - live blogging in the afternoon

16.10 Q&A session: concluziile mele din discutii:
Agile cannot be implemented without the cultural paradigm change.
Pentru a creste calitatea interactiunilor, este necesar sa cresti cantitatea si calitatea feedbackului. Feedback continuu.
Pentru a adopta agile cu clienti non-agile, vorbeste despre asta.
Agile inseamna ca fiecare sa isi asume mai multe responsabilitati.
Programatorii sunt niste rasfatati! Ma alatur parerii. Sunt si eu cumva un rasfatat.
Cei din tarile nordice au in cultura nationala incluse ideile de a lucra in consens, iar in scoala le sunt asignate teme impreuna.Cum dracu' sa aplici lean daca nu poti sa stingi lumina fara sa iti zica seful?


Si foto (merci, Oana!)

15.10 Andrea Provaglio - KEY SPEAKER The beating heart of Agile

Vorbeste despre "Humanistic side of software development"

• Software-ul este intangibil, la fel ca si muzica. Exista numai cand "il canta" cineva. In rest, e doar e o reprezentare statica a unei intentii. Softistii lucreaza cu idei!
• Software-ul este collaborativ. Nu ajunge un singur creier sa termini proiectele la timp pentru un proiect complex.
•  A scrie software este o explorare. Mai mica sau mai mare.
•  Sistemele educationale (inventate nu mai mult de 200 de ani in urma) influenteaza tipul de comportament.
• Sistemele actuale educa oamenii in loturi. In lotul 1979, in cazul meu. Ca pe o linie, de productie.
• evaluarea este individuala, si mai niciodata legata de o performanta a grupului.
• Sprints are feedback loops. Nu putem face totul perfect de fiecare data. Sunt diferite metode de a introduce feedback loops.
• Constant learning and adjusting. I like that !!!
•  Teams are systems 
• Una tare: In the long run, the only sustainable source of competitive advantage is your organization ability to learn faster than the competition Peter Senge
• 12manage.com :Fifth discipline : System Thinking. Celelalte sunt : Personall Mastery, Mental Models, Building shared vision, team learning. All together, Learning organization. 
• Oricine este influentat de faptul ca lucreaza intr-o echipa. Big me in a team.
• The organic mind : o alta perspectiva, diferita de tehnica is logica.Oamenii si interactiunile definesc rezultate.Analogiile si conexiunile pot transcende logica imediata.
•  Collective intelligence : complexitatea cere cresterea inteligentei colective a echipei. Un exemplu: ce facea un 286 in 90' si ce face un smartphone acum. Eu nu am reusit sa ma destept atat de mult in 20 de ani.
• Andrea spune ca echipele mixte de proiect (femei si barbati) au o inteligenta colectiva mai buna
• Grupurile care au oameni cu inteligenta sociala ridicata au o inteligenta colectiva mai mare. 
• Be ready to make mistakes and learn out of it (asta e de la mine, dar prilejuita de discutie)
• Self-organization is built into Agile
• Team reflects from time to time how to adjust its performance. This shall be inline with a business goal.
• Auto organizarea se refera la realizarea tehnica. Auto organizarea nu se refera la scopurile de business. How to work, not what to work.
• Better than empowerment is emancipation. Emancipation cannot be taken back.
• Self organization can be enabled, not organized. 
• WRAP_UP: Individuals and teams are defined by the nature of their interactions
• We learn, from feedback, from others. 
• Collective intelligence helps us tackle the increasing complexity. 

Excellente skilluri de prezentare. Accent californian.Mai trebuie sa adaug si verbe. Asta a facut si Andrea
Individuals and interactions. ==> Individuals are interactions.


14.35 |am avut o sesiune interesanta de discutii despre subiecte aduse de participanti.
Am participat la o sesiune despre Lean/Kanban si una despre Scrum of Scrums.

Lean este un principiu care se orienteaza ca oamenii sa elimine ineficienta, sa aduca valoare si sa imbunatateasca practicile in mod continuu.
despre Scrum of Scrums, am aflat ca este o metoda de a organiza proiecte foarte mari. Ma intereseaza sa aflu mai mult!!! Carmen Munteanu este urmatorul speaker. Este parte din Alcatel si este internal coach pentru Agile acolo.


What I've learnt? // CARMEN MUNTEANU

Idei despre adoptia metodelor Agile or Lean.

All for one and one for all - primul lucru care faciliteaza adoptia acestor idei. Toate nivele trebuie sa contribuie, de la developeri pana la CEO.
Communicate the change - unde vrei sa ajungi, toate lumea trebuie sa stie unde vrei sa ajungi. Celebreaza succesele si anunta-le.
Toata lumea trebuie sa fie educata. Software, testing, dar si toate celelalte functii (vanzari, HR, purchasing / achizitii, real estate). Cel mai important este sa nu uiti sa educi si clientii.
Echipele e bine sa cunoasca practicile de agile. Aceeasi idee ca si la Stefan Bargaoanu. Exmple de practici : continous integration. TDD, Code Cleanu, refactoring. Sunt diferite tehnici de invatare, dar e important e sa fie si distractiv, dar si la momentul oportun. Nu exista timp de invatare, daca nu este "furat". S-au dezvoltat idei cum ar fi Coding Dojo, Code Retreat.


 

O idee interesanta : Project management by Objectives nu se potriveste cu Agile.
Apropo de organizarea cladirii: nu toate birourile sunt echipate pentru Agile sau Kanban.

Continously adapt! pare a fi in linie cu Adapt or die! (vezi Moneyball).
Auto-organizarea este unul din principiile importante ale Agile. Corect, aduce valoare de la toti membrii, nu doar de la sefi.

Read More...

Open Agile Iasi - live blogging

mai mult, dupa amiaza aici 
[12:10] Ionel Condor despre Agile Career Development. Vorbeste despre un subiect care ma pasioneaza.

Prima idee de la el: "Love what you are doing"
Altceva in care cred: cum sa recunosti diamantul in noroi sau intr-o gramada de sticla.

Ce fel de traininguri iti ofera o companie? de toate, depinde de firma,  dar nu e foarte simplu sa le urmezi pe alea semnificative pentru tine.

Cate companii pot sa vorbeasca despre "unde vei fi tu peste 10 ani"?
Sunt cazuri in companii care nu nu mai ofera Career Paths, tehnologia se schimba prea mult
Si una de la mine: un plan de cariera inseamna sa fii pregatit pentru cat mai multe schimbari.


Ionel spune si despre ce favorizeaza succesul in cariera. Am selectat: leadership, networking, passion. drive.

De asemenea, cateva cuvinte despre modelul de dezvoltare al lui Dreyfus.
Majoritatea practitionistilor sunt la nivelul advanced beginner.
Rules are not for everyone, they are mostly good to novices. 

Ce mai buna metoda de a invata este de a ii invata si pe altii. 

 Specialist sau generalist? Specialisti pe cateva directii pare a fi cea mai buna directie.Balansarea directiilor de specialist si generalist. De asemenea, a prezentat cum au pregatit setul de competente pe care il doresc sa il implementeze in companie si care sunt metodele. Una dintre ele este sa pregatesti timp special pentru development. O idee geniala, in opinia mea, dar foarte greu de implementat.

Un alt principiu este sa petreci 40 de ore la munca si alte 20 de ore sa te pregatesti. Nu e usor de facut, mai ales cand vorbim si de familie.

Si cateva citate bune:
Winners do not carry losers.
If you think you are standing firm, be careful that you don't fall.
The brain rule: use it or lose it.


[11:30] Stefan Bargaoanu a inceput speach-ul. Jumatate din audienta este membra a Agile Meetup Iasi.Stefan este initiatorul evenimentelor in Iasi.

Start small or go all-in?

Cateva idei despre de ce ai incepe la scara mica.
- necesarul de training e mic
- poti facilita o poveste de succes (aduci oameni buni, concentrezi resurse)
- nu afectezi multe proiecte
- nu afectezi organizatia in ansamblu
Impact in organizatie: Schimbare de roluri, nume, tipuri de evaluare.

De ce ai incepe la scara mare:
- reducerea rezistentei la schimbare
- se poate aplica eticheta "we are an agile company"
- cand anunti public, exista o anume presiune de a reusi. De asemenea, poti proclama o viziune, de urmat pentru membrii echipei. Se creeaza un dialog pe aceasta tema...

Daca mergi "inchis", nu ai parte de rezistenta inutila pana nu gasesti o cale de a face deployment. Nu poti intampina rezistenta clientului care nu stie ce inseamna Agile.

Cateodata, esti obligat sa adopti Agile pentru ca te obliga clientul.
===========================================================================
Split and seed : incepe cu o echipa care sa invete. Nu vor fi perfecti, dar e o baza. Imparte-i apoi in 2-3 echipe, care sa inceapa alte proiecte. Si asa mai departe. Interesanta idee de la Stefan

Grow and split: variatie pe tema de mai sus: se adauga membri in echipa, pana cand se poate imparti, fara riscuri, echipa in mai multe echipe. Oamenii lucreaza mai mult timp impreuna si observa avantajele.

Internal coaching: cei care au inceput sa fie buni in Agile (SCRUM) ii invata si pe ceilalti. 

===========================================================================
Cat de repede sa incepi cu "technical practices" (adica ce este peste organizarea de baza a SCRUM), de exemplu, TDD? nu e de dorit sa amani prea mult, pentru ca se va modifica destul de greu practica initiala.

Stefan recomanda sa folositi consultanti, training ("professional help").Nici mentoringul nu e de aruncat. Cateodata iese si pentru o bere. Ca sa nu mai povestesc despre community of practitioners, de exemplu Agile meetup in Iasi. Sau PMI, local chapter.
Si cea mai tare chestie de azi: "There is no leader without the first follower". Merci, Stefan !
[10:45] Unit tests - the immune system of the product
O alta idee de baza este ca se investeste disproportionat in diferite tipuri de teste. Ceea ce vedeti mai jos este realitatea. Ideal ar fi invers.

Un citat tare: "I measure the development time. I want that unit testing coverage is 90%"

[10:30] Alexandru Bolboaca vorbeste despre Unit Test. Mare problema, intotdeauna programatorii considera asta drept "second class work" - parerea mea.
Prezinta cele 4 cadrane ale Agile Testing. Unul dintre ele este Unit Tests.

Clarificari despre momentul de a scrie teste:
A> Design, Code, Test ==> Test After // SURPRIZE, SURPRIZE
B> Design, Test, Code ==> Test first Programming
C> Test, Code, Design =-> Test Driven Development // PARADIGM CHANGE NEEDED

 Inca una tare de la Alex Bolboaca: Developers write tests!

[10:15] Masurarea eficientei unui Scrum fata de altul devine o problema Anti-agile, spune Richard.
O alta idee interesanta: instant messaging este baza pentru o munca eficienta de tip agile.

[10:00] Unul dintre subiectele abordate de Richard Stinear: cum sa tratezi cu clienti non-agile: explica-le. 
Am aflat si de ce se vorbeste in engleza. Richard este nascut in Noua Zeelanda si este Group Head of Development la Endava. Cifrele lor arata cca 550 de oameni in Romania si Moldova, plus 150 in UK.

[09:25] Nu sunt toti practicieni in Agile. Cam jumatate de sala.
Open Space session --> 50 minute, pentru a facilita toate ideile bune care se genereaza in "coffee breaks". Conferinta este in engleza. Nu sunt sigur ca sunt alti participanti decat romani.
Law of two feet: use your two feets and move to another Open Space 
Your responsibilities in such a meeting: Be present in time, express your interest and discuss about it
Eu voi vorbi despre adoptarea de tehnici noi  in echipe vechi.

[09:05] Prima postare: sala este pe jumatate plina. O parte dintre figuri sunt cunoscute. Firmele ce sponsorizeaza sunt MosaicWorks (organizatorii de traditie), Endava si Pentalog - dintre cei mai mari, FITS (care da si un speaker - Stefan Bargaoanu, cel care a initiat Agile Meetup in Iasi).

Prima prezentare va fi a lui Richard Stinear - How to build a Death Star.

Read More...

Open AGILE la Iasi

Pe 31 martie, la hotel Ramada va avea loc conferinta Open Agile Romania. Este prima conferinta despre Agile organizata in Iasi si va recomand sa participati.

Tema de anul acesta este

Agile & Lean: What We’ve Learned.

Cine vorbeste si care sunt subiectele, puteti afla de pe site-ul evenimentului: www.openagile.ro

Cateva cuvinte despre organizatori si istorie: Maria Diaconu este sufletul acestei initiative si cea care organizeaza conferintele Open Agile in Romania. Conferintele anterioare au avut loc in Bucuresti, unde au inceput din 2009. Au fost trei teme diferite, iar invitatii au avut fost nume importante in Agile: Ken Schwaber, Jurgen Appelo, David Hussman, Corey Haines, Alexandru Bolboaca, Rachel Davies, Janet Gregory, Andrea Provaglio. Mai multe despre istorie aici. Cei care au sustinut financiar aceasta initiativa sunt cei de la Mosaic Works. Personal, ii apreciez foarte mult pentru ceea ce fac.

In Iasi, Stefan Bargaoanu de la FITS, a organizat comunitatea si sustine intalnirile celor implicati sau interesati de Agile in companiile din Iasi. Daca vreti sa va inscrieti in Iasi Agile Group, o puteti face aici. Incerc sa particip la meetups, chiar daca nu am experienta deocamdata, ci doar mult interes. Comunitatea AgileWorks din Iasi are pana acum 65 de membri. Intalnirea precedenta a avut loc la Endava, iar oaspete de onoare a fost Maria Diaconu.

Va recomand calduros sa va inscrieti la conferinta, chiar daca implica si ceva costuri. Ne vedem acolo...

Read More...

Team velocity

`First time I heard about team velocity has been when I read some things on Agile development. There are various descriptions of the team velocity in Agile and I invite you to read this one.
I said this is a great descriptor of the team performance and I should introduce it as objective reference for comparison with the other teams. Thinking back, I realized that it is not easy to implement this due to the way estimations are made and planning is implemented. Therefore, I put this on the shelf, for more reflection...

But, I came to the idea that there is another velocity of the team. I wrote some weeks ago about the team seen as road. If you are the vehicle, and the speed of this vehicle is the speed of your personal development, we come to the idea that the team velocity is actually the average development speed of the team members plus the development of the team itself (different than of the individuals).

According to physics, the speed is the ration between the distance and time. Of course, we will make, for this concept, a similar ratio between the personal development achieved and the time elapsed. When your are thinking
It's excellent for any human being to progress. The trick that manager has to master is the direction of development. How this direction is in the interest of the team, respectively of the company. It's the post-capitalism era we face now. Talents are important, this are the competitive advantage. Money are a fantasy.

Let's continue with some more considerations about team velocity, how can it be ensured and what are the consequences of it.

The first idea you could put in practice is the set of trainings for a certain role. This is obvious and there are not so many things to say on it. I would add that each training shall be discussed by the manager with the team member to underline the objectives for the team and to reflect on the objectives for self development.
This is putting me to a next suggestion: consciously or not, each individual is developing from point A to point B. Having identified the two points A and B, the manager can use specifically the trainings and other development measures to facilitate this journey. Enrolling the individual in irrelevant trainings for his journey makes the journey longer and decreases the team velocity.
Trainings are not enough. Everyone needs practice. With the destination point in mind, with the next role in mind, the manager can facilitate learning experiences within controlled environment. For instance, there is the need that John becomes a very efficient software release engineer (you, that guy that prepares the releases and makes sure that the others gets what they have been promised). So, John can prepare some internal releases, can do some less important projects where he can practice his knowledge and imagine own working style.
Of course, development is harder as one advance in seniority. Things become fuzzy and manager should add his visionary talent to identify possibles steps ahead. There is always the need of transformation. A team does not remain the same, in roles, activities and responsibilities.Team velocity cannot be measured objectively in all aspects, but there is one obvious output: the thrive of team members.
I've read recently a post on HBR.org on Creating Sustainable Performance. One of the main ideas has been that people thrive within an environment that supports learning and based on their inborn skills. You can read full article, I noted down two things I could do in my team to ensure a great team velocity.
Delegate decisions.
This comes with a bunch of benefits (see the theory of distributed computing power) and with certain drawbacks in dealing with mistakes. For me, looking for the rootcause, fixing it and not dealing with guiltiness and guilty people fixed most of the things. People love to decide and to participate to decisions, but they are afraid of mistakes. Having this fixed, manager can embrace a participative leadership style that prevents him on being part of every decision and leaves some time to think forward.
Constantly offer feedback
Based on my personal leadership style, I tried to improve the way I collect and give feedback. I've started with giving feedback only during evaluations, but I am trying (keep trying...) to offer positive and constructive feedback through out the year and make the evaluations only a sum of previous discussions. Additionally, I am looking constantly to facilitate the expression of feedback between team members. I think is not yet where it should be. Keep trying...

One thing it sure helps in team velocity is to explain and discuss. The journey should be a team journey. The development of one team member should be in the direction of the team development and should not do any harm to others. Constant discussions about the team's roadmap increase the awareness and facilitate contribution. Also, one can identify other potential leaders during these discussions, gather useful insights and include common vision of the future.

This is not all about velocity. Next weeks we will speak about:
- adjustment of velocity for each team member
- expectations for senior team members
- how to retain the know-how and release the humans
- how to make the development speed uniform and avoid internal turmoils

Read more on the same subject:
Team velocity [1] -the mission of the team slightly influence the velocity

Team velocity [3] - the entry points

Read More...

Estimations (not agile)

Why are needed?
Simply because you also need a deadline from your builder when the house is finished. And for sure, you ask for a delivery date when you go to your tailor. Plus, you ask for a price. No deal is closed without a price indication and a delivery date.

Simple tricks to make it better:
1. Read down what you have to do
2. Understand it
3. Split it in pieces.
4. Write down the pieces and think how much would you spend for each.
4.a. You have do in it and can look back in the history. Put the figures there.
4.b. This is the first time you have to do this. Split it in more pieces and go back to step 4.
4.c You cannot escape from step 4.b. Use your intuition. How complicated does it seems?
                        Same other task : put the same effort as for that, plus the learning effort
                        Twice as complicated: twice the effort plus the learning effort.
                        Five time as complicated than what you did so far: ask for another task.
5. Think a little about risks: what can happen to prevent you for completing the task. Put some effort there (not for all risk you identify, only for half of the big ones).
If the risks are to high, ask for another task or tell this to manager.
6. Sum it up and see if you can reach the deadline.
If this is not possible, then see what is the delta missing: can you speed up and delivery in time or is basically impossible and should tell this to the guy who requested this.

Read More...