Recently, my colleagues and I were about to embark on a mission to gather requirements for an upcoming release. We had already worked with this particular client and therefore knew that they would have a solid understanding of their existing solution, if not the full capabilities of the Sitecore platform. For the new requirements, we decided to put together some prototypes. I’m so glad we did!
We have all seen the magical project plans that have no grounding in reality. Schedules are far too aggressive, scope is beyond what the team can handle, not enough resources available to properly run the team… all to meet some magical “hard deadline” that has been imposed seemingly without any reason.
The folks in charge of these plans are not evil – they may just have somebody enforcing a deadline on them and are trying every possible thing to draw a picture to meet that deadline so they don’t get fired. These people are members of our team and we cannot leave them struggling alone. As architects and technical subject matter experts, we need to help our team members make their complete nutbar of a project plan into something that makes sense in the real world we live in.
I am a big fan of continuous delivery and deployment. You might have seen me write about it a few times before. When I first bring the idea up with clients, there is hesitation. One might even call it fear. The benefits are huge, allowing you to reap the return on investment immediately, but the big question is “how”. How does an organization switch to a continuous delivery model?
I’m not sure what triggered it, but at some point while I was on vacation a few folks started getting really ticked off about the state of “Agile” these days. People adhering to rules or tools, not understanding what it means to bring agility to a project, or building giant runways in the jungle hoping an aircraft drop of supplies will come by.
I don’t necessarily disagree with the points made by the authors, except perhaps the insinuation that all consultants are a bunch of wannabes trying to fleece money from unknowing customers by using buzzwords and flashy smiles. What I didn’t understand: what was prompting this? Have we just reached a tipping point where the first generation of agilists is getting fed up with dealing with ‘fake’ agile?
On Friday, a large group of us gathered in the office for a full day of looking at how we are currently managing our requirements over the course of a project. In the room we had folks who play the roles of technical leads, scrum masters, and product owners, all chatting over some giant muffins, lots of sticky notes, and one too many rehashings of the insanely catchy Lego movie song.
Cue “Everything is awesome” to be stuck in your head for 4 days now.
A lot of our focus was on the various artifacts we need to pull together, and how they depend on each other. Really, what we were trying to do, was expose the details of why our Product Owners have been needing to pull off heroics just to keep on top of things.
In the past, I’ve written about some tools for doing Scrum inside of Trello, as well as some guidance on creating Scrum boards using these plugins. Recently, I received a question about how to accurately track hours spent in Trello. Zig Mandel, the man behind Plus for Trello and Spent for Trello, reached out and recommended taking a look at his Chrome plugin which does some similar tasks to Scrum for Trello and Burndown for Trello, but provides a richer hours burndown.
The plugin is advertised as an open-source and free tool that will not collect data or insert ads, whose primary purpose seems to be tracking time spent on cards in Trello. A lot of reporting features and timers built into the plugin allow you to track at card levels, list levels, or across the entire board. Other plugins I’ve used don’t have this level of accurate spent tracking for tasks, that is for sure.
Development teams using Scrum, or similar agile forms, will find that the constraints on the system that are represented by Nonfunctional Requirements (NFRs) can be a pain to capture and reference in product backlogs. The NFRs aren’t acceptance criteria, but the “story” isn’t really done unless it meets them. The NFRs also usually span multiple stories, or the entire application itself (such as performance) so cannot be managed on an individual story level.
So how can we represent these constraints in the backlog?