Drunken PM

by
Drunken Boxing for Project Managers “The main feature of the drunkard boxing is to hide combative hits in drunkard-like, unsteady movements and actions so as to confuse the opponent. The secret of this style of boxing is maintaining a clear mind while giving a drunken appearance.” Yeah... just like that… but with network diagrams and burndown charts… and a wee bit less vodka.
Agile | Agile 2010 | agile 2015 | Agile Alliance | agile transformation | agile2015 | AgileThinking | AOW4PM | apple | art of war | Bas De Baar | body language | branding | Brian Bozzuto | capacity | certified scrum trainer | Chris Li | cloud | cloud worker | commitment | Corkulous | CSM for PMP | cst | Dave Prior | David Bland | Digital PM | digitalpm | Docs to Go | Don Kim | dpm | dpm2013 | EMEA | emotional intelligence | Essential Scrum | facebook | field guide | FIRM REPORT | Flipboard | Global Economics | Greg Balestrero | GTD | Howard Sublett | Idea Wallets | IOS4 | iPad | iPad 2 | iPad2 | iPhone | IT&T SIG | Jesse Fewell | jim benson | kanban | Kathy Compton | Ken Schwaber | Kuala Lumpur | lacey | Leadership Meeting | LeadingAgile | lean | LeanKit | Livescribe | Livescribe Pulse | Mac | MacWorld | Macworld 2011 | Malaysia | Marshall Rosenberg | mashup | MDEC | Merlin | Mike Cohn | Mike Sutton | Mike Vizdos | mitch lacey | MITPM | modus cooperandi | Non-violent communication | Notes Plus | NVC | off shore | Offshore | Olaf Lewitz | Oredev | Øredev | overcommitment | Panda Transport | Papershow | personal branding | personal kanban | personal productivity | PMI | PMI Portugal | Product Owner | productivity | Project | project management | project manaqement | project planning | Project Potion | Projects At Work | projectshrink | ProjectWizards | pulse | Ricardo Vargas | Robyn Meredith | Scrum | Scrum Alliance | scrum but | scrum field guide | Scrum Gathering | ScrumFest | Shane Hastie | SK Khor | social media | sprint planning | SXSW | telecom | Thierry Holoweck | Things | Thushara | Tobias Mayer | Tom Perry | troy magennis | twitter | value | VCP | video conferencing | Vivek Angiras | vocal technique | waste | What We Say Matters | Wijewardena | WIzewerks | show all posts

About this Blog

RSS

Recent Posts

Certified Agile Leadership Training with Olaf

Don Kim - I Think, Therefore I Plan

Agile Coach to Agile Gamer - Peter Saddington

Scrum in School - A Case Study of Grandview Prep's Transformation

Forecasting Tools Based on Team Performance with Troy Magennis

Off the Rails...

It was all going so very well. By the start of the 3rd week I was beginning to get the hang of the process. I wasn’t a shining model of productivity, but I was certainly making improvements.  I was learning a lot about how I worked and what I needed to do to become more productive. I had started making notes about all the experiments I wanted to run in the coming weeks.  I was keeping my PK Journal up to date. The only issue was that I hadn’t tried it with real work yet because I was also still on staycation. (I travel a lot for work, so when it comes to vacation, I’m totally happy to just spend the time at home becoming fully present with what a bad decision it was for someone who is horribly allergic to cats to adopt three of them.) Being at home for the first part of this experiment had allowed me to establish the physical habits of personal kanban and my hope was that this would keep me rooted in the practice once I was on the road again.

So naturally, the obvious next step was to completely screw that all up.

I had planned to be away on a retreat for a few days during the 3rd week. While I was there I picked up a slight cold that immediately turned me into a walker for about 8 days. Both of these events meant that for a period of almost 2 weeks, I was completely unable to do work on anything on my board.

Failure Bow

So… time for a Failure Bow
 


 

(If you aren't familiar with the Failure Bow, I'd like to recommend watching the Matt Smith TED talk below.)

 

While it would be easy to rip myself up for losing step, I knew that was going to happen at some point. What I was more interested in was what it would take for me to recover when it did happen.

Since I’d been keeping detailed notes on what was and was not working I turned to those to try and see what issues were causing the biggest trouble.

 

“Hi, My name is Dave… and I’m a Things-aholic.”
 

I was still using Things every day. I was recording tasks on my board and working them, but there were additional items in Things that I worked on and they never made it to the Kanban board. Most of them were personal items, but it did seem kinda of pointless to me to be working with two tools at once. It just divided my focus and make getting anything done that much more complicated.


I decided that I was going to start capturing everything I do on the board. I took everything listed in Things and created a post it for each item. I sorted and grouped the whole thing on my Kanban board. My plan was to try and go one week without using Things. During that time I would rely 100% on the Kanban board.

I made some modifications to the layout of my board as well. I added blocked boxes for some of the swimlanes and also made adjustments to my WIP limits.

I decided that I would start each day with (re)prioritization

I had learned that travel can have a very negative impact on working this way. I had a number of jobs coming up that would require travel. So, I decided to start researching electronic tools so I could test one out during my next trip.

