The Agile School

In traditional software development model QA/testers were actively involved in only certain phases of the project. After development finishes the coding the entire project was handed over to QA. In many cases QA and developer wouldn’t even know each other. All the communication will be through email or bug tracking system. I remember one instance when my project manager relocated the entire QA team to another building!!! He didn’t want the QA and development team to communicate face to face. We had different competency centers for QA and development teams with different career objectives and career ladder.   The QA team had a separate identity, a feeling of ownership over an entire phase of product. They were called the gatekeepers of quality. Don’t fear the change But in scrum apart from the sprint cycles there are no definite phases. In scrum there is a big change in the way team operates and interacts. In scrum there is no differentiation between a QA and developer. Scrum jus

this is a thought provoking article by   James Grenning Boy Scout Rule Applied to Every Day Coding http://www.renaissancesoftware.net/blog/archives/90

Lighting Corporate Passion: Everything you need to know about FedEx Day Introduction  A FedEx Day is a 24-hour event in which employees deliver innovation to the company they work for. It is called FedEx Day, because you have to deliver overnight, like the parcel delivery company. A FedEx Day is a fixed time box in which people are not disturbed for regular work. Within this time box, employees have total autonomy over the project they are enthusiastic about. They decide for themselves what they will be working on, who they are going to work with, and how they are going to do it. Only one rule applies:  People who sign up show the results to the company at the end of the FedEx Day. In short, a FedEx Day is about boosting motivation and creativity overnight by getting out of people’s way. Business Model The traditional business model regarding motivation is built around external motivators, the carrot and-stick motivation scheme. For simple, mechanical tasks, punishme

Scrum/Agile demands frequent delivery of software. Most of the companies develop software in a sprint of two weeks. ( How to choose Sprint duration? ) But many companies don’t release software that frequently. According to scrum principles software at the sprint end should be of shippable quality. But really is this the case?  Many teams who diligently deliver the software periodically complain that because of frequent release they are not able to fix all the bugs. Because of the number of bugs they have an affinity for longer sprint cycles. But in reality there is no co-relation between the sprint duration or release duration and the quality of the software produced after each sprint. Slow down to move fast If you or your team is in a vicious cycle of releasing software with bugs release after release – then stop what you are doing, review the process you are following Review the definition of “done” – Schedule a meeting with all stakeholders, decide on a definition of done.

I have seen this conflict in many organizations which are new to Scrum/Agile. Most of them are transitioning to agile methodologies from the traditional methods. It’s very difficult for that management to let go the power hierarchy. They still want one single neck to catch. They never believed in collective thinking. Rather than motivation , their believe in pressure to get the work done. Such dysfunctions exists in most of the organizations, scrum just exposes it. ScrumMaster doesn’t run the scrum. He/She should help build a team, bring out the leaders in every member of your team. ScrumMaster helps the team to self-organize so that they can move forward without the classic “delay” of waiting for decisions. ScrumMaster is not a person who can be used as a single neck to catch or blame. Scrum is a collective team approach. If it succeeds everyone succeeds if it fails everyone fails. ScrumMasters in such an environment have to do a critical job in the transition. You will have

When developing software, it makes sense to 'fail early, fail often'; to become aware of mistakes quickly and to learn from them. This means being able to deliver software as early in development as possible. This makes it easier to gather opinions and promote discussions with the people who would want to use the application; and then respond to the feedback. A nice article by James Moore Read the full article @ https://www.simple-talk.com/opinion/opinion-pieces/the-benefits-of-regular-deployment/ The Benefits of Regular Deployment