http://scrum.org.ua

Trends

Warning: /sata1/home/users/scrum/www/www.scrum.org.ua/wp-content/cache/27e75d26653c2d737790cb4a6b8507b9.spc is not writeable in /sata1/home/users/scrum/www/www.scrum.org.ua/wp-includes/class-simplepie.php on line 1780

• Technical Debt is Really a Lease

  
  

  At the last SDTConf, Todd Little facilitated a session called “Technical Debt is Really a Lease.”

  I had a few interesting take-aways from this discussion:

  • A debt always has a notation that you need to pay it eventually (unless you default.) This is not true in case of a technical debt. There might be parts of your code which is a complete mess, but you don’t touch it and its fine to live with that debt. Or you might just decide to throw away that code since it served its purpose. You might never need to pay off that technical debt.
  • Deep down in our psychology, the term “debt” trigger a negative thought. We strive hard to avoid a debt. However if you project the same thing as a lease, it seems to have a more positive feel. In the business world, taking on a lease, in many cases, can give you a good business advantage. In fact some might even consider it to be stupid not to lease out stuff.
  • The important thing to consider is: what is the “Cost of Service” for a lease/debt? If the cost is significantly high, you are better off not taking it on. But if the cost is really low, it makes all economical sense to embrace it. We’ve learned that long-term, heavy interest leases/loans are a bad idea for that very reason. But a short-term, low interest loan can provide extra working capital to expand business.

  IMHO it can really help teams to think of technical debt really in terms of the “cost of service” of a lease.

  Beware not to make technical debt a dumping ground for tasks that the team wants to defer without a conscious, thoughtful reason. I’ve seen in many organizations, technical debt becomes an easy excuse for the team to skip things that are very important but for their short-sighted hasty decisions.

• CouchDB versus Couchbase: What are the differences, and what happened to Membase?

  
  Recently Couchbase published a comparison of Couchbase and CouchDB to denote the differences and simlarities between the two. This document addresses a common question: "What is the difference between CouchDB and Couchbase?", and what happened to Membase? InfoQ caught up with James Phillips, a Couchbase founder, to discuss the comparison and the merger of the two products Membase and CouchDB. By Rick Hightower

• Scrum and Agile Test Prep Mania

  
  

  In the past few weeks I’ve noticed a worrying up tick in the number of people asking questions around how to pass their upcoming Agile/Scrum XXX test (i.e. PMI-ACP, PSM, CSM, CSP). They want to know what to read and what magic incantations to invoke.

  Scrum (Agile, Lean, Kanban, …) aren’t something you really learn or understand by reading books. These are things you learn by doing or practicing. The focus shouldn’t be on certifications it should be on delivering valuable software.

  My promise: If you take my ScrumMaster Training we will focus on learning by doing and not on slides. The focus is on the successful use of Scrum to build working software not passing a test.

  
  

• Definition of Done: A Hang-over from the Waterfall Era

  
  

  You might think Definition of Done (DoD) is a brilliant idea from the Agile world…but the dirty little secret is… its just a hand-over from the waterfall era.

  While the DoD thought-process is helpful, it can lead to certain unwanted behavior in your team. For example:

  • DoD usually ends up being a measure of output, but rarely it focuses on outcome.
  • In some teams, I’ve seen it disrupt true collaboration and instead encourage more of a contractual and “cover my @ss” mentality.
  • DoD creates a false-sense/illusion of doneness. Unless you have real data showing users actually benefiting and using the feature/story, how can we say its done?
  • I’ve also seen teams gold-plating stuff in the name of DoD. DoD encourages a all-or-nothing approach. Teams are forced to build fully sophisticated features/stories. We might not even be sure if those features/stories are really required or not.
  • It get harder to practice iterative & incremental approach to develop features. DoD does not encourage experimenting with different sophistication levels of a feature.

  I would much rather prefer the team members to truly collaborate on an-ongoing basis. Build features in an iterative and incremental fashion. Strongly focus on Simplicity (maximizing the amount of work NOT done.) IME Continuous Deployment is a great practice to drive some of this behavior.

   

• Presentation: Pallet - DevOps for the JVM

  
  Antoni Batchelli introduces Pallet, a devops platform for the JVM for provisioning and configuring servers, configuring clustered services, deploying and managing software, servers and services. By Antoni Batchelli