Geeks and non-geeks alike should do their research when buying electronic devices to make sure they can actually do what they want, and don’t have unacceptable attributes. In this post I’ll give some examples, and some helpful guidelines.
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.
I’ve been focusing on change a lot lately. Thankfully, not because of my day job this time. This time, it’s more to do with one of the not-for-profit groups I’m involved with. A couple of other things have planted this bug in my ear, though. Someone I know told me about the book Switch: How to Change Things When Change Is Hard, which is a fantastic book (so far. I just got my own copy and am reading it now). The other thing that got me thinking was an episode of Anthony Bourdain: No Reservations I saw recently. More on both of those later. The message I want to throw out there is that you can often achieve much better progress making small changes you can make today instead of waiting until there’s buy-in, resources, and removal of obstacles to a much larger effort. And those smaller changes are likely to have more direct beneficial effect, because contrary to what large corporations like to think, big changes often introduce larger problems. I have always tried to do this in my personal life and at work, and try to get others to do the same.
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…
Agile New England, one of the groups I’m on the board of, had a sold out meeting this week. We even asked our hosts to expand the capacity of the room and still had a waiting list. Janet Gregory spoke about the pitfalls of testing, how to tell when you’re in trouble, and how to get out of it. The audience was fully engaged, and there were lots of great questions. Next month, Johanna Rothman speaks on Agile project management vs non-Agile project management. Sign up quick!
Just as exciting, next week is our Agile Games 2011 event, which is almost sold out. There are four or five tickets next. What is it you say?
The Agile Games conference is an exploration of how concepts like serious play, collaboration, and experiential learning apply to the field of Agile software development and project management. Our theme for this year is “Learn. Share. Play!” More than a conference, this will be an experience where attendees will be able to learn new concepts, then immediately share and experiment with other professionals. Forget death by PowerPoint. Every single session we offer will be interactive, hands on, and – dare we say – fun! Whether you’re new to Agile, a capable practitioner, or a seasoned veteran, this conference has something for you.
This promises to be a great event for people at all levels. If it interests you, sign up soon.
As a creative person (and as a geek), when building something (software or hardware), I often say to myself “For just a little more time and/or effort, I can add this cool feature.” There are many good reasons why this is a bad idea. I would like to lead with the reason that has caused my blog to be stagnant for months, which is that doing more than you have to gets in the way of actually finishing. An artist I almost knew once said “The hard part about painting, is not the painting, but knowing when to stop.”
Since my last post, I’ve started about six posts that I never finished because I just wanted to add this one last point, or tweak that paragraph one more time. The result was no visible work output, which is inexcusable for an Agilista. Read on…