Yes, that’s right. Agile teams don’t need software programmers, they need software developers. I don’t mean this as some English vocabulary usage. I think the key difference is, if you ask a programmer to build some code, you will get code. If that programmer is good, you might get good, reasonably commented and reasonably efficient code which works.
If you ask a software developer to build some code, you will first get questions before you get a solution.
- How does it fit in the business process? Are the requirements thought out?
- Are you sure you understand what it will cost?
- Who will support it? What about diagnostics and instrumentation?
- What kind of documentation will it need?
- How might it interact with other code?
- What platform will it run on. Are the scalability issues?
- How might it impact future development? How might it be enhanced in the future?
Another key difference is, programmers focus on languages, software developers focus on language characteristics. A programmer might see himself/herself as a Java programmer, C# programmer or a Ruby programmer. But a developer focuses on language characteristics such as strong or loosely typed? Object oriented or functional? Interpreted or compiled? Etc. This allows developers to quickly adapt and pick up new languages and technologies.
So, the key mantra for agile teams is to deliver high business value software with high quality. This cannot happen with programmers whose focus is just to code and ignore everything else.
Code is not always ‘THE’ solution but its ‘a’ solution.
Credit: This blog is inspired by a talk from Dan Appleman
One of the biggest challenges for agile teams or for that matter lot of organizations is fear of conflict. This fear of conflict is a major reason why organizations fail to call right shots. In a survey conducted among US and Europe executives, 85% have acknowledged that they had issues/concerns at work that they were afraid to raise. They were afraid of conflict that would provoke, afraid that it would lead to arguments that they won’t know how to manage and loose.
Arguments are necessary; disagreements are required to drive creative solutions to problems. Well, easier said than done. How can we have these conversations more easily and more often? Organizations culture should reflect and encourage the attitude of questing, willingness to start an argument. Imagine in an agile team, if individuals are hesitant to prove others wrong, it will ultimately do bad to the team.
Developing “Prove me wrong” attitude doesn’t mean that team/organization loses team sprint. In fact, the opposite would happen; there is even more team collaboration, very little room for wrong decisions or judgments. The reason why Phd theses have such a high quality is because they have to pass “Prove me wrong” phase.
It is not enough to make things transparent and open, but as I mentioned above, the discussions and arguments around it is what makes it effective.
Openness isn’t the end; it’s the beginning.
Credit:This blog is inspired by the TED talk give by Margaret Heffernan – Dare to disagree
Back in collage days, I learnt a lesson when my friend almost killed me (not literally though 🙂 ) when I responded to a question by saying “yes, you look fat”. Recently I noticed such a scenario in a team, well it’s nothing to do being fat 🙂 but fundamentally it was same, “Giving and taking feedback”.
I believe that feedback is a gift. It always helps us grow personally and professionally. Yet, most of us have a negative perception towards it. Most of us still believe age old saying “If you don’t have anything nice to say, don’t say anything at all.”
Today’s demanding and challenging work environment calls for an imbibed culture of giving and receiving feedback. This aspect should be even more emphasized in agile teams. For example, lot of agile practices have an inbuilt framework to facilitate faster feedback such as with XP, we have CI, Pair programming, Peer reviews etc, with scrum we have retrospectives etc. Most of these feedback mechanisms are targeted at technical accepts and abstracted at team level.
In order to have hyper-productive teams, individuals should be comfortable to give feedback at an individual contribution level to acknowledge his/her achievements or to identify any growth areas.
Here are some points on giving and receiving feedback.
- Give your feedback as soon as possible: If you notice something done really well, don’t wait till a retrospective or some event to give a pat on back. If it is appropriate, drop an email, or post it in a bulletin board about the good work. At the same time, if you see something can be improved, or done at substandard level, let the person know ASAP.
- Balance your feedback: Always start your feedbacks with a positive note. It is important to mix both positives and growth areas.
- Be Constructive: The whole idea of giving feedback to help the other person to grow and not to criticize. So, always give your feedback in a constructive way. Be careful with the language you use. Replace words such as “but” and “however” with the word “and” when you string together your positive and negative feedback. When people hear the word “but” they immediately discount the part that came before it and only hear the negative comments.
- Listen: While receiving feedback, listen to the other person’s point of view. Perceptions are true at least for the ones who own it. So here it out without any justification or explanation.
- Reaction: If you don’t completely accept the feedback, thank the person and tell him how you are going to take that feedback. Be careful, it sometime do happen, that rather than accepting the feedback, we tend to denounce not only what is said but also those who say it.
Always remember, if someone is giving you feedback, it means they are interested in what you are doing and wants to help you to become better at it. Now, coming back to my collage days, if I had known point 3, I would have said “This dress suites you very well and I guess you look little big now” (not sure if it would have really helped) 🙂