When Failure is acceptable, Success is more likely.
– Michael (Doc) Norton @DocOnDev
– Michael (Doc) Norton @DocOnDev
Image source (prior to modification): beliefsoftheheart.com
Most of us have worked with that one software developer whom the entire team looked up to when in crisis, the one who would come through despite obstacles, the one who would have answers to everything. To borrow a phrase from Star Wars, he was “the Chosen One” (I just had to get a Star Wars quote in). There is nothing wrong with the above except that it is “one person”. If your software strategy is hinged on one person, then you are setting yourself up for disappointment (and possibly failure).
While it is great that you have a superhero in your team who delivers when needed, what you really need are more everyday heroes. And not those one-man-army type ones but the ones who can work with a team and use their skills in harmony with others a la Fast and Furious. Yes, in a team with diverse skills and competencies, not everyone can work on everything. But it should not be the case that it is just one guy bailing the team out every time. Don’t get me wrong here. I am not advising a culture of mediocracy. In fact, I furiously fought against a culture of mediocracy at some of the organisations I worked for previously. I am all for making superheroes out of regular joes. All I am saying is that a culture dependent on superheroes to deliver instead of a team to do its job is a wrong culture.
It is not just about contingency planning (your superhero is sick or worse, leaves the company), it is also about building a culture where all the team members feel equally important and responsible. To take the analogy of Indian cricket team a few years back, some opening batsmen would play fast and loose because they knew Sachin Tendulkar (one of the best batsmen in the world) would be there to score big time if they fail. And fail they did. And when Sachin failed too, India lost the match.
We have been raised in a culture where it is good to be a maverick. Most of the movies of our times highlight that fact. But I would almost always give preference to a well-performing, highly-cohesive team of regular heroes than one that is dependent on its superhero. As the old African saying goes, “if you want to go fast, go alone; if you want to go far, go together”.
Image Source: kcet.org
Many times I come across quotes, phrases, small nuggets of information that seem profound yet do not require an entire blog post. Henceforth, I will post such pieces as “microblogs”. No fluff, no detail, just the condensed version.
Image Source: lipstick-pictures.blogspot.com.au
Oh, the confusion! Saying UX when you meant to say UI and vice versa? Believe me, I have been there. I have watched designers and UX experts cringe when I mixed up the words. I think I understand them better now. And not because I got myself a certification in either. It’s because I am a foodie! So, I will explain you the same way I understood it.
How many times have you dug your teeth into a pie (or a burger for that matter) that looked tantalising only to realise that it didn’t taste as good. All those pretty pictures of food in advertisements (I call it food porn) that left you salivating and yet had you taken a bite of it, you would have probably ended up in the hospital. That’s all fake. But I don’t want this post to turn into a rant on how advertisers mess with our senses so I will stay on course.
How the food looks is its UI (User Interface). What you feel when you eat it is its UX (User Experience). If it looks good and tastes good, you are a winner (and so is the chef!). However if it looks good but doesn’t taste so, then you might not visit that eatery again (don’t go there on a date). If it doesn’t look great but tastes awesome, then you might want to go there repeatedly (it might be a tad difficult for the eatery to get customers in the first time though). Now let’s see how does this analogy work with digital screens (websites, mobile apps, etc.).
When you look at a website or a mobile app that looks really slick but is a nightmare to work with because of convoluted workflows, you have a great UI but bad UX. The opposite is when you have an average or poor looking screen but it does what it says and doesn’t tax your brain in the process. That is when you have a poor UI but good UX though such scenarios are rare. A winning website or app not just looks awesome but also lets the user cruise through it leaving him with a sense of satisfaction and accomplishment.
Sometimes the experience with food goes beyond eating and involves digestion or even longer term affects. You had a great meal but it made you feel bloated and you ended up farting all night much to the chagrin of your partner. Or it gave you a sore throat and you had to go to the doctor to find some relief from incessant coughing. Disclaimer: As someone who loves to try new food from different eateries, I have fallen victim to both the above scenarios. Similarly, it’s possible that the user experience with a website led you to believe that you had set everything properly only to realise later that it wasn’t so and you had to go through a lot of trouble fixing it. That qualifies as poor (if not terrible) UX too.
Summing up, don’t just put lipstick on a pig. Before you make the website or app pretty, make sure it works well too. If you really want your burger to give an orgasmic satisfaction to its eater, make sure its done well and looks good too. Now all this talk about food has made me hungry. I will go and eat something.
Image Source: chuansong.me
I recently attended a meet-up where one of the presenters spoke about Theory of Constraints. While a lot of us use this term, only a few truly understand it and can put it to good use. Luckily for me, the presenter was one such person and did a great job at explaining it to the audience. As he went along explaining the paradigm to us, I couldn’t help but notice how nicely it fit with the Agile and Lean philosophies. This blog post is about that connection.
But before we go any further, let’s first understand what ToC is. The website for Theory of Constraints Institute describes ToC as a way of identifying and managing bottlenecks that restrict the entire system’s output. It is a set of management tools devised by Dr. Eli Goldratt and introduced in his book “The Goal”.
ToC says that, at any point of time, there is a single constraint throttling the system. Eliminating/ easing this constraint improves the output. You then have to evaluate the entire system again to find out the next constraint. Rinse and repeat.
The above has an interesting corollary. An hour lost on the constraint is an hour lost by the entire system. However, an hour lost on a non-constraint is no loss for the system overall. So when we continue to improve something and still wonder why there is no improvement with the system at large, possibly we are trying to optimise something that is not the constraint choking the bigger system. Yes, we might still end up improving a sub-system but local optimisations do not help the larger scheme of things.
Eli structured the following 5-step process for ongoing improvement:
Image Source: Theory of Constraints Institute
When we get bowled over by methodologies like Agile, Lean, Six-Sigma, etc., we forget that these methodologies primarily help to Elevate the Constraint (Step 4). Some of them might also contribute towards other steps but we still need to perform them.
If you throw a stone at a congregation of software people, chances are you will hit an Agile Coach. Being an Agile Coach is almost becoming a fashion these days. “I am an Agile Coach”. I get to hear this quite a lot these days. It’s like ScrumMasters of yesteryears have now graduated to become Agile Coaches.
Not to condescend all Agile Coaches out there (well, I am one of them), I see lot of asses in lions’ skins (ass means donkey here, not what you think!). Yes, some of these Agile Coaches have truly risen from the ranks, worked their way through the trenches, and have earned their stripes (I come from a family with a long tradition of serving in defence forces). Such coaches have reached the Ri stage of Shuhari paradigm. They really know their stuff and are making significant impact with the teams/ organisations they are working with. However, there are others who picked up a ScrumMaster certification after two-days of training and became Agile Coaches overnight. Some of them even flaunt certifications across methodologies – Six-Sigma whatever belt, PMP (seriously?), etc.
Being an Agile Coach is not very different from being a sports coach. To begin with, you can’t be one just by passing a theoretical exam and having worked very little in the field. You need to have years of experience in the field and should have mastered some aspect of it. Like a sports coach, you should know that not all methods apply the same way everywhere – different teams have different training needs because of their own strength/weakness combinations. There is no one-size-fits-all approach. Yes, the basic principles remain the same but you still need to customise the treatment for each team.
And to make matters worse, such Agile Coaches are being hired by organisations (as employees on payrolls or as consultants) eager to get on the Agile bandwagon. And when their methods don’t work in such organisations, Agile gets bad name. People think, “maybe Agile is not for me”. Well, that could be true with some teams/ organisations but a bad implementation of Agile by a worse “Agile Coach” should not be considered a representation of what Agile truly has to offer.
I would just end this rant hoping that professional astuteness would trump fancy titles.