Reflective Piece on Agile

I was hired about 3 years back into a software company that practice Scrum. It was my first time being in a company that adopts Agile and I was made the Scrum Master who is suppose to uphold the Agile Manifesto which I have no idea it exists then. I’ll skip the question of why I was hired for another time.

Back to my Scrum Master role, we did the ritual daily Stand-up, bi-weekly Sprint Planning, Sprint Retro, Sprint Review, you get the idea. At times, I wondered how much of these “communications” are useful. During Stand-up for example, we have engineers who launched into technical problem in-depth but when asked to simplify / put into layman terms so the non-techie Product Manager can understand, the engineers go to the extreme with general statement like “Well, it’s In-Progress”. Great, that’s very helpful and the team sure knows how to empathize with you. Two things I learnt about Stand-up:-

  • The idea behind Stand-up is to increase team empathy (I first heard this from a Lean coach, Katherine Kirk which makes a lot of sense) when a story becomes more complex than expected and have team members to help each other if required. But most engineers misunderstood it as merely status update, primarily because of the way it is conducted.
  • Engineers are poor communicators or they are like cats (an illustration from Prof. Gunter Dueck on why managers and techies do not speak the same language).

Our Sprint Planning is a little better. At least, we grew to ask “Why?” before building a feature but the nightmare comes when we are asked to commit to the stories based on our estimates by mandays. What’s the problem? Here is what I gathered:-

  • Estimate does not equals to commitment as to how productivity does not equals to building more features (it is about building the right feature). At best, it’s estimation but more often than not, it’s just “guesstimation”.
  • Engineers will trade quality with deadline just to complete the stories, resulting in technical debts that will haunt you one day.
  • It is done by the smartest person in the team (the rest obviously can’t estimate cause they have no idea how to do it to begin with). There will be no issue if the whole team has similar level of intelligence. Otherwise, Prof. Gunter Dueck coined a formula he thinks is pretty accurate. Multiply the estimates with 2.1 or use historical story points.
  • There is a strong feeling that the feature is useless, so there is no need to talk about estimation here. Unless of course your organization has a mechanism to measure value to prove people wrong.

I love Sprint Retro the most cause here is where we thresh out what works and what doesn’t, find the root cause of the problems the team faced in a Sprint. Unfortunately, it doesn’t take me long to realize it’s the same old problems since Day 1. I can understand why the team grew comatose cause we’ve gone over this topic ad nauseam. What happened?

Apparently, Agile works best when there is no silo.

According to Emily Webber (another Lean coach I thought makes much sense), whenever there is statements like “<fill in department / team name> is so stupid. They have no idea what they are doing” or something along that line, it means your company has silos no matter how cross-functional your team seems to be.

Another example of silo killing Agile is this. One year back, we had a highly experienced Product Director who came on-board. He commented that the team is not Agile regardless how much we claimed to be. We are only practicing the motion of Scrum (e.g. rituals above) but we are working in mini-Waterfall fashion within two weeks Sprints. He then implemented a few process changes. (1) Cross-functional team members works in parallel. Test engineer should code to build automation script before developer completes coding. Mock everything if things are not ready. (2) Designers should not stop at designing, they are required to turn their design to releasable artifacts. (3) Dev Ops has to be part of development team. (4) Automate everything with Continuous Integration and Continuous Delivery. So we did that for nine months and we built five products (including two portals). Now, that’s Agile isn’t it? We did deliver, lightning FAST! What’s the problem?

  • Quality — Our testers are just getting trained to be automation tester. They have to pick up Java without technical background.
  • Front-end Development — Our designers are now expected to convert into front-end developer and some are still struggling with the basics of JavaScript.
  • Management does not think products are good enough. There are some must-have features before we can go to market. One year later, we are still building the features.

The first two could be improved on (teething problems) but the last one evidently shows there is silo even within the top management.

In the end, I like how the authors in this book “Lean Enterprise: How High Performance Organizations Innovate at Scale” put it — Agile is essentially a “human” system. Tools / processes help to make it better but the team (including top management) is the catalyst for success in Agile:-

  • Team trusts each other and communicates effectively (a skill that most engineers lack).
I had an epiphany when Katherine Kirk talked about her litmus test of trust is when your team doesn’t hold people accountable on what they wrote in email. Maybe because it happens a lot in my workplace.
  • Setting good values within a motivated team.
  • Team learns by experimenting and apply them in the next iteration (adapted from “Lean Enterprise” book).

I will be taking on Scrum Master role again in my next job at a larger scale. Knowing what I know now compared to 3 years ago, I am determined to invest my time in people and culture. Specifically, I am interested in the concepts/areas around:-

Perhaps, I will write about those once I have some clarity of what I’ll be experimenting with my team.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.