Know more and connect with me on [Linkedin Profile].

Sunday, September 25, 2016

Google Maps and Agility

I commute driving my car almost daily from 2 to 3 hours, . I live and work in one of the biggest and busiest cities I think, Cairo. If you are not regularly commuting in a busy and a big city, possibly you cannot imagine the hassle and uncertainty of it. It is disappointing. I face unexpected congestion randomly and have a very limited clue on how to manage my trip. Sometimes, I find unexpected congestion, and change my route to another one, assuming it is faster, to find it much worse. Actually I cannot be sure, as I do not have knowledge to be sure. With fear and ignorance, my commute is a misery.

Last year, I started to use a local mobile application named "Bey2ollak". Bey2ollak is an Arabic word means "He is saying to you". Yes, too much English words in only one Arabic word, that written in English characters and Arabic numerals! Bey2ollak is a social mobile application  who breaks famous route into segments and enable commuters to rate the segment from busyness perspective. A rank from "Perfectly Clean" to"Too busy - Avoid" is used. They use nice smiley faces as in the picture. It enables users to easily register account and post comments also. That is all. Recently they added more features but I am talking about my past experience and not evaluating the current state of the tool.

Using Bey2ollak, before going to work or returning back to home, I used to check my route conditions and decide if I should go home now, in which route or if it is better to stay an extra couple of hours at work until the road congestion resolves. Generally better than before, but I still has several pains:
  • The application does not propose different routes. 
  • I have to design my route myself, by selecting all segments manually.
  • Commuters rate segments manually. (Later, they made it automated if you open your GPS)
  • There is no time estimation for the entire route.
  • Sometimes people report on the wrong route segment.
  • Many times reporters got very emotional and start cursing the traffic and the city!

Google Maps app was available at that time, but was not handling traffic conditions of my city.

Recent months, Google Maps added  traffic conditions, and trip time estimation features. Now, I set my destination address, then it displays different routes with time estimates. It highlights parts of the road that has congestion and shows how much time it will delay me. Not only that, as I drive the selected route, it alerts me of better routes that become available. When the situation is changed, it alerts me of a new congestion ahead and tells me how much time it will delay me. 

With all these live information, my commute emotional experience is changed completely. Frustration of uncertainty and limited visibility are eliminated. The road conditions are not enhanced at all, but now, I have visibility and timely information to manage the situation and reduce its adverse impact on me. With Maps, my situation is changed. Even in difficult busy days, which I cannot control, the information given by Maps is calming. I no more got disastrous ambiguous situation hitting me as an unexpected mine. It relieved my emotions that, whatever the route status, I have power of knowledge to decide my route with accurate predictions and choices.

Yesterday, it popped to my mind that, our Agile approach (Typically Scrum) has similar characteristics. It enables me to manage the uncertainty and enables the team and Product Owner to decide what to do. Agile planning and tracking will not prevent problems (like in Maps), but it helps you track them down and helps you to manage the uncertainty inherent in software development. Let me highlight some Agile/Scrum concepts that helps:

  1. Relative size estimates done by the whole team without political pressure from management will help Agile team quantify reliably the amount of features required for the next release.
  2. With Done Definition that treats completeness as 100% criteria. It enforces the team to reliably finish valuable requirements completely to get the score of the finished stories. If not completely done per the Done Definition, they earn zero. It frees them from debating whether some requirements are finished by 60% or 80%. And hence enables more reliable progress visibility.
  3. With every sprint, we measure how much story points are completed. It gives a strong sense of our progress and our velocity regarding the required scope of work. 
  4. If problems happen, and it will, we can re-plan the remainder of the release accordingly.
  5. With Burn Down charts and daily Standup Meetings, the team can spot impediments and delays very early. It enables the team to react very fast to impediments and issues.

So, these Agile concepts/tools does not eliminate uncertainty or complexity of developing software, but it sets the stage to reliably navigate them. It helps in the same sense that Maps helped me to manage the complexity and uncertainty of my commute. Or at least, this is what happened with me.

Wednesday, September 14, 2016

