Another feather in the hat...

Phew... took a while to get ready to take the exam!!

agile: (adjective) able to move quickly and easily.

... and there you have the official definition of Agile(1).

Similar: nimble, lithe, spry, supple, limber, sprightly, dexterous, deft, willowy, graceful, light-footed, fleet-footed, active, lively, quick-moving, nippy, twinkle-toed, fleet, lightsome, alert, sharp, acute, clever, shrewd, astute, on the ball

Opposite: clumsy, stiff, slow, dull

... and in the software world,

"relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans."

Welcome back.

I recently came upon a online article on Scenario-Focused Engineering: Take an Experimental Approach which has an interested snippet on Agile. Copy-Pasted below verbatim.

Agile was born from the software developer community in response to the need to build higher-quality software with less wasted effort in an environment in which precise customer requirements change over time and are hard to articulate upfront(1). Agile was invented independently by software engineers, but fascinatingly, it aimed to solve a lot of the same root problems that user-centered design aimed to tackle.

If you’re working on an Agile team, a lot of this chapter probably feels familiar. You already loop quickly in sprints, likely somewhere from one to four weeks in length. It’s easy to squint and see how one loop around the Fast Feedback Cycle could map to an Agile sprint, complete with a customer touch point at the end to get direct customer feedback on the increment you just delivered. It’s likely that some of the same activities we discussed already occur during the course of your sprints.

Scenario-Focused Engineering differs from Agile in two main areas, which we believe help fill in some missing gaps. First, we believe that it’s not necessary for every sprint to deliver shippable code(2). In early sprints, it’s often more efficient to get customer feedback on a sketch, mockup, or prototype before investing in production code. However, we completely agree that getting customer feedback at the end of every sprint is absolutely essential, whether that sprint built prototypes or production code.

Second, we believe that the product owner is actually a mythical creature. We challenge the idea that any one person on the team, no matter how senior, no matter how often they talk with customers, can accurately channel exactly what real customers need and desire and provide accurate “customer” feedback at the end of a sprint. Agile oversimplified the whole business of understanding customers by giving that job to one person—the product owner(2). Anything beyond the most basic customer needs are too complex for that approach to work reliably in today’s market. We hope you’ll find that the ideas in this book give you practical ways to break out of that mold and actually talk to real customers(3).

Interestingly, most Agilists have concluded that shorter sprints work better than longer ones: sprints of one to two weeks are better than sprints of three to four weeks. We have come to a similar conclusion; you should probably aim to finish a single cycle within two weeks(3). Left to their own devices, most teams will spend too long on an iteration. Time boxing is key to keep people moving, and Agile sprints are a really natural way to time box on a software project.

Here are a couple of things that I agree and disagree in the above paragraphs,

Agree -

1. move quickly & easily - that is the crux of Agile. If Agile does not allow a team to be nimble and dextrous then it is not helping. This certainly does not mean individual team members are themselves fast which is a common misconception that most sr. leaders have. The movement is never within a sprint. It is always at the boundary of a sprint.
2. It is really not necessary for a team to deliver shippable code every sprint. This is another common misconception that most sr. leaders and especially product managers have that if you are not shipping code at the end of the sprint then you are not delivering anything worthwhile and hence have not done ANY work. Software development is a thought process even the 'Build' stage of the Fast Feedback Cycle, can be broken into 'Design', 'Development', 'Test', 'QA', 'Deploy', etc. which is a much longer and involved process.
3. Two weeks is the sweet spot for a sprint. I've worked with teams have have 4 week sprints and also with teams that have 1 week sprints. In neither of them did I see an improvement in meeting sprint goals. In many organizations, this is usually left to the team and I completely support that. Some teams work well in 4 week sprints and some in 1 week sprints. At the end of the day, is the team delivering an incremental change in the product.

Disagree -

1. If customer requirements are hard to articulate upfront, to me, that means the customer does not know what they really want. If a customer knows exactly what they want, it should be much easier to articulate it and convert it into a technical requirement specification. Is anyone ever going to tell a customer, 'You have no idea what you need?', I doubt that. Hence we continue to live with customer requirements that are hard to articulate and unclear.
2. There needs to be a designated product owner for a product. The job of the product owner is not just 'talking' to customers but much more than that. This is where most product owners fail. I've come across product owners that are totally customer focused and detached from the development team. They have no clue as to what has been shipped and what has not. On the other hand, I've come across product owners that are totally development focussed and lose sight of the customer. It has to be a balance.
3. If everyone in the team ends up talking to real customers (or end customers) then who is going to do all the work? It is not possible for an individual to talk to real customers, 'Observe', 'Frame', 'Brainstorm', and 'Build' at the same time. It is different if your customer is not an end customer but maybe an intermediate upstream/downstream team that is using/supporting your product.

Let me know what you think in the comments section.

