Software the Agile Way....

The first is the number of defects found after development.  An  XP  team should have dramatically fewer defects in its first deployment and make rapid progress from there. Some  XP  teams that have been on the path of improvement for several years see only a handful of defects per year. No defect is acceptable; each is an opportunity for the team to learn and improve. The second metric is the time lag between the beginning of investment in an idea and when the idea first generates revenue.   Even small organizations typically find they take more than a year from investment to return. Gradually reducing the time from investment to return increases the amount and timeliness of feedback available to the whole team. Both post-development defects and investment-to-return are indicators of team effectiveness much as a speedometer is an indicator of speed. You don't make a car go faster by grabbing the speedometer needle and moving it over. If you wan...

Comparing to other Scrum Meetings, Sprint retrospection meeting is sometimes considered boring by the Scrum Teams. Team do not find much value in participating in this meeting. What could be cause of such feelings. Sometimes this becomes repetitive and same issues/pointers are discussed. SM need to think over it. I advise the Scrum Master to follow the below mentioned pointers to make retrospective meeting effective: 1) This is a place for team to talk about the people, process, relationships and tools which are delicate matters as there are chances team members start pointing fingers to one another for the failure. SM master need to avoid such discussion to popup. Lets keep this meeting healthy. Note it down and discuss it later with the concerned member. 2) See all the team members are getting the opportunity to talk and share their thoughts on the sprint.  3) This meeting to thank to all the people who helped during sprint execution. There could be dependencies ...

One of the Agile Manifesto principle says " Individual and interactions over process and tools " this needs to be practised on a daily basis to make it a habit. In a team, you can have team members of different behaviour, some talk less, some talk more and some try to hide their feelings. In such situations, it is the responsibility of Scrum Master to ensure team members are talking to each other and the conversations are happening. Scrum Master can do this by having casual, informal conversation and this would help team to collaborate often and this could minimize the issues. Encourage face to face conversation if possible. Another very important responsibility of Scrum master is to promote discussions which requires attention from other team members. Most of the project fails due to communication issues hence this principle must be taken very seriously and scrum master need to keep innovating the ways of handling this! How do you want to promote this principle...

While working in an Scrum projects, I have experienced that there is a need to have a continuous learning approach. In a complex project environment, we face issues/impediments on a daily basis which is quite possible if there are dependencies across many teams.In such case, though Scrum master and team need to continuously resolve issues but at the same time we need to pause and think on how can we prevent the issues to occur. If Scrum master coaches the team to become proactive then there are high chances we can reduce a lot of issues to occur. What is a proactive approach...an example would be team on the very first 2-3 days of sprint start, is able to start conversation around the dependencies and possible issues. Scrum Master need to encourage such thoughts so as to make the sprint smooth. additionally collaboration with product owner is required here so that a shared understanding is built. By practising this, everyone is continuously learning about the people,process and te...

In the Scrum meetings, if the one of the team members are digressing from the agenda then  other team member will say "can we take this after this stand-up meeting" instead of Scrum Master saying this. In the daily stand-up meeting, team members are stressing on the done activities rather than discussing something which is not bringing clarity. Team is flexible to accommodate small ( non significant requirement changes) rather than becoming rigid in not accepting this. Team members respect each other and one conversation is going on during the meeting. Team members are asking question to PO on why this feature is needed? Team members are looking for improvements and taking interest during retrospective meeting to bring the topics without any fear. Team members are skilled and confident of the work and are not scared of ambiguity rather than working towards it to make it clear.  Team members respect time. Team members trust each other and do not depend on email or a...

Daily Stand-up Meeting- Are team members committed to the goal of the Sprint ? This should be verified by showing the taskboard to team possibly a Kanban board and let the team team provide their opinion on where they stand. Additionally, show them the burndown chart trend on the daily basis in the meeting, if the chart is deviating from ideal graph. Sprint Planning Meeting           2.  Are the team members doing some pre-planning and preparing themselves for the planning meeting. This should be verified by checking that team is very sure about the user stories and they know what stories to be delivered and how. Sprint Refinement/Grooming Meeting     3.  Are the user stories are prepared well prior to this meeting? Are the user stories understood to PO before explaining to team? This  can be verified by ensuring that sizing of the stories are happening for the planned stories for this meeting. Sprint Review ...

Poka-Yoke   is a device or method that prevents people from making mistakes. The word in Japanese means mistake proofing or error proofing. What habits we can have in Scrum Sprints: 1. PO must have this constant habit of thinking "Is this User story solving the problem"? 2. Developers must do code check-in when all the team members are there. This will create a stable build. 3. Scrum Master need to constantly think of not only current sprint status but also about next sprint risks/dependencies. 4. QA must have a habit of checking the software on every code check-in and not when all the features are available. If any logical feature/test case is finished QA should start verifying it. 5. QA must interact with Dev on regular basis to share the observations. Bugs reported much early in the sprint cycle is better than later. Can someone think of any other habits?

1. Story point estimate is an amalgamation of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherent in it, and so on. 2. The first approach is to select a story that you expect to be one of the smallest stories you’ll work with and say that story is estimated at 1 story point. 3. The second approach is instead to select a story that seems somewhat medium-sized and give it a number somewhere in the middle of the range you expect to use. 4. Velocity is a measure of a team’s rate of progress. It is calculated by summing the number of story points assigned to each user story that the team completed during the iteration. If the team completed three stories each estimated at five story points then their velocity would be fifteen. If the team completed two five-point stories their velocity would be ten. 5. On any given day, in addition to working on the planned activities of a project, a team member may spend time answering em...

