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

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

BBC News is reporting on researchers’ announcement of the discovery of a very sophisticated piece of malware, called Project Sauron. Of particular note is how long the malware has remained undetected (five years) and the sophistication of the malware, which can jump the so-called “air gap” to computers not connected to the internet. Highly secure computers are typically air-gapped to prevent or complicate attack and exfiltration of data, and Project Sauron is an interesting example of the lengths to which a (likely state-sponsored), sophisticated attacker can go to get at the systems they want to compromise.

[via BBC News]

I haven’t blogged on security topics in a while, and this one ran across my news feed. Researchers investigating a Distributed Denial of Service (DDoS) attack on a website have uncovered a 25,000-bot strong network consisting of CCTV cameras running Busybox.

https://www.helpnetsecurity.com/2016/06/28/25000-strong-cctv-botnet/

While we frequently think about botnets on full-on computers, the increasing use of devices such as cell phones, and now cameras highlights the increasing need for IT security as we roll towards a more comprehensive Internet of Things, lest it become an Internet of Bots.

In a Scrum project, we want teams to buy stories only if they are going to complete them within the sprint. There are several good reasons why that’s true, but many teams don’t know what they are. 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