Jyothin

Covi-blog

Dear Reader,

Hope you are doing well, healthy and fine in this pandemic. We are all battling this pandemic in our own ways and so am I along with my family. We are all deep into the battle against COVID-9 and there is hope that we will be out of this soon. However, I don't think we will ever get back to our old way of life.

This blog is not about my thoughts on the pandemic but a Ctrl+C & Ctrl-V of an article I read that summarizes the situation today.

From Kevin C,

I’m reading lots of information about the latest virus “surge” – as virologists and epidemiologists all over the world try to make sense of conflicting information on the coronavirus infection rate trends.  Rather than debate what is/isn’t a surge, I am going to stick with an analogy that makes the most sense to me right now: a forest fire.

A forest fire starts with a spark – it could be from lighting – it could be from a careless camper who doesn’t extinguish a campfire fully.  While the cause of the forest fire is something to investigate, the more urgent question is how to best limit the amount of damage the fire causes.  How, where, and when the virus started will be important to determine one day, but the pandemic has been underway for more than a year now – and the battle lines are all about damage control – just like a forest fire.

 

The forest fire grows and spreads by finding fuel – dry wood that is easily consumed by the inferno of a forest fire.  The more it finds, the hotter it burns.  This coronavirus (SARS CoV-2) is no different.  It spreads by finding fuel (humans) who lack sufficient immunity to fight it off.  Forest fires are often accompanied by hot, dry wind – which accelerates the spread, and makes the resulting fire larger, more explosive, and more difficult to fight and contain.  In the case of SARS CoV-2, the hot, dry wind can be compared to the mutations (variants) that are occurring – changes in the virus that make the contagion shift shape and direction, making it harder to fight and contain, just like a forest fire.

 

The last part of the analogy is the firefighters, the brave men and women who expertly fight the fires, and risk their lives trying to limit damage to life and property.  I think of vaccines as the firefighters of the pandemic.  Vaccines are racing against the hot, dry wind of the variants.  Where the virus finds dry wood (unprotected, unvaccinated humans), we can expect “hot spots” or “flare ups”.  And those hot spots will burn until they are contained – either through non pharmaceutical interventions, like physical distancing and face protection – or until they can’t find any more dry wood to burn – due to immunity conferred by having had the disease, or by immunity conferred by vaccines.

The fight against the virus is very active right now, but only in certain parts of the world.  And just like what happens during forest fire season – there are ebbs and flows – progress and setbacks – that make it very hard to keep score as to which side is winning.  In the U.S., Europe and Brazil, it looks to me as though the virus is currently winning.  While vaccine distribution is ramping up in many places, SARS CoV-2 had a massive head start, and is not having any trouble finding plenty of dry fuel to burn.  Global infections are increasing by 30% (14-day average), a sign that the virus continues to build on its lead in certain parts of the world.

 

Forest firefighters often encounter people who don’t want to evacuate or leave their homes.  They want to stay and “ride it out” – just like we find with hurricanes, or floods, or other natural disasters.  They have many reasons for wanting to stay in place – they don’t believe the fire will affect them – they’ve survived prior disasters before, so why will this one be different?  They don’t like anyone telling them what to do.  The list goes on.  We see the same beliefs and attitudes playing out in this natural disaster.  Although I am sure the firefighter banging on the door telling someone they really need to evacuate is incredibly frustrating – in the end, people are going to make the decisions they think is best for them.  It is hard for me to understand this, but I’ve come to understand I don’t have a right to impress my values and beliefs on others in this regard.  All we can do for those who are vaccine hesitant is to educate and answer questions in as balanced a way as possible.  For the truly “vaccine resistant”—like those who choose to shelter in place during a forest fire—I accept we’ll need to focus our attention elsewhere.

 

Forest firefighters are very confident in their tools and training, but they realize that their tools and training are no match for the power of nature.  When temperatures are high, or winds are strong, forest fires are impossible to extinguish – nature is in clearly in charge – no matter how talented the firefighters might be.  But when it begins to cool – when the winds die down – or best of all, when it begins to rain – firefighters make enormous headway, and eventually, the fire is extinguished.   

 

Back to the other side of the analogy one last time:  we badly need some “rain” in the battle against the pandemic.  We need the vaccine distribution process to strengthen.  We need non pharmaceutical interventions to stay in place for longer.  With every vaccination, we throw water on the dry wood – and we make it harder for the virus to find fuel.  Each day, millions of people all over the world are receiving the vaccines, which will speed up the end of the pandemic.  

 

Like a forest fire – it is really a race against time – to give the firefighters a chance to succeed.

Hope you found this summary useful. Thank you Kevin C for this analogy.

Until next time.

Jyothin

PS: Let me know what you think in the comments section.

Return of the PHB

Dear Reader,

