I have heard several talks and attended several presentations both comparing Scrum and Kanban and explaining how they can be used together. I came across this article, which talks about this article (I list both because the commenting article brings up good points, too). So why am I adding yet another level of indirection to this chain? Because an awful lot of people understand past the surface and the buzzwords of the various flavors of Agile/Lean, and that leads to confusion, unmet expectations, and failed projects. The most important point of these articles is that Scrum and Kanban are not interchangeable techniques. They differ greatly in scope and goal. That’s why they bring up the metaphor of choosing between a knife and fork.
Read on…
One of the frustrations of managing software development is that different people have a different idea of what “Done” means. It can range from “It compiles and it’s checked in”, to “It compiles, and all the unit tests pass, and new unit tests were added for the new functionality, and the documentation was updated, as was the issue tracking system, and the QA guys signed off on it”. This is especially a problem with Agile development, because so much rides on a common understanding of the state of the software.
Alixx Skevington recently posted an article in the Agilistas group on LinkedIn called My Manifesto of done. It’s an interesting read, and a good start. He’s flagged it as a draft, so I don’t say that as a criticism. I know I’m going to follow that discussion (I’ve already contributed to it). Hopefully it will turn into something that companies can point a finger at and say “Do this”.
Generally speaking, I hate frameworks. Most frameworks I’ve met fall into one or more of these camps:
- Frameworks so lightweight that they’re not worth the hassle of using them. These frameworks can be useful when you need some functionality that you don’t want to learn in detail how to do. This is almost never the case for me, because I like fully understanding any technologies I rely upon. That’s why at Aptima I wrote my own AJAX JavaScript library. It was something like 50 lines of code, worked flawlessly, and worked exactly as I wanted it to.
- Frameworks so heavy the work to utilize them approaches the work of rolling your own. This often happens with frameworks that start out simple and are expanded to encompass too much functionality outside of the original scope.
- Frameworks that are staunchly inflexible in how they are used and how they work. Using a software tool to make your life easier should not like implementing an ERP system. This often happens when when the framework was designed for a specific purpose then released as a separate product. See The Cathedral And The Bazaar.
- Frameworks that are completely opaque or have an unreasonable learning curve. Most meaningful operations in software have some sort of side effect you need to be aware of. Insufficient documentation and software that does not follow the mantra of the Principle Of Least Astonishment can make diagnosing problems a nightmare.
I’m currently working on my knowledge and skills with Spring and Hibernate. They continue to fail to suck. I was very surprised how easy they were to implement, how much they’re for me, and how flexible they are. Spring is a framework that specializes in (among other things) inversion of control to promote decoupling and testability, and Hibernate is an object relationship mapper that eases the burden of persisting entities in a database. There are many good tutorials on the Intertubes, but I’ve been working my way through the book Spring Recipes, which covers both technologies very well.
Read on…