Do Each active participant in the daily standup is supposed to share what they did yesterday and what they are doing today on work that progresses the work defined for the sprint. Others may certainly attend and listen. Don't Any detailed discussion,  revisions of requirements,  changing of priorities,  changing of the backlog or any other decisions are not to be made in the daily standup. NOTE - If the information shared in the daily standup warrant detailed discussion, changes or decisions, that should happen in a subsequent sit-down meeting  with relevant participants  in which the PO should probably be an active participant.

Jez Humble and Dave Farley defined the following principles in their Book “Continuous Delivery”: Repeatable reliable process  – use the same release process in all environments. If a feature or enhancement has to work through one process on the way into the integration find a way of popping up. Automate everything  – automate your builds, your testing, your releases, your configuration changes and everything else. Manual processes are inherently less repeatable, more prone to error and less efficient. Once you automate a process, less effort is needed to run it and monitor its progress – and it will ensure you get consistent results. Version control everything  – code, configuration, scripts, databases, documentation. Everything! Having one source of truth – and a reliable one – gives you a stable foundation to build your processes upon. “Bring the pain forward”  – deal with the hard stuff first. Time-consuming or error prone tasks should be dealt with as soon...

Tips for Effective Ice-Breakers ·          Keep it simple. ·          Make it fun. ·          Be creative. ·          Consider various types of Ice-breakers--don't just stick to "questions." ·          Consider your audience. ·          Be aware of time constraints ·          Keep in mind technology requirements. Consider using an ice breaker when: ·          Participants come from different backgrounds. ·          People need to bond quickly so as to work towards a common goal. ·          Your team is newly formed. ·        ...

- Programmers write more automated testes and focus on higher automated testing  - Manual testers are more focused on exploratory testing  - Documentation of BRS, FRS, Test Plans are totally reduced to a simple list of features with scenarios; i.e. BDD. This provides a common language that business users, programmers, testers can all understand share and collaborate on.  - Development Team is structured that programmer and testing skills are in the team.Instead team members pair up to both do development and testing in a highly iterative and incremental nature.  - Culturally the team succeeds when the work is done and meets the quality standards defined by the "Definition of Done". If something is wrong, all fail.  - Defects found in Sprint are actually not logged, but the developer / tester pair simply chat and fix it on the spot as the work to the Product Owner is not "Done" yet.  - Missing requirements are not bugs, but simply new requireme...

Strategy First  it should be clear about what your strategy for automation is. (And don't say Automate everything. The people who think you can automate everything are just as wrong as the people who think you can manually test everything. Automation can help, but you need to know its strengths and weaknesses.) Plan Secondly, you should decide what success might look like. Most teams will do a lot better if they try to achieve something close to the testing pyramid , that being where developers write a lot of unit tests and specific integration tests with dependencies, and then a combination of devs/testers write service level, and API tests, but in a smaller proportion. lastly any UI should probably be kept small and focused on critical areas of the software (because they are so slow). Implement Another thing you should consider, is that automation efforts slow down, the further from the code it actually tests it is to develop. This means that while your testers may be pur...

● They are self-organizing rather than role- or title-based. ● They are empowered to make decisions. ● They truly believe that as a team they can solve any problem. ● They are committed to team success vs. success at any cost. ● The team owns its decisions and commitments. ● Trust, vs. fear or anger, motivates them. ● They are consensus-driven, with full divergence and then convergence. ' ● And they live in a world of constant constructive disagreement. —the characteristics of high collaboration and, thus, high performance (adapted from Tabaka 2006): 

A tester on an Agile team should not just be doing testing after implementation, but should be actively involved all the way through development.  They can spot testability problems and other gaps from the very beginning, help the developers design the implementation with testability in mind, and define the tests before and during development to help the developers hit the right target.  As this is the case, the tester really needs to understand the whole story, not just the testing aspects. Quality is the responsibility of an Agile team, not any one individual. Offloading quality tasks to Tester people is a handoff that decreases the responsibility as well as the agility of the team.  Offloading will not increase quality in the long run nearly as much has collaborating. These people should be integrated, which means they need to collaborate with the rest of the team on quality tasks as well as collaborate with the team on other tasks (including story pointing). ...

Problem Many teams start out with good intentions and then have quality erode as people go through the motions due to burn out or just no longer having fun.  Solution 1. For sustainability, the team really should own and evolve their standards instead of them being handed a bible. 2. Also, it is more critical to get early momentum through delivery of working software and feedback on that software than to get bogged down in the minutiae of a specific standard.  3. I suggest starting with the minimum that the team reaches a quick consensus on as necessary from the beginning and then add/subtract from it as feedback and experience indicates to the whole team. The standards can and should change over time. The key is clarity , testability , extensibility and maintainability of the code itself.  4. It is also important to establish from the beginning that the code base is shared by the whole team. No part of the code should be understood and maintained by only one tea...

Goals:  what do you want to get out of the negotiation? What do you think the other person wants? Trades:  What do you and the other person have that you can trade? What do you each have that the other wants? What are you each comfortable giving away? Alternatives:  if you don't reach agreement with the other person, what alternatives do you have? Are these good or bad? How much does it matter if you do not reach agreement? Does failure to reach an agreement cut you out of future opportunities? And what alternatives might the other person have? Relationships:  what is the history of the relationship? Could or should this history impact the negotiation? Will there be any hidden issues that may influence the negotiation? How will you handle these? Expected outcomes:  what outcome will people be expecting from this negotiation? What has the outcome been in the past, and what precedents have been set? The consequences:  what are the consequences for you ...

 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)  

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.

Team Formation Requirement workshop and identifying the Epics and stories Initial technical architecture Initial Release goal Secure Funding Development Environment setup  Risks identification