I never thought I would see this day but nonetheless I have. I've actually encountered a PHB in real life. No really... I'm not kidding. I've really encountered one in real life. And this PHB exactly matches the one in Dilbert's comic strips. For those who don't know, PHB stands for 'Pointy Haired Boss' and is a character in Dilberts comics by Scott Adams. PHB is best described by the first few lines in his Wikipedia page. Copy and pasted below verbatim,

"The Pointy-haired Boss (or Pointy-headed Boss often abbreviated to just PHB^[1] or "The Boss") is Dilbert's boss in the Dilbert comic strip. He is notable for his micromanagement, gross incompetence, obliviousness to his surroundings, and unhelpful buzzword usage; yet somehow retains power in the workplace."

AND

The PHB's real name is unknown in the comic...

As much as I'd like to tell you the name of my real life PHB, I'll take a hint from Scott Adams and not name him/her.

What I've come to realize is that it is just not possible to deal with this person. Initially, I used to think that he/she will get over it, it can't be possible that someone is so much like a PHB. I've tried other ways to deal with situations but those too didn't help. Then I recalled PHB in Dilbert and started viewing things from a different lens. It then all made sense. I was able to relate to PHB's behavior in just the same context as in the comic book. Similar situations, similar behavior, and similar results. It was an eye opener and made it a little easy to get through a work day with a PHB around. I could not stop laughing when I actually came across some situations in real life as depicted in the comics (you can read some good ones at The 10 Best Pointy Haired Boss Moments From Dilbert )

I also realized that there are subtle ways to deal with them without them knowing. Here is one link that I found.

Leadership: Dealing With the Pointy-Haired Boss

Here is another one that I came across...

The Seven Habits of Pointy-Haired Bosses

This one was an interesting read...

The funny thing about PHBs are that they just don't know they are PHB material. They just survive and make other's lives miserable without even realizing it. To top it off they feel they are doing us a favor by being this way. Clearly trying their best to reach the top of the Moron-mountain.

Here is a typical conversation with a PHB.

• Dilbert: I discovered a hole in our Internet security.
• PointyHairedBoss: What?!! Good grief, man! How could you put a hole in our Internet?
• Dilbert: I didn't _put_ it there. I _found_ it... And it's not...
• PointyHairedBoss: It's your job to fix that hole. I want you to work 24-7!
• Dilbert: Actually, that's _not_ my job. But I'll inform our network management group.
• PointyHairedBoss: PASSING THE BUCK! YOU'RE A BUCK PASSER!
• Dilbert: Forget it! There's no hole! It got better.
• PointyHairedBoss: That's more like it.
• PointyHairedBoss (thinking to himself): I fixed the Internet.

This actually happened to me but in a different context.

We've all encountered a PHB in our work at some time or the other. I was fortunate to have not encountered one for 16 years and then I did. It took me a while to get around it and face the facts. But when you see things from a PHB perspective... well they will make sense from a PHB perspective ;-).

Tell me about the PHBs you've encountered in your work in the comments section.

Until next time.

Jyothin

PS: Stay safe... from the PHB :-)

One 'Action Item' list to rule them all; my precious 'Action Items'

Dear Reader,

Welcome back. It has been a while since I've blogged and I certainly need to get back into a regular rhythm. Lately, I've been tied up with a long list of action items. We all have lists of items that we need to work on and get done. One list for yourself, one list for your family, one list for work, etc. 'ToDo' lists are a very useful way to keep track of the things one needs to do and make sure you get them done. They also serve as an effective way to not forget things and have them written some where for reference. For some, writing them down is a form of committing to getting it done. For others, crossing items off a list gives them a sense of accomplishment.

I too use ToDo lists. I have a ToDo list for things that I need to purchase from the grocery store. I have a ToDo list for things that need to get done in general, such as, 'Clean the car', 'Pay my insurance premium', 'Buy gifts for someone', etc.. They usually don't have a deadline associated to them. They are just there so as not to forget things. When an item on my ToDo list is time bound, I put in on my personal calendar. For example, 'Pay the electricity bill' is a monthly reminder on my personal calendar. Since the item does not really require any prior work, it transitions from an item on my Todo list to a reminder on my calendar. Items that I do on a daily basis, that I usually don't forget, or that has been trained by my muscle mind; I don't put them down on a ToDo list.

I've seen some people get really fancy with ToDo lists. Almost to the point that they have an item on their list, to create a new list. Even things as regular as brush your teeth or take a bath, are on their ToDo list!! But I'm sure they have good reasons for it.

At work, these lists are most often also called Action Items: things that need to get done by a specific person within a specific time frame. BUT there is a big difference when an action item is assigned by someone else vs. an action item that you assign to yourself. An action item assigned by someone else is, most often, perceived as 'extra work'. 'I already have a ton of things to do during a day and I certainly don't need someone assigning me more work'. Most often action items are not scoped out appropriately enough to know if they can really be done within the time frame or need more time or are simply complex enough to warrant its own list ;-)

