Biggest hindrances to being agile

I often wonder how projects fail to be agile enough even though the team consists of talented team members.  So today I am planning to summarize few points that are the biggest hindrances to being agile in a team based environment.

1.  Laziness / Procrastination

I think this is by far the number one hindrance to being agile.  This habit by individuals will result in a gap that widens with each work that is being delayed.  Let me explain this a bit better.  If you are part of a QA team, your responsibilities will primarily include testing of your module perfectly.  Obviously everyone will do that.  But automating the current testing will act as a regression suite for your future needs.  How many of you would do that if automation is not mandated in your process?  The answer is not all.  

So the laziness / Procrastination sets in and the gap widens with each delayed item.  So unless automation is mandated, it will not be implemented by everyone.  So the Agile Definition of Done should include all these nitty and gritty details that makes the entire process more agile.

2.  Lack of understanding

Not everyone is comfortable with Agile concepts and the lack of understanding of Agile has a direct impact on the team performance.  No Agile is almost always better than bad Agile.  For example, trying to be Agile without giving importance

Agile, Agile, Agile. What is so different about Agile for Developers and Testers?

The word Agile has taken the software world by storm.  Agile has grown well past it's hype cycle.  People have got increasing awareness about Agile, however doubts still remain in several minds especially developers and testers.  So what is so different about Agile and how does it matter if you are a developer or a tester?

Fast Paced Environment

Typically Agile Environments are fast paced.  It doesn't mean that there will be no breathing space.  No.  That is not the case.  In good Agile environments, the outputs are faster.  It takes lesser time to deliver same features in a good Agile environment.

More focused results

The problem with many focus is that they try to do too many things at once.  And many a times, multitasking is counter productive.  That is both true for an individual or a project.  So Agile puts more emphasis on providing proper attention to the things that really matter.

Focus towards customer rather than technical easiness

Given a choice between easy for the customer vs easy for us, we almost take the latter option.  And that makes sense sometimes, but not always.  However in Agile Projects, customers are kings and if there is something that will be easier for the customer, we will do that even though it means that it might not be technically easy.  There are of course technically infeasible aspects but that is a different point altogether.

Common excuses a Developer makes when a feature doesn't work [And how to avoid them in the future]

I always feel that Developers should have an attitude for development, which I have detailed in the blog post Attitudes of a Great Software Developer.  But generally when it comes to issues, a lot of developers make excuses.  As long they are genuine, it is not a matter of concern however if it is really an Excuse, then it is a cause for concern for the entire team.  I am guilty of a few of those myself however when I saw the big picture, I rectified those and understood why people make those excuses and how we can avoid them in the future.  I am detailing a few in my below post.

1.  It works fine in my machine

Come on guys, this is the number one excuse that developers give.  We often have a feeling that testers or the customers have a magical computer which injects bugs into our code.  But that is far from true.

The only way to avoid this excuse is to be aware of the environments that are used for development, testing and production.  By being aware of those, the first thing you would probably ask is, what sort of configuration/environment it is and get more details about the issue and check if it is really a valid bug.  Another way to avoid this is to have a Continuous Integration environment, where with each and every code check-in, code is compiled and deployed in some test machines.

Image courtesy: cheatcc.com

How to improve agility of an Agile Team

Often as an Agile Project Manager or an Agile Scrum Master, your very first challenge is to improve the agility of teams.  Before we try to go to the core topic, we will try to define what is Agility?

Wikipedia defines Agility as

"Agility or nimbleness is the ability to change the body's position efficiently, and requires the integration of isolated movement skills using a combination of balance, coordination, speed, reflexes, strength, and endurance"

From the definition, it is quite clear that Agility is a function of lot of factors such as Balance, Coordination, Speed, Reflexes, Strength and Endurance.

So in this article, I will try to post my thoughts on how to improve Agility of a Team in my own words of course and out of my experience.

 

 

1.  Change their mindset

Agile is a lot about mindset.  Once someone is into that mindset, obviously he/she will contribute the best to the team's cause and thereby it will increase the speed and also the agility of the team.
 

2.  Change your mindset

Acknowledge the fact that you need a mental conditioning as much as the team.  First of all, try to understand what Agile is all about and how it benefits the different stakeholders in the teams.  Try to understand that Agile is not a miracle game and it takes time, proper execution, support from every team member and support from team as a whole to reap its benefits.

 

 

3.  Improve collaboration

Agile is lot about team working together to complete challenging tasks rather than several team members working in silos.  Emphasize the fact that Agile is a team game.  So Improve the collaboration among the team members, ask them to pair up for some problems and encourage good collaborative team work and make collaboration a habit.

Agile is not for you IF

In my previous posts I have tried to put forward my points on What an Agile Project needs for success, 11 areas an Agile Project Manager needs to focus o... and Scrum meeting. Are you kidding me?

In this post I am going to describe in my own words and experiences that Agile is not for you if you are among the following category.

1.  If you are not willing to change your mindset and continue to work the same way, you did before

2.  If as a manager, you think people are resources

3.  If as a developer, you think your job is just to code by specifications

4.  If your organization is run by bureaucrats

5.  If your team is not mature enough to handle changes frequently

6.  If you want to deliver something fixed within a fixed time frame

7.  If you can't have customer or Product Owner inputs on a regular basis

8.  If you have fairly straightforward requirements