Joined Happy Melly

I just joined @Happy_Melly network! and became a supporting member.

Why is that important?
I love my programming work and find it a joy and it was miserable why current management practices make people unhappy and disappointed unnecessarily. But simply I have no solution. I worked as a manager for 8 years and still can not find how to really manage the right way.

My exploration started by discovering Agile and Extreme Programming and found ways to find joy while developing great application. What was really great, is finding that joy on the team level.

Next, I discovered self organization through Open Space Technology by Harrison Owen great book and mailing list. I learned that, we are already self-organized and happy creatures and poor management just delays us and makes us unproductive and unhappy. But still something is missing in the buzzle.

That missing thing is uncovered recently. I discovered Management 3.0, and found the whole concept of self organization and Agility expanded to all areas of management, even areas that seems untouchable such as performance appraisals and bonuses.

I am learning and exploring all the time, very soon I will share with you my new stories.

Be Powerful Be Happy

Friday, September 09, 2016

Session Review: Next Evolution of Agile Leadership Roles

Session:  Agile Project Manager, Product Owner and ScrumMaster are all broken - The Next Evolution of Agile Leadership Roles
At:     Holiday-inn Hotel ... City Stars, Cairo, Egypt
Date: 8 Sept 2016, 


There was a QA session followed by a session by Ahmed Sidky. My comments here are related to Sidky session.

In my opinion, he was presenting his experience in managing ownership and accountability in his Riot Games company.

First, he showed that, after joining Riot, he found the traditional Agile roles are confusing and makes it difficult to decide which one is really accountable for team results. That situation pushed him to experiment and come up with a different model.

Sidky broke up responsibilities into 35 distinct responsibilities. He was presenting them in the form of plastic cards, something similar to Planning Poker cards but double its size.
At Riot Games, they created 4 leadership roles as following:
  • Team Captain: This is the head of the other three leads. He is accountable about the project. He is the only accountable person in the four leadership roles. Later on, I will explain what is meant by being accountable.
  • Delivery Lead: Responsible about delivery deadlines.
  • Product Lead: Responsible about the product scope, something like Product Owner, I think.
  • Craft Lead: Like Test Lead, Developers Lead and so on. He is responsible about the craft quality and standards of his/her team’s work.
Sidky gave color for each leadership role, for example red color is assigned to the Team Captain. He showed us physical hats with different colors. The only problem is that; the size of hats is a little bit small to be wore by humans.

From the 35 responsibilities, there are 10 that are hard coded to each role and cannot be changed. 

First, the project team conduct a workshop with team members. They list the other 25 role cards and they collaborate to assign each of these responsibilities to these hats/roles.

Then, the team self-organize to assign a team member to each role/hat. There may be some additional conversations and negotiation until the team agree on the result. The result will be that, all 35 responsibilities are distributed on the four roles and a team member is assigned to each role/hat. Each team member can have one or more hats, or none at all of course.
Regarding accountability, Sidky described three steps for poor performance evaluation. First Step is to conduct a meeting, understand the problem, and what to do about it now and in the future. There is no blame culture, any one mentioned in conversation is invited immediately.

Second Poor Performance case: Just like the first one. I expect the conversation will be more difficult.

Third poor performance case: Here is where management will take action.

He mentioned that, we cannot overlook that, there are poor members and good members. In some cases, you have to fire poor performing members.

Note: The above description is a representation of my understanding to what Sidky proposed. It may be incomplete or inaccurate. Your feedback is welcomed.

My Personal Notes:
  • I find it is OK to design your role in your organization. Feel free to break the famous Scrum Roles SM/PO if it makes sense. According to Agile Manifesto, roles are not included in Agile Values or Principles. It was described in Scrum and many people find it useful.
  • As Sidky said that, this is RI phase of inventing things. If you are an Agile beginner, be careful and follow some well-known recipes, such as Scrum or Kanban.
  • I find it very self-organizing and matches Agile spirit to let the team collaborate on responsibilities and role assignment.  

It was a fun event, Sidky enjoys a sense of humor. Here are some pictures from the event.