At work, I maintain a list of items in a hand written book along with other notes for quick and easy reference in the future. However, for me it is just a way to not forget things or to refer to an important discussion point in the past.

I was once in a meeting where the meeting organizer was assigning items to someone who was not even in the meeting and not even in the organization!! In the next meeting, the meeting organizer was calling on to them to give a status update and they weren't even invited to the meeting. How wierd is that!! I've also been in meetings where the debate is on what exactly should be written as an item on the ToDo list!! And the person assigned to the item was not even part of the debate. How crazy is that!!

There is tons of research on why ToDo lists work and why they don't work. I haven't come across an article yet where a successful leader has said, 'I live by ToDo lists'. I also believe that's not how a leader should lead i.e. by making ToDo lists and assigning them to others. I don't do it.

ToDo lists don't work

Why lists don't work and how to change that

ToDo list alternative

So, what's next on your ToDo list? ;-)

Until next time.

Jyothin

Give a Chance to Chance Upon

Dear Reader,

We are in an era where everything is super precise. This is because new technological innovations are allowing us to measure everything to a very precise degree. Time, distance, events, emotions, habits, communication, thoughts, etc. practically everything can be measured in one way or another.

All this high precision data is helping us make better decisions, super accurate predictions and high quality assessments. In general, we are in a era where things are so precise that an individual can get siloed into his own 'precise world'. Take for example, Google search results. When the company started, results were great but there were also other results that were not very relevant. In 2018, Google search results are so precise that one does not even need to look at the 2nd result from all the results returned.

This leaves very little room for the user to 'chance' upon something that perhaps he is not immediately looking for but may be of interest to the user. Higher levels of precision leaves little chance to chance upon something whereas lower levels of precision gives a high chance to chance upon something. I have personally experienced this when I end up clicking on a search result lower down the relevance list that ends up taking me to other links and eventually I end up learning something new. Information that I otherwise would not have found and information that may be relevant to me at another time.

Lots of discoveries and innovations have also been chanced upon. Take for example,

18 Accidental and Unintended Scientific Discoveries that Changed the World

The higher the level of precision - lower the chances to chance upon. Like the illustration below, a simple black dot. It is precise and on the dot (pun intended). Very low chances of varied interpretations and its properties are well define.

The lower the level of precision - higher the changes to chance upon. Like the illustration below, new interpretations can be made from the illustration, new properties can be observed, different colors can be observed, etc.

What would be the right balance of precision and the chance to chance upon? I don't know and makes for an interesting scientific paper.

Those with a curious/exploratory mind would generally tend to go down the path of chancing upon something new even when they are not looking for it. Some companies use this behavior to their advantage and have algorithms integrated into their products that suggest the same, such as, "suggested link", "people who bought this also bought this", "friends of friends liked this post", etc. People are generally more curious about certain topics than others. For example, a 16-year old would be curious to know who in his/her class is friends with who (come to think of it this is a topic that transcends all ages 😉 ), who is married to who, who visited which place, who ate what and where and why and how, and so on. Makes for a great rabbit hole.

What do you think?

Until next time.

Jyothin M. Madari 😊

Quiznak - Lessons on team work from Voltron

Dear Reader,

I've been binge watching Voltron - Legendary Defenders on Netflix for the past couple of months and can't get enough of it. I first watched the old version Voltron - Defender of the Universe when I was a kid, waaaay back in 1990s and have always been a fan of the show. The idea of 5 lions coming together to form a lean mean fighting robot was truly incredible at that time. So, when I came across the new version of the show on Netflix I could not resist watching it.

Voltron animated series touches up on many aspects of leadership. Such as, ownership, insisting on high standards, obsession with a goal, invent and simplify, thinking big, bias for action, learn and be curious, earn trust, have backbone - disagree and commit, deliver results and more importantly collaboration & team work.

Team work can make or break the future of the team.

Some lessons from Voltron on teamwork and well functioning teams,

• Every member in the team has a unique skill/quality that is different from others and very unique to that member. This also includes the team leader and no I'm not talking about leadership skills. These are skills that are required for the team to achieve their goals.
• Members in teams communicate on the best way to achieve a goal/target. They may not always agree on the way forward but they decide on consensus and agree to the decided approach i.e. "Disagree and Commit"
• Each team member seeks support from others in the team at the different times and in different situations and let others take the lead if required.
• Humor is a great way to break tension in teams, break an argument, lighten the mood in difficult situations and get perspective.
• Members encourage other team members to excel in his/her own area of expertise and in the process uncover unknown strengths.
• A team works together when faced with an external threat, even if it is unknown and are dealing with a new situation.

What more do you think constitutes a great team?

Until next time.

Vrepit Sa!