Category: Tech

Categories
Opinion Tech

When Agile Hurts

I am an Agile Coach. I believe in the tenets of Agile and am sold on its value. I enable others to be Agile. However, due to misconceptions and bad applications of Agile, examples are plenty when Agile has hurt where it was meant to help.

One of the contrasts of Agile and Waterfall, is in the amount of documentation. Agile has taken the Use Case documents, the architectural and technical detail design documents and scattered the plethora of information into series of user stories. A user story is a tangible unit of work resulting in user delight in the form of a new capability. It takes user pain away in a meaningful way even if it is a small functionality such as radiating the status of an application throughout the process (on a website).

david-travis-554904-unsplash

The detailed requirement documents of waterfall take months in which timeframe paradigms supporting the requirement change. It is the reason why in Agile, we make requirements golden at the “Last Responsible Moment” in smaller, bit-size chunks. All this works wonderful in theory. In application if not done right, the machine breaks down. Listed below are Agile process smells or pitfalls hurting teams because of improper application or misunderstanding of the practice.

Vertical Slices of work in Siloed Component-Based Model

I repeat, “a user story is a slice of work resulting in user delight.” User could care less there are ten APIs to be built or which technical framework programmers must use. User only concerns in the capabilities they wish to receive from the product. Does the word processor I am using allow me to type my blog and share it in one click?

All good so far. It is the reason why we create stories vertically to focus on the impact to the end customer. This good intention gets punished in an organization fostering experts in niche skills instead of full stack developers. Let me rephrase. When software teams are built around key types of skills, the web service team, the front-end team building the UI, the database team, the Java team, the SQL team, the JS team…there is an awful number of handoffs, and consequently, waste in the system. This model produces experts in the field (DB guy, network gal…) with idea that experts will take requirements and deliver them in a mighty pace. It is a gain received at the risk of self-created silos. When the developed experts leave, they take with them their knowledge that should have been spread around to begin with.

So, in these organizations with horizontal teams a vertical backlog (for the end customer) results in stories with large cycle time (because teams need to wait for “the other guy” to commit, finish and deliver before they can). Large cycle times equal large feedback loops. Large feedback loops result in potential missed opportunities of improving fast and pivoting. Sometimes, it is okay. A lot of time, not. A vertical backlog for such an organization is dragging the horse to the well, but horse will not drink until all its buddy horses arrive.

Reduced documentation = no documentation

Delivering potentially shippable software in two-weeks cadence can be mind-boggling and chaotic (until it becomes muscle memory). Sometimes in the whirlwind of it all, hallway conversations take the place where key decisions on a user story are made. Agile is big on co-location and hallway collaborations, let me be transparent. Synergy existing in people eating together, coding together, storming together, and getting back together is priceless. But a hierarchal organizational structure with borders, requires alignment of understanding across those borders. For example, most large organizations have a separate end-to-end testing teams. When a user story is committed to be worked upon does the PO or the developer on the team or the end-to-end tester, do all of these cross-functional units perceive the requirement with one lens? Are all of them included in these hallway conversations? Same argument for distributed teams.

In the waterfall world, I can confidently say the documentation is organic because it is instituted and reviewed multiple times. So, where its drawback lies in the lack of speed to respond to change, the pro is requirements when well-written are clearly understood and prescriptive. Can it hinder innovation from the techies? Sure. But the business knows what it wants and has taken the pain to write it out in great detail.

So, beware that becoming Agile does not mean compromising on the quality of documentation. It simply changes when you are focused on refining what.

Anyone can write a user story

I have coaches highlight the bottleneck (waste) in the system in numerous Agile trainings. Look, if you wait on one gal, the product owner, to finish writing all your user stories for a team of 8 developers, then you may go slower.

So, the whole team should be trained on writing user stories. The whole team should be trained and empowered to write user stories. However, there are pitfalls here to watch for.