One of the things I have found to be invaluable in this whole process is having the physical board to return to when things break down. There have been a number of events and situations that resulted in me needing to reset my approach.  I’ll be posting about them in the coming weeks. For anyone who is going to try personal kanban, my first advice would be to start out with a physical board and develop good habits with your practice. These will be an important touchstone for you as you work through the changes this approach will have on your work.

The final thing that came out of my retrospective for iterations 3 and 4, was a new question… what should I do about recurring tasks? Was it really going to be worth creating post-its for recurring each item so that there was a card for each one on each day of the week? That seemed ridiculous. I had no answer, but sometimes, just having the question is a good start. 

Posted on: March 24, 2013 10:23 PM | Permalink | Comments (0)

The iPad2 and Project Management

Last year when Apple unveiled the iPad, I, along with countless others were overcome with that all too familiar craving for new gear from Cupertino. Having tried and quickly abandoned several tablets running the other operating system, I was hopeful that the iPad would gain the acceptance it has rightfully earned, but as a project manager, I was mostly curious about how this new device would fit in with my job. The Windows tablets I had tried in the past always seemed to make my job harder. So, when I purchased it, I wasn't exactly sure what I was going to do it… but like I said… The craving…

Since then I've found a number of ways the original iPad enables me in managing projects and best of all, I'm able to use it with Merlin.

So last week when the new iPad was introduced, I was mostly focused on trying to figure out how this new model would enable project managers in a way the first generation didn't. The increase in speed, the lighter form factor are all very cool, but as a PM, those aren't really problems for me when I use the first version. The two enhancements I see in the new model that I think will have the greatest impact on project management, and the workscape in general are the HD video connection and the cameras. Here's why…

The first version of the iPad is a strictly personal device. When I first got it, I spent a lot of time trying to work out how it could be used in a collaborative way. With it's size, ease of use and connectivity, it seemed like it might be viable as a shared device. I was originally thinking it might serve as a great replacement for an Agile task board, and instead of standing around a board, Agile teams could pass it around the war room when they were together, and then, with the connectivity, it could serve virtual teams as well. But, there's not an App for that. The closest viable thing I found was Google' chalkboard - which was cool, but too small to be of any real use. With the new video out and the ability to show the whole screen, we have something even better. In meetings, rather than standing and working at a whiteboard, or a flip chart, we can work on the iPad and have the video show up on a screen. This will give us the same capability to work freehand by using any one of the apps that lets a user write and draw with their finger tip. When we're done, we can store the file in the cloud and share it with whomever we need to. This may not seem like a big deal at first blush, but think about all the time you spent (or have spent) typing up or otherwise capturing information from a whiteboard of flip chart. This would completely remove that step. Yes, we can take pictures of what ends up on the whiteboard or flip chart in a meeting, but it isn't as easy to recall those and update them later when we need to. As soon as someone creates an App that will also record audio and tie it back to the graphic file we create, the iPad will begin solving the same need that both Livescribe and Papershow solve. If the Gen 1 iPad gave us new options, the Gen 2 has the potential to deliver an easier way to work. Given the volume of work most PMs carry nowadays, this could be very significant. (Plus, we could end up with a lot less conference room doubling as storage for those electronic white board that always seem to be broken.)

The new cameras brought me back to something I have been thinking about since the set up was first introduced in the iPhone 4. Project Managers spend a lot of time writing, (editing, correcting, explaining, etc.) status reports. Our job is primarily one of communication and status reports are a critical part of that. However, we now have another option. It may take awhile to become accepted, but it would enable us to communicate far more effectively, in less time, than what we do now. With the self-facing camera it is easy to shoot a quick video and export it to email or iMovie. With the new iPad (or iPhone) PMs could record video status reports in short video status segments, tag them so that it is clear to anyone watching what the relevant topics are, and then post those. (In Merlin, you could even store them in the project file as elements.) Once we have all our snippets done, we could use iMovie on the iPad to assemble a full status report and post that as well. So, for those who want just the pieces relevant to them, they are available. For those who want the full report, we have that too. The argument against this is likely to be that it is faster for a consumer of our status report to just scan through ti quickly if it is written. That may be true, but writing is a limited form of communication when you compare it to video. Think about how many status reports, emails, etc. have been misinterpreted because all the reader had to go on was text. With video, you get facial expression, vocal tone and all those other nuances that can help someone get a clearer picture of when the PM is trying to convey serious concern, or even just make a joke. Think about all the communication struggles we continue to have in working with geographically spread teams and how much of that could be addressed if we were simply able to add additional layers of communication through voice and facial expression. Yes, scanning a text document may be faster, but the question is, does that quick read really provide an effective enough method of information consumption? This one may take a little while to catch on, but it would be hard to argue that increasing the depth of information it offers could do anything other than benefit a project and the people involved.

In both of the above examples, the new iPad has the potential to change how we handle our day to day work as project managers. It may not be Angry Birds, but if it can save you time and help you collaborate and communicate more effectively then it may be as magic as they claim.

Posted on: March 11, 2011 11:40 AM | Permalink | Comments (5)

Letting Go of the Concrete Liferaft

An article I wrote for the Scrum Alliance about the challenges PMs face when trying to embrace Agile has been posted here on the Scrum Alliance Site. Here is an excerpt...

 

On my first day of work on a job where my very official job title was listed as "Project Manager", a stressed out, old, bearded guy took me and the other newly minted PM into a room to teach us how to do our job. The first thing he said was, "When I am done with you, everything you do will be a project. You'll be unable to look at the world any other way." Truer words were never spoken. Looking at the world as a series of smaller tasks, with dependencies, a baseline, and a critical path invaded every corner of my brain. I stopped brushing my teeth and started executing a series of steps, which had dental hygiene as a measure of success. A few years later, after months of study, I passed the PMP exam and began trying to impose my "enlightened" approach on the rest of the world with results that were occasionally successful, but mostly, not so much.

If you'd like to read the rest, you can find it here

Posted on: December 31, 2010 01:35 PM | Permalink | Comments (1)

Why You Suck at Offshoring, Even With Agile (Recap and Retrospective)

Thushara Wijewardena and I have had a great response to our Agile 2010 presentation, "Why You Suck at Offshoring, Even with Agile". In an effort to respond to some of the requests we have received, we put together a video recap of our presentation along with a retrospective. The video is broken up into two segments because of the size. Please let us know what you think.

 

Part 1

Part 2

Posted on: September 27, 2010 12:37 AM | Permalink | Comments (2)

Why an Iteration is Not A Mini Waterfall

Categories: Agile, project planning, Scrum

 

When I am working with Project Managers who are in the throws of trying to learn Agile, there are certain discussions (debates), which can indicate that the person is going to have more of a struggle with making the change. These are usually the PMs who quickly grasp the flow of the process, but immediately begin second-guessing the system, and all of this usually happens without the PM even realizing it. After all, if you have been around a bit, and you are a halfway decent PM, you look at everything that enters your path as a potential threat to your project and start working out how you are going to get around it. This is what we are taught to do – find a workaround.

I think the bigger issue though, usually stems from the fact that the PM often does not recognize how their own expertise can be the obstacle. One of the ways this often manifests itself is through a question or declarative statement/argument about how the PMBOK is clearly, already Agile and these iterations or sprints we are talking about are nothing more than mini-waterfall projects.

Just in case any of the mini-waterfall people happen upon this… I mean you no harm. I spent about 8 years inside that argument. Please bear with me a few minutes and this will make more sense.

I have learned my lesson about trying to engage in an argument against the perception that a sprint (or iteration) is just a mini-waterfall. I don’t agree with it, but it is perception, and my experience has been that getting pulled into this one kind of like trying to debate whether Sammy Hagar was a better front man than David Lee Roth. 

To me, the real issue comes down to something completely outside the steps of the process itself. A traditional PM can make all the arguments they need to in order to maintain their death grip on the belief that everything in the world can be broken down into a traditional (waterfall) project. But, no matter how much Kool-Aid they’ve consumed, there is one thing which cannot be avoided, and which they cannot deny…

A waterfall project schedule is nothing more than a guess.

“…But little Mouse, you are not alone,?
In proving foresight may be vain:?
The best laid schemes of mice and men
?Go often askew,?
And leave us nothing but grief and pain,?
For promised joy!”
(from To A Mouse by Robert Burns http://en.wikipedia.org/wiki/To_a_Mouse)

Yes, it is an educated guess and yes, there is usually math involved and we all know that if there is math, it must be true. Math aside, a traditional project schedule is  just a guess based on what we think we know will happen, made at a point where we think we know enough to predict the future. (And I think we all know how good we project managers) are at predicting the future.

So, in managing a project, a significant part of the PMs gig is to come up with this educated guess and then do his/her very best to make sure to bend the very fabric of reality to match the guess. The idea is to manage to the plan.

In Agile, we focus more on the team and what we can do in order to better support and enable them, because it goes (Theory Y Alert!) that if you’ve got a bunch of smart, motivated people, you give them what they need, a clear objective and the power to make smart decisions, that the rest will take care of itself. (Remember – it says Theory Y above, not Theory X).

So, regardless of the steps in the process, the whole value system is completely different. A PM who is looking at the world through a waterfall will see the steps in the process as the thing that exists to make sure everyone stays on schedule as planned. An Agile PM is one who looks at the process as something their to support the team’s ability to perform. At the end of the day, both sides need to get stuff done, but a traditional PM uses the schedule to do this, an Agile PM enables the team to do this.

To me, if a PM is locked into the vice-grip of trying to prove that Agile is something that is already covered in the PMBOK, working their way out of that Gordian knot is usually something they will have to work through on their own, but if they can see the variance in the structure of the value system, and how that vantage point impacts their actions on the project, it is definitely a step in the right direction.

(And yeah, I’m willing to throw down on for Hagar any time, anywhere.)

Posted on: June 20, 2010 09:05 AM | Permalink | Comments (2)
ADVERTISEMENTS

"Talk low, talk slow, and don't say too much."

- John Wayne

ADVERTISEMENT

Sponsors