You’re not a code monkey, don’t try to be one

I started this month revisiting the manifesto for Agile Software Development:

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. These are our values and…agilemanifesto.org

Five points from the manifesto —

1. Agile is an adjective don’t use it as noun! Next time, if you hear someone saying, Agile doesn’t work at our scale! ask them to replace Agile with any other adjective, for e.g. Humble.
2. The 11th point from the manifesto — The best architectures, requirements, and designs emerge from self-organizing teams. It’s safe to assert that the agile process works well with smaller teams!
3. As a business person, you must decide on what and why to develop as per the bucket list of priorities, but when it comes to how and extended why-what, the customer’s feedback doesn’t become a weapon to stigmatize the developers’ point of view.
4. The 12th point from the manifesto — At regular intervals, the team reflects on how to become more effective, then tunes and adjusts the behavior accordingly. I have seen the teams playing safe during the sprint retrospection and leaving the topics of concern off the tables. The retrospection is an opportunity to discuss them, improve the processes and methodologies with the one common goal of the team’s success. You can certainly score a number of goals, but if your team is not cheering for those goals, it’s still not worth it(period) Play with the team!
5. The 6th point from the manifesto — The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation. With the ton loads of collaborating software and platform, even some are labeled as Agile Software (it’s wrong!), you must realize and remember, it’s the human who is going to use the end product. If you are developing for humans, talk to a human instead of sending the byte code instructions in the human-readable format. The instructions are one directional protocol and conversation is bidirectional!

Later in the month, I came across one of my favorite talks from 2014-

Five points from the above talk —

• The notion is given from the business analyst or managers and handed over to developer to turn a rough task into a code, the developer builds that what they were told to build. It’s very much against the Agile!
• Conversational: The conversation of business people (analyst) and the developers should come together and converse what should we build instead of stories hand over!
• Learn the domain that you’re working on. As software developers, we’re already familiar with what software can do and what are the opportunities. If a developer is not shutting down at the cost of priorities and customer feedback, the developer can deliver at her best capacity.
• We’re responsible for the software we write, both good and bad. You must be responsible for it and stand up to Say No! if it does not feel right to you. You should avoid the dark patterns. And avoid the methodology of I've implemented what I've asked for!

As developers we need to be knowledgeable about the domain we are building software for. Having domain knowledge allows us to be the user advocates and understand user needs, And it gives you a purpose to deliver beyond the lines of code.

In my last company, I worked in the Forex trading domain and as much as I wanted to learn that domain, I couldn’t develop the same level of interest in leaning finance. And at the end, it became one of the reasons to leave the company. For the developers, the domain knowledge and ownership are important, it challenges you to deliver your best for your components.

I am a strong believer of not being just a code monkey! I have worked with people —

Who endorsed this belief and achieved the best outcomes: In this case, we as a team look at the what are the feedback items, priorities, bugs and features all together. Adhering the priorities and commitments, the team discusses what to pick up and discuss on how to deliver the best version of it. It’s the creative way of the collaborative delivery where the outcomes are not derived from the single point of failure as well as the one who is delivering is actually entitled to deliver the best.

Who believe in the benevolent dictatorship (or Not a business person <-> developers collaboration style of working) for the better outcomes: In this case, the group of people decides on why, what and how to work on, prepare a story document and hand it over to the developers. The developers then have only one responsibility of delivering it line by line. Not all the developers have the same urge of learning the domains, for some developers, writing other than code is a noise, in these cases, it works. A large number of services based development companies, follow the same method of development and it kills the creative brains if the developers love to own what they write.

There are some big companies who follow the later concept, but balances it beautifully (Remember, you’re in good company!), so the creative brains can innovate and remain entitled. How do they balance it? It’s a separate topic, not sharing it in this blog :-).

In conclusion—

1. There is more to deliver than the pixels and the bytes.
2. Knowing the domain causes no harm, it empowers you to advocate your solution for your users and it enables you to look at the problem from the other side.
3. It’s OKAY to say NO! if something doesn’t feel right. Saying yes to everything that your boss is asking, your contribution becomes inadequate for the long term goal. Also, it’s not 80s, you don’t need to read a document to deliver, if you’ve not contributed in building that document at first.
4. The collaboration is an important aspect of the product development, and if there are opportunities, take a break from your coding and listen to your customers. It helps you to build a product that the customer loves and you too, are, proud of.

Originally Published here ... You’re not a code monkey, don’t try to be one