This time, the seminar focused on recruitment and retention in the IT industry, and while I originally went in support of the organizers, I figured I’d pick up an interesting thing or two as I also deal with the subject as part of my job as an IT professional.

There were three resource speakers who focused on recruitment, retention, and applications respectively:

There were three resource speakers who focused on recruitment, retention, and applications respectively:

• Ricky Gumaru of SysGen shared his experiences in recruitment, which he broke down to understanding the requirements, sourcing the candidates, and then processing them.   Ricky also highlighted branding and its importance in recruitment.
• Penny Bongato of Logica came next and shared her views on retention.  Her talk answered the question “after getting the right people, what’s next?”  Keeping employees engaged is what every company should aim for to retain their employees.
• Marilyn Siy of Accenture was the last to speak and shared how her company applies recruitment and retention strategies.  Accenture is such a huge company (compared to other Philippine-based IT companies at least) that it has recruitment teams and programs to hire and retain people.

Some points and thoughts from the seminar were:

• People are always looking for something in their jobs and how you brand your company is important. It should tell them that you are the best choice that answers their needs.  You invite people to work for you.
• Not everyone who applies for a job in your company pursues it, as each individual has concerns and priorities.  But that doesn’t mean that you can’t keep in touch with them – I’ve had a couple of cases wherein this happened and I kept touch and I think it worked well especially since the IT industry here in the Philippines is a small one.
• Companies need to keep employees engaged in their jobs.  Leaders are very important here and they must understand how important their roles are.  I would be engaged if I understand where we are going in the future and if the future is clear. I think it is the job of leaders to make sure the future makes sense.  Uncertainty affects engagement.
• People and priorities change and those need to be factored in.  Accenture has a personnel engagement list of things people find important and they have employees rank it.  Extra-curricular activities can be introduced but these should enhance rather than ruin one’s focus on his job. Performance matters.
• “Mechanics fix cars but do not own one.” This statement can be applied to IT companies as well where they sell solutions but still have manual processes.  Fulfil your brand’s promise.
• I read a quote that we spend most of our awake hours at work and thus we have to make it count.  I do think companies should make working for them count as well.
• Line vs. support, or the billable vs. the non-billable which are terms closer at home.  People complain that HR is not responsive but they should understand that line people deal with a client while support deals with a lot of people.  Thus, communication is really important as everyone in a company is critical to keep it working as a cohesive whole.

All in all, it was a very interesting seminar.  I went with our company’s HR and recruitment people and I’m excited to see how the lessons from this seminar can affect the company positively.

Pictures and live tweets from the event can be found on my Flickr and Twitter sites, respectively.

Last Friday, I had a chance to facilitate the retrospective of the Scrum team I am part of.  We have done retrospectives in the past, yes, but I would say that our understanding and practice is fairly shallow, and will need more time and reflection in order to mature.  This retrospective aimed to start doing just that.  Here are some of my thoughts from the retrospective. 

Leveling

Before we started, we had a leveling exercise to determine how open the team is in discussing things within itself.  This is very important as it sets everyone’s expectations on the retrospective and allows everyone to act accordingly during the discussions.

Each team member wrote anonymously on a piece of paper a number ranging from 1 to 5, with 5 being the most comfortable.  These are then averaged in front of the team and the outcome is the team’s comfort level.  This is then revisited at the end of the retrospective if the discussions did reflect the level.  We scored a 4, which was quite high in my opinion, but was actually reflective of our discussions and thus was pretty accurate and is a good thing as the team is fairly comfortable with each other .

Retrospective itself

I would group the retrospective into three main parts: revisiting the sprint, discussion of relevant points, and coming op with action plans.  We revisit to gather information so we have something to talk about and thus act upon.  The common way is to have a timeline where everyone would post events they feel are important.  My CSM training suggested other possible approaches such as the team drawing a picture of the sprint (shown in the image above), or an emotion graph to indicate how happy the team was each day in the sprint.  We had a combination of the three and below is the picture that we came up with.

Admittedly I think we had more discussions with the timeline than the picture but the latter did give us an idea on what the team felt the sprint was like.

We built the timeline as a team with each team member posting what they felt was relevant on each day.  No group discussions yet at this point as we want to get everyone’s perspective before we stop and integrate.  As an added twist, we put smileys on each day to signify how they felt.  Smileys were either happy , not happy , or no reaction .  We did this on a whiteboard, but I think it would have been better on something that we can easily archive so we can revisit it in the future.

