Agile methodologies, like most flexible yet powerful systems, rely on knowing exactly where things stand. You may not know exactly what’s coming in the future, but you know what you’ve already got, and roughly how close work in process is to done. This is one of the many reasons short iterations are a good idea. Not only do you know on a frequent basis (the end of each iteration) where you stand, but if what was done is acceptable to the stakeholders (and QA) and can really be considered done. The product backlog tells you what needs to be done in the future (based on current knowledge, which may change, and that’s OK) and the iteration backlog tells you what’s done and what needs to be done now. The burndown chart shows how things are going inside the iteration.
Read on…
I have to admit when I first experienced Adobe Flex, the successor to Adobe Flash for rich internet application development, I thought it was a fragile toy that wasn’t good for much more than pretty moving pictures. At my current day job, I had to not only learn it, but spend about half my time working in it (as opposed to my current favorite language, Java). One thing I’ve learned from the experience is that it wasn’t so much Flex that I had a problem with, as much as Flex Developers. The Flex developers I’ve worked with up until this job came to Flex from being Illustrators, Graphic Artists, or just kinda fell into it. They never learned the art of software development, never learned to appreciate best practices, and never learned to value code quality or readability. But as a long-time Software Engineer, I know you can create bad software in any language. But now I’ve spent about 10 months working in Flex, and feel I can opine fairly. Read on…
In my last post, I talked about tools for tracking Agile projects. Whatever too you use, you have to know what to do with the information. It’s not just about the project being ahead or behind schedule, it’s about using the information to improve the software development process and its implementation. One optimization which has been part of many Agile schools from the beginning, back to the Toyota days, is minimizing work in process. In fact, it’s the major focus of Kanban.
Work In Process isn’t just code sitting in your editor. It’s any task that’s not done, done, done. In other words, if it hasn’t made it all the way through your software process, it’s still work in process.
Read on…
I admit it, I’m a bit of a geek. OK, I am an Alpha Geek. And yes, I sometimes go with the slightly more computerized solution that others might. I just don’t get Agile’s fascination with sticking hundreds of pieces of paper on the wall, though. Agile teams need a mechanism to share knowledge about stories and tasks. They often do this by using whiteboards with sticky notes (so they can be moved) or cork boards with push pins and index cards. There are columns for the stages (waiting, in process, in QA, done done done) and rows for each story. This article shows an example of one.
I talked about it with an Agile coach friend of mine, Nancy Van Schooenderwoert of Lean Agile Partners, and she made a good point that the paper system makes the whole process easier to learn. She also pointed out that all software has limitations, and it’s important to start out with the index cards or sticky notes so you don’t get the impression that any limitations in the software are a limitation in the Agile practices. I get that. But once the team is passed that point, it’s time to use software-based collaborative tools. Why?
Read on…
I came across this blog post on the Developer Art blog on preserving and sharing project knowledge. I found both the articles and the comments insightful, offering several good suggestions for persisting and disseminating project knowledge.
This is a topic near and dear to my heart. Anyone who has worked with me on a project knows I take endless notes, and I have been saved by them many times. They can lead to information overload, but to me, it’s worth the risk. You can’t go back in time and take notes at a meeting that already happened any more than you can reshoot your vacation pictures once you’re back home and notice that they all have your thumb in them. I would rather record information and throw it away later if I don’t need it, than try to reconstruct an undocumented conversation after the fact. The act of recording the information also helps me remember it.
Read on…
Just a link to a nice article on the subject. I know we can be pretty hard to figure out, but geeks need love too 
Here’s the article on DZone, a technology publishing company that produces valuable content for software architects and developers worldwide.