Everyday Kanban

Discussing Management, Teams, Agile, Lean, Kanban & more

I just want to code! A look at developer challenges in agile transformations

Print

I know developers who “just want to code.” Their love of coding is why they got a development job in the first place if you recall. You know the stereotype of the developer who likes to sit and code in a dark cubicle, right? For a long time, that was an acceptable, if not prized, condition for developers at companies across the world. In many places, it still is. This is because developers didn’t need to interact with anyone, much less end users, in the stereotypical waterfall world. Requirement documents were delivered to developer inboxes, quality assurance teams tested the code and business analysts conducted the user acceptance testing directly with the end users. Proxies and documents become your link to the outside so those with social skills need not apply.

Now, there is a movement of agile and lean practices flooding through the corporate world. Developers who desire the non-social world they were used to are finding it harder and harder to exist in the new ecosystem. In order to have the dynamic duo of less frustration and quick speed to market, you need the people that make things to be close to the people who use things… quick feedback loops. When your competition gains these things and you don’t, you risk losing crucial market share.

The question is, how do we make the transition? You can tell at this point that agile is not just a way of doing — a series of steps to success — but, rather, it is a way of being that requires deployment of additional skills in pre-existing roles in order to actualize the publicized benefits. I imagine that many of the failed “agile” implementation attempts are, in some part, a result of not recognizing this core issue. If you haven’t quite figured it out yet, there’s no recipe for success for much that involves people, including this conundrum. However, there are some things you can do to try to help those struggling with this transition.

Stop and understand the barriers facing people: don’t assume they just aren’t trying hard enough. If I told you one day that you would have to learn a new technology and then I was irritated on day 5 because you weren’t an expert yet, would you be upset? There are new soft skills these folks have to learn and they are generally harder and more time consuming to master than their academic “hard skill” counterparts.

Set them up for success: find ways to smooth the transition into their new reality. Ideas such as pairing them with someone who is excelling in the new culture lets them see what this new expected “stuff” really looks like in action.

Ensure the benefits are clear and visible: If they were considered an expert in their previous culture, why would they want to change anything? Don’t expect that everyone already knows. Proactively explain it. Regardless of who they are, there are conditions they were never happy with. Show them how these conditions are improved by the new way of being and doing. If they are not better, ask yourself why you’re changing. Either the people or the product need to be happier from any change.

Have realistic expectations: Not everyone will be equally successful. Regardless of desire, you can’t change your essential make-up and sometimes people don’t want to change after decades of doing things a certain way. This doesn’t mean they aren’t right for your organization. Is there a value this person can bring using their traditional skills? My way or the highway mentalities create subversiveness and gaming. Its unrealistic to say that the highway is never the right choice, but it rarely should be the first choice.

In the end, I want you to consider that people are hard. Code is easy. Changing expectations of people’s skills “mid-stream” can feel personal. If people have served the company well previously, they deserve a little care and feeding when the company expects something new of them – including an agile mindset. If they don’t get that, then the real failure is not theirs, but yours.

1 Comment

  1. It is crazy how a developer / programmer / engineer can spend years building and supporting a product and not have the first clue about the experience of its users (demands, frustrations, constraints, etc). Some folks naturally empathize well, but for those head-in-code devs, it’s great to just pull them out periodically and put them in the seat of a user. Certainly it’s not a substitute for a tightly coupled team that communicates and shares well, but like you’re saying, no one can act alone in a bubble and expect great results.

Leave a Reply