We then went through the timeline and then everyone wrote what they felt was remarkable from it and this served as our discussion points.  Another approach is to ask the team to mark events in the timeline that they found relevant and then discussing them afterwards.  A valuable addition to the timeline would be a burn down chart, as the slope changes give a summary of the team’s performance each day.  Unfortunately we didn’t have burn down charts in this sprint so we didn’t have access to this info.  We did start on one for our current sprint so we have something to use in our next the retrospective.

We spent most of our time in the discussions and came up with 3 “things to keep” and 3 “things to improve” for the next sprint.  One of the things that we should have done during the retrospective was to discussed how we can actually say we improved on these 3 items in the next sprint, as this sets everyone’s expectations on what needs to be done.  We defined these during our sprint planning the Monday after the retrospective.

End with the retrospective

It was pointed out that this sprint was the best one yet (yehey!).  We were able to end it will all tasks done.  We accomplished this by not adding stories into the sprint as well as cutting items from the sprint when we felt we couldn’t finish them (a burn down chart would have really helped here).  I don’t think people would have wanted to end the sprint and then immediately start on the next one.  It would be better to drink to the success of the sprint, or drown it if it wasn’t, which merits drinking as well

The common scenario is retrospectives happened and is then immediately followed by planning.  I think this happens because of the following:

1. Product Owner availability to do a sprint review.  Either the review was moved to another day, or was not done at all.  Unfortunately, we are the latter simply because we haven’t figured out how to do this in an offshore context with a fairly large time differential.  Sprint review and retrospective should happen in the last day, and we need to get everyone’s commitment on this.  This also means we took the entire day for the retrospective, which isn’t good as well as we didn’t time box properly.
2. 2 week sprints.  Sprint reviews should be done in 4 hours and retrospectives in 3 hours, but this is for 4 week sprints and for 2 week sprints we cut this into two.  This leaves about half a day free to do other things, which leads us to point 3:
3. Maximize time.  Why not have a planning meeting?  My thoughts is that it may be possible to either just stick to the 4 hour review and 3 hour retrospective, or use the extra time for training or team activities but not planning.

Each point is valid of course, so I’m not really certain on how to do this.  Time to bring it up to the team then .

We weren’t able to plan our post sprint event but most of the team were able to head out to Charlie’s burgers for carwash and to try their burgers.  Check this out:

More pictures of the retrospective and Charlie’s burgers at my Flickr site.

We took time to learn more about Scrum as well as the system to be built before we proceeded with the actual sprint planning.  We did not have the luxury of an actual Scrum course, and so we both learned and then applied them as we went along.  I had some observations on how things were done earlier:

Agile Manifesto, and the three pillars of Scrum

Traditionally, I would explain Scrum by how the process goes: sprints, meetings, daily scrums, and the like.  The biggest issue here is that teams thus do not understand the motivation behind Scrum and why it is structured this way, making process improvement impossible as the goal of the process is not clear.

We approached Agile and Scrum by starting with the Agile manifesto and then the three pillars of Scrum: inspect, adapt, and transparency.  “We are uncovering better ways of developing software by doing it and helping others do it”, the first line in the manifesto, was stressed as this is what we should aim for when doing Agile software development.  We then moved to the three pillars and how Scrum is structured to allow these to happen.  This was highlighted by an explanation on where Scrum came from, from rugby, and how it is done in real life.

I hope that the stress put on the points above will give the Team a litmus test to check if any changes, improvements, and decisions they will make are in line with what they are doing.

Breaking down user stories

There seems to be two camps on how user stories are broken down: as tasks with hour estimates, or as smaller stories with story points.  My CSM training focused on the former and this is what we did.  During Part 1 however we came across a story that the Team felt was too big and thus was broken down.  I wondered how this would affect Part 2 if we hadn’t approached it using the former.

There are three parts in a product backlog: DONE, fine grained stories, and finally coarse grained stories.  A product backlog is periodically groomed in order to prioritize as well as break down stories.  I suppose what happened earlier was to be expected as this was the first time the backlog was groomed by the team and the PO.  I’m interested in seeing how Part 1 is carried out with a properly groomed backlog, as time that was supposed to be used to groom it can be used in other ways.

During Part 2 the Team started discussing some possible implementation concerns with one of the stories.  We were able to agree with a plan of attack for that and continued on with Part 2 and within the time box.  What was highlighted after task breakdown and time estimation was that we need to look at the story level more and less on the task level – stories must be finished first before moving on to the next one.   This set the tone for the discussion on team velocity as well as Big Visible Charts.

One of the developers in the Team asked how tasks were assigned.  He came from another company and just joined us recently.  I responded that you grab one from the board once you are done with your current one.  This prevents people from only focusing on tasks assigned to them and not on working as a team to get the sprint done, and was what he also observed before.