Too many cooks spoil the stew. Or a clear voice missing in the product, or have you heard of the bystander effect? When lots of people are standing and witnessing the same wrong, everyone thinks someone else will act, not me. End result, no one responds. Everyone thinks everyone/others can write stories, so not me. I have seen this one too many times.

So, I differ from my fellow agilists in this advice. I feel Product Owner should have a clear, crisp vision. The vision needs to be disseminated from the PO to the teams in how features are broken into stories and what each story entails. However, the PO should not limit the innovation of the team and encourage questions and collaboration to improve the requirements and embody the whole team spirit. If the PO is absent, the team should feel self-sufficient to step in, but the team writing the stories does not replace the vision guiding the product.

Because when the PO takes the back seat and depends on the team to self-organize in creating and writing their own stories, result is never good, I assure you.

Acceptance criterion can change mid-sprint

Agile puts processes in place enabling the team to respond to change and incorporate customer feedback, etc. However, the last responsible moment as a rule for acceptance criterion formulation is ahead of the sprint start, period. Changes mid-sprint should be exceptions and not the norm. It is unfair to accept the development team to pivot with their heads spinning round the clock. The stability is desired within the sprint.

 

All these problems are experienced when Agile is misunderstood or a sentiment is abused to an extreme end. I am sorry to inform that Agile is not a cure all for the documentation. It does not mean crappy or no documentation. We are still obligated to do a top-notch job. Nothing changes there no matter the methodology.

Featured Photo by Tom Pumford on Unsplash; Inline Photo by David Travis on Unsplash

Categories
non-fiction Opinion Tech

Journey Beyond the Headlights

When I was a little girl, I wanted to be a teacher. Teacher craze lasted a few years. When teenage acne took over, I had a distant family friend visit us from the United States. She had an eclectic selection of high-heeled shoes my sheltered eyes had ever laid eyes on. And, she told heroic tales of her experiences being a detective. So, I wanted to be a detective. So, as my wants blended with the winds and went place to place, I too floated from a small town in rural Punjab to a small Midwestern town in the US. Destiny winds continued to sway me around. I found myself in a high-rise in Downtown Chicago in 2007, at Buc, France giving Agile training in 2015, and last summer, I joined Allstate in Chicago land as a Program Manager.

One thing is same in my aged heart from the one that beat in me as a child – desire to get better, anxiety to succeed in life and in career. The burning desire had me chasing “the road less traveled” or simply “the road I wished to travel on.”

I recently changed roles for the third time, I must say, within Allstate in my first year itself. Blame the burning desire inside me that is waiting for the right winds to propel me because all I can see is as far as the headlights of my near vision.

What do I do? I am an Agile Coach, I change people’s behaviors for a living. May I say, I do the same at home as a mother. Beyond the headlights, only lies the ashes from my desire of where I want to go and where I want to be.

For now, I am teaching myself a lesson I have applied all my life. Do the best you can. Give the best you can. And, worry not for the rest. Let’s roll!

Categories
Opinion Tech

Standardization vs Variability in a Program – Choose Variability

From the time we are born, we are taught to conform, from language to religion to traditions.

One of the first intentions I see in fellow program managers is a desire to enforce a standard across teams within a program. A standard is desired in the interest of predictability but also in the interest of uniformity. How important is it to be uniform?

While it is key to align on values and fundamentals (or even working agreements), it is also important to encourage deviations. Unless a rule is broken, it cannot be improved upon.

For example: to be an agilist, your values must agree with the Agile Manifesto, that says we value => individuals/interactions over process and tools, working software over documentation, customer collaboration over contracts, responding to change over following a plan (in my life all plans have tragically failed me, no wonder I am an agilist!)

Once the core values align, a standard enforced on a program consisting of disparate teams can be indicative of command and control.

Burden of a program manager is to visualize the flow of information across boundaries and do so in a believable, transparent manner that brings all those disparate teams together as one whole.

Enforcing a standard can feel like adding value to the story a program manager must tell of one program no matter the differences within.

Encourage good behavior via inspiration instead of a stick to make teams conform to your way. Trust me, it is your way even if it is right. We are all different. When we do the same task, we differ from one another. That is what makes a person unique.

