Correlation does not imply causation

After every Agile conference, agilists return back to work with tons of new ideas.  They get excited about these new ideas and would be looking forward to roll them out sooner than later. However, based on my past experiences, I have realized that many ideas could do more harm than being helpful.  This is not because ideas we hear at conferences aren’t good, however, what we assume as the “idea” behind success may not be the “one” causing the success.

Popular ideas being borrowed in the Agile community include the Spotify’s  tribes/guilds, Google’s 20% innovation time and many more. In this advisor, I am challenging the readers to think before they act and understand the hidden secret’s of success.

Here is link to the complete article.

This advisor has been written to enable the Agile conferences attendees to look deeper about the “causation” aspect rather than the “correlation” .

How to make wall-related decisions in Distributed Agile projects

I authored the following article for Cutter which got published today. So, it is hot out of the press.

The subject that every distributed Agile team is questioning is the topic of setting up visual walls. Conflicts arise when purists argue in support of setting up visual boards across all locations, while the distributed teams consider it an inconvenience.

Many companies don't realize the importance of making the right decisions related to visual walls. Typically, wall setup is left to the ScrumMaster. These companies don't realize that this "single-handed" decision could result in loss of productivity, increased stress levels, and thousands of dollars in loss due to waste.

====  I am recommending a principle based approach for deciding if the information needs to be displayed on Physical wall or Digital wall. ===============

Wrong wall decisions or forcing wall decisions on a team could end up with stale walls and thousands of hours could be wasted in maintaining these walls. Be sure your organization considers the core principles during its exploration of walls.

Since this article is available only for Cutter Members, kindly continue reading rest of article on Cutter

If you are start up, think beyond one user

As I am coaching and mentoring a few start ups in Melbourne and elsewhere, I have noticed common pattern of issues across the board.

• All start up founders are really enthusiastic and dream of becoming rich –> Nothing wrong with it
• All start up founders have a strong idea in mind ---> Nothing wrong with it
• Most start up founders believe that their idea would take over the world, even though they have never tested beyond one user   ---> Something wrong with it

Recently read a story about startup failure “Patient Communicator”.   The founder built fantastic features applying iterative development method, however, it was never tested beyond his father’s medical center.

As the founder shares his experience, PC began as a product for my father’s medical practice.  Plain and simple, I never assessed the market need for a patient portal.  It’s extraordinarily difficult to take a product that was built perfectly for a particular user and commercialize that into a broader market.

If you are in start up journey, think beyond one particular user !  

Large Scale Scrum (LeSS)

Last week, I had the opportunity to speak about Large Scale Scrum (LeSS) at Agile PM meet up group  in Melbourne.  It was really an honor to speak with such an incredibly experienced, knowledgeable audience. At the end of the session, we had very engaging Q&A.

As part of the session, I shared some of the challenges of  scaling Agile and possible solutions as well. One of the solution being, applying the Large Scale Scrum(LeSS). 

Based on my experience of working on several large scale Agile projects, I have come to realize the following 4 types of challenges common across large enterprises.  They are People, Process, Tools/Technology and Org Structure/Culture. 

I have summarized the challenges into this diagram

Even though these challenges are common in small Agile projects but gets amplified while scaling Agile.

The popular  Scaling Frameworks are as follows:   Spotify,  XScale, SAFe, DAD (Disciplined Agile Delivery).

In addition to the above,  Large Scale Scrum(LeSS) by Craig Larman is popular as well.  I have personally applied this while working with Craig Larman during 2006 at Valtech India. LeSS and LeSS Huge are two variants for large scale projects.  LeSS huge can be depicted as shown in the diagram below:

LeSS is based on some of the proven principles around Queuing Theory,  Systems Thinking  and Empirical Process Control  as shown below.

If you want to learn more about  applying Large Scale Scrum on your projects, do drop me an email and happy to share the ideas.

What is Loyalty ?