We discovered that double sided tape is very bad for index cards, so we need to make sure we have a supply of masking tape.  Also, we figured out a good way to focus on the stories by grouping and hiding tasks under them.  Once the story is to ready to be worked on would we then reveal the tasks in the board.

Acceptance tests in user stories

User stories are promises to talk in the future.  They are a quick way of capturing what we would like to see in the system without too much definition to allow us to start working on it as soon as possible.  They are short and simple and without detail by design, and should be complimented by acceptance tests to verify them.  I don’t think we have been that good on capturing these acceptance tests in the past.

We were estimating a story to generate a report in the system.  We did not have full confidence in assigning a story point to it as we weren’t sure of the details – an expected scenario with user stories.  The team finally asked our PO on how he envisioned report generation would work: how do we access it?  How should it look it?  How is a user going to use it?  With this we were able to get a better idea on how the story would end up and thus have an estimate.

I got introduced to Acceptance Test Driven Development, specifically Robot Framework, during my CSM course, and one of the tenets on this is to as the customer examples on how a story is suppose to behave.  This would then lead to a customer-focused acceptance test that can be automated using tools such as Robot.  We are still exploring how to add ATDD to our teams but the idea of using examples can be used to make user stories more relevant.

I asked earlier on what we can do with time freed up from grooming the product backlog and I realized that this is it.  We weren’t able to do this effectively as we took time to groom the backlog but I hope to suggest this to the team and PO in the next sprint planning.

And that’s it.  Once we finished with Part 2 we went back to the Strike Force area which already had whiteboards and other tools so the team can start work.  They are off to a two week sprint and we had two hour time boxes, one for planning Part 1 and one for Part 2.  Daily Scrum time was agreed by the team and the PO was informed on what they think is possible for this sprint.  Looks like they are ready to go and I wish them well on their sprint .

And I almost missed it!  I wasn’t feeling 100% at that time and had to work from home earlier that week.  I managed to pull myself up and get to Makati for the course.  I had three objectives for joining , which were:

1. To know the difference between books on Scrum and the actual CSM course.  Each of us were asked to write down why we took this course and this is what I put down.
2. Gather the perspective of other professionals in this industry.  I’ve only worked with O&B so far and thus my experience is limited to that.  I was hoping to get a chance to hear the thoughts of other people from other companies, their situations, and circumstances.
3. To try the food at Dusit Thani, which is where the course was held.  This was my biggest motivator to take the course.

And maybe to become a Certified Scrum Master as well, of course .  Plus it was my first-ever company sponsored training, and I was going with Butch,  Joel, and Martin to it.

Some of my takeaways from the course were:

• The keywords to remember in Scrum are: inspect, adapt, and improve.  Exposing these things is what the Scrum process does, and we need to remember that the process is simply a means to this.  I guess it is possible to do Scrum without getting the point of why it was set up this way.
• A Scrum Master is not part of the team, which was huge and something I did not expect after reading Scrum books.  This is to maintain a separation of roles.  The Team needs to decide and implement a sprint as best as they can.  An SM needs to always take a look at the Scrum process and ensure that both the Team and the Product Owner are playing within it.  Both are full time jobs and having the role of an SM and being part of a Team would either: make one less effective in both roles, or give a person too much power in Scrum and start breaking down the process.
• Self-organization is easy to say but hard to do. How hard is something that I didn’t really understand before.  There has to be change both on the organizational level as well as on the individual level to accomplish this.  Self-organization is both letting go and taking responsibility, with a focus on learning and improving. And not everyone is comfortable in doing that which is the hard part.
• There is a huge focus on the Team and its jelling as one.  Bas spoke of teams that have been together for years which allows them to work really well in projects.  Bas suggested different ways to do retrospectives for one, and different activities to get the Team to be closer to each other.
• Culture plays a role in the dynamics of a team.  “Patience” and “silence” are very helpful to being an SM, and are ingrained in Bas culture.  The Filipino culture on the other hand are conscious on emotions which can help resolve issues in teams better.  These realizations highlight the fact that culture needs to be taken into consideration and thus used to a team’s advantage.
• Sprint planning seeks to understand what a Team needs to do in a sprint.  This is done by breaking down stories into smaller units which gives us more confidence in estimation, but the actual process of doing this varies depending on who you ask.  Some people prefer to break down stories to smaller one rather than tasks, and estimate them with story points rather than hours.  This course was on the tasks and hours camp, which I think is a good starting point that can be evolved as needed.
• We had some informal discussions on current trends such as distributed version control systems, acceptance test driven development, Lean, and KanBan.  DVCS is somewhat incompatible with continuous integration, as it lessens the pressure of integrating (read: committing to the source repository) daily, but this is: due to the nature of DVCS and how it started in the first place, something that can be dealt with, and not a problem right now but will probably be in a few years time.   ATDD showed me how it is possible to break down the assembly-line approach to design-implementation-testing which is what usually happens.

