Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Adjusting Your Working Style to Agile Practices and Mindset

Productivity
Agile / Scrum

15 June, 2020

Ben Coats
Ben Coats

Vice President of Technology at Quest Mindshare

Ben Coats, Solutions Architect at InfoArmor, recalls how he had to adjust his personal working style of non-linear thinking and coding, to the shifting priorities and incremental delivery of Agile development.

Problem

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.

Actions taken

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.

Lessons learned

  • 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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

How to Build a Software Team from the Ground Up

12 November

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.

Hiring
Motivation
Cross-Functional Collaboration
Agile / Scrum
Deepesh Makkar

Deepesh Makkar

Sr Director of Engineering at SunPower Corporation

Choosing the Perfect Implementation of Agile

25 October

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.

Goal Setting
New Manager
Agile / Scrum
Shubhro Roy

Shubhro Roy

Engineering Manager at box

Creating an Engineering Vision

25 October

Mustafa Furniturewala, VP of Engineering, uncovers how he created a succinct engineering vision with their company's values in mind.

Alignment
Mission / Vision / Charter
Goal Setting
Productivity
Mustafa Furniturewala

Mustafa Furniturewala

VP Of Engineering at Coursera

Optimizing With Scrum

13 October

Phillip Derosa, Global Director of QA at OneSpan, takes Scrum seriously; he knows that the methodology is only as effective as its implementation.

Goal Setting
Agile / Scrum
Phillip Derosa

Phillip Derosa

Global Director of QA at OneSpan

How to Wear a Lot of Hats

13 October

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.

QA Team
Leadership
Agile / Scrum
Phillip Derosa

Phillip Derosa

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.