No one plans to fall sick isn't it? Similarly, when I caught some flu couple of years ago, we were eager to see a doctor. Being new to our suburb, googled around to find a nearby medical center. Took an appointment with "any available GP," visited and got better.

After some time, it was my wife's turn. When she wasn't keeping well, she too called the medical center, took an appointment with "any available GP" and felt better.

Apparently she visited a different GP than mine. She recommended me to see him next. Over the course of time, we noted his name and started getting appointment specifically with him when needed. Suddenly one day we heard that he moved out of this medical center, and the receptionist wasn't eager to share his new coordinates.
We felt a bit sad as he knew us well, and we had a built a good rapport over the years and now we don’t know his whereabouts.

Later due to circumstances, we moved to a different suburb and once again started the search for "any available GP". We weren't so happy with the GPs we had seen compared to our earlier one. We used to remember our earlier GP once in a while.

One day we casually thought of searching our earlier GPs name on google, and some names came up. We called a few and one of them actually turned out to be our earlier GP. Everyone was elated, and we went and met him as well. He was not only surprised to see us but was beaming with a big smile.

I would call our selves as the loyal customers for this GP as we did everything we could do get the services only from him even when several options were available.

Loyalty is something when you chose a specific service inspite of having many options in available to you. Of course, a more formal definition from Wikipedia would be “Loyalty is faithfulness or a devotion to a person, country, group, or cause.”

On the other hand, repeat business is something where customers use existing service as they don't have an alternate option.

It is shameful to see that many companies measure "repeat business" rather than "loyalty." Loyalty is much more powerful than getting a repeat customer. Loyalty is something that will enable the company to grow during downturns and fierce competition. Repeat customer will leave you and go when they find better options.

Nowadays companies rollout the so-called "loyalty program." Big shopping malls and airlines have this loyalty program. I feel that this is a bit misnomer. People tend to go back to these companies not because they like the service, but because they get some discounts or redeemable reward points. I don't call such programs as a "loyalty programs", but as "carrot programs."

Couple of things I liked about our family GP has been his relationship building skills, his frankness, his specialty, customer service and respect for us.

Here is another personal example, while I moved to a new suburb, I was scouting for an electricity provider. I was calling each provider and gathering various details. As one could see, each one was tried their level best to sell a service by sharing their discount program, except one of them who explained their weaknesses as well. She not only suggested alternate but better options. I genuinely got connected with this company. Lesson learnt, being truthful and genuine breeds loyalty.

To conclude, It is very important for a business to evaluate if the returning customer is a loyal one or a repeat.

Even though we have tools like NPS, it won't clearly tell you the difference between loyalty and repeat. It partially helps to understand the situation though.

Always try to build a loyal customer base and work towards converting the repeat customers to loyal ones.

I have also posted this article on LinkedIn

Increase speed by incentives and sacrifice quality

Recently  I read an article in the news paper about improving the speed of passport delivery to citizens.  This is the news published in Times of India. It seems that passports are getting delayed as the police verification is taking a lot of time. In order to improve the speed, the passport office is planning to incentivize the police.  That is, if  the police completes their verification within 21 days, then would get more money else they are penalized by reducing the incentive.  I felt that this is one of the most dumbest idea ever implemented !!

Here is the quote from the news paper:

However, he said the delivery of passports has been expedited by incentivizing police. "We have reduced the time taken for delivery once the application is sent for processing. We are insisting that the police department send in police verification reports in 21 days. For each report sent before 21 days, cops are incentivized Rs 150 per report. If sent later, they get Rs 25 only. This will reduce the time taken to get the passport delivered. In some cases, the passport is delivered less than a week if verification report is sent fast,"

There are couple of issues with the above idea:

1. I don’t think any root cause analysis has been done to identify the delay in verification. There could be various reasons for the delay.

      For example, this passport verification may not be the top of police’s backlog list.  It is also possible that police force don’t have sufficient people to support this activity.

