From Bulky, Fat ..to …… Lean & Healthy!!!

Read the heading again, nope not an easy task… you might say - I tried so many times but doesn’t look like I am losing any fats or I will start doing something about it from tomorrow (and tomorrow never comes) or I am too busy at the moment, let this phase go and I shall start my work-out. Few of my friends even argue, you need to have fats/bit of tummy that’s when the tuxedo or blazer suites you well

I bet many of us who are reading this and are on “heavier” side of BMI (Body Mass Index) knows what I am taking about. Basically what is happening – we have started “enjoying” the “fatness”, even though we know that extra fat is not healthy as soon it will start impacting our performance and comes with a hefty cost we still carry it and come up with “innovative” excuses for not taking any action to reduce it.

Yes, there are people who does take action for few days (jogging around the blocks or joining gym) but not able to continue it consistently.

Do you see some pattern here? If we/our processes are fat, somehow we start love it having around (fat), we just convince ourselves that .. that’s okay, it is not much, or I shall work on removing/reducing the fat (wastage) tomorrow coz I am too busy now.. and over time we start even acknowledging it as great “possession”… 

Hard truth - the fact remains – Fat(wastage) invites issues, slows our speed/progress, hits us both mentally and physically and starts spoiling our environment slowly...almost unnoticeable.

So how do you start towards the “Lean” and “Healthy” journey?

To start with, you need to ignite (and keep up the flame) the thought of becoming “Lean”.

How?

First, You need to visualize clearly in your mind – what is your goal (end value – in terms of specific weight, size etc).. what value/benefit you would bring to yourself or people around you when you are a lean-mean machine (Identify Value)

Second, identify and organize your steps, actions and things to achieve the end goal. Steps could include identifying a gym, searching a joggers track/park, buying jogging apparels/shoes, selecting energizing music track during the course (I personally prefer audio books), eating habits - what to eat what to avoid or may be a companion who always motivates you… that is list of everything that serves you as Value stream to achieve your end goal.

Third, create a habit, rhythm a flow … best way to do it to internalize the process. Coz when it comes from within, you will start enjoying it, you will not take it as burden. It should happen in a way such that you should be drawn/pull towards your “end goal”, as you are with your “Value stream” and “flow”, you will start observing that waste is slowly getting removed/ disappeared as you would start taking initiatives to eliminate the obstacles in your flow. So, who is removing those hurdles and impediments? It is you, as you've started enjoying the journey, you've started feeling light and healthy. Remember -You don’t just create the flow – maximize the flow / the grind.

Fourth, as things are in flow, you ought to motivate/empower people around you. After all whats the fun in keeping the joy and benefits to yourself when you see that people around you are still carrying the burden of bulkiness? Tell your success stories and benefit of staying lean, light, healthy and energetic. Guide/help/train people around you to take lean journey with you. Create and standardize the process, a kind of ready-reckoner for people to refer and inspire and empower people to follow the path for great results.

This last one, Fifth, circle backs to the entire process. In simple terms, how do you optimize it? Make it work better? It is Continuous improvement.
PDCA – Plan, Do, Check, Act/Adapt offers us a methodical way to solve problem and improve. It is about observing each of our steps to see what works, what doesn’t and what can be done to improve/optimize the entire life-cycle of becoming lean and taking those actions. It is about always trying to seek optimal and innovative ways stay lean all the time.

Follow this and I bet you will be a lean-mean machine soon...and if you pay attention to the "Fifth" step, you would stay lean.

What more, apply the above five steps/principles at your work and soon you will establish a “Toyota” like culture at your workplace.

Wondering can we use the metaphor above and map it to the five principle of “Lean Thinking”? (check the text in bold)

What do you think?!

PS: About me, nope I am not Lean yet, but nevertheless I am already on my way and started enjoying the journey itself :-)

Reducing Technical Debt - My code, my responsibility

• Let's get the core functionality implemented and tested first and in later release we can retrofit and concentrate it on quality...
• Coding standards?! But, I always used to write in this way..
• I have already developed 90% of the feature during the spike itself, it is just matter of promoting it to integration...
• We discussed this during code review, but since functionality was working we just avoided to touch the code..
• I was in hurry...
• What difference does it make anyways?
• This piece of code doesn't need to follow the framework, it is a "different" functionality...

Sounds familiar...? Yes, I too have come across this and may other so called "genuine" reasons when I see some features getting dragged for iterations or even PIs (Program Increments) together. Unfortunate, but true.

Now how do we address this? Simple, by educating them on basics, be it "software engineering" practice or basics of agile principles.

Here are some questions to ask ourselves or teams on how do we avoid or reduce technical debt -

• Prevention is better than cure... yes, first step is to prevent it from happening or reduce the possibility of it happening it to maximum extent. Gather the team, architect, SMEs etc. and ask them - How to avoid creating technical debt in first place rather than dealing with it at later stage?
• Does the team understand (and have access to - this is funny but I have to mention it explicity) application framework and coding standards?
• Does my team understands the overall architecture of the system as well have fair idea about enterprise architecture? Is team align and following the same architecture?
• Is there anything already developed that can be reused?
• Is my System Architect collaborating with the team?
• Is System Architect aligned with Enterprise architect?
• Was the estimation done by an individual "bright" member or by the team?
• Do I have good DOD (Definition of Done) in place?
• Is team aware of NFRs (Non Functional Requirements)?
• Is team working on too many user stories in parallel?
• What are the software engineering practice that team follows?
• Was the design reviewed by someone else as well?
• Is my code structured and looks simple or complex to understand?
• Am I applying any design pattern thinking?
• Am I learning from past.. say retros, defects etc?

... and list can go on and on and on... Sometime team or the member involved can be bit in hurry or unaware or even lazy and would cut corners; but reducing technical debt is not a matter of choice, it is "responsibility" and we have to inculcate this habit in the team.

Here are some prevention-cum-cure tips:

• Get the entire team involved - Ensure that team has awareness of system and enterprise level architect - and proposed solution is aligned to the same
• Publish coding standards, guidelines to follow
• Ensure that team is collaborating with architect
• Help team identify the strategy - MBSE(Model Based System Engineering) or Set Based?
• If it is getting overwhelming, dedicate iteration(s) to address technical debt
• Encourage collaborative design
• Identify and suggest best software engineering practice
• Help team to develop a strong a clear and DOD for each delivery unit - be it user  Story, Feature or even Epic 
• Look back, refer to retros, defects past discussion and improve. Identify the defect patterns.
• Keep the WIP (Work In Progress) limits low.
• Plan the code/test coverage (TDD-Test Driven Development, BDD-Behavior Driven Development) better
• Level of automation planned and keeping the automation in sync with development
• Effective and frequent code reviews, preferably reviews of small chunks of code rather than taking it up as a last activity once the feature is developed
• Encouraging design pattern thinking
• Clear understanding of NFRs (load, response time, concurrency, security etc.)
• Simplifying the code rather than making it complex and unstructured
• Promote pair programming and share your insights about good and bad code and promote the learning about preventing the technical debt rather than fixing it later. 

There could be many more... and I welcome readers to add them in comments.

As uncle Bob says -

“Go well, not fast. Care about your code. Take the time to do things right. In software, slow and steady wins the race; and speed kills” –Robert C. Martin , president of Object Mentor and agile methods author.