Last time we talked about two questions to help you understand if you’re doing Kanban to improve your workflow, or simply keeping your tasks visible on a board. I mentioned in that post that your workflow should be more than just “not started – in progress – done” didn’t go in to why. Let’s take a look at that. Read more



As organizations come to understand Kanban, they’re increasingly are deciding to use it for some or all of their work. In my experience however it’s pretty easy to do Kanban incorrectly or ineffectively, because there are so few rules to follow. Here are two questions you should be able to answer if you’re really doing Kanban they way you should. Read more



Spike Abuse

September 12, 2016 | Leave a Comment

It’s interesting to me that after years of working with teams on Scrum adoption, I see some of the same patterns repeatedly. One of those is what I call “Spike Abuse.” Let’s start with what a spike is, then we can talk about how they get misused by some teams.

The Agile Dictionary defines a spike as “A story or task aimed at answering a question or gathering information, rather than at producing shippable product.” Said another way, it’s a story that results in knowledge (and sometimes other user stories), not in working software. Since our primary measure of progress in a project is working software, we should minimize the number of spikes we use. Sometimes however spikes get pressed into service in ways they shouldn’t be. Read more



I’m happy to announce that my latest article, “Why Johnny Can’t Write Secure Code” has been published in the September/October issue of InfoSec Professional Magazine, a publication of (ISC)2, the International Information System Security Certification Consortium.

Intended primarily for InfoSec professionals with limited exposure to application development, the article is an explanation of modern Scrum/XP project management, with advice on how to work with teams using these techniques. You can get a copy of the article (and previous ones I’ve written) from the Resources page on my website.



One of the troubling things to me about the Scaled Agile Framework (SAFe) was it’s increasing tendency towards an all-encompassing view of “the things you could do.” It had begun in my mind at least to resemble the Rational Unified Process (RUP) from years ago, even down to the interactive website nature of the SAFe website. The problem with RUP wasn’t that it was wrong or bad, it was that it was a complete toolbox, and required that you select the tools that were required to do your job. In many environments that resulted in oversized process, particularly in environments where teams were afraid of being blamed for failure, and for getting blamed for not doing something that in hindsight might have saved the otherwise doomed project. Read more



Larger enterprises usually have several environments. There’s obviously the production environment, and usually a testing and QA environment. Many will also have a stress testing/staging environment, which is a close facsimile of production, used to characterize the performance of the solution being built/maintained.

A common problem is testing data. As a matter of good hygiene, it’s a good idea to use testing data in environments other than production, and there may be strong regulatory or other motivations to do that (think HIPAA requirements, Payment Card Industry (PCI) requirements, Personal Health Information (PHI) and Personally Identifying Information (PII)).

Opposing this desire for scrubbed, faked or otherwise testing-only data is the idea that the best data to test with is production data, because of the volume and diversity of the data. How then do you reconcile the desire for consistent, production volume data in lower environments while still preventing access to sensitive data by people who really have no need to see it? Enter Format Preserving Encryption, or FPE. Read more



On a Scrum project, we hold a retrospective at the end of every sprint, to determine how to be more effective. There are lots of ways of collecting this type of discussion, and one of the most popular is Start, Stop and Continue, or it’s cousin, Do More, Do Less, Keep Doing. Something has been bothering me about this approach. Yeah, that “continue” thing… Read more



I’m in a coaching mindset recently, since the current client is employing me to do that first and foremost. It’s gotten me thinking that we need a different approach to retrospectives than I’ve seen commonly used in the industry. Read more



I’ve been coaching again on with my current client, and I’ve been see some folks struggle with the three Scrum questions: what did you do last (yesterday or today, based on what time of day your Scrum occurs); what are you going to do next (today or tomorrow); do you have any blockers. It’s clear that people don’t always get why we restrict the Scrum to just these three things. Read more



Ah, story points! The darling child of Scrum-style estimation. They have a lot to recommend them, in particular because of the many problems with using hours (ideal or otherwise) to estimate tasks. There are however some unspoken assumptions around using story points, which could catch the inexperienced or incautious team and cause significant problems. Do you know what’s assumed when you estimate your work using story points? Read more

keep looking »


WP Themes