Posts

Agile testing: Exploratory testing vs Automation testing

Automation Testing Automated tests are important, but they can't always address the complexity of finding potential problems related to usability, reliability, performance, compatibility and other quality criteria. Automated tests can't ensure the documentation matches the final product. They don't typically cover test scenarios past common use (like disfavored use or extreme use).  Automated tests are great for testing specific aspects of functionality, but for complex applications they aren't so great at testing the platform dependencies (external hardware or software, deployment configurations).  They don't often address issues related to operations (dealing with how data ages, alarming/alerting, logging, etc.).  And automated tests aren't often focused on relationships between the product and time (concurrency, changing rates or transactions, or delays on input). Exploratory testing: Exploratory testing to help inform the project team about p...

11 common DevOps Bottlenecks

1. Inconsistent Environments Create standard infrastructure blueprints and implement continuous delivery to ensure all environments are identical. 2. Manual Intervention Automate the build and deployment processes and implement a test automation methodology like test driven development (TDD) 3. SDLC Maturity Invest in training and hold blameless post mortems to continously solicit feedback and improve. 4. Legacy Change Management Processes Companies with legacy processes need to look at how they can modernize processes to be more agile instead of being the reason why their company can’t move fast enough. 5. Lack of Operational Maturity Assess your operational processes, tools, and organization and modernize to increase agility and transparency. 6. Outdated testing practices Quality is everyone’s responsibility, not just the QA team. 7. Automating waste Automate processes after the bottlenecks are removed. ...

15 Characteristics of a Agile Programmer

1. Impressive technical skills   Describe your experience with different programming languages. 2. Willingness to learn   What do you do to keep your programming skills current? 3. Debugging skills.   How do you handle bugs in your code? (next, I would give them a trial run to debug code) 4. Work environment match   Some programmers require complete silence to concentrate, while others thrive in chaos. 5. Problem-solving skills.   How would you create (insert near impossible task for your organization)? 6. Passion for the work. True programmers are self-proclaimed “computer geeks,” spending their time gaming, building servers, or creating apps for friends.  7. Grace under fire.   The ideal programming candidate will be able to handle even the most stressful situations calmly and, most importantly, be able to continue working. Describe a time when you were under extreme pressure and your application wasn...

3 imporatant lessons to make meetings productive from Steve Jobs

keep meetings as small as possible. made sure someone was responsible for each item on the agenda. wouldn't let people hide behind PowerPoint .                              Lessons from Steve Jobs

do's and don'ts for Scrum Master

The SM should NEVER tell the team what to do but rather facilitate with Asking why? Did this work for you? What do you think? Have you thought about? It sucks to be you, what are you going to do to change it? The team must learn to see their failures and recognize them early. This is the principal of fail fast. Jeffrey Sutherland prefers weekly sprints to allow fast failures and quick adaptation to issues. To reaffirm, the SM should not make decisions for the team, but instead help the team make the right decision. The SM must also create a safe environment allowing the team to fail, Fail fast and fail safely.

first sprint in Scrum- what is expected??

Before launching a project, organization need to include a first cut as per the below list: Product vision  Product roadmapping   Feature selection (feasibility, WSJF-Weighted Shortest Job First, etc)   Story mapping / initial product backlog   MoSCoW / slicing / MVP   High level architecture   Technology stack selection   Risk management (starting with identification)   Some UX/UI as this needs to work a bit ahead of "coding"   Test strategy   Tool selection (CI, testing, build, code analytics etc)   Scrum Team definition   Skill gap identification + training / coaching plan   Stakeholder Management (starting with identification)   1 pager Scrum Team charter + social contract   User feedback strategy   (outside) dependency management (starting with identification)   PBR that makes the product backlog ready for sprint 1   How to deal with (enterprise) governance   Strate...

scaling agile means??

To some people, “scaling agile” means going from a few agile teams to multiple, or even hundreds of, agile development teams. There are some unique challenges that come up whenever you have an organization where more than 3 or 4 agile teams need to work together in a coordinated fashion. Most agile scaling frameworks try to offer ideas or techniques that can help in organizations with anywhere from 4 to hundreds of Agile teams that need to work together. Other definitions of scaling may be to spread agile beyond IT, seeking agility in business operations or other areas of the organization. This need is not addressed as effectively by many popular approaches. source - http://www.infoq.com/news/2014/07/compare-agile-scaling  

In simple terms agile is about behaviours and techniques.

Behaviours would cover such things as empowerment, collaboration and good communication.  Techniques would cover areas such as having a clear processes with defined roles and responsibilities, along with practices such as timeboxing, iterative and incremental delivery and flexing the requirements.

7 questions to ask before planning to include any document in Scrum Agile

Why we have this document When to prepare it  How to represent it   How far in advance is the document,   Who creates it   In what format is the document Who need this document and what value it will generate

When Scrum is not required!!

Are your current practices and processes working?  Is there collaboration where everyone tries to get things done or is there a sense of passing the buck? Are you happy with the current way you work?  If you feel your current situation is not really working, then inspect and start adapting. If everything works and people are genuinely happy. Then don't change.