A root cause analysis could have helped to unearth the real cause of the delay and proper action could have been taken.

2. Going forward, I could see that the all police verification will complete within 21 days due to incentives. Question is, at the cost of  WHAT ?    I could see that the quality of verification will drop heavily as the possible root causes are never addressed. 

Being in the software industry, we keep hearing that external motivation causes more harm than the anything else.  The above story correlates to what we commonly see in the organizations. Employees are incentivized for ensuring on time delivery. But the companies pays for the cost of quality at a later stage, which no one really bothers or accounts for. 

Your understanding of Kaizen is wrong

Kaizen is popularly associated with continuous learning or continuous improvement.  However, where people get wrong is who should continuously improve ? 

Most Agilists and Leanists use Kaizen in the context of team improvement. That is, an agile team should continuously improve, and thus excluding the managers/leaders, rest of the company. 

This is exactly where the understanding goes wrong.   The true Kaizen involves continuous improvement across the organization starting from the CxOs, and involving HR department, Finance, PMOs, Sales and marketing. It is also about improving everyday and everywhere. 

So to conclude, you are not really following Kaizen if the expectation for improvement is only for the team(shopfloor) and rest are excluded !!!

Watch this video to hear directly from the master Masaaki Imai, founder of Kaizen Institute

https://www.youtube.com/watch?v=jRdTFis4-3Q

Secret recipe for building self organizing teams

I authored this short post for as part of Agile chronicles.

Some time back I noticed something odd with an agile team. Team temperature used to be 10 out of 10, and each team member expressed their happiness working on this project.  I was curious to find the secret behind an “always happy team.” A bit of interaction with the team and the ScrumMaster revealed some disturbing secrets.  Here are the key ones:

1. The team is self-organizing, and individuals can pick the story of their choice and deliver at their discretion!!
2. Team has neither time pressure nor delivery timelines

I thought to myself that this is not a self-organizing team, but a directionless team.

As Esther Derby points out, there are several myths and misconceptions about Self-Organizing teams.  I did cover a bit about these myths during my talk at Lean Agile Systems Thinking conference(LAST) in Melbourne, which is available on Youtube (toward the end at 1:03 minutes).

I understand it is not easy to build a self-organizing team, but there are principles enabling leaders in building such agile teams.

One of the best analogies that I have heard so far about self-organizing teams is from Joseph Pelrine.  As Joseph puts it, building self-organizing teams is like preparing soup.  I thought it would be easier for readers to understand the self-organizing concept if I map the soup preparation steps to the self-organizing steps. Yes, soup preparation involves many more steps, but the key ones below would give the clues to readers for further analysis.

Read rest of the article on  : Agile Chronicles

Photo courtesy : https://flic.kr/p/ayhjag

Measuring Business value in Agile projects

Because the first principle of the Agile Manifesto talks about delivering valuable software to the customer, many agile practitioners are constantly thoughtful of the value in each step of the software-development lifecycle.

At the thirty-thousand-foot level, value creation starts with gathering requirements and continues with backlog creation, backlog grooming, writing user stories, and development, finally ending with integration, deployment, and support. Even with knowledge of all these moving parts, it is common to see organizations only measuring value during development and ignoring the rest of the steps.

What’s the fix? During backlog creation, user stories need to be compared and contrasted in order to promote maximum value delivery. The product owner might need to use different techniques, such as T-shirt sizing, in order to better prioritize the project’s stories.

An alternate approach to measuring the business value of user stories is to use a three-dimensional metric that incorporates complexity, business value, and the ROI. Creating value can often require a change in perspective from the normal project’s tasks and functions. Thinking outside the box, identifying business value before writing the user stories is much better than writing and then trying to evaluate.

Read  the complete article about measuring business value on TechWell

Picture courtesy https://flic.kr/p/8E7Dr5

LAST (Lean Agile Systems Thinking) 2014 Conference

