Software the Agile Way....

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

The purpose of velocity is to calibrate the current local value for a story point in order to facilitate planning for the near future.  This allows us to continuously deliver value and steer a project without having to put a lot of time and effort into estimation.  Estimation does not deliver any value, so the less time and effort we can get away devoting to it, the more time and effort is available for actually delivering value.  Just estimating story points and moving on without worrying much about precision is the fastest way to get on with doing the work.  The alternatives that would seem to create more order and precision to estimates never actually produce a sufficiently better outcome to justify the otherwise unnecessary time and effort required to do so.  There is, however, an alternative that even makes the little bit of time and effort required for story pointing and velocity calculation unnecessary. Just always split all stories into the approxim...

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

An example of an idealized, modern software delivery pipeline might look like the following:  • Plan user stories and manage issues with a project management tool like JIRA.  • Collaborate on code via GitHub pull requests or a code review tool.  • Kick off a build in a CI system like Jenkins or Bamboo.  • Automatically run unit and functional tests with open source testing tools like xUnit and other testing frameworks, and automation tools like Selenium and Appium.  • Deploy with an IT automation tool like Puppet or Chef, or using a PaaS.  • Monitor performance and impact on business metrics with systems like New Relic and Mixpanel.

Step 1: Identify the Problem Step 2: Work Out the Major Factors Involved Step 3: Identify Possible Causes Step 4: Analyze Your Diagram Depending on the complexity and importance of the problem, you can now investigate the most likely causes further. http://www.mindtools.com/pages/article/newTMC_03.htm http://www.techrepublic.com/blog/tech-decision-maker/create-fishbone-diagrams-with-the-xmind-open-source-tool/

TFS infrastucture  For PROD, you may like to have Nightly Builds, for Development you want to have a build triggered at every check-in and so on…  These builds require a build server.  You can use 1 build server for all the builds or you can have a separate build server for each Repository, or you can share build server between 2 repositories. The decision to use one-build server or more depends on the peak-load, expected build queue, h/w infrastructure and a lot of other parameters.  If you do not want build services, you do not need to configure a build server at all. http://www.codetails.com/2013/11/23/team-foundation-server-understanding-the-architecture/   Set Up a Dedicated Build Server Installs the build service on the team's build server Set Up the Drop Folders A folder where the Team Foundation build service can drop the builds. Give the folder permissions to the server that runs the build service Create the Continuous-Integ...

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

No project can go very long before someone starts asking “When will you be done?” The best approach for estimating stories would be one that: • allows us to change our mind whenever we have new information about a story • works for both epics and smaller stories • doesn’t take a lot of time • provides useful information about our progress and the work remaining • is tolerant of imprecision in the estimates • can be used to plan releases An approach that satisfies each of these goals is to estimate in story points. A nice feature of story points is that each team defines them as they see fit. Source - Mike Cohn's book

Tip#1 - Spend a few moments to get inside your client’s head.  Talk to them , listen carefully, figure out exactly how you need to package your ideas so that they will choose the option that’s best for their needs. Tip#2 -  Do your research and present your case clearly.  Support your design decisions with data.   Tip#3 - Build a Product backlog with clear acceptance criteria  Tip#4 -  Be specific about the project’s deliverable and outcomes, and protect yourself by       having a solid terms and conditions agreement in the event of out-of-scope work.   Tip#5- Empower team to openly share the gaps and changes in the system the client is suggesting so that you can set expectation with client for successful delivery. Tip#6- Identify the risks (Uncertainty/ambiguity in Environment,Technology,Domain) and keep a plan for this and inform to client. This can be updated on a regular DSM ( ...