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.

Thought Leaders who disrupted the Software Industry

There is something in common among thought leaders.  Their thought innovations simply disrupt an existing paradigm.  Today we will see a few of those who really disrupted the Software Industry, be it in Development or Testing or Databases through their inventive and innovative thinking.

Kent Beck:

Kent Beck is the creator of the revolutionary ExtremeProgramming or XP as it is shortly called, along with 2 other notable thought leaders and improvisational Test DrivenDevelopment.  He is also the mastermind behing JUnit, the xUnit class of Unit Testing Frameworks.  These innovations eventually formed the basis for what we currently call Agile SoftwareDevelopment.

Martin Fowler:

If you don’t know him, then probably you are not in touch with the Software industry recently.  MartinFowler is a chief Scientist in Thoughtworks.  He is a highly reputed international speaker and is a guru who popularized Agile and NoSQL to a great extent.  He along with other thought leaders formed the Agile Manifesto.  Some of his notable writings include Evolutionary Design, Agile, ContinuousIntegration, ContinuousDelivery, NoSQL and Mobile and is a author of several best selling books.

Ward Cunningham:

He is one of the 3 inventors of the Extreme Programming.  Also a pioneer in Design Patterns, Extreme Programming and the Agile movement and one of the thought leaders who framed the Agile Manifesto.  He is also the inventor of the Wiki and the popular FITframework. 

Ron Jeffries:

He is also one of the 3 inventors of the Extreme Programming.  He is also the author of one of the best selling books “ExtremeProgramming Adventures in C#” where he wrote about his journey through XPing using a new programming language (C#).

James Bach:

James Bach is a revolutionary thought leader in the field of Software Testing.  He is most notable for his works on Exploratory Testing along with other thought leaders, Session Based Testing and Context Driven School ofTesting. 

Ken Schwaber and Dr. Jeff Sutherland:

Inventors of the ever so popular Scrum methodology in Agile, which revolutionized the way of working for teams and brought a new perspective to Agile Projects.  They are also the initial signers of the Agile Manifesto.  Ken Schwaber is also a founder of the Agile Alliance and Scrum.org.  He is also a book writer and has written on varioustopics in Scrum.

Michael Stonebraker:

A computer scientist and one of the fathers in the Database Management Systems.   He is the inventor of the RDBMS Ingres and Postgres.  He is a pioneer in the field of Big Data and is most notable for his work in Vertica and VoltDB.  He is also one of the criticsof the NoSQL movement.

There are a handful lot of other Thought leaders in the industry, but unfortunately we would not be able to cover everyone in this post.  Do you aspire to become a Thought Leader?  Who is your most favorite and respected Thought Leader?

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 Test Data Management Blog & Agile Blog.  Connect with him on Google+

Power of the Startup Culture - Small or Big Organization

Everyone knows a thing or two about Startups.  Either they are involved in one or read about one.  The most important thing about the Startups and why it is so exciting is the culture within the startups.  And it is quite true that, even though rare, startup cultures can prevail even in large organizations.  But definitely not without the support of the management.  So that brings us to the question, what exactly is this startup culture and what are the exciting things that are associated with this so called startup culture.  In this article, I am going to point out few things that make together the startup culture.

• Passion
• One thing that you get a lot from people working in a startup or a startup setup (like a very small team in a large organization) is plenty of passion.  People are passionate about their work, their team, their product or their service, their organization, their managers, they are passionate about literally everything.
• Lots of energy
• The thing that passion brings to the table is the high energy, it almost feels like you have plenty of electricity, we will only need to utilize the energy in an effective way.
• Group & Individual Ownership
• People tend to take / have a lot of individual as well as collective ownership in a startup setup.  Every loss of the product/service/company is treated as their personal & team loss and they take collective responsibility and every victory is cherished as their personal and team victory.

Lessons Learnt in Product Development

Product development is an interesting activity.  It involves a lot of challenges and lot of learnings.  But over time, we get to learn a lot of crucial lessons.  In this post, I am going to share some of my learnings based on my experience in Product Development.

• Go for an MVP rather than a full blown product
• A product might require lot of changes according to the changes in the market.  Hence it is imperative that a product needs to be shipped as soon as possible to the customers to get their feedback.  But how do we ship our product in 3 months when the actual development takes around 2 years.  That's when a Minimum Viable Product Strategy will help.
• Assess what the market requires and prioritize that over the internal product roadmap
• A lot of times, we have fancy features or features that provide extra punch to the product.  Those can wait.  What really needs to go to the market quicker are the features what the market really requires at present, solves the problems at present.  It is like "A bird in hand is worth 2 in a bush".  Do not include features envisioned by us too early in the life cycle, they can wait until they are absolute killer features / selling points.
• If a product takes shape, increase the investments on the Product to take it to completion
• Typically things start small and then the product gains momentum in terms of popularity or demand and is seen as a value proposition.  Then it is time to increase the investments in the product to make it more robust, stable and to deliver it fast to the market.

Video - Testing in an Agile Environment by James Bach

A nice video about Testing in Agile Environment by James Bach.

Some key notes from the video:

Testers are like the headlights of a car.  Testers don't steer the product/project, they illuminate the status of the product to the different stakeholders

Some of the important things that a tester needs to do during a sprint planning phase

• Learn (Ask a lot of questions)
• Know about Testability
• Observability
• Controllability (control states, configurable)
• Simplicity - Some features can take longer to test than to develop - Alert the Dev and managers about this
• Going through spec and highlighting dodgy things

Other points:

• Testing directly on the developer machine (Shake n Bake) - a session for 90 minutes or lesser
• Try to test defects as soon as they are fixed, that's when the developers are still thinking about the defects.

To be aware of:

Automation - tendency to be biased towards automation, play with tools rather than testing

The art of debugging

In software, everyone faces issues almost daily.  We need to be highly equipped to solve those issues.  Not all problems are straightforward to find out and require a lot of debugging to be done.  Hence debugging skills is of prime importance.  I would like to reiterate that everything in software development is an art.  Similarly debugging is also an art.  In this post I will focus on how to debug a software problem.

• Understand the architecture
• The more the number of components in a system, the more complex it gets to solve an issue.  It is critical to understand the architecture of the software / the module in order to debug a problem.  Suppose your system has a client web browser and at the server side a web server and a database server.  What if this setup is required to be able to work through a VPN connection? And you get an error in your web server mentioning that you "Could not connect to the database server", where do you think the problem might be.  The problem might be anywhere.  Hence it is very important to understand the architecture if you want to solve the problem quickly.
• Analyze the entire picture
• Once you get the entire picture, analyze the entire picture and try to see where the symptoms are lying.  I refer symptoms here because whatever you see is only a symptom, we need to trace to the problem in order to solve it.
• From the symptom, try to trace the problem
• Many problems tend to have more than one symptom, look out for those and try to get those hints.  In our example, "Could not connect to the database" is a symptom.  The problem might be due to various reasons.