Last week I had the pleasure of speaking  at the LAST 2014 (Lean Agile Systems Thinking) conference. This is my second consecutive year of having opportunity to speak at this popular Melbournian event.I  have seen this event growing year after year. First year, we had 150 attendees, the second year 350 and third year is even more successful with 450 people. The event is highly affordable and run by the Melbourne community.  Some call this conference as  “Meet up on Steroids”. 

The two passionate people who are successfully managing this event are Craig Brown  and Ed Wong.  Organizing such a large scale event managing speakers, schedule, events and sponsors is not a simple thing. The event was such a smooth one, didn’t realize that the day had already passed.

This is a classic example of power of passion and network in the community.  You don’t need many people to make a positive difference to the society, you just need one or two passionate givers.

The session was organized by  TABAR 

I spoke about  10 Irrefutable laws of Agile Coaching.  The presentation slides are available on Slideshare as well. Feel free to download/share.  

My intent for sharing these ideas was to encourage Agile coaches to think beyond  Scrum, Lean, XP, etc.   Agile coaching involves a broader systems knowledge to succeed.

More details about my session:  Agile coaching is one of sought after skills in the IT industry and many experienced coaches are doing extremely well. However some change agents are struggling to make an impact, not because, they don't know Agile but because, they don't know some ground rules dealing with the coaching teams and leaders.

Whether you are a novice or an experienced coach, there are irrefutable laws governing Agile coaches. Based on my own personal experiences coaching teams/leaders since the last several years, I have come to realize the 10 secrets. Irrespective of where you are in the journey as an Agile coach, practicing these 10 laws will help you to become a successful Agile coach. These handy rules can help you anywhere in Agile coaching journey.

Upcoming Agile Project Management MasterClass at Swinburne – Aug 21st and 22nd

This two day Masterclass commences with an introduction to the foundation and history of the Agile movement. It then looks at common practices and frameworks used by teams including Scrum, Kanban, Lean Start-up and XP.

Day two drills into project management activities related to planning, monitoring and controlling projects highlighting the role of collaboration, developing appropriate feedback and quality systems, including elevating the focus from schedule and budget targets to delivering customer value.

This course introduces

• The background and history of Agile management
• Leading frameworks used in industry and their features and benefits
• Principles and practices to initiate and plan a project
• How Agile practices and techniques can be used to manage a project, with particular focus on dealing with a changing project scope

Check out here for more details.

Enterprise Agile Transformation through Centralized Agile Group – Benefits and Challenges

Authored the following article for Cutter Consortium as part of their Agile advisory series.  In this article, some analysis has been done detailing pros/cons of setting up centralized Agile excellence or group to promote Agile as part of Agile transformation in the enterprise.

Here is just a snippet and the complete article can be accessible by  Cutter members.

Read rest of the article on Cutter

Changing the mindset of Agile teams

Recently I penned a guest post for Version One  about the why people behave in the way they do and how to change them ?

Agile is not about practicing Scrum, XP or Kanban. It is a mindset that one needs to cultivate. It is not about doing a daily standup or retrospective but knowing the values/principles behind it. Most of the agile teams are interested in practices and very few are interested to learn the values/principles.

People resist adopting new values and principles as it expects a change in mindset of teams. Changing the mindset of agile teams is always a bit difficult. I have started believing that it is easier to change the people than their mind. The good news is, there are some tools and tips available to help in this journey of changing mindset.

Let me explain one of the tools with an example. A couple of weeks ago, I came across these two dustbins outside of our apartment complex.

As one could see, one of them a simple open cardboard box and the other one is a proper dustbin. Not sure why they had kept these two together. In the next few days, I noticed that people were throwing wastes mostly into the open box. However, the other one needed additional effort to open the lid to throw the wastes, which was left unused.

What I learned from this experience is, if you want people to follow ideas, make it easier for them to learn and use. Or else they will never change.

