Archive for ◊ August, 2012 ◊
amount)
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
Scrum offers different benefits to people in different roles. If you’re a developer, switching to Scrum will help you in several ways. I am a developer, and I confess, I was a bit apprehensive about Scrum when we started about 3 years ago. But having done it, I think it was the best move for me, my team and our client. The biggest advantage I experienced was a sense of empowerment.
Scrum promotes self-organizing teams. As a part of this team you’ll have better support, better control and higher flexibility. Every sprint the team works towards a common goal and team members are bound to voluntarily help each other do whatever it takes to meet that goal. You’ll have better coordination with your colleagues. Team members will be more willing to seek help when they’re stuck. Team members will also be more willing to help each other. You also get the flexibility of working on different kind of tasks. Team members usually pick tasks in the order of their priority, so you’ll get to work on new things (sometimes with help from another team member). Eventually, the collective knowledge of team will grow.
As a part of scrum team, you have more control over estimations. In scrum, you’re not working on someone else’s schedule. The team estimates, everyone has a say (and stake) in estimation. The commitment per sprint is simply a reflection of your velocity. The whole thing is pretty transparent. Which is beneficial to you as a developer and also to your customer. Estimation techniques like Planning Poker facilitate this and makes sure every team member is involved in the estimations and the conversations around it.
As a part of scrum team, you’ll have lesser instances of high work pressure (or burnouts). Scrum works in Sprints of short durations. Each sprint has a fixed set of goals/commitments which is known right at the start of the sprint. In fact, the team chooses this commitment. Throughout the duration of sprint, the team works together in meeting these goals. The daily scrum meeting helps the team coordinate their efforts towards this goal. You work at a consistent pace and don’t have late nights or burnouts.
I’ve also found that Scrum makes your more involved with your work and your customers. You’ll talk to your customer more often, you understand their problems better and are in a better position to offer solutions. In turn, you’ll feel more satisfied with work you’re doing. You get to make a difference. You’ll also be delivering more often and get feedback from the users sooner. It’ll help you and your customers immensely.
Are you a developer? Are you doing Scrum?
Are you not doing Scrum? Do you have questions or comments for me?
Feel free to post them below.
- Anand Gothe
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)
Naturally, I’m tempted to answer “YES” to this question as I wear my Agile Coach hat at work. As I pay close attention to the person’s conversation, what he/she is really saying (screaming inside) is bunch of fears such as
- Fear of failure
- Fear of change
- Fear of moving out of comfort zone
- Fear of learning curve
- Fear of wrong decision
- Fear of transparency
- Fear of losing control
- And it’s so easy to give orders or follow orders J
So, when you want to convince your boss or your customer to go Agile, ask what challenges they think that exists currently with their organization or team. It’s much easier to focus on solutions and start that conversation when people acknowledge that a problem exists.
JavaScript performance is always a question of debate in web development. Bulk of JavaScript’s problem in client side programming is due to its blocking nature. Most of the browsers use a single process for UI updates and JavaScript execution. Longer the time it takes for JavaScript execution longer the browser is locked for updating contents on the web page.
The following are refreshers for improving JavaScript performance.
i) Place <script></script> tag always at the bottom of the page.
<html>
<head></head>
<body>
<div>..</div>
<script>JavaScript Code Snippet</script>
</body>
</html>
ii) Group multiple JavaScript files together. It always faster to load one 100KB file than to load four 25KB files.
iii) Minification and Obfuscation – Sure minification and obfuscation helps but not at the cost of losing readable content.
iv) XHR – Though XHR addresses bulk of the synchronous loading nature of JavaScript it still has cross-domain policy issues. XHR also doesn’t address dependency management.
To address the blocking nature and the dependency management functionalities in JavaScript we use Script Loaders.
One of the more popular framework for Script loaders available today is RequireJS.
i) RequireJS addresses blocking nature of JavaScript by loading just one JavaScript file and releases the browser process for UI.
<script data-main=“scripts/main” src=“scripts/require.js”></script>
This script requires you to load require.js. User scripts will be located in a file called main.js under scripts folder. User scripts are loaded asynchronously.
ii) RequireJS also addresses dependency management by loading scripts on demand
require(["scripts/jquery"], function($) {
$(“display”).html = “This is my text”;
});
This script will add jQuery module to the application.
….. More about RequireJS and its functionality in future sessions.
FluentAOP is a lightweight, fluent interface based library that allows implementing aspects of method interception in a simpler and easier way. FluentAOP is primarily designed to simplify the adoption and use of AOP in .NET. In contrast to most AOP implementations, its interception semantics exclusively rely on strongly-typed method definitions and a fluent API. Check this link for more details on method interception and AOP.








