Software the Agile Way....

1.  HP LoadRunner Performance testing for websites is something which, in the past, was mostly done with software tools installed on local machines. Take for example HP's  LoadRunner , probably the most well known tool in the world of performance testing (it’s been around for a while). 2. JMeter - Advanced Open Source Option JMeter is an open source project that is very similar to LoadRunner as far as technical capabilities go. It essentially runs simulated, virtual users that make all of the requests that a real browser would make. The JMeter Challenge Like many open source, developer-oriented platforms, the real challenge with JMeter is that it was written with a focus on technical functionality and not on user experience. For example, in JMeter, a virtual user is called a ‘thread’, whereas other tools use the terms 'virtual user', 'simulated user', or even simply, 'user'. JMeter also makes use of the term 'sampler', whi...

The 5 Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem.The primary goal of the technique is to determine the root cause of a defect or problem. (The "5" in the name derives from an empirical observation on the number of iterations typically required to resolve the problem.) A key phrase to keep in mind in any 5 Why exercise is "people do not fail, processes do". Source-  5 Whys Example-  The vehicle will not start. (the problem) Why?  - The battery is dead. (first why) Why?  - The alternator is not functioning. (second why) Why?  - The alternator belt has broken. (third why) Why?  - The alternator belt was well beyond its useful service life and not replaced. (fourth why) Why?  - The vehicle was not maintained according to the recommended service schedule. (fifth why, a root cause)

All projects have risks and the risks have the potential for negatively impacting the project. (I am not referring to opportunity (positive) risk.)   Try to Include Budget and Schedule for Unknown Risks A project manager can request additional budget and schedule to account for known risks at the beginning of a project. Of course, the risk contingency does not include the full impact of risk. Instead you multiply impact by the percentage likelihood for all high risks. Then add the numbers to come up with a risk contingency budget and schedule. However, risk identification is not something that only happens at the beginning of a project. The project manager assesses risks throughout the project.  Therefore, it makes sense to include time and budget for unknown risks as a part of your estimating process. If you do an effective job of periodically reassessing risks, you may find new risks to manage that were not included in the original risk contingency budget. You can...

Source: (The Standish Group, 2011) Lack of top management commitment Scrum demands commitment from the top management through the assignation of a full-time cross-functional self organized team. The team is protected and can take their own decisions about the project with the support of the top management. Failure to gain user commitment In Scrum, the team constantly show working software to the users, which increase the commitment and feedback. Misunderstanding the requirements Scrum knows that is not possible to fully understand all the user requirements. In each iteration, the team work in the more important and clear requirements. As the software is developed, the team get better insights about the project goals and have more clarity about the following requirements. Lack of adequate user involvement Constantly working software makes the users more involve in the process. Lack of required knowledge/skills in the project personnel In Scrum, the teams are cros...

Spike are type of Story that are used for activities such as research,design,exploration and even prototyping. Functional Spike- It is used to list out the scenarios which can influence the implementation. Technical Spike- It is used to determine the Feasibility and impact of design strategy.

Encourage employees to disagree with you.  Companies get into trouble when everyone is afraid to speak truth to power. "If all you hear is how great you're doing, that should be a danger sign," says executive coach Ray Williams. Don't micromanage.  Empower the people below you, then leave them alone. "A good part of leadership is stepping back," says Bill Pasmore, senior vice president at the Center for Creative Leadership. "A good leader leads from front and back." When people err, don't destroy them. But make sure they learn whatever lessons there are to be learned from their mistakes. Show compassion.  "Develop strong interpersonal relationships at work, so employees have some meaning attached to the work they are doing," Williams says. Vow to be constantly learning and curious. Pasmore advises taking risks and asking yourself, "What is it that I don't know that I should know? How do I learn it and test it out ...

Agile release planning is best accomplished via the straightforward method of getting everyone into a room together. Everybody who will be involved in the release should participate in the planning. That gives us a potential invite list that looks like this: ·          Scrum Master ·          Product Owner ·          Delivery Team ·          Stakeholders ·          Outside experts ·          Customer(s) ·          3rd Party Vendors ·          Marketing ·          Sales When all of these people gather and work together on the release, marvelous things can happen. A Release Planning agenda might look like this...

1. Iteration is too short and stories are big ( Can't get things done in 2 or 3 weeks) 2. We need experts 3. Team formation by layer/component 4. Experts estimating 5. We must have overtime 6. We don't have technical debt 7. Featur-itis

1. Changing old ways of thinking  Learn Scrum well, read lots and talk to people that have done it. Be willing to learn.  2. Be a servant leader and coach.  Learn to let go and not manage. Attend courses on how to coach.  3. If you have just learnt Scrum, don't try transform an organisation into agile.  Be a Scrum Master in a team, but hire a person that has experience in changing an organisation. A good transformation coach will help you learn to really run a team and not theoretically.

Mentor other team members  Challenge other team members  Involve with other team members in Decision Making Appreciate other team members Listen to other team members Respect other team members