Adjusting Your Working Style to Agile Practices and Mindset
15 June, 2020
Ten or more years ago, when I was new to a company, I was tasked to write an entire document management system myself - in four weeks. While the project technically embraces Agile/scrum methodologies - something I was relatively new to - I was left to my own devices to execute on this. However, I have a very distinctive way of working -- I am a non-linear thinker who envisions and grasps the problem as a whole, all at once. Until that moment, my personal working style had served me very well. I would jump from one thing to another, never completing one piece in its entirety before moving onto another one. I would work on everything at once and when it was all done -- it was all done! That approach functioned really well in a Waterfall context, where I knew exactly what was needed and by when. I was soon to find out that style was not well adapted for Agile methodologies! Three weeks into the project I was told by the management that a new priority came along and we had to ship what was done so far, even though we hadn’t built in everything we’d planned. None of it was completely done because I was working on all the pieces at once, counting on those four weeks allowed. I had to deliver unpleasant news that there was nothing skippable.
I had a very serious conversation with a chief architect that I worked with. This individual didn’t know me well, was not familiar with my previous achievements or my working style, but had drawn some mistaken conclusions, attributing the situation to a poor work ethic and other impressions about the generation to which I belong. Though it was difficult, I made sure I did not respond defensively. Rather, I tried to explain how I think, how my way of working derived from my way of thinking, and how effective
e that style had been for me over the prior decade.
I acknowledged my mistake -- I never stopped to consider whether my natural way of working fit the Agile model, and by not adapting my working style to this brave new work I had failed my employer by failing to deliver. I apologized sincerely, and promised that I would view this as a life lesson and commit to addressing the problem. I was true to my word.
While humbling, this was an extremely important lesson for me. Not only did it teach me to adapt my way of working to my environment and expectations, but the way I handled this situation dramatically changed this chief architect’s impression of me, resulting in a fantastic working relationship. He appreciated me acknowledging the problem without becoming defensive, recognizing what I needed to change my working style in order not to make the same mistake, and truly committing to change.
After that, even on projects where I was left to my own devices, I kept this in mind. I made sure that at any point I would be able to deliver something functional, and focus on one feature at a time. Even if I would occasionally diverge and do a bit of this and bit of that in order to be able to think through the solution, I wouldn’t follow that thread the way I would have before. Instead, I would do just enough to be able to conceptualize what I needed to do, then return to complete the task at hand. If you removed the in-progress feature, the whole was deliverable. I knew that I would always have to stay self-aware and mindful of what I'm doing, to make sure I could pull myself back if I start going off on a tangent.
- Evaluate your personal working style to make sure that it conforms to what is expected of you in terms of deliverables.
- When you're being given a project, think through in advance how to execute on that successfully (which is specific to the problem). Even if you are told that you have a certain amount of time to deliver a piece, be aware that priorities may shift without warning, and that you will be expected to have something shippable when those priorities change.
- Be self-aware, be humble, and ready to admit your mistakes. Embrace criticism. Even when it feels very personal, be deliberate in finding the kernels of truth, and using them to achieve valuable self-improvements.
Arun Krishnaswamy, Director of Data Science at Workday, describes how to build a data science team emphasizing the difference between software development lifecycle and data science methodology.
Director at Workday
Alex Litvak, Engineering Manager II at Uber, explains how he adjusted Spotify’s squad health check to enhance his team’s engineering quality.
Engineering Manager II at Uber
Andrew First, Co-Founder and Chief Technologist at Leanplum, shares how with a focused effort his company succeeded in reducing cloud costs by more than 60 percent in only six months.
Co-founder & Chief Technologist at Leanplum
Venkat Venkataraman, Sr. Director of Engineering @ Gracenote, shares a story about learning from what happens during a company wide initiative that has tons of potential.
Sr. Director of Engineering at Gracenote
Shyam Prabhakar, Engineering Manager at Stitch Fix, explains how design sprints helped him fix problems caused by the lack of sufficient research and overall improve his company’s products.
Engineering Manager at Stitch Fix
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.