When a team first transitions to an agile delivery model, the team experiences challenges and frustration as they adopt a new way of thinking and new processes. Often times, teams are told that they are making the change to agile in order to deliver software faster and cheaper, but find that during the change it actually takes them longer to accomplish what they usually do.
Time to blame the new process, right?
Wrong. I’ll tell you why…
Continue reading “Setting organizational expectations when implementing Scrum”
Most of us have had to move ourselves at least once in our lives. We think we have it all planned out, but the true test is when the movers show up (or your friends who were lucky enough to show up and provide free labour). I got to be one of the lucky ones this weekend and I couldn’t help noticing that everything was running exactly like a new team trying to work in an agile development process.
Then again, maybe I’m just starting to see sprints everywhere and need to take a break from scrum. 🙂
In any case, this move had it all: impediments, timeboxed delivery, unknown backlog size, and a new group working together to determine their velocity.
Continue reading “Moving day always brings out the agile practitioner in me”
Many of us are valiantly in the trenches trying to bring agile practices to our teams, clients, and organizations. Others have heard the buzz over the last decade and are starting to make their first steps. Either way, you need to remember that some issues never go away. The old constraints of scope, budget, and time keep coming back, regardless of software methodology involved. Over on the nonlinear blog, I’ve got a new blog up about working with Agile in the Iron Triangle.
UPDATE (2020-03-31): I have discovered that this blog was taken down so I have copied it over to this site. Enjoy!
Continue reading “Agile in the Iron Triangle”
Continuous refinement is always in need when working in an agile delivery framework. The first thing you learn when you adopt a framework is that it does not work for all situations. Scrum, like other models, works really well in particular development situations. Sometimes, however, you need to transition your team to something leaner for a particular project that doesn’t fit into the regular delivery cadence.
Continue reading “Going Lean: Tips from the trenches”
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!
Continue reading “Clearer requirements through Sitecore prototyping”
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.
Continue reading “How I know a project plan is total nutbars… and how it can be fixed”
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?
Continue reading “4 ways to change so you can deliver more often”
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?
Continue reading “Et tu brute? Of cargo cults and agility…”
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.
Continue reading “Feeling the Product Owner’s pain”
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.
Continue reading “Tracking hours burndown in Trello”