New Ruminations on Tools
New Ruminations on Tools
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
Been a couple years ago that I went from Rally to AgileZen. About to move to Atlassian now.
In the spirit of keeping the tone the usual combination of acerbic and direct, I‘ve decided to group my reasons for this, first the philosophical ones:
- NoQA has it right, but No Ticky, No Good: So the basic premise of NOQA is that programmers leave things undone and then think it‘s someone else‘s job to file complaints into another system. However, thinking you can just keep pushing stories back into the In Development column is a fantasy. Frankly, there are other ways to conflate the absurdity of having two worlds, aka three-legged sack race. The one I‘m drawn to now is to keep practicing NoQA, but also have the ability to have the Customer enter tickets and push them onto the board. When I first looked at GreenHopper it looked like a tinkertoy that couldn't make up its mind whether it was a kanban or a cork board. It looks a lot better now. When we moved from Rally to AgileZen, it was to try radical Kanban, after watching iteration planning turn into a massive exercise in slogging a wet slurry twice a month. Kanban only is not less predictable. It doesn‘t equal no deadlines. It‘s not lightweight, or a proxy or a hall pass for the lazy. The problem is that for it to work, the scope needs to be not vast: this is the main shortcoming of Lean and tools in general: there is no means using modularization to keep the board from exploding (you could divide teams into different projects but then there‘s no way to see how they impact each other as they pursue their deliverables).
- The problem with tickets is that in a QA-based environment, there is: a. the Customer, b. the QA person, c. a PM, d. the original Developer. It‘s pretty funny when you think about it. It often degrades into ‘open wide‘ followed by a bunch of scenes where apple sauce turns into an airplane, narrated with much babytalk. It‘s not always the dev‘s fault that the story doesn‘t just run from one edge of the board to the other. That said, in the best of worlds, you will have situations where stupid little seams need caulk and writing a new story or reopening a story to add something that is clearly not restating anything about what was done is just wrong.
- I was going back to look at Atlassian because of the chimerical fusion of kanban and tickets, but in so doing, I discovered they have a new testing tool. It looks stupidly visionary. (See it here: Bonfire) The mission of the tool is in this same seam: give a Customer (not a QA person) the easiest, most powerful way to communicate issues, not just one at a time, but as part of sessions, with annotations, etc. Really psyched to try this and the integration with the rest of the suite is crucial. Lean dictates that the Value Stream Map is the focus of continuous improvement. Maps that have more steps and people are not good. I am not saying there should never be QA. I am saying that projects should practice the first precept of Lean: grow into resources through need.
- Have become more and more convinced that the tools world is chasing its tail, dining on a dog‘s dinner of assorted bromides. Lean has the most right impulses, but most Lean toolmakers are porcine posers who were stuffed into polyester rent-a-cop suits a few days ago.
- It‘s time for tools to start moving away from just a list management for the subjugation of serfs by List Lords.
Now for the non-philosophical drivers:
- I posted about how AgileZen had added no features in a year of paying them $100/month. That‘s an iPhone 4 a month and they couldn‘t even fix one of their many infantile omissions. Here‘s my final judgment on that: buh-bye. (Their explanation was ‘yeah, sorry, we were porting to EC2…‘ Oh, ok, apology accepted.. ??? Really?)
- Atlassian made points with its Bitbucket remake which is clearly an antidote to GitHub‘s witless greed.
- The membrane between Customer and Architect should be permeable and fluid. If there‘s any evolution required, adaptation, creativity, etc., this is the seam the Complexity guys identified (a hundred years after Nietzsche) where chaos and order fuel generative energy. (BTW, when you hear programmers whining about the lack of ironclad certainty in the working spec, it‘s kind of like listening to the whack jobs on wall street complaining about uncertainty. (Although it is funnier in the case of the wall streeters, since they are making their money running a bloody casino. It‘s like a swimmer complaining about having to get wet.)
There are still a lot of shortcomings in the tools space. It seems more likely that a unicorn will bolt through your next Kanban Board than one of these teams will start to really think up some new, creative ways to make things more effective. Atlassian may finally be getting with it after making their first bid to be a playa doing the usual jig of checking feature boxes like an M&A team at a New York bank. Most tools are so dead that they remind you of the part of Zarathustra where the main character is carrying a corpse around until he realizes its time to bury it and move on.
Published at DZone with permission of Rob Williams , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.