Scrum meeting. Are you kidding me?

Recently I was part of a "Daily Scrum Meeting" in a reputed product development company (I travelled to work with this company on a joint initiative, anyway that is not the point of this blog post).  I was really baffled at the way the meeting was happening, because there were several things that didn't go well during that meeting.  Being a huge fan of Agile and a committed practitioner, it was concerning that people were actually adopting it the wrong way.  I felt like asking to them "Is this a Scrum meeting? Are you guys kidding me?".   In this blog post, I am sharing some of the learning from the meeting were:

• Everyone on time

A Daily Scrum is a commitment to the entire team.  So everyone needs to be on time for the meeting.  Never forget your meeting etiquette. :)

• It's for everyone team

A Daily Scrum meeting is for the entire Scrum.  It is not just a subset of the people.  Agile focuses highly on team collaboration and it's high time teams understand that.

• Everyone present throughout

Intention of the daily stand up is to have the team members communicate, collaborate and the team should be knowing what each others are doing.  No one should leave a meeting in the middle.

MongoDB Schema Design - How to think Non-Relational

A nice video about MongoDB schema design.  To all who are new to MongoDB, MongoDB is a leading NoSQL document oriented database.  A table in RDBMS can be contrasted to a Collection in MongoDB, and a row in RDBMS table corresponds to a JSON document in MongoDB.

Key Points:

• MongoDB introduction
• Comarison of concepts of MongoDB Vs Traditional RDBMS
• Schema Evolution
• How to Model 1-Many and Many-Many relationships in Mongo
• Queries and Indexes

11 areas an Agile Project Manager needs to focus on

In my previous posts I focused on the Attitudes of a Great Software Developer and the Attitudes of a Great Software Tester.  

An Agile project's success also depends a lot on the Agile Project Manager.  The decisions he takes and the emphasis he provides on certain areas will pave the way for a successful Agile Project.  In this post, I provide some key points that an Agile Project Manager should focus on, for the betterment of an Agile Project

• Employee hiring
• First and foremost, an Agile Project Manager needs to hire the right people for the project.  Apart from the technical skills and non-technical skills required of Agile teams, it is imperative that the chosen candidates adopt to the Agile practices and are themselves Agile.
• Technical and Non-technical grooming
• Once into the project, the candidates needs to be groomed to meet the project needs and also grow further.
• Employee motivation
• I always believed that Employee motivation is one of the Critical Success Factor of an Agile Project, for that matter any project.  Motivated employees can do wonders if provided with the right environment.  Motivated employees go that extra mile to achieve the common goals.  Hence an Agile Project Manager needs to put high emphasis on this point.
• Engineering Practices
• There are a lot of engineering practices that make an Agile project successful.  An Agile Project Manager should focus on putting the right Engineering Practices to place. He/She should not forget that there is an overhead in following certain practices, but once fully functional, they start to provide high returns on the investment.  For ex. following Automated Unit tests and TDD can be very difficult to start with, but over time, developers get into that practice and the results start to follow.  

What an Agile Project needs for success

In my previous posts I explained about the Attitude of a Great Software Developer and Attitude of a Great Software Tester.  I am a huge fan of Agile methodologies.  I believe, if an Agile project needs to be successful, there are certain factors that will make it happen.

• Technical Craft
• The technical capabilities of a team should be of top quality, if you want to run a successful Agile Project.  An Agile project is actually run by the collective strengths of the individual team members and hence they need to be highly adept at their jobs.
• Team maturity
• This is one of the critical success factors for an Agile Project.  Not everyone is comfortable in working in an environment where there are lot of changes.  Hence the team members and the team as a whole should be highly mature enough to understand the realities and make quick yet thoughtful decisions
• Collaboration
• I cannot stress this point enough.  The entire team should collaborate within themselves and also with external stakeholders.  This is actually one step ahead of an important point Communication.  It emphasizes the fact that it is a complete team game.  A developer needs to collaborate with Product Owners, Testers and vice versa.
• Team Morale
• Agile methodologies put a high emphasis on the people who run the projects.  It is a given that, a team with high morale will produce better quality work and with more speed.  It is important that the team is

Attitudes of a Great Software Tester

In my previous post, I explained in my own words the "Attitude of a Great Software Developer".  This post will focus on the testers.  Developers and Testers are two great personalities that work literally in the opposite direction but towards a common goal of producing good quality software.  One deals with the making aspect of the software and other with the breaking aspect of the software.

In this post, I will share the attitudes that a Great Software Tester should have, in my own views.

Attitude #1 - I want to break that software at any cost

Make no mistake about it.  A tester's job is to find out bugs and in the process, make the software better and better as time progresses.  A bug is a tester's best friend.  So his/her primary intent is to break the software at any cost, find the loop holes, find that best friend of his one way or the other.  Whether it is through a systematic process of executing test cases or adhoc testing or exploratory testing, the objective is clear.

If you want to be a Great Tester, your attitude has to be to "Break the software at any cost and find out that BUG".

Attitude #2 - Ms. Great Developer, I challenge you that I can find bugs in your code.

I seriously doubt how many testers have this attitude.  

But if a person wants to be a Great Tester,

I want to run an Agile Project

This 2 part video clearly explains the challenges in running an "Agile Project".  Funny but very thoughful videos.

"I want to run an Agile Project" - Part 1




"I want to run an Agile Project" - Part 2