Agile
now browsing by category
Ping Pong Programming
Hi guys, in my last post I gave a small introduction to pair programming. This post will be short where I would like to present a small technique that can be used during pair programming. I learnt this in Rachel’s and Liz’s book. This technique is called Ping Pong Programming and it ensures that both members of the pair take a turn at the keyboard. Below you can find the steps.
What do you think about this approach? Do you think that would help your developers? Do you think it would help you guys to design a better code and to spread knowledge within a team?
Please leave some comments.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Small intro to “Pair Programming”
Hi guys, some of teams, that I have been helping lately, identified a lack of knowledge as a problem in some parts of our product. To tackle this issue, they decided to start with “Pair Programming”. Previously, they never did it so they asked me for some guidance where and how to start. That´s why I am writing a small intro to a “Pair Programming”.
As Rachel and Liz said in their book: “Pair programming is two people working together- at the same computer, solving the same problem. Each person plays an active role in creating the software; the person actively typing is known as the driver, and her/his partner is the navigator who looks ahead to consider next steps and potential pitfalls. Pairs swap fluidly between these roles.”
If your team adopts “Pair Programming”, these are some of the advantages that you will benefit from:
But what should be done during the Pair Programming session?
First, when you are driving, demonstrate that an important aspect of pair programming is explaining what you are doing and why, so don´t just type code in silence.
Second, stay open for suggestions from your pair, even if they are novice programmers. Even though you see a very obvious solution, be willing to try the solution that your pair suggests. In any case, both will learn. If the solution of your pair is wrong, he/she will learn why it is wrong with a help of your explanation. If the solution is good, then you will learn new aspects with your novice colleague :).
Third, one person shouldn´t use the keyboard for more than ten minutes at a time. Using ping pong programming can be a good approach. More information about ping pong programming here.
One big mistake that is common in “Pair programming” is the fact that only one person does all the job. A lot of interaction between pairs should be observed. Interactive pairing forces pairs moving keyboard back and forward several times. In the beginning pair programming can be frustrating. Most of the time it means that developers will slow down to help colleagues but on the long term this is a tremendous help for the team itself.
This was a brief introduction to the “Pair Programming” . Naturally, this post itself is not enough but at least gives an idea about what “Pair Programming” is. If you want to know more resources about pair programming, just let me know.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Small intro to “Coding Dojo”
Hi guys,at the company, where I currently work, we are ramping up several Communities of Practices and one of the activities we want to introduce is “Coding Dojos”. This is the topic for today´s blog.
A Coding Dojo is an activity that brings developers together to work in a pre-selected programming challenge. This is a great way for developers to improve their skills and it´s a great activity to encourage learning between developers.
Everything starts with a pre-selection of a coding challenge which helps the people to prepare better for the activity. The dojo runs with two developers working in a pair in front of a computer solving the coding challenge. This can span different topics. For example, re-factoring some part of the code, implement a new architecture, etc. The PC will be connected into a projector in order to share their work with the rest of the room/office.
During the development task, developers talk aloud giving an explanation to others about tasks and their solutions. If the room cannot follow what is being said, the developers will explain once again until they understand the approach taken by the pair.
In every five minutes one half of the pair changes a seat with someone else in the room. This will allow everyone in the room to participate in this activity. Usually this exercise lasts for 1 hour.
I believe this is a great way to help team members sharing the knowledge among each other.
What do you think about this activity?
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
How to build agreement within your team
Hi guys, in this post I want to demonstrate a small exercise that I learned from the book “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner.
As an agile coach I spend lot of time introducing new ideas to teams but a question is: ” How can I figure out if these ideas will have enough buy-in from teams to be implemented?” The exercise that I´m showing you today will solve this problem; the exercise is called “Gradient of Agreement”.
The exercise is really easy. Use a flip-chart, draw fiver different levels of agreement: “Endorse”, “Agree with reservations”, “Mixed feelings”, “Disagree but go with the majority” and “Block”. Ask team members to put a check mark on the level they feel comfortable, as presented below in the example.
Using this kind of tool allows everyone to reveal its own opinion and level of commitment to the proposed approach. Sometimes it is not possible to get buy-in from the team, therefore I propose that you start with small steps, instead of having an ambitious final solution. Why not break the solution in small pieces, for example, instead of proposing to the team that automated tests should run after every check in, split this ambitious goal into smaller ones:
- Automated tests should run automatically after every checkin
- Automated tests should run manually after every checkin
- Automated tests should run automatically every night
- Automated tests should run manually every night
And use the same technique for each different goal. After that chose the one that has the right balance between an ambition and agreement from the team.
This was the exercise that I wanted to bring up today.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Rules to design good Unit Tests
Hi guys, this post will be short but in my opinion it is really useful for agile developers. Some weeks ago, when I was reading the book “Agile Coaching” by Rachel Davies and Liz Sedley, I found an interesting part that I wanted to share: “Unit tests Rules” by Michael Feathers.
Michael Feathers tells us that a test is not the unit test if:
- it talks to the database
- it communicates across the network
- it touches the file system
- it can´t run correctly at the same time as any of your other unit test
- you have to do special things to your environment (such as editing config files) to run it
He also tells us that tests which do these kind of things are not bad tests. Most of times, it is necessary to have these kind of tests, however, it´s important to separate them from true Unit Test so that we can keep a set of tests that we can run fast whenever we make changes.
This is a short pillar I wanted to share with you.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Why “Retrospectives” should not be pushed to the next sprint
Hi guys, first of all I want to apologize for not contributing with any posts. I moved to another city, changed the job and this took all my energy :)
During this week I had some interesting discussions with some colleagues about retrospectives and when to conduct them. Therefore, I want to explain why, in my opinion, retrospectives should be the last thing to do in a sprint and not dragged to the next sprint.
In my opinion, retrospectives are the most important part of agile software development. This is the time when teams analyse their way of working and suggest new ways to improve a current process. I believe everyone agrees that this is a mandatory artifact and cannot be avoided. However, not everyone agrees that retrospectives should be conducted within the sprint, thus I would like to explain why I think it´s important to do it within the sprint.
First, I see retrospectives as the closing part of a sprint, when team does a retrospective, the sprint is over and everything related to it is gone. This allows the team to start a new fresh sprint without any pending issues from the previous sprint.
Second, during the retrospectives teams come up with several action points and topics to be tackled during next sprint. If we allow the retrospective to be dragged two or three days inside of the next sprint, how can we take all items that will pop up within the retrospective into the planning? This is why I think it´s extremely important to have it within the current sprint.
Just wanted to share this with you.
Do you have any arguments/ideas? Please share them with me.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
What´s going on in the coach´s mind during a coaching session
Hi guys, on my previous post I had the opportunity to present a good framework that helps coaches to develop their skills. This post is a continuation of that post, I want to write about “What´s going on in the coach´s mind during a coaching session. For this I will use the same framework and the same levels of listening presented on my previous post. Let´s take a look into it…
Level I - Internal Listening
At this level the coach is thinking just about him. During a coaching session he thinks something like: “I hear you. I have some things to add about what you said”. Basically the coach hear what is being said by the coache but we are concentrated on what it means to for us. For example, during a coaching session never happened to you that you end up in a situation thinking for yourself: “Hoooo I know the solution for that, I have the experience to solve that”? In my opinion that is a good example of Level I. You should force yourself to be fully concentrated on the speaker.
Level II - Focused Listening
On this level the coach hears the coache and accept him. He gets curious about what the coache says. He is more focused on what the speaker says. On this level the coach can interpret the words on coache´s context rather than on his own. The coach accepts what the speak says and also how is it said, it is not uncommon for the coach to use the same words or expressions back in reflection.
Level III - Global Listening
This level reveals a more global form of listening. The coach is focused on the coache but not just on his words, he can use his own posture, emotions and body language to help the coache. The coach perceives the environment around the speaker. He can place the speaker´s words, expressions, experiences and emotions in the speaker´s own context.
This blog like all the previous ones were taken out from Lyssa and Michael training. For more information about their trainings go to Agile Coaching Institute.
Thank you so much for your time.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Coaching focus during Iteration
Hi guys, in my last post I explained a tool that I learned in one of Lyssa´s and Michael´s workshop. This tool is a great guidance for coaches in their coaching sessions. Now I will explain where you coaching focus should be placed. During an iteration, a coach must be aware that sometimes his coaching skills are needed to help both teams as well as individual team members. So let´s see when these different skills are needed…
In the beginning of each iteration, the coach must lead the team as a whole unit. Activities, like an iteration planning, require the coach to fulfill all elements in a group. At this point, there is not much work for individual coaching.
As soon as the iteration begins, team members approach the coach with their specific problems. Here, the coach must give an attention to each of them. At this point, the team coaching is not needed. The further the iteration proceeds, more attention towards individuals is required.
When the iteration reaches its end, team coaching is again desired. Activities, like retrospectives, are fundamental and here the coach must help the team as an whole unit. The coach will immediately address individual concerns together with the team, making the individual coaching almost no existent.
Below you can find a picture I took from Lyssa´s and Michael´s material - Coaching Agile Teams Workshop, that concludes what I wrote. The reason why I conceived this post is to create awareness among agile coaches. Coaches need to be aware that we need different skills for different situations. I believe, to be a good agile coach, we need to master not only the individual coaching but the team coaching as well.
Hope you liked this post.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Arc of the coaching conversation, a tool to help coaches
Hi guys, this blog will be about coaching. I want to bring you a simple tool that I learned in Lyssa´s and Michael´s workshop few months ago. I believe this is a fantastic tool, especially for beginner coaches. It´s a great way for them to learn how to keep a coaching session. The tool is called the “Arc of the coaching conversation” . Below you can see its representation, this picture was taken from Lyssa´s and Michael´s material - Coaching Agile Teams workshop.
A coaching session usually initiates because a coachee needs to take one or several things out of the mind and he/she needs to be heard. The coach must create the environment in order to make the coachee comfortable for a discussion. The most important characteristic for a coach is the listening part. A great coach is a great listener. Try to think about it and do not interrupt the coachee at any point. You will have an urge to interrupt him/her, you will start to think yourself that you know the answer and you don´t want to wait to give it to him/her… Do not do that, instead, let the person release the feelings. You must self-manage yourself.
At some point, you must be sure that you understand exactly the couchee´s problem. Try to use the phrases, such as “If I understood correctly, the problem is…” This will allow you to confirm the problem and give you a better understanding what does truly bother the person. After understanding hiser/h problem, start to explore the topic. At this point you should use powerful questions. Here under “Skills for Agile Coaches/Powerful Questions Resources” you can find several powerful questions that can be used. After some time, using exploration and powerful question, the coachee will find some possible solutions for his/her problem.
It is your job as a coach to help him to narrow down actions. Together you should figure out which approach he/she wants to try first. After that, specifically ask what he/she will do, by when and how will you know what was the result. This will end the coaching session.
I personally think this is a good way to keep a coaching session valuable and I wanted to share this with all of you. Hope you enjoy it and find it useful.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
Techniques to make sure that everyone is heard
Hi guys, in this post I want to bring you some techniques that can be used, for example, in retrospectives. Using these exercises will help you to make sure that everyone will be “heard”. Sometimes teams consist of shy members that usually do not express their opinions that much. With the help of these exercises, they can express themselves without going out from their comfort zone. Some of these exercises were already known to me, others I learned with Lyssa and Michael
Consent Check
This exercise is to be used when the facilitator knows that the group is in an agreement or the stakes are low. This exercise will serve to make sure that everyone´s opinion is the same. The facilitator can ask “Does anyone object to ? After this, just confirm that everyone is aligned.
Roman Vote
The facilitator makes a statement, on the count of 3 people hold up their thumbs up,down or sideways. Let the team see each other´s opinions. After that, invite the ones with thumbs down or sideways to talk.
Vote with your feet
This exercise is a bit similar to the one explained here. The facilitator makes a statement: “How successful this iteration was”. People imagine a line on the floor where the left side means: “not successful at all” and the right side means: “a complete success”. People will move themselves according to their opinion. If there is a big difference between opinions, invite people to discuss about it.
Consensus Check
You can use planning poker cards for this exercise, but you have dozens of different options. The facilitator makes a statement and on the count of 3 people will show their cards. Higher the score of the cards, higher they agree with the statement. Lower the score, less they agree with the statement. As in a normal estimation meeting, if the scores are too different, invite people for a discussion.
These are small exercises that can be done in order to help everyone to be listened… Hope it was useful for you.
Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: @lgoncalves1979.
I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.
Thanks guys,
Luis
D5 Creation