Archive for the ‘Agile’ Category
Olivia: One thing I’d add to your post might be that you have to go into iterative efforts fully open to the fact that the “Loop” step might mean you took at wrong turn and need to stop and/or kill what you’ve done. Otherwise, you wind up with Winchester Mystery House product and resources spent supporting worthless crap. And killing something off is suuuuuuper hard to do, from what I’ve seen. But it’s part of that whole “committing to the Loop”…that’s the toughest part.
Me: I’m not a good killer. I love all my children.
…if you don’t “loop”. People…you are killing me! There’s a reason it’s called the “Build-Measure-Learn Loop” and the most important word in that phrase is the “loop”!
Okay, take a deep breath…let me Take a Step Back™…because I started with the conclusion.
All the rage these days is talking about iterative development and emergent design. If you’re in the business, you know what I’m talking about. If you’re not, a bit of background:
My ISPI Newsletter pointed me to your piece about SCRUM/AGILE. I’ve been told that a piece I published back in 1993 about a project carried out in 1987 is considered by some to be foundational with respect to AGILE/SCRUM. Here’s a link. I think you’ll like and appreciate it. http://www.nickols.us/prototyping.pdf.*
My post about Scrum in 5 Simple Steps sparked a raging debate on Hacker News yesterday. One commenter, Tom Elders, was aggressively opposed to Agile and and felt like, “It’s lunacy. It has all the hall marks of a religion.”
[Scott's post] is implying that Agile works, if only people would do it right. So it’s the same nonsense in fewer words.
Egads! I was recently given a 478 page hard-cover textbook by a major educational publisher on Scrum. You gotta be kidding me. There is so much talk and writing about Agile and Scrum and, frankly, in my opinion, 99% of it is confusing and makes things worse for the people who read it.
Don’t read that stuff. Read this. Keep it simple. Here’s how Scrum works:
Decide on amount of time that you’re going to work. This is your work cycle, and at the end of this amount of time you’re going to start a new work cycle.
It bugs me when people refer to a “status meeting” as a “standup”. It probably shouldn’t because it’s only semantics, but I’m a language nerd, what can I say? I’m hoping we can nip this loose use of the language in the bud because I don’t want us to unlearn the distinction between the two types of meetings.
To me, a “standup” is a very specific type of meeting. A “standup” is a colloquliasm for the “daily meeting” in the the Scrum software development process. In this meeting, the team comes together for a brief period of time to evaluate progress toward their goal.
It is customary that to keep the daily meeting short, teams will have the meeting, literally, standing up. The theory was that people can only stand comfortably for a short period of time, so that would keep the meeting brief. Hence, people started referring to the “daily meeting” as the “standup”.
Check it out! I was at my kids’ school today, and saw that my son’s 5th grade class is using a Kanban board for their class newspaper. Each row is a student, each card is a story, and each column is a step in the process. Very cool!
At Cheezburger today we took some time to reflect on how we’ve done the last few months using a technique called, “Mad, Sad, Glad”. Each person took a few sticky notes to express how they thought things had been going.
Turns out this is a great way to harvest success and surface impediments.
I am a huge proponent of test automation. That is, having robots that exercise the code to verify that it’s working as expected. There are numerous and endless reasons for why test automation is important, but I’ll leave it up to you to search the Interwebs and learn why.
In an automated test environment, it’s important to understand how much code is covered by the automated tests. Knowing the portion of code that is covered influences trust in the automated testing, and how much manual testing is needed.
There are tools that will do this for you called “code coverage” tools. (For example, at Cheezburger we use a product called NCover.)
There’s an expression I’ve heard that says there are two types of work: working in your business and working on your business. What’s the difference?
Working in your business is doing the work of making the business go. For example, if you have a widget factory, you’re working in your business when you’re making widgets.
Working on your business is doing the work of improving the business. For example, if you have a widget factory, you’re working on your business when you streamline your processes to produce more widgets at a lower cost.