If all the people in the world dressed alike, life would be boring. If all the people in the world responded to success and grief in exactly the same way, sure life would be predictable, but it may also be stagnant and monotonous.

In our differences lie our fascination and deference for each other. Encourage the teams under you to break from the norms and experience autonomy.

Ask yourself one question, do you want your teams to follow and do things when asked to do? Or do you wish them to self-organize, self-manage and propose new ideas to improve the program?

And finally, I will refer to Simon Sinek’s “Together is Better.” Would you like to be the king of a playground others fear to play in and try to conform to the rules? Or would you rather your teams play fearless to use their imagination to come up with better games, better ideas than before?  If the answer is second, it is important to go easy with trying to enforce one behavior from all and encourage differences. Because we are different.

Originally posted on my website: https://bookofdreams.us

Categories
Opinion Tech

Key Lessons for New Leaders/Managers

The biggest worry I had as a software engineer was my work, my accountability and the quality of what I delivered. Stepping into management, however, changed that dynamic as now I was responsible for other people’s work, accountability and quality. We all have different inspirations that propel us to deliver more and better. What worked for me may not work for another.

Key lessons I have learnt when in a leadership role are:

  1. Know when to disconnect
    Leaders coach. They impart lessons they have learned so others can exceed and develop into leaders. However, it is key to let others make mistakes and learn from their mistakes even if you knew how to not make the same mistake. It is important to learn to not own other people’s mistakes and that is incredibly hard to do.First response when a leader recognizes someone is making a mistake is to do everything in your power to not let them make the same mistake. While, it is correct for the leader to coach another person or team but once you have advised them, it is KEY to take a step back and not own what they ultimately do. Because if they choose to ignore the advice and do it their way and fail, they own the decision, the failure and the resilience to get up after the fall. That is key in building teams that are self-managing and self-organizing.
  2. Know the difference between enabling teams to self-manage and lack of leadership
    I had a fast-learner peer. They learned that delegating responsibilities is a good thing, it enables self-managing teams. However, while delegating, it is key to know the skillset of the person asked to perform a role. Do they have the desire or the knowledge to do justice to what they are asked to do? For example, delegating a meeting facilitation is no big deal. But if you are delegating a techie to write requirements when they have not had the training or the exposure to it being done can be disastrous without guidance.Delegation does not take the place of leadership that gives clear direction on what is required from a team and when. Once the clear direction is in place, the team can pivot and make things better. However, when the direction is missing and you ask a disparate set of individuals to make key decisions, result is same as “too many cooks in the kitchen spoil the stew.”
  3. Team is bigger than a set of high-performing individuals
    Have you ever witnessed a sports team consisting of world MVP (Most Valuable Players) lose badly? Far more important than rising stars is the chemistry of a team in how it performs together – do they have each other’s back? Are they inspired by each other or are trying to tear each other down in an effort to get ahead? Because teamwork, passing the ball at the right time, thinking about the team winning above yourself winning, are traits that rise or doom a team and when in a leadership position, it is important to value a team over a set of individuals, some performing better than others.
  4. Embellish or not to embellish
    Having attended countless Team Reviews (in Sprint Reviews or Demos) I have seen countless examples of teams embellishing themselves – look at our throughput, look at our automation.
    But just like offering extra praise to a toddler actually results in the toddler throwing a tantrum next time when the praise does not come through, it is important to stick to facts even when facts are less than flattering, even when the team is slipping and faltering. Because unless you shed light on the pitfalls, it will be hard to improve and shed light on the relentless improvements. So, refrain from embellishing is what experience has taught me.

All in all, becoming leaders involves caring a lot and letting go at the same time, a paradox very difficult to master. It is in knowing when to intervene and when to take a step back. It is in not fearing mistakes and failures and allowing its place in the team and in the organization.

Categories
non-fiction Opinion Tech Uncategorized

We want someone else in the city.

IMG_8379