Another case study is from one of my agile projects. The teams were using an agile project management tool which was not so user-friendly. Teams diligently added all the user stories and tracked them on a regular basis. However, when the need came to extract the key metrics like Velocity and Cycle times, the team had to write queries manually and tweak it regularly. They always resisted this manual, cumbersome process, which was time consuming as well. The teams always used to fall behind sharing these critical agile metrics with the stakeholders.

I suggested an alternate approach, which involved adding a dot on the user story cards after their daily standup until it is complete. It looked something like the one shown in the picture below for measuring the cycle times.  They used a simple sketch pen to put the dots on the cards.  This was so much easier, and the team loved it.  After this little change, they never resisted sharing the metrics.

Conclusion: If you want to change the behavior or mindset of agile teams, create an environment that is easier to navigate and use. The non-intuitive tools and processes could be a major blocker in the change journey of your teams.

Some buzzwords in Agile community and new trends

In the recent times the following ideas/buzzwords are getting filled with the void of struggling, adolescent Agile

1. Holacracy :   Read more here from Zappos example.

2. Real Options Theory :  Read more here

3. For scaling Agile:  SAFe(Scaled Agile Framework) is already popular,  Craig’s  LeSS(Large Scale Scrum) and now ScALeD

4. Open Agile Adoption

Photo Courtesy: Flickr

How culture gets created and how to change ?

I will explain this through a simple example of how culture gets created in organizations.
The team is conducting a retrospective.  They capture all the good, bad and ugly items on post-its and capture the action items as well. However, the Scrum Master never bothers to follow up with action items.
Team attends the second retrospective and the similar issues crop up again.  Some one nudges the Scrum Master about the pending action from the last retro and you would hear that it is yet to be done.
By the time you are in 3rd or 4th retro, team members would have lost interest in creating action items as they have lost faith in this process. This has lead to creation of a culture that “nothing works in this team” OR “It is a waste of time”
When new members join the team and observes the retro, they would be surprised to see that no one is creating action items. They could potentially blame the team for this.  Even if the new team members try to bring their new ideas, rest of the team would be skeptical and pull them down by saying  “nothing works in this team” don’t stress yourself.  This trend will have domino effect on the entire system.
In retrospect, it is not that the team was un-willing to do anything with action items, it is the leader who silenced them in every instance. People in power, authority, dominant and influential positions play a key role in  creating culture in the organizations.
Good news is, it is possible to change. I see two options in such situations, either get a new leader who could enable in creating a new culture or get a shark in the team, who could stand up and challenge the status-quo
What is your experience in changing the culture ?

Different Root cause analysis techniques and tools

It’s common to see people point fingers and play the blame game after a project fails. These blame games not only hurt the team members but also impact their morale as well. Is there a way to avoid these hurtful situations while focusing on improving process and identifying the failure’s root cause? 

The answer to that question can be found with root cause analysis (RCA), which helps to divert attention from people to process improvement.

Typically, agile teams are recommended to do an RCA session in response to issues raised during retrospectives. Shamefully, many agile teams skip RCA and continue to struggle in a whirlwind of issues.

RCA is not rocket science—especially when we have such a simple tool as the five whys. Eric Ries has elaborated on RCA with some practical examples from his lean startup journey. Here’s an example of a simple Excel spreadsheet that shows how to conduct RCA using the five whys; you can download a ready-to-use spreadsheet here.

Read the complete article on Techwell

Photo attribution: ThinkReliability

Scrum, XP, SAFe, Kanban: Which Method Is Suitable for My Organization?

I have recently seen the SAFe framework criticized by the Scrum founder as well as the Kanban founder (see "unSAFEe at Any Speed" and "Kanban -- The Anti-SAFe for Almost a Decade Already"). Method wars are not new, however, and could go on forever. In the face of these discussions, it is important to remember the real intent behind Agile methods.

In this recently published Cutter article, I discuss the importance of understanding Agile as a tool rather than as a goal.  I am also proposing some ideas from complexity theory and Cynefin framework to substantiate the need for parallel/safe to fail experiments rather than  handcuffing organizations with single framework/method or a process.

