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.

Agile Reflection: Part I

In the midst of an Agile adoption whether it be scaling Agile or moving from a collocated model to distributed, there can be a tendency to keep ploughing through and crossing your fingers in the hope that the end is near.

My first point is that the end is never going to come.  I know this sounds cliche but it is true, Agile is a journey not a destination.  Instead, you should be looking for ways to improve as you progress.  That does not mean addressing the surface level symptoms.  The root cause needs to be determined.  Only then can you tackle the problem at hand.  Implementing bandaid solutions are likely to provide little value and will just add frustration.

Below are some questions you may want to ask yourself and others.  And not just those were directly/indirectly involved with the adoption but new comers to the organization as well.  They may have a fresh perspective that is worth noting.

Thought provoking questions:

  1. What were some of the biggest hurdles?
  2. Who were some of the biggest adopters?
  3. If you could go back in time what would you do differently?
  4. Are you pleased with the progress?
  5. What was your biggest surprise (whether it be good or bad)?
  6. Was there ever a time where you thought we should go back to the old ways of doing things?
  7. What was your opinion of the training you received?
  8. Does the Agile progression feel like it has stalemated?
  9. Were the right people involved?
  10. Was it worth it?


Top 10 signs you had a successful Agile project

Before I get into it, there are 2 things I should point out.

Point #1, this is by no means a complete list.  I’m sure there are hundreds of signs that point to Agile success.  These are the top 10 that stand out for me.

Point #2, you can experience Agile success without uncovering all 10 signs.  But if you’ve truly reached success then you’re likely to encounter most.


  1. Everyone is sad to see the project end

  2. Exceptionally high velocity was achieved
  3. Low defects.
  4. Lots of chatter & laughter
  5. People are still talking about project months after its completion
  6. Everyone outside the project is asking “How did you do it?”
  7. Sprint goals were achieved almost every sprint
  8. SMART goals that derived from the retrospectives were also achieved

  9. Management support is evident even if it isn’t plentiful

  10. The Project Manager role is questioned