Put on your best clothes, check. Speed to the station, check. Pay parking ticket, check. Stand behind the yellow line, check. Take the train, check. Step out of the train along with countless bobbing heads, all walking fast, almost speeding with you like competitive eight-year-olds, check. Behold numerous larger-than-life billboards inside buildings, some reckoning you to move to warm Arizona, but all making you feel like someone important (just like a super hero), check.

About a decade ago, I worked in the city. Since then, I found a job in the suburbs as my family grew. A training course propelled me to take the train to the city for three days in February of this year. I went as a tourist, as an outsider.

In the decade of departure from the city, I had forgotten the energy that flourished in the city, the young that made even the middle-aged people like me, feel important, if only along the neck-to-neck walk with them.

The bustling cafes, the trendy clothes…ah, the list goes on.

My past years witnessed my ex-company relocate to the city. I  heard of numerous others embarking on the same journey. Why?

When I had questioned my previous employer why, they said they wanted to tap into the younger, bustling crowd, go where the momentum was.

In that reasoning to move to the city, I was also hearing, I was aging. They wanted the fresh folks, just graduated with new ideas. When did experience become underrated? Hint, salaries. Why bother gaining experience when (relatively) cheaper labor can be readily available?

Are there no old people in the city? Sure, there are. They may live there. They may well commute there. They may be valued. But for the vast majority of my peers with little children moving with a company to downtown meant sacrificing family life and not seeing daylight at home.

The company probably was more interesting in my budding children than me.

This is the harsh reality for the tech industry. I wish I knew the exact formula for success past forty, as I have yet to reach that milestone as fast as it is approaching, but bubbling in the hustle of downtown Chicago, observing the fresh new faces, their confidence, I also wondered if merely moving the location of a company was a guarantee of a company’s success.

Because a great company should value talent, regardless of geography or age or gender or color. And when large corporations make such decisions to aim for profit at the cost of signaling the lack of value of employees’ personal lives or experience, it is a two-way street. They too lose in key fundamentals that make a place worth working for, period.

I spent the three days in city savoring the delectable food in the restaurants, staring out the train window listening to blasting music. But the most cherished part of my day remained coming back to a loving home. For companies can move where they wish and can be replaced but the truly irreplaceable parts of my life were taken care of. I enjoyed the oomph of the city and was afresh proud of my decision to remain close to family, so I could take pride in my work as a professional and as a mother at the same time. Downtown Chicago can continue to bubble with energy, and I with love. Maybe, some day when my kids have grown up, and I have more of “me” time in the day, a startup that distinguishes not between old and young, and only sees talent, will reckon me to check all the checks and take the train to the city and feel young again.

Until then…here is to another day, and another week in suburban Chicago.

Categories
non-fiction Opinion Tech

I Will Not Undersell Myself Anymore

I have the luxury of working in the tech industry. Because of that, I am proud of breaking the stereotype that engineering cannot be for girls. I code. And, no matter where I am at in my career, I will always be that girl who started her career coding.

One thing, I as an Asian techie professional have grown to accept is a lesson I wish to pass to all alike regardless of gender, race, or origin is to  lean in.

When I became a mother, it is true I had to walk past some opportunities. It is true when opportunities came my way, I wondered if I would be able to do justice to the opportunity because being a good and available mother was important to me. Today when those thoughts enter my mind, I scold myself.

This process is called underselling yourself.

When you are capable and you let go of these opportunities and settle for less, frustration builds in when you feel you could do more with your career. Frustration also hurts when others in position you passed are less experienced and potentially less capable but they stood up for themselves. And, you ask yourself did you undersell yourself? Let go the fear, my friend, and embrace your capabilities freely.

I have learnt to not undersell myself because frustration is more costly than the work life balance we all have to do, singles, couples, and parents. Work life is not my issue alone. The world is engaged in that affair. And if they can, I sure can too no matter my background.

So, I say to me fellow women and men professionals alike, do not undersell yourself. Reach for the stars.

Follow

Get the latest posts delivered to your mailbox: