Loading...

Adjusting Your Working Style to Agile Practices and Mindset

Ben Coats

CTO at Innovative Research Technologies

Loading...

Problem

"I was soon to find out that style was not well adapted for Agile methodologies!"

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

Be notified about next articles from Ben Coats

Ben Coats

CTO at Innovative Research Technologies


Leadership & StrategyLeadership DevelopmentCommunicationDecision MakingEngineering ManagementTeam & Project ManagementAgile, Scrum & KanbanFeedback & ReviewsCareer GrowthSkill Development

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


Product

HomeCircles1-on-1 MentorshipBountiesBecome a mentor

© 2024 Plato. All rights reserved

LoginSign up