Software the Agile Way....

- Lack of change management or understanding of it  -   Agile solution- Sprint review meeting ensures this - Stakeholder's understanding of the scope and scope creep   - Agile solution- Can be resolved by maintaining a well maintained Product backlog by the PO - Over-commitment  -  - Agile solution- This can be ensured using Team collaboration in Sprint planning in Scrum - Managing up instead of down or across the waves  -  - Agile solution- Collaboration resolves this - Allowing outside forces and management to affect your team   - Agile solution-Scrum Master protects the team - Not understanding your personnel resource strengths  -  - Agile solution- Retrospective meeting resolves this ( let the team resolve this) - not updating the schedule and taking action.-   - Agile solution- Shorter Sprint goal is set  -   Not communicating in the proper format at the proper level of the organization to affect a positive project outcome. -  - Agile solution-Demo meeting resolves

 Code builds without warnings (technical task)  Code review by peer as per the standard  Code unit tested (technical task)  Unit test case review as per standard  Test cases are executed (test task)  Test cases are reviewed by peer as per user story  Documentation updated (user story)  Documentation reviewed as per user story  Build pushed to demo server (user story)  

Usability - e.g Number of Clicks User Experience - e.g. Scroll acceleration Performance - e.g. latency and Throughput Sizing  - e.g. Period of Transactions to keep Scalability -  e.g. multithreading/multiprocessing Availability  - e.g 3-9s/4-9s/5-9s Security - e.g. authentication/authorization  Certificates/Legal etc  

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

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.

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’t working. What did you do? 8. Peo

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

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.

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   Strategy for distribution / scaling + tools   System access and tool setup for Scrum Team

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  

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.

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

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.

We're trying to deliver what clients want.  Since we know, through decades of experience, that clients, whether internal or external, can't articulate what they want until they see it, showing them working results as we progress makes obvious sense.  We also know from experience that "throwing requirements over the wall" without deep collaboration is a failed approach, so requiring clients to be "product owners" and remain engaged makes obvious sense as well. We've learned that big-bang, front loaded project planning doesn't account for inevitable changes in business and environment, so we plan and develop in cycles to enable reality to influence our delivery.  Agile is a reflection of the realities we've learned from decades of failed projects, mingled with the modern, lean style of management pioneered by the Deming, Six Sigma movements, leavened with the sensibilities of new generations of developers.

Having 100% coverage doesn't guarantee the lack of defects—it only guarantees that all of your code was executed, regardless of whether your application behaves like it should.  So rather than obsessing about code coverage, focus your attention on making sure that the tests you do write are meaningful.

The algorithmic model for product feature prioritization is comprised of the following four core parameters: Dependency  - Measure of how dependent other features are on this feature (High/Low). Fundamental  - The product will not work properly without this feature, from a technical perspective (Yes/No). Differentiator  - The feature is a key differentiator, relative to competing products (Yes/No). Importance  - Product management's measure of importance of this feature, from a product marketing and/or product planning perspective (High/Low). Source-  An Algorithmic Model for Product Feature Prioritization   linkedin.com

Always Have a Plan Restate the Problem Divide the Problem Start with What You Know Reduce the Problem Look for Analogies Experiment Don’t Get Frustrated

Establish and clearly communicate objectives and outcomes to focus your participants and clarify what’s in and out of scope. The purpose of your meeting should determine the right attendees. Are you trying to brainstorm, solve problems or share information? Invite key stakeholders, decision-makers, and influencers when making cross-functional decisions that impact organization-wide processes. Unsure if a participant should join your meeting? Ask! People may come with their own agenda so clearly define the list of topics that need to be covered in the meeting. Make sure you allocate enough time to address each topic listed. If you have a packed agenda, consider scheduling two separate meetings. Want people to wait to ask questions at the end? Specify in your agenda when questions are welcomed, so people don’t interrupt you or try to jump ahead in the presentation. How many times have you received a calendar invite for a meeting that is set to take place in 30 minutes? If it’s not