Adopting Agile is all about changing the Mindset – Scrum Motivation

Agile methodology has proven results. Many software organizations are already taking real use of this methodology and many others are adopting this software development methodology. The challenge is in completely overcome switching to this methodology especially in an organization which has been following water fall model or any other traditional software development methodologies in the past.

Everything boils down to people in a team. The developers, testers, architects, customers, virtually every stake holders involved in the process should have been convenienced and more importantly realized the benefits of agile methodology. Even few stake holders did not like or not convenienced with agile benefits, then migrating to agile would be a failure. Failure because, agile requires a lot of people interactions than documentation.

One way to get started with agile is that ask all the stake holders about their real opinions. A formal training has to be given if the stake holders are not aware how agile is going to work and what difference it makes for each of the stake holders in their day to today activities. Before announcing agile methodology officially, a trial PSI(Potentially Shippable Increment) can be tried out just observe the peoples' behavior, opinion & nature of questions and the output.

Hearing lot of questions from every stake holder is a good sign that people are curious to know about the methodology; however, if the same questions start repeating again across the PSIs then probably people are not comfortable or not convenienced. Agile is best suited for pure software development (for example, if you are developing a website for a bank), however if the agile is being applied for products that involve multiple assets such as hardware, firmware and a software, there will definitely be a lot of questions and its going to be a challenge.

Let’s say there exists a team called Architecture Team who decides the architecture of the product portfolio and work only architecting the future systems/enhancing the existing systems. This team may not have the tasks that can be broken into smaller junks and demo the work in each Sprints and may feel agile is not worth following. However, the architecture will be ahead of design and coding activities. And the same applies for hardware & firmware also. The System Architecture, Hardware & the firmware can be finished ahead of the software since these will be mandatory inputs for software work.

There are no hard rules to follow in agile, what makes sense and adds value to the customers can be taken up and adopted which is exactly 'scaled' agile framework. If somebody feels that he/she is doing a particular task that agile demands but has no value the customers(internal or external), then that task should not be performed.

Having said all that, finally it comes to the actual people. It’s all about the mindset of the people and same level of frequency among people. Initially it may so happen that people tend to go back to their old or traditional way of work, so there has to be continuous motivation. If people do not change their mindset, then deploying agile is going to be a nightmare. Once people realized the benefits of following agile, then it’s going to be a 'self organizing' teams which require no external motivation or the support.