Blog

Agile, Scrum and Talent Management not only for IT professionals

How to conduct your first agile meeting (IT or not)

During the last weeks I have had the chance to organize two different first Agile meetings with 2 different groups.  One was my first Meetup in Mallorca with Agile practitioners and the other one with a client team in UK.  Very different cultures, completely different audiences.  In any case I confirmed some key aspects that help a lot when you organize an Agile meeting:

  • Clarify Why are we here for:  In both cases the aim of the meeting was shared in advance to all participants. For example: Share your experience on Agile, Watergile or Agilefall practice in 3 minutes.  Nevertheless, once in the meeting is always good to make sure everyone knows why they are there without making assumptions up front (when was the last time you asked to the people in the room if they knew what was the meeting for?).  So, in the presentation round, asking to share expectations is sometimes useful to manage the scope of the meeting and clarify what topics will not be covered. 
  • Review the rules of the game with participants: the meeting mechanics can be clarified and agreed with participants.  What do we do if we are more people or less than expected?  Shall we wait for those that are late? How long can we stay if necessary? Who needs to leave earlier?  Who goes first?  How we solve the poor Skype connection? The projector does work or better to use flipchart?  Any topic that should be included in agenda?
  • You acknowledge where you are and how you feel: the initial chitchat talk is extremely useless for some people, but for most is the human touch you need to have an open conversation.  You can also acknowledge during the meeting: if you foresee a deviation in the timing it is always good to ask the participants for help to manage time.  Are you all OK on finishing later? Anybody that needs to leave earlier? What if we change the time allowed per person?  Shall we cover this topic and leave the other for later?
  • You do look back to learn - In my case both meetings had learning purposes behind, so that people can take something home right after.  You care for the past only in order to move forward faster.  This means you need to address the elephants in the room if necessary, and that includes pointing out behaviours that you consider were damaging (if a colleague annoys or hurts us in a way that impacts our work, for example) but also those that helped!  Meetup participants for example shared their experiences and some highlighted specific types of people that facilitated change and some types of people that didn't.  Interesting to confirm that personality do influence how Agile teams work, but that is material for another post. ;)
  • Ask for feedback - it does not need to be super engineered questionnaire, but a very simple round of comments or wrap-up helps if there is no other way at hand.  It also helps to shape next meeting.  For example Meetup participants suggested to have another meeting in which the topics to share were first voted by the audience so that we could start for those more relevant to more people.  Important:  Remember that in an Agile meeting the responsibility of the outcome is shared, the same as in any project.  It is a co creation process and unique itself, as the combination of people plays a role.  Of course facilitators help, but each meeting could be a completely different scenario.  A first meeting with a group of people is like a first iteration.  They are not necessarily a team.  They might or not know about Agile, and each has different level of knowledge.
  • Focus on the outcome: As servant leader conducting an agile meeting the least of your worries is to expect to be liked.  Do focus on the value each one takes home. An agile meeting is one of those precious opportunities for magic to happen, discover insights from people and qualitative information you will not find in databases.  It helps you to become better facilitator next time, adapting your style to the specific group in hand.

All these points don't seem "Agile" specific right? I would say there are 3 key aspects that make them different from others:  

1- You want to build trust and human interaction instead of monologue-type discourse

2- You allow participants to shape the meeting and self-organise as much as possible 

3- You care about adding value to each participant: there for agenda is flexible as long as it serves this main outcome

Greetings from foggy London!

On how to promote Diversity, Inclusion & flat non hierarchical organisations

Yesterday I was happy to attend the WomenTechMakers first meeting in Mallorca.  It was interesting to meet with people that love Tech and at the same time care about the future of the professional world in general.  "We need to get women interested on STEM careers now or we as women will be out of the business world in the years to come" was  one of the phrases that made me think.  Women are indeed under represented in STEM fields in general (some countries less than others), so getting to promote the STEM careers among girls is a great objective. There are not many references available for young women that might be thinking "How can I become a Hacker if I am bad at Maths?": you need to search to find examples of influential women in Tech, and some companies are doing their best to attract diversity with social campaigns... but really, why are we so worried to promote equal participation in Tech or any other area? 

My opinion is that diversity is necessary, not only regarding gender, race, nationalities but also personalities, working styles, social background and age in order to foster innovation and generate alternatives.  If your clients are diverse, better get people that think like them right?  

In a traditional hierarchical or power oriented organisation the value of diversity might suffer: friends hiring their friends to maintain and reinforce their positions at the top instead of looking for the best talent, or HR favouring recent MBA or top-tier university graduates with a great ability to socialize their skills on top of the always hard working introverted colleague that could not pay for such an expensive education but has come up through the ranks and is able to do the same tasks and more... why this happens? 

One of the reasons why I chose to promote Agile values is because I trust that it can change the environment in which we work to reach inclusive and non hierarchical teams of unique individuals working together.  Unfortunately, very few companies realise that Agile requires transparency and risk taking culture to start with, empowering people that actually do the job and can take decisions and letting go on departmental silos. As my fellow mates in the meeting yesterday mentioned, most of the time it becomes a "Watergile" or "Agilefall" attempt of the management just to get some visibility.  You might have seen cases in which the Product Owner role itself gets duplicated as no department want to be excluded in the decisions... what is behind that? Fear of one department to be excluded? Why we have departments in the first place instead of all working to create a great product or service?  Also I freak out everytime I hear some Tech colleagues saying that "Business" have to decide this or that. Why we build the "we" and "they".  Who is the "business"? Is IT not part of the business? Who is in the best position to take that decision? Sometimes fear of making a mistake is behind the Business / IT  wall.  Better to let Marketing fail, we just take requirements and develop whatever they want. They should know why they ask for it right?  A comfortable non risk taking position after all... 

