I was having a chat with an old colleague on LinkedIn today (Brian Osman) and we were talking about Agile. The question was, “how does Agile at Tyro differ from <Client>*?” My conclusion was that by focusing on certain “Agile” rituals an artificially high stress environment can be easily created.
Here is this conversation:
Bosman:
Samster! How’s it going at EPAM? All good I hope đ . Hey just a question – do you guys *do* agile and if so how does it compare to Tyro?
Samster:
There’s lots of people in EPAM who do agile but in the <Client> office in my little corner there is no mention of agile, no Kanban boards, no daily standups (in my team). Every team is encouraged to develop their own process. E.g. my manager at <Client> often doesn’t come into the office until 10:30-12pm so a 9am standup just wouldn’t work. He has kids and often works from home. I know the EPAM cloud support guys we have here in Sydney have standups and mostly deal with support tickets so their work is fairly regular.
So with my manager we have a sync doc that I fill out every day on what I’m working on with a breakdown of roughly how much time I’m spending on tasks. Roughly half my time should be spent on bug triaging and trying to mainstream that process across some of the Sydney teams (about 70 developers/designers/PM’s and researchers) and the other half of my time spent on helping those teams with feature testing. This sync doc is in place of a daily standup and we have a sync up once a week where we go through it and look for improvements. There’s no sprints, no regular retrospectives. The <Client> guys will tend to work based on quarters (3 month cycles). Higher up management will set certain goals for the quarter and every team will set their own goals that hopefully line up with those.
So atleast in my little bubble at <Client> there is very little”formal” Agile but product excellence is a heavy part of the culture.
The funny thing with Tyro’s agile is it didn’t really support flexibility. A bit of an oxymoron in a way.
The context of <Client> and Tyro is vastly different too. Often the guys in the Sydney <Client> office have to collaborate with people all over the world, so they will often have conference calls with guys from Mountain View in the morning, often taking these calls at home and maybe conference calls with India in the afternoon. I have a weekly sync with one guy in India who helps lead the team that is responsible for communicating with public transport providers. The ops team for <Client> project that I’m working on is based in Seattle.
On a side note, I have heard stories of <Client> bringing in agile experts for coaching/consulting to learn about it. They usually bring in the guys that write the books on the stuff because <Client> has that kind of pull.
Bosman:
That’s awesome! It’s something like I just read from a <Client staff member>Â and something I like…lower case agile. Figure out the problem yourself and make your own rules (but don’t break the law….and be nice!). Thanks Sammy! I’m writing a report for a team I’m coaching at <Somewhere>Â and they want to compare this with places like <Client>. I think they’ll be surprised đ .
Samster:
Yeah. Otherwise things are going pretty well. No one has kicked me out yet. There have been a few days where I felt I wasn’t good enough to be at <Client> but it wasn’t really as stressful as starting at Tyro was. I think a lot of companies aspire to have a culture like <Client> but that’s actually pretty expensive, but nicely liberating. I think companies also often miss the point of <Client>’s culture, I guess they see the free food and games rooms and think that’s all you need to emulate <Client>’s culture.
I think the whole point of agile, is the being able to adapt to a rapidly changing environment. In the context of <Client>, sure there are some areas of the business that are constantly evolving but focusing more on product excellence tends to put a slower spin on things. There’s a focus on facilitating fast feedback but it’s to help make work easier, not to adapt to the market. There’s no mantra of ship it quickly, but there is a huge amount of effort put into supporting engineers get new code into production. Even <Client> uses a giant spreadsheet of manual test cases for Android/iOS <Client> maps apps on top of all of their other checks and balances.
There is a lot of process involved with getting a new feature into <Client> maps.
Maybe the over emphasis on”Agile”, and adapting quickly creates an artificially high stress environment. There’s always this push to beat competitors to market, to get this work out the door this sprint, to be constantly, “Go Go Go”. People don’t function well under stressful situations and that constant stress can’t be that healthy.
Bosman:
I agree with your point …. I don’t know if they’ll meet their growth targets and I don’t know if staff will feel happy about being ALWAYS under the pump so to speak…
*<Client> = I work client side as a contractor. I can’t officially say who this client is (because contract) but I get to help test an android app you might use for mapping and navigation. The Client is pretty well renowned in the tech space.
