ICGSE 2018

I was pretty excited when my submission for this conference was accepted. I’ve been trying for the last few years without success. One of the reasons I’ve been trying to get accepted is due to the ‘global’ aspect of this conference. This was a large focus in my Master’s thesis and I felt this would be a good way to leverage some of the research I’ve already done.

Since ICGSE was collocated with the ICSE suite of conferences, a proper conference facility was needed. The Congress Center Gothia Towers provided an excellent venue.

I gave my presentation (Effective Distributed Pair Programming) on May 28th which was less than week after I had given my presentation at XP 2018. My presentation was followed by talks from Google and Samsung. At the end of the entire time slot, each presenter was required to take a corner of the room to answer any questions. There was some excellent discussion and I did receive some requests for my presentation slides.


Constantly changing project delivery dates

Whether you’re doing Waterfall or Agile, it can become almost second nature to adjust delivery dates especially when key milestones are missed.  Most of the time it’s wishful thinking because the developers have told us they’re really close to solving the problem.

In the Waterfall world, deliverables largely go unnoticed until the end of phase. At that point, the only real option is to insert a sub-phase, adjust the timelines, ask for more money, and hope nobody gets fired.

In the Agile world, teams that miss their sprint end deliverables just roll those deliverables into the next sprint. This may seem like a minimal impact but sometimes this trend continues onto further sprints.

What does this mean?

If you find yourself constantly changing delivery dates it could mean you’re working towards a fictitious date and compromising quality at the same time.

Chances are the team is stressed out and the stress continues to build because they know they can’t deliver on the next fictitious date imposed on them.

What can you do?

STOP! It’s not ideal but sometimes necessary.

Try to figure out the root cause. Is the team simply taking on too much work? Do you have the required expertise?

When teams get into this situation they sometimes feel the need to divide and conquer. So they work in silos so that if they don’t deliver on the key areas they’re still able to show some progress in other areas. Instead, they should look at the #1 and possibly #2 priorities and just focus on that. In other words, minimize work in progress (WIP).

Also, focus on quality. Chances are the reason you’re in this predicament is because you didn’t focus on quality to begin with. Adopt XP practices such as Test Driven Development (TDD) and Refactoring.

What you shouldn’t do

Don’t come up with more fictitious dates. You’re only making the problem worse and the client will only get more dissatisfied every time you promise to deliver and don’t.

Don’t continue to stress out the team. If you do people will leave, maybe not all but some. That doesn’t mean they’re no longer accountable. If overtime is needed, encourage them to put in extra time at the start of sprint so that they can get ahead. You also need to incentivize them to do so and show that you’ll support them along the way.

FTC 2017

This was my first Future Technologies Conference so I didn’t know what to expect.

Being a smaller conference in Vancouver I expected the attendees to mostly consist of Canadians and Americans. However, that was not the case. There was a lot of representation from across the globe (over 50 countries were represented).

In terms of attendee types, there were definitely more academics than practitioners.

My presentation, “Pair Programming: Collocated vs. Distributed” lasted about 20 minutes. I was only allotted 14 minutes but there were a few no shows so I was able to go a bit longer. The presentation ended with excellent questions and insight.

I really enjoyed learning about some of the ground breaking research that is currently going on. I don’t know how they come up with this stuff.


Having attended previous PMI-SAC PDC conferences, I must say this one was quite different.

The Winsport venue had a much different ambience compared to the BMO Centre, and I mean that in a good way.

Also, the attendance had noticeably diminished from previous years which is expected considering the downturn in Calgary’s economy.

The keynotes that I was able to attend were fantastic, especially the one on Brain Science. The point on visualization made complete sense to me. I heard Hayley Wickenheiser’s keynote was also inspiring but unfortunately I was unable to attend.

My first presentation, “Scaling Agile @ FCC” went well. Everything worked as expected. The audience seemed to enjoy all 3 short video clips. However, the presentation almost lasted the entire hour which didn’t leave a whole lot of time for questions and I wasn’t able to stick around because I had to head off to my next presentation which was in a different room. Thankfully my co-presenter was able to entertain one-on-one questions after I departed.

The second presentation, “Agile Product Rescue” also went well. The only hiccup I had was with the audio went it came time to show my YouTube clip. The audience could hear the audio but it was very faint. I didn’t have any questions during Q&A but a few individuals approached me afterwards.

It was great to see a lot of familiar faces. Hope to be in attendance next year!