Read the complete article on Cutter

 

Photo courtesy: Flickr

Tennis coaching , Halo effect and celebrity bias

One of my friends is a very successful  tennis coach, however, he sends his kids to a different coach.  This was interesting, and I asked him why can’t he teach his kids. His response didn’t surprise me at all. He said, kids take parents for granted and some times, they listen to outsiders more intently.

I see a similar pattern at work as well.  Some times, employees listen to a highly paid external consultant rather than an in-house expert or supervisors.

Why is that ?

I googled around to find some research or articles around this kids behavior, and I found this interesting article.  The author gives the following 3 reasons behind kids behind deaf to their parents:

• Biggest Reason #1 - You don't listen to them.
• Biggest Reason #2 - You don't do what you say you're going to do.
• Biggest Reason #3 - You don't keep the commitments you make.

Applying the above reasons in the context of organizations,  I see that employees don’t listen to organizations when organizations don’t listen to them. Is this a reasonable hypothesis  ?

On a similar note,  I have seen another “Celebrity bias”.  I have seen some tweets from celebrities tweeted  and favorited by hundreds. But the same information published by a lesser known person does not get noticed much.  For example,  if  Seth Godin or Richard Branson say something and if a common man “X” says exactly the same thing, then people tend to believe celebrities more than a common man.

Why do we have this celebrity bias ?

Many people attribute this to  “Halo Effect” .  Some good stuff from the article below…

As you read above, the halo effect can influence how teachers treat students, but it can also impact how students perceive teachers. In one study, researchers found that when an instructor was viewed as warm and friendly, students also rated him as more attractive, appealing, and likeable.

Marketers take advantage of the halo effect to sell products and services. When a celebrity spokesperson endorses a particular item, our positive evaluations of that individual can spread to our perceptions of the product itself.

Job applicants are also likely to feel the impact of the halo effect. If a prospective employer views the applicant as attractive or likeable, they are more likely to also rate the individual as intelligent, competent, and qualified.

So, the next time you trying to make an evaluation of another person, whether it is deciding which political candidate to vote for or which movie to see on a Friday night, consider how your overall impressions of an individual might influence your evaluations of other characteristics. Does your impression of a candidate being a good public speaker lead you to feel that she is also smart, kind, and hard-working? Does thinking that a particular actor is good-looking also lead you to think that he is also a compelling actor?

First book: Who is Agile in Australia and New Zealand is published

I had the privilege to  Co-Author  my first book “Who is Agile in Australia and New Zealand”  with  Renee  and Sunish .  This book is available for purchase from here

This book is a collection of interviews with passionate Australia & New Zealand agilists who answer the following questions:

1. What is something people usually don’t know about you but has influenced you in who you are?

2. What would have become of you, if you were not doing the job you do today?

3. What is your biggest challenge and why is it a good thing for you?

4. What drives you?

5. What do you think makes a great team?

6. What is the essence of Agile?

7. What is the last book you have read and which book made a huge impact in your life?

8. If you were going to have a dinner party with anyone alive or deceased - which three people would you invite and why?

9. What is the one piece of advice you would give to someone just starting with Agile?

10. What question do you think I should also ask and what is your answer?

11. Whom do you think we should ask next in Australia and/or New Zealand and why do you feel they should be included in the book?

Based on the original "Who Is Agile" book, this book is a regional version for Australia & New Zealand. Whether you’re a novice or an Agile Guru, this book is going to help you learn a bit about the people behind the names & get their perspective on Agile.

Which Agile adoption Strategy is good for my company ?

  The statistics I have seen recently give me a euphoric feeling about the pace of Agile adoption. However, I feel that most of the so-called "Agile projects" are just the "water-Scrum-fall," which no one is willing to admit. I could list various reasons behind the failure, but one thing that stands out clearly is a poor Agile adoption strategy.

