Software the Agile Way....

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