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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Deepesh Makkar, Sr Director of Engineering at SunPower Corporation, shares his experience transitioning his organization from contractors to a 50/50 split of full-time employees and international vendors.
Sr Director of Engineering at SunPower Corporation
Shubhro Roy, Engineering Manager at Box, stresses the importance of the holistic nature of Agile methodology; picking and choosing à la carte may cause more problems than it solves.
Engineering Manager at box
Mustafa Furniturewala, VP of Engineering, uncovers how he created a succinct engineering vision with their company's values in mind.
VP Of Engineering at Coursera
Phillip Derosa, Global Director of QA at OneSpan, takes Scrum seriously; he knows that the methodology is only as effective as its implementation.
Global Director of QA at OneSpan
Phillip Derosa, Global Director of QA at OneSpan, has never been afraid to fill in the cracks between departmental duties, often coming up with a brand new intermediary position to occupy during times of need.
Global Director of QA at OneSpan
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.