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…
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…
Last week I started my new job as a Principal Software Engineer at Workscape. I’m back in another Agile position, working on Java (and starting work on Flex, too), which are the two things I was looking for. I would have settled for a position at a company that wasn’t Agile, but it would have been hard, knowing the benefits of it. I was waiting to post this until I got my first paycheck or did my first commit of fixed issues, whichever came first. Thursday and Friday I fixed three issues, so now it’s official.
Workscape offers HR services to other companies and their employees.
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…
As a Software Engineer, I normally think of Agile in terms of software development. As someone who has rolled out Agile practices at several companies, I also think of it in terms of how Agile software development affects the rest of the company. The last company I worked for (yes, I’m still looking for work!) implemented full Scrum, including pair programming, TDD (as in, insufficient code coverage had a direct effect on your bonus), retrospectives, standups, etc.
I came across an interesting blog post, The Smart Entrepreneur’s Guide to Finishing What You Started, on Scott Ginsberg‘s blog that suggests entrepreneurs learn lessons from Agile, too. Scott bills himself as “The Authority on Approachability”, but most of his blog posts seem to be aimed at high-level business and marketing people. He also claims to wear a nametag 24/7, with a tattoo of a nametag sufficing for certain occasions. Everyone needs a shtick, though, and this is what us geeks call “mostly harmless“.
This post proposes favoring action over inaction, moving at a sustainable rate, making sure you’re focused on the customer’s needs, limiting scope to enable completion of a phase/project, and [post="Done Means Done Done Done" text="making sure done means done done done"]. Sound familiar?
I also liked his post 6 Ways to Rally without Being Ready, reminding us that you’re never 100% ready, but that’s not actually required to start.