And the list goes on.  I’m hoping to be able to expand each of the points above and more in the future as one blog post is not enough to cover them.

It was quite a course and I’m glad I actually took it.  We were about 25 in the course and was quite a mix.  Some were developers while others were project managers.   Some were heads and leaders in their respective IT departments and organizations, while some were simply interested to find out more about this Agile thing.  The questions and discussions that resulted from this were definitely interesting and I hope we can have more of them informally in the future.  And the food was great!  I wish I could dine here everyday.

We had a night out after the first day of the course and took Bas to a local store that served good Filipino food.  He apparently does not like desserts and soup much.  Pictures at my Flickr site.

I’ve spent the past month working with Joel, Butch, and Martin on how Scrum affects O&B as a company, and what things we can adopt.  On a macro level we have begun moving into a more team-based organization, adding a support structure for our teams both in leadership and in career development.  We recognized that not all teams can do the Scrum flavor of Agile and we need to work with this.  On the micro level we started implementing what we’ve learned in the course to our teams with the focus on inspection, adaptation, and improvement.  There is a lot of work to be done and it will definitely take time, but we are at least happy on where we are moving.

And finally, my biggest thought after the course is if I actually want to be a Scrum Master, which is something I share with Lorenzo of Headstrong which was also in attendance.  It would be much easier to simply stay as part of the Team as a developer and handle the technical side of things.  Interesting thought to ponder on indeed.

Of course, it wasn’t without its share of headaches and points of improvement.  Below are three things I think are worth pointing out, primarily so I can remind myself from time-to-time about them:

It’s high priority for a reason

This module was mostly about computation and had to be right the first time.  And it was marked as “high priority”.  These should have been signals to get this module started as soon as possible.

Unfortunately, that wasn’t the case.  We spent a couple of days into the release sprint before we sat down and ironed out the details.  On the other hand, the positive spin to this was that we really sat down to discuss things which I haven’t seen for some time, so we had something that was well thought of.  Just that more implementation time would have been great.

Get people involved

Especially QA.  I managed to get a sub feature split and implemented by a team mate but the fact that this module had a couple of cases that needed a lot of testing meant that I spent more time than I would have liked verifying and re-verifying things.  And I had to do this without letting my biases get the best of me.

As a side effect, getting people involved meant that I need to review my understanding of the entire thing.  So instead of figuring things out as I go along, I am forced to add a bit of planning to make sure that things made more sense that if I was only involved.

Amusingly, when I got around getting people involved it didn’t really take that much time to explain things.

Focus on quality

So on the implementation side I got to go alternating between adding new stuff covered with tests, and refactoring it when it made sense.  I believe that tests and refactoring should be done along the way so they are fresh in one’s mind and are manageable.  I had to cut some corners when the end of the sprint neared though which, as expected, proved to be hard to address post release.

I think I could have focused a bit more though, since I ended up writing custom stuff such as a utility to format amounts and dates correctly but I guess they simply had to be done.

I told him that I do not have enough time to do the things I want to do.  Of course, everyone can say the same thing.  There is never enough time.  Prioritize.  If everything is important then nothing is important.  Yeah, yeah.

He then asked me, if I had a list of things I needed to do.  I stopped.  I had a few things here and there, but nothing like a list.  It was a strange situation, as we always talk about lists, or what we call backlogs, at work, and yet I didn’t have one.  And so I said that I didn’t have one, and he reminded me to make the list, and then tell him if I still didn’t have enough time.

The simplicity was embarrassing but that was all there was to it.  I ended by saying that perhaps the list is nonexistent because I do not want to do what I should do.  That if you put everyone on top of a table and see things as a whole, then the steps that you need to take next would simply stare back at you.  The list helps you to start.  The question is, did I want to start?  He simply said it was an interesting observation.

I always wondered how he’d touch base when I have something interesting to share.  The again, he only touches base when there is something interesting for him to hear.

Suffice to say that things have been interesting and I hope I can write them down this time around.  Here we go again, blogging.

Before wishes are granted we need to have a wish.  And so I shall have some.  Farewell 2008, with all your lessons and experiences, and hello 2009 with your promise of something much better.  Lets see how far we’ll reach a year from now!