It’s been 4 years since my last Agile Alliance conference so while I kinda knew what to expect I was very curious as to what had changed. The format seemed fairly similar to what I recall.  There were 4 keynotes, various stalwarts sessions, lightning talks, etc. So I can’t say a whole lot has changed, and that’s not a bad thing.

This time around the experience was completely different mostly because I was a volunteer. I really enjoyed volunteering. It’s a great way to meet people and network. With that said, it can be difficult to attend the sessions you’re yearning for. While the volunteer duties can be plentiful at times, it is a lot of fun. You’re never alone and the people you’re surrounded with are awesome.

I was careful not to repeat the mistakes of the past. At the 2013 conference I tried to take in too much and was overloaded by the end of the week. This time around I made sure to take breaks and make time to socialize.

Orlando was a fantastic venue. Most people were able to take in Universal or Disney or both. With that said, the conference hotel was spectacular just in case you didn’t have time to escape the event.

Next year it’s in San Diego. I hope to be there!

Agile Reflection: Part III

Letting go of Agile Obsessions

This is the last of the 3 part series on Agile Reflection.

Throughout our Agile journey we come across things that work well.  As we progress, we find some of these things work really well.  As a result, we convince ourselves there is no better way to do things.  The problem with that  thinking is that we haven’t applied our theory to all situations, so we shouldn’t make such an assumption.  But we  develop these Agile Obsessions and sometimes they can cloud our judgement.

I too developed these Agile Obsessions and I had to force myself to let go of them.

Here are just a few:

1. The daily standup should always incorporate the 3 questions

2. Estimation is mandatory

3. When in doubt, always go back to the team

Let’s examine each one of these in detail.

Having the team answer the 3 questions is a very good way of applying the daily standup.  But this can get stale.  And  in some cases it can get monotonous especially in situations where the team isn’t progressing very fast.  Another option is to take the Kanban approach and focus on the board, starting with the right-most column and working towards to the left.  It kinda goes against the Agile mantra “Individuals and interactions over processes and tools” but it can  re-invigorate your daily standups. Furthermore, there’s no reason why you can’t go back to the 3 questions later on.

Estimations can be really helpful when planning a release or an iteration.  But in some cases the return on time  invested (ROTI) can be quite small.  Whether you’re doing affinity estimating, poker planning, or t-shirt sizes, the  practice of estimating is not an exact science and it never will be.  The #noestimates movement has become quite popular.  I was against it at first but I was finding that some portion of project work is absolutely necessary  (whether you want to do it or not).  So why waste time estimating when you could be spending that time getting the  work done.

For the most part, going back to the team is a great way to keep everyone engaged and hear differing opinions. There  are many other benefits but I won’t get into all of them. Sometimes, uncomfortable situations arise that may be  better dealt with outside of the team.  For instance, you may have a team member that just isn’t a good fit and  never will be.  You could try to engage the team and get them to make a decision (in terms of termination).  But you  may be putting them in a awkward position.  Chances are they’ve never been asked to determine someone’s fate and nor  do they want that responsibility.  Also, they have to work the individual under scrutiny while pretending they’re not  privy to the private conversations.  So in these special circumstances it may be prudent for the Scrum Master or  Product Owner to make the decision and move forward.

Final Thoughts:

Letting go isn’t easy, but it’s important to read the situation.  If a process isn’t working or if people are telling  you what you don’t want to hear, maybe it’s time to make a change. Just because something worked really well in the  past doesn’t mean it will continue to work well for every situation in the present and future.

Don’t just do Agile.


Agile Reflection: Part II

I recently reviewed the books I used to prepare for the PMI-ACP exam.  I took that exam about 4 years ago.  If you’re interested in my quick notes see https://markrajpal.com/2013/05/09/pmi-acp-agile-certified-practitioner/

The experience of reviewing these books was analogous to watching a movie for the 2nd time. I picked up quite a few things that I completely missed or got completely wrong the first time through.

My suggestion is this.  Take some time to review the Agile material you immersed yourself in when you were at the “Shu” stage.  For example:

  • Books
  • Webinars
  • White Papers
  • Research Papers
  • Presentations
  • Study Guides from course
  • Notes from conferences

As you’re reviewing the material ask yourself, do you agree/disagree?  I feel this is an appropriate question to ask because at this point you’re probably at the “Ha” or maybe even “Ri” stage.

I’m not suggesting you go back and re-read everything.  But you may want to flip through the material and pay special attention to tables & figures, and maybe read the end of chapter summaries.  Is there anything you completely disagree with and maybe even with the Agile community at large?  Maybe it’s worth sharing.