conversations on agile technical practices and investments

Negotiation methods should be judged by three criteria It should produce a wise agreement if an agreement is possible it should be efficient it should improve or at least not damage the relationship between the parties Common obstacles to the negotiation when another party is more powerful avoid establishing a "bottom line" (worst acceptable outcome) in an attempt to protect themselves against a poor agreement since it would limit/prevent creativity in generating options concentrate on assessing BATNA (best alternative to a negotiated agreement) power in a negotiation comes from the ability to walk away from talks. The weaker party will better understand the negotiation context if they also try to estimate the other side's BATNA. When the other party doesn't use principled negotiation when to refuse to budget from their positions, asking for reasons behind that position when attacking the other side's ideas, should take it as constructive criticism and invite furt

  Sudoku Refactoring Kata Following Jay and Llewellyn on their sudoku refactoring, I have forked the sudoku repo and added the java version. As usual, I will post the snippets I found useful in doing the refactoring Original repo: https://github.com/zoran-horvat/sudoku-kata our forked repo: https://github.com/calgarysoftwarecrafters/sudoku-kata Jay and Llewellyn attempt on this: https://github.com/JayBazuzi/sudoku-kata/branches , part 1: https://www.youtube.com/watch?v=BVGH-dNn-tc&ab_channel=LlewellynFalco , and you can follow other parts in the channel our C# refactoring attempt: https://github.com/calgarysoftwarecrafters/sudoku-kata/tree/tvo/sample-refactor-solution-steps our Java refactoring attempt: coming soon…. Snippets Golden Master Extract Method Extract anonymous class to named class Delete Comments convert parameters to object move the inner class to upper level specify type explicitly transform out parameters to object move types to matching files inline variable extract

Written collaboratively by: Trung Vo, Bob Allen, Jacqueline Bilston, Christopher Fietz, Llewellyn Falco “… I really liked that there was something there for every level and anytime I would get stuck, there was someone there to help….” — Sara K. What is a Coderetreat? Coderetreat is a day dedicated to allowing developers time to practice their craft. The focus is on practicing skills like Test-Driven Development (TDD), refactoring, and incremental design that is proven to make developers move faster with fewer bugs. It is designed to enable participants to focus on their practice, with as few distractions as possible. The day is made up of several short sessions where we either work in pairs or mobs to solve a small coding problem. Each session, we start new with the same problem; this allows us to focus on the new skill we are learning. What do you get out of it? Coderetreat is an excellent place to learn what you know and what you don’t know. As in life in general, there are always ne

In recent conversations regarding automating tests, It seems to me that the common understanding of the team is that the only acceptable automated test case is through the workflow tests through the UI. As far as I know, that’s not entirely correct and per “Pyramids of Automation” chapter 15 in More Agile Testing , I think there are lots of different ways we can automate test cases. I would like to take the opportunity to describe the pyramids of automation again with some thoughts/questions. First, let me try to describe the original pyramid again, and here’s the picture that is worth thousands of words Per the above pyramid from Mike Cohn with some modification in “More Agile Testing”, the lowest level, the unit tests, gets the fastest feedback on every commit which would provide the most benefits. The higher the tests located in the pyramid texts, the slower the feedback and lower profit we would get from the automated tests . “The test automation pyramid is a model intended to guid