For the past year, the IT&T SIG has been working together with the Scrum Alliance with the aim of fostering a stronger relationship between the PMI project management community and the Scrum and Agile communities. We started out by holding a series of Scrum and Agile webinars, and last fall we followed up with a special networking reception in Denver at the 2008 PMI Global Congress that celebrated the work we’ve been doing with the Scrum Alliance

The work we’ve done so far has been very successful in beginning to build a bridge between the two communities. But now we have even better news!

This Spring, at the Scrum Gathering in Orlando, Florida, top thought leaders from the Scrum and Agile community will meet with thought leaders from PMI to discuss ways in which we can continue to develop the relationship and increase the awareness on both sides of the fact that each of the approaches has benefits which can be realized across the others.

Here are the official details:
2009 Orlando Scrum Gathering - Scrum Alliance

March 16, 17, 18th, 2009 at The Gaylord Palms Resort, Orlando, Florida, USA

Featured Speakers include: Scrum co-founders: Ken Schwaber & Jeff
Sutherland, along with Mike Cohn, Jim "Cope" Coplien, Ron Jeffries, Alistair
Cockburn, Gregory Balestrero (PMI), Chet Hendrickson plus many more industry
leaders.

Space is limited, and the expectation is that it will SELL OUT very soon, so if you are interested, please sign up as soon as possible.

Because of the significance of the event, the Scrum Alliance is offering a special discount to members of PMI. If you are a member of PMI and register for the Scrum Gathering, you’ll get the same discount that you’d receive if you were a member of the Scrum Alliance. Click here to receive the discount:
https://www.regonline.com?eventID=680388&rTypeID=196410

If you would like additional information on the event, please visit:
www.scrumgathering.org

MacWorld Roundup

I’m just back from MacWorld and ready to get back to work. While I was there I had an opportunity to spend the week helping out in the ProjectWizards booth, showing folks some of the new things that Merlin has to offer.

While I spent most of my time in the booth, and didn’t see much of the other exhibitors, there were a few products there, which won awards, that I’ve already been using to help me manage my projects... so I thought I’d focus on them.

The Livescribe Pulse is a pen... oh, no wait... it’s a smart pen that costs almost $200. Which sounds insane, until you use it. Available on the PC for awhile, it only recently became available to Mac users. What makes it worth the price is the fact that when I am in a meeting, then pen records all the audio. At the same time, I capture notes in a special paper notebook. After the meeting, the pen can by synch’d up with a computer so that the notes and the audio are transferred to your computer for later review and storage. I’ve only been using this for a few weeks, but it has already proven its’ worth by allowing me easy access to critical information. I had a team member on a project who claimed he had not known about a particular action item which was assigned to him. I merely pointed the pen at the note I jotted down in the meeting, tapped the pen to it and it played back the audio of him saying “Ok, I’ll take that as an action item.”

I’ve written in here before about my continuing efforts to get better at using some version of GTD to manage all my work. There are a lot of products out there. Some of which are really good, some, not so much. Things, which has been receiving a lot of attention lately went to version 1.0 last week and is now able to sync with the desktop client on the Mac. Between the easy interface, the level of detail it lets you get to and the fact that I can now work off of either my desktop or iphone (or ipod touch), it is definitely my app of choice for managing the onslaught of tasks I am still not quite able to get done each day.

The last thing I want to mention today, is Merlin. I’m a huge Merlin fan and have been for a number of years. If you use a Mac, and do serious project planning, it is the most robust client available. For me, the line in the sand was the ability to separate work and duration. None of the competing products allow that level of planning. For a while now, the desktop has also allowed you to imbed things like register items and documents (project plans, change requests, etc.) right into the plan, making them available right from the client. It also lets you read and write MS Project files. But Merlin is making another huge leap with the ability to share to the web and iPhone (or iPod Touch) that allows a real time update back to the client or server version of the project plan. This means I can serve my project file from the desktop or server and have my Windows and Linux users update their tasks from the browser window and I can see updates the moment they make them. There is no check in process - it feeds directly in over the internet. With the iPhone (or iPod Touch) I can not only look at my Gantt Chart on the device, but I can make the same updates and they push across the internet back into my plan in real time. I can even view the documents I’ve embeded into my project schedule on the iPhone (or iPod Touch) if the file type is one the device can read (like PDF). 

It has been a few years since I’ve looked at trying to get Project Server implemented anywhere, but the last time I checked, the cost to get it set up for testing in an enterprise environment was upwards of $100K (US). With the new Merlin capabilities, I can get all that set up and running, including the cost of a new machine (it will run on anything that has 1 GB of RAM and can run 10.4.9 or higher) for under $2K (US).

My New Year's Resolution
A few weeks ago I was at P2P in Cairo, speaking with Philip Diab, the 2008 Chair of PMI. We were both about to give brief speeches at a conference and he brought up the idea of developing a consistent theme and using it as a sort of guiding idea when preparing for presentations over a period of time. It was great advice, and I have decided that I am going to start off by applying it to the blog.

Remix
In Lawrence Lessig's new book "Remix", he devotes a fair amount of time early on, to explaining how kids today are creating mashups with music and he goes on to detail what the legal ramifications are with this and the book goes on from there. If you like Lessig's work, or are at all into reading up on copyright law and intellectual property rights, I highly recommend it.

While I was reading it, I found that I kept drifting back to the idea of mashups and other places that they occur in modern life. The basic premise is that you take two existing things and push them together to create something new and (ideally) better. The site Mashuptown.com has a great video explanation of it in the upper right corner of their homepage.

Depending on your taste in music, this could be a good or a bad thing. But, in coming back to it, I started to think more about the other places in my life that this takes place - especially work.

So, jumping back to the whole consistent theme thing... for 2009 my focus is going to be on PM Mashups, or, bringing different (pm related or not) ideas and practices, etc., together in one's approach to project management with the end goal of coming up with a more cohesive, adaptive and ideally, creative way of managing work. My plan is to develop a series on the idea and hopefully, I'll be able to find a bunch of folks along the way who are also mixing their chocolate and peanut butter and don't mind talking about it.

PM Mashup #1 

For about 18 months I have been primarily using Scrum to manage my projects. For most of what I do, it works very well. It's adaptive, lightweight, and is great for developing trust with the clients. However, I have found that it for it to work best, I need to add some components from other approaches.

Traditional PMBOK type documentation is something I tend to get lazy about, so I am always trying to find ways to make it easier to get through. I do, however, think it is critical to have those artifacts and I am a very firm believer in keeping a historical record so that you can learn from your mistakes. It would be easy to get away without doing this in Scrum, but, as I mentioned above, I think that historical artifacts are critical and, even if there are no defined requirements at Go, I do think that they need to be locked down by the end of the project. (Always leave the room nicer than you found it.)

So now, when I'm working on Scrum projects, I generally try to make sure we have a wiki set up so that we can provide the client with documentation that will be current by the time we leave and which they will hopefully maintain as a living, organic version of the requirements doc. Now, I know that the requirements doc should be created up front, but the simple fact is that most of the time, what is being asked for initially, is not entirely definable and will probably change during development. I also know that once we create the initial requirements that I, as the PM am responsible for keeping it current. Unfortunately, in practice, what I've found is that the requirements doc becomes something that is either A) gathering dust the moment it leaves the printer or B) something I work furiously on updating so that it can gather dust the moment it leaves the printer.

My goal is to have a place to capture whatever we initially know in an informal, plain language manner and then build on it as we move forward. We usually start out by entering whatever use cases we have and we work with the product owner until they reach a level of comfort entering directly into the wiki themselves. Over the development cycle, the use cases are updated by the team as they evolve into a sort of post development explanation of what is in place. We evolve, with the product owner, from the initial need, to the realized product, which is documented in plain, simple language. It is not traditional requirements and may lack a lot of the structure that a traditional requirements doc includes, but if the objective of the traditional requirements doc is to define what is requested to a level of detail that can be executed and litigated against, then the wiki reqs, or Requirements 2.0 is intended to be easily digested by humans who may have a need for the information.

This mashup doesn't fit perfectly into Scrum or a PMBOK type approach. But, it does enable the workflow process and meets the informational needs of the client in a way that does not place an undue burden on the team.

I'll post more in about a week, but if you have any mashups of your own, I'd love to hear about them.

Happy New Year!