Organizations generally go with copying the practices/strategies from other popular brands/companies with the assumption that it works for them. In reality, it won’t.  Every practice is context dependent, and since each company is different the strategies adoption should be different.

In this Cutter article, I write some of the secret ingredients that fuel the strategies.  Check this article out:  http://www.cutter.com/project/fulltext/advisor/2014/140306.html

Photo Courtesy

How to overcome resistance to change ?

One of the key responsibilities of the change agents is to bring positive change to the teams. However, we always hear that people resist change !  Some of the common answers for any change proposal includes,  “It won’t work here”, “It doesn’t work”, “We don’t have time”, “Our priorities are different”.

According to Peter Senge, “People don’t resist change but resist being changed”.  As human beings we change almost every day. Whether it is getting married and living with a new person or a new born baby adjusting to the changing environment by learning things.  People change when they perceive the change satisfies their needs and fulfills their wishes. 

From the change agents perspective, It is very important to provide as much information as possible from different angles while suggesting change. Typically, the vision for change gets initiated by the leadership and change agents are roped in to implement them.

Based on my experience, I see the following obstacles that derails changes.

1. Unclear goal
2. Goals with no way to track
3. Change agents with no access to visionary. This is a major issue as the vision gets diluted while being passed from one layer to the other
4. Benefits of the change shared only through the business angle. People who are supposed to change will keep asking, What is in it for me ?
5. Looking at a quick fix rather than a sustainable change

I could enlist many more challenges !! 

Before I conclude, I invite you to watch this good video about overcoming resistance to change.

Photo courtesy: http://flic.kr/p/7e1XGT

Tips for coaching Agile teams

I recently attended Lyssa Adkins’s workshop on coaching agile teams at the YOW conference, and I would like to share some of the lessons I learned. The workshop began with a presentation defining the different characteristics of an agile coach, including being a bulldozer of blockers,a servant leader, and a guardian of quality and performance.

One needs to understand the skills and mastery needed to succeed as an agile coach. The agile coaching competency framework provides the guidelines, criteria, and pathways for an aspirant. Knowledge is one part of it, but listening skills are even more important. Coaches need to be aware of their own listening skill level and strive to reach level three.

Change could be brought, not by listening but by asking powerful questions (PQ). Even though there are several resources about PQ available on the Internet, I would highly recommend reading Co-Active Coaching.

Continue reading this article here to learn more about  Arc of conversation and Asking powerful questions.

When you have a chance check this link out to read all my articles on Techwell.

Are you new to offshoring ? Beware of these technological challenges

Tools and technologies are an essential part of any distributed Agile development. Companies invest thousands of dollars in procuring high-fidelity video conferencing equipment at their onshore locations. However, one thing they nearly always ignore is the integration capability with their offshore locations.

Continue reading rest of the article on Cutter ….  

Why should you be worried about stress at your workplace ?

One of the key reasons Steve Ballmer cited for his resignation from Microsoft was that he was under too much pressure from senior leadership. The bottom-line seems to be that the board expected quick results to beat the competition, which resulted in a lot of stress for Ballmer; he couldn’t take this anymore and decided to step aside.

This kind of stress and expectation is not uncommon in the IT world. The same pressure trickles down from the top to the delivery teams, spreading the negative effects throughout the company.

Many organizations don’t realize that putting undue pressure on people forces them to make more mistakes rather than helping them perform better. Whether it is running a project or a company, the cost of stress in the workplace is more damaging than the benefits.

The European Agency for Safety and Health at Work clearly describes that stress is due to the demand-and-supply gap. In a software development environment, the demands could be to deliver the working software on time and within budget using available resources. Most of the time, however, the budget and resources are inadequate to meet the demand, resulting in stressful situations. 

Continue reading rest of the article about managing stress at workplace here  on Techwell

Guest post: Attitudes of a Great Software Developer

About the Author

