Promote the culture

Agile is really about culture. Culture not only means how we approach on software development but how we tech teams and customer the new mindsets.  Change culture is hard, growing teams its harder, culture is something really powerful and yet danger.

Training is a must have, to promote change, but is not the only thing and is far to the be game change act, don't get me wrong, I'm totally pro training BUT I'm just saying that training is the basic not the big deal nor the big turning point.

The title of this should should be actually: "Promote the culture and keep doing it". That's key element of changing culture, every meeting, every retrospective, every planning, every training, everything 'ts a opportunity to keep promoting the culture.

It's like that great quote says:


“We are what we repeatedly do.
Excellence, therefore, is not an act,  but a habit.”


There is a implicit thing here, I mean, there is no way getting a new culture without doing it. I don't see how you will get something just doing a "normal" training.



Let's say that do yo want change your team and make they get XP values and let's say not only the values but also the practices like unit testing / test driven , pair programming, refactoring and simple design. All this practices are empowered by simplicity, communication, respect, courage and feedback(XP values). The best way to make your team get that is doing, doing is the most effective way to get that.


The classical pyramid above show how effectively we learn for each kind of method. The pyramid make 2 simple and clean statements, first is: the classical training method stink and it stink a lot. Why this classical teaching method sucks ? Well because offen you don't see demonstration that was only (30% average retainer) often you just see a bunch of boring ugly text slides. How often you just see people given lectures or just telling about how agile or lean works without having group discussions ? and about practices ? Second: The pyramid says "move your ass and do it". It's a very clear statement to me, doing is the only thing that matters.

IMHO given more than 5 days training is just waste. People need time to get new ideas and practices and instead of given a big bag boom training that cover everything I do prefer do it slice different. Small bets trainings proof to me work better and you just keep pushing the practices and the values even if people don't notice you always are doing things to put values in place.

Creativity, Fun and Challenges

If you do something that don't have fun at all I don't get my attention. Don't think I'm not professional BUT developers like to have fun it's not surprise for me that 99% have video games and like gadgets, it's all about fun. Challenges are great if you pick them carefully, they could really sucks depending what you do. Creativity is the engine of the brand new, creativity and fun it's like coke with ice i'ts really the perfect match.

You don't need money to do it, ops let me rephrase you don't need much money to do it. I find very interesting and yet cool challenges without spending much money. There is a lot of online tool that can help you to archive that like stopwatches, that give more adrenaline to the challenges.

Must be Real and Visible and Touchable

People don't like to do fake stuff, I perfect understand that, this is the reasons why i always put code of the exersise on my github or subversion online repositories. Also I keep tweeting during the trainings and taking pictures of the people doing code, this just enforce the training important and also make people feel important and they really are.

Photos are great for that, photos with prizes are even better. I always try to get funny and cool prized like a great can of Guinness beer or other caliber not national beer(often developers love beers :-) ).  This is not just real but touchable and talking about Guinness its God  Damn good, hell yeah!

Other common approach that I always do with beers its use the beer passport, when I don't pay the prize during the trainings I promise(believe me I do pay my promises) pay a beer that people can choose BUT must be during the retrospective. This is good for 2 simple reasons, first because it remember people of the training and how they went great and how valuable they're for the team and for the company. Second because, let me be freaking clear about it: "You owe me MF" you went to the training did a great job, so keep doing that during the daily and job and don't even think do skip the retrospective you must be there otherwise other people will drink you beer. It's all a implicit statement BUT people get the message.

So in this case beer is not just helping me to keep people focus on the training but also help they to do great stuff like doing tests, yeah do lots of tests this you cool this is social this is great and go to the retrospective and you won more beers, simple things great results.



 I that case I gave a workshop about testing and folks performed code in pairs(the pairs how made more code and not only more tests but the best testes they wow a great can of murphys :D I also take those pictures and posted on my tweeter stream. Believe me or not the folks that won the first prize are the guys who most do tests in my team(this training was several mouths ago). Folks who didn't won the prizes are the guys who less do tests until some day that they get pissed by always not doing that and the team sees that, so the guys change slowly, step by step they are getting more and more usual and confident about tests.

Pair is a must have to

Always when I do trainings I put folks do code in pairs. This way of working proof to be more effective on trainings and also you remember we are enforcing the XP practices to pair programming, by default also enforcing the communication value.

Pair programming is great, let people focus much more on the problem, I see people cooperating in pairs not just because of the problem they need solve but they are trying to do they best because they want learn and ultimately the want the prize the beer.

I never ever had a training with my team following my crazy ideas that never had been very well accepted by the team, one of the proofs is that fact that people always mention trainings  as good things on the retrospectives and I see the results during the daily basis work.

I like do change the place where the tannings are executed, in the side picture I'm providing a REST training onside my team work room.

BUT as you noted in pictures above are trainings that I gave on my own home, yes on my own home, why the #$% i'm so crazy ? The answer it's simple, this is personal and must be. People are people, there is no such a bullshit that people are equals and should be threat equally. I don't a effective way working with people without knowing they. The proof is that I just work much better with the people that I know in my company, people that I know who they are what they like, trainings in house with barbecue and playing wii are great opportunities.

Pair programming is a awesome opportunity to team and to the people understand and learn about each other and more you do better you get as a team. Pair programming is my default exercise mode during trainings, people talking and trying things they learned in pairs its really cool.

Don't forget to talk about it


People having group discussions help a lot on the learning process (look the pyramid above) I always promote that in one way or in other, sometimes I put every pair code in the projector some everyone can see, this is not only to promote transparency but also to embrace change and technical excellence, so I go trough every piece of code and explain to everyone if is bad why and how could we improve it.

This is good also because we are promoting the good code standards, real kick ass code standards are not the ones who are inside a nasty word document but truly the one who folks do it day by day, I get really happy after every code review session because I see that some mistakes never come back, this is consistency this is code standards this is a proof of team smooth integrated working like a swiss clock.

Trainings, daily's , retrospectives, demos and planning are great moments(like every other moment) to improve and promote the culture, the practices and to grow the team, see the opportunity and make it different, make it creative and fun its up to you.

Cheers,
Diego Pacheco

Popular posts from this blog

Kafka Streams with Java 15

Rust and Java Interoperability

HMAC in Java