Software the Agile Way....

There are four leadership styles: Directing, Coaching, Supporting and Delegating. o Delegating i.e. Low Supportive & Low Directive o Directing i.e. Low Supportive & High Directive o Supporting i.e. High Supportive & High Directive o Coaching i.e. High Supportive & Low Directive Situational Leadership is a way of describing and analysing leadership styles. It is a combination of directive and supportive behaviours. Directive behaviour involves telling people what to do, how to do it, where to do it, when to do it and then closely supervising this performance.  Supportive behaviour involves listening to people, providing support and encouragement for their efforts and then facilitating their involvement in problem solving and decision-making. Source-  http://business-financialrange.com/?p=1663

Generally teams take on different types of work that is  - building new features and fixing broken features that are product related. PO ideally want only new features and begrudgingly accepts defects.  - fixing poor code, outdated code that is hampering and slowing the team down in building value to the product. Developers feel they are working on 'bad' code and find new work demotivating as they have to work through pains. This is tech debt its best and Product Owners struggle to  recognize  this and see the importance.  - practice and build improvements. Introducing ALM tooling, build pipelines, automated testing take significant effort and much more than most people  realize . Teams spend months on this. Product Owners don't  realize  that this takes work to  customize  for their product as they expect it to work out the box. The reality it's not plug and play and takes effort.  PO needs some education on techni...

- 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...

 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...

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.