The way companies hire people give some hints on how flat and inclusive they are: is it always top down? Only HR, managers and same seniority peers interviewing candidates?  Do you hire by certain bands or by talent according to market? Do you happen to have only analytical people in Engineering and communicative in Marketing? Do you really know what that person will be doing and what you are lacking in terms of diversity? Do you ask for the personal values openly, share the hiring process timing plan and are clear from the beginning on what the candidate can expect from your organisation?

There are many fields in which diversity, inclusion and flat organisations could make a difference, not only in Tech.  And you don't need to be a top manager to promote these values. Start looking around and wondering if everyone speaks in meetings, if not, start to ask.  Also check who gets the credit for the ideas... some transparency and peer recognition helps to drive change too.

 

On “feedback” or “guidance” and Direct Communication value

One of the key values I preach and live with (for better or worse) is Direct Communication.  All of my dearest friends have at some point had a clear criticism to give me and help me grow.  Starting with my parents! Unfortunately these cases are rare pearls to find as it requires people to care for you personally, be corageous and also have the knowledge on how to give praise and criticism without damaging the relationship.

A good article I found on this is one which made me remember how hard it could be to organize a feedback session.

I have experienced the total silence or just avoidance from some people that I directly asked feedback from.  Not everyone is up for it.   So when I had the chance to build and lead a team I provided with specific time for this personal feedback to happen.  But not only from me!

It is great to have a boss that dares to give feedback but is even better to get it from your peers or people that expects decisions from you.  There are not many occasions to talk about the elephants in the room while working AND your peers share more time with you! So your boss might be good commenting how you performed in a specific meeting but could never be so accurate and get a comprehensive vision as a mate.

So after 3 months of weekly retrospectives as an Agile team of 6 people I put in the agenda 2 hours for a single topic: “each one of us will receive feedback from the rest of the team and listen.  You can only reply to make a question and dig into the comment, not to justify you.  Giving feedback is about behaviours, we do not pretend to know why that person is doing something, we just explain how that specific behaviour is perceived by oneself.  The person who gets it decides what to do with the information.  And if another person in the room agrees with the feedback given, should state it again at turn.”

As explained in the article, most people is tempted to sugarcoat the truth making it impossible to get the real message.  So I also added one radical rule to the invite: no “sandwich” feedback allowed.  This means that you cannot search for 2 great behaviours that person demonstrates in order to talk about the single one that you think and wish would change.  That was questioned by my team and perceived as mean.  “So only negative feedback allowed?”

I explained the reasoning behind: We know each other and we know we are the best in what we do (that’s why we are here!), and this is not to talk about what we know but about things that we may ignore and therefore remain as noise at work and areas for personal improvement.  Feedback is a gift.  Plus we are adults, and each one will evaluate if the feedback is relevant for himself.  And take ito account that if one says you do “A” it might not be relevant, but if 4 people says you do “A” and have same perception, maybe it is useful for you to consider to change it.

The meeting was received as weird (it was).  It wouldn’t have happened if we were a normal team, but the ground for it was built before by weekly retrospectives. In any case it was forceful for some people.  So I volunteered to be the first to receive the round of feedback.  It was the most amazing experience I had.  I asked how exactly I behaved in particular situations and I got the real answers.  Then I took public notes on my growing path, also prioritised of course  (as any other backlog).  And I decided on the importance based on the number of people mentioning it or the impact of my behaviours.

There was a case in which one of the team members got sick the day she was to receive feedback! So, just be aware it is stressful for some and requires an atmosphere that embraces personal improvement too.  Others just love it as much as I did and volunteers appeared easily with time.  I recommend to have these personal feedback sessions if you are an Agile team that really cares for People as much for Outcomes.  

I can explain some variations my team experienced in other posts!  Now I will continue my summer fresh holidays in Germany!  Wishing to know your own experience!

 

Agile Activator in 3 minutes

Last May I recorded one of many talks with a friend and coach, Munir Rashid. You can see the video clicking on the title of this post.  He graduated in Computer Science back 1987 (Brown University) and started his career helping non profits to transition from paper & pencil systems into computer systems (emulating relational databases using Xbase code). The niche in which he really fit was working in the middle between business and tech on a Business Analyst role.  Later he got more interested in Optimisation of Human Systems in technical projects, so got a Masters Degree in Leadership and Certified Coaching Program, so he has been coaching people for the last 12 years and coming back to IT world to help on projects.  Living in Canada and Berlin, he is a great business partner of Agile Activator and always available for conversation.  

I leave you with a 3 min edited version (I am not a pro, so sorry for the cuts) for you to get a quick idea of our working styles and common vision.  By the way, Happy Independence Day to all my US friends!

Read More

Retrospectives: why is it good to look back?

The easiest and most powerful tool I discovered using Scrum, was the retrospective session.  As the name indicates, it requires to talk about the past.   

Actually this is one of the Agile tools you can use even if you don't have an Agile structure as such.  You just need a team and a leader that performs as Scrum Master.  So, you don't have to be part of IT department to make retrospective sessions.  You don't need a project either.

You are probably working waterfall in many projects and having a weekly session with your team. Maybe you are doing retrospectives without knowing... as it consist on a team meeting.  Nevertheless, this team meeting is special because it has a very specific agenda:

Each participant shall answer the following questions:

  • What are you proud of this week?
  • What have you learned?
  • What would you do different?
  • What are the barriers you face to do a great work the following week?

The full session might take 1 hour... and it could be the best investment you can do in the week.  A servant leader would take notes of the barriers, as those are important issues to solve ASAP... and the team can always help and comment if there is time.  Give it a try... hopefully you will enjoy it as much as I do.