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.

Estimation of User Stories (Features) in PSI planning – Scrum (Agile) Methodology – Tips & Techniques

In Scrum Methodology, the estimation of identified user stories is an essential and important aspect. In-fact the software estimation is a challenging task and it depends on the nature of the software,  technologies being used to implement the user stories or it may depend on the kind of past product knowledge or the team
experience level on the product lines and domain knowledge. It so happens that there are always "forgotten tasks or scenarios" which were never thought of during the estimation process.  In accurate estimations lead to bad burn down charts and graphs which usually management keeps an eye and reviews on regular basis. So when there is an accurate estimation (as much as possible), the sprint work goes smooth.  In this post, I would like write what are the best practices, techniques that help us come up with accurate estimations.

• Never ever take single person's or individual's estimation granted. The estimation has to be a collective decision from all the participating scrum members.

• Compare the story in hand with other past done stories before giving an estimate for it. Every team would have done similar tasks in the past and there can be estimation data. The organizations that maintain good matrix have an advantage of predicting the estimation basing the past matrix.

• Pokar planning has been proven effective method in software estimation. In this method, each scrum team member is bunch of card with relative size or the estimate written on them. The user story is read out and each team member is to think and project a pokar card that has the most accurate size/effort. Everybody's pokar says different effort, and then team members discuss themselves why each team member is thinking that is the most accurate and brain storm the user story again and come to a common estimation that is agreed upon by all members.

• For the user stories which are unclear or there is no sufficient clarity, they are in-fact the spikes and team should not even estimate for implementing it but an investigation story to understand more on the particular user story. Because, sometimes team requires time to understand the user story and which is very essential for estimation.

• Consider the 'side effects' of implementing a user story in an existing software, such as impacted areas and testing scenarios. This is mostly 'forgotten' aspect and hence estimation has to include testing effort of the user story in all the affected areas of the software as the need be.

Estimation requires the scrum team to enough experienced. There should not be any estimation issues in an 'Self Organizing' scrum teams. The becomes self organizing after team members work together for long time and there is a common frequency among members in undertaking any work. The estimate created by a new member who recently joined the team may not be accurate and its obvious and this is the main reason why Pokar planning is highly recommended.

Test Driven Development (TDD) Practice - An Effective Software Development-Test Style

TDD - Test Driven Development is where automated Test Cases are written before even writing the actual code. Once the test cases are written the actual minimal code is written just to pass the test case. TDD puts the software test focused before coding and enables to write ONLY testable code. This style of software development makes developers think about the kind of interface that is needed and what are the method parameters before even writing the functional code. Usually in TDD, automated unit test cases are written, however, this can be extended for integration test cases also. Understanding the interface well ahead helps to tackle the Developer Integration Test (DIT) challenges. Following are certain facts, best practices for people who are willing to follow TDD.

It’s not mandatory to automate all the test cases using a single tool in Test Driven Development Approach. And it may not necessarily be for example JUnit Java. It can be any testing tool XUnit or any UI automated test framework such as Eggplant.

Test Driven Development gives a high confidence for the developers during the code refactoring. Code refactoring activity as riskier operation when there are no automated test cases because during refactoring every time there is a code change, that needs to be tested first to ensure it works and does not break any of the other software functionality before continuing with further code refactoring.

To begin with TDD, the best practice is to write test case to test the smallest possible chunk of software functionality. Writing test cases for a larger functionality is discouraged. Automate the software builds using tools such as Hudson, Jenkins that will execute the automated test suites and report build success or failure that includes the result of test case execution results. Its a best practice to gather as a team and discuss the various module interactions before starting to write the automated test cases which helps resolve the developer integration tests.

TDD is a challenge and requires lot of encouragement especially for the team which not got used this methodology and not the team wants to follow. The benefits/advantages have to be thoroughly discussed and realized and these realizations are most of the times inspiration for following the Test Driven Development. It’s also said that developers following TDD are more productive than developers who follow traditional way of software development.