Rajaraman Raghuraman has nearly 8 years of experience in the Information Technology industry focusing on Product Development, R&D, Test Data Management and Automation Testing.  He has architected a TDM product from scratch and currently leads the TDM Product Development team in an IT MNC.  He is passionate about Agile Methodologies and is a huge fan of Product Development, Agile Development and Agile Testing.  He blogs at  AgileDevTest Blog.  He is also an author of a free Ebook "Programmer's Motivation for Beginners".  Connect with him on Google+

Software development is an art, not just a science.  You can learn all the technicalities of software development, but you need to be absolutely passionate about coding and perceive it as an art to be extremely good at it.  If you are one such person, I will introduce you to the journey of becoming a "Great Developer".  The objective of a Great Developer, as i name him/her is to make his/her art as beautiful as possible and make it the best.

In my own thoughts, I will share some attitudes which a great developer should have apart from the general expectations of being technically and analytically sound, understanding requirements in detail, good design skills, etc.

Attitude #1 -  A bug is a question of my ability to write good code

Fixing bugs is part and parcel of a software developer's activities.  A bug is obviously the worst enemy of a Developer.  But how many developers think in the following lines while fixing the defects

· What I could have done to avoid this bug in the first place?

· How did I allow this bug to escape my eyes?

· OK, something wrong has happened this time.  How do I avoid the same mistake next time? What steps do I need to take?

Truth is very few developers think on those lines.

A  person willing to be a great developer should consider a bug as a threat to his position, as a threat to his credibility, as a threat to his programming skills.  That is the attitude that will make him/her a great developer.

Attitude #2 - Mr. Tester, I challenge you to find bugs in my code

How many developers have this attitude?  Many developers think that the job of the testers is to find bugs.  Yes.  Obviously, but that doesn't mean as developers, we can take bugs for granted.

A great developer or a person willing to be a great developer should
always invite / challenge the tester to find bugs in his/her code.  He should have so much confidence in his code that he can challenge in such a way.

Attitude #3 - No compromise on code quality

Code quality should be of prime importance to a developer.  That will include following the right coding standards, making the code more maintainable using proper design and code refactoring, etc, etc.  But how many of us compromise code quality for many reasons best known to us?

I can quote an instance in my project to explain this.  I was leading a team of developers and we were working on fixing something in the very last hours of a Friday night.  We had to give a build on Monday.  All of us were looking into the problem.  I got curious as I saw the problem and started getting my hands dirty in the code.  Time went by and only the last 5 mins were left for everyone's cab.  It was a make or break.  We had to come the next day, if that was not solved today.  I did something at that time, which absolutely infuriated all my team members.  Unable to see the clarity in the running code, I refactored a bunch of lines at that last minute.  Everyone were so pissed of, that they started scolding me :-) asking if it was so important at that moment.  I answered "Yes, it is that important".  Of course we worked the next day for other reasons, but the whole point was even though I had an option of fixing  the code in the running code, I chose to refactor the code not compromising on the code quality.

A great developer or a person willing to become a great developer should never compromise on the code quality, no matter what.

Attitude #4 - Confident but not arrogant

A great developer or a person willing to be a great developer should be absolutely confident of his abilities but should not be arrogant towards fellow developers and testers.  He should always remember that he is part of a team that is working towards a common goal of shipping a project on time with good quality.

Attitude #5 - Acknowledge the Tester

It can happen that despite all the hard work and efforts put in by the great developer, a great tester can still find defects in his code.  In those cases, acknowledge the great tester.

A great developer or a person willing to be a great developer should always acknowledge the tester for the bug that he found.  He/she should remember that the bug is the enemy, and not the tester :-)

With this I conclude this post, hope you find it informative.  Thanks for the read.  Cheers.

If you found this post useful, please share it with your friends.  You can also stay updated with the latest blog post by simply submitting your email id to the right in the section "Get Updates by Email"
If you liked this post, you will also like my free Ebook "Programmer's Motivation for Beginners" which is available at http://programmersmotivation.com.