I recently hosted a lean coffee during which project management roles and responsibilities were discussed. The discussion helped me realize that this title held many different meanings for people.
The first line of Wikipedia’s entry on project management reads: “Project management is the discipline of planning, organizing, securing, managing, leading, and controlling resources to achieve specific goals. ”
The words in that description are quire provocative to me, but I’d rather hear what others believe.
I am keen to get some more understanding around this prevalent role. This blog post, more-so than others, is an explicit invitation to engage in a dialogue in the comments.
The questions I’d like to use to seed this discussion are:
What does a project manager do?
What problems would you hope to solve by hiring a project manager?
What’s the difference between a project manager and a program manager?
What are the most important traits of a good project manager?
How does a PMP certification make a project manager better?
Okay, so I’ll gladly add to this blog post and maybe even take what we learn from the comments in what I hope will be an educational, lively yet respectful discussion, and aggregate a subsequent post.
I’ll also add that I recognize there are not “best practices” I don’t believe there is a correct answer to be learned. What I hope is for us to learn from people in various contexts what the answers to these questions are for them.
I just got back last week from SFAgile2012 conference where I talked with a group of smart people about eliminating silos in a “whole team” kanban and the power of lean coffee.
As is usually the case when I attend conferences that align with my values; it felt as though I had been transported to the very best parts of my twitter stream. Putting faces to people once known to me only as @OlafLewitz, @MattBarcomb, @LisaCrispin, @JitterTed, @DavidJBland, @Zspencer and @hogfish during the conference and even got to meet @marlenac at the press club monday night and visit with my favorite tester @testobsessed.
I could write about the excellent keynotes:or the sessions where we played with legos to help us learn Cynefin or the fact that some exceptional people like Steve Rogalsky actually changed the content of his late conference sessions to incorporate things he’d learned during the conference.
But instead I’m going to write about why I present at conferences. The answer may come as a surprise but I present at conferences to learn. I’ve yet to discover a better way to learn a subject than to present it to others. There are many examples I could give of brilliant people attending presentations of mine and completely blowing my mind with their contributions. But before that happens I use anxiety to learn from my commitment to present. I have no fear of speaking in public. I have an intense fear of wasting people’s time by yammering about things I don’t understand in front of them. This fear is a big reason I am such a huge fan of open space conferences. Specifically the “rule of 2 feet” which states “If you’re not learning something or teaching something use your ‘two feet’ to leave the session and go elsewhere.” I think conferences, tutorials, open or closed space should have this rule clearly posted on every wall of every conference.
I do not make powerpoint slides and prepare a script to present, I just freak out that I need to make sure I’m as knowledgeable about the subject as I am make myself. I use sticky notes to help anchor my talk and ensure I don’t forget anything critical, but otherwise I’m generally on my own. This seems to work reasonably well when I know what I’m talking about. Consequently there is no better way for me to dive headfirst into a subject than to promise to teach it to a room full of people. My fear of wasting their time will keep me obsessively researching till the minute I walk into the room.
So what did my sessions at SFAgile2012 teach me?
In this case I feel like my talk about removing Silos needs more ideas and to lose the “kanban” label. I am eager to give that talk again about removing silos in organizations regardless of the methodology being used. This is an important subject that deserves attention and not to be obfuscated by attaching it to a given methodology. Silos are harmful to alignment and collaboration regardless of what system is being used to get the work done.
During the three days of SFAgile2012 I hosted a lean coffee every morning at the Blu Cafe at 7AM. On day one we had 10 attendees and as always seems to be the case the level of discussion was first rate. Steve Rogalsky introduced the topic of selling lean to CFOs, Jabe Bloom shared his upcoming talk for GLASSCON and bounced some ideas around how to address 200 government employees about introducing experimentation and lean to their organizations. Jim Benson talked about “Agile in a can” and respect for people. On day 2 we had almost 20 people and day three lots of folks showed up. As is usually the case I wish I had recorded or taken notes to share with those 3 lean coffees.
On Wednesday I presented the power of lean coffee as a session for the conference. I realized too late that while I had prepared an extensive discussion about facilitation patterns, cynefin, and some pitfalls inherent in the process I had missed the most critical aspect of the presentation. I realized that nobody had to teach me how to do lean coffee. The best way to learn lean coffee is to do lean coffee. I decided at that moment that if we had time after the talk we’d break into groups and have lean coffee.
I conversed for nearly 45 minutes about lean coffee wth the group before we split into two lean coffees. During those 2 lean coffees I was reminded of some antipatterns and things I should’ve included in the talk. Ultimately I think the lean coffees were the best part of my session. I bounced between the two lean coffee tables and found it incredibly difficult to observe all the passionate discussion while not diving in myself. My talk was just before the lunch break and each table stayed at their lean coffees well past the end of the session. A sure testament to the power of lean coffee to engage people.
I’ll never again give a 45 minute talk about the things I’ve learned facilitating lean coffee. I’ll present a 15 minute introduction to the process mechanics before breaking into lean coffee groups. After an hour of lean coffee I’ll bring it all back together to discuss facilitation patterns with an audience that has greater understanding and get feedback on those people’s observations of running their own first lean coffee.
During SFAgile2012 I taught myself that silos are a problem many people are interested in solving and that I need to give more thought and research on eliminating them. I also learned what I believe to be the very best way to teach an advanced lean coffee facilitation course. Lean Coffee teaches itself, and once folks have learned from Lean Coffee they’ll benefit greatly from additional facilitation patterns and stories of past challenges.
I learned a ton from the sessions I attended and look forward to writing about them in future posts. I would also like to thank the organizers of SFAgile2012 for the invitation and hope they enjoyed my contribution.
I would also be grateful for any feedback people wanted to give me so I can do a better job on this blog or in future conference sessions.
Every Wednesday morning I drive down to Kakao Coffee in the South Lake Union neighborhood of Seattle and learn from a panel of esteemed “professors” for free at Lean Coffee.
The experience is nearly always amazing, when it’s not amazing it’s merely great. The mechanics of this meeting are deceptively simple: write ideas on stickies and then talk about them.
The facilitation tools are cheap sticky notes and sharpies. The “professors” take time out of their busy days as practicing coaches, consultants, project managers, testers, programmers, authors, university professors, and entrepreneurs from diverse fields ranging from software development to health care.
We almost always walk away with powerful new insights into very serious and complex life challenges. Topics vary from how to identify and overcome our own cognitive biases to how to facilitate enterprise lean organizational transformation. No one person has the answers but as a collaborative group we’re far greater than the sum of our parts.
Jim Benson and Jeremy Lightsmith founded this powerful convergence in 2009 and due to busy travel schedules attend rarely. Another testament to the power of this thing is the fact that it quickly became a self-sustaining community of practice. It happens every week regardless of the attendance of it’s founders. It’s a living entity that cannot be stopped.
I look forward not only to presenting the power of this system to attendees of SFAgile 2012 but to sharing my experiences as an attendee and facilitator. Additionally I’m going to host a lean coffee in the very early morning hours prior to each conference day 1 block from the venue at Blu Cafe 747 Market St. . I am counting on our east coast and european jet laggards to be bright eyed and bushy tailed for a 7AM lean coffee.
Here is a mind-map I made of the talk/process. I’d love feedback any time.
The source of this concept comes from my experience with teams transitioning to scrum/kanban/scrumban systems as a tester. In my experience even when WIP limits are applied they are only applied to the development swim lane. Which means as work gets finished it avalanches down into the testing team. The concept that development is a more complex endeavor than testing is a potential driving force behind this fallacy. The belief being that testing is easier than development so you can heap loads of stories onto the testers and they’ll knock it out in a similar amount of time to how long it took to develop.
There are loads of issues with these assumptions. Rigorous, skilled testing can be considerably more time/effort intensive that coding the story. When testing is left until the end as a separate activity the only result of that testing is rework and therefore cards are send backwards along the kanban.
Beyond the testing example, we have different business units interested in the process. How can we have a “whole team approach” if we put walls between engineering and management, or sales and engineering? How do we engage these teams in collaboration?
I have some ideas about ways to attempt to resolve these questions. I have no answers but I look forward to having an active discussion about this important topic. I hope we’re able through this dialog to come up with some ideas to explore further, and ideally we’ll even commit to actionable goals that we can individually strive to achieve.
Here’s a mind-map of the structure of the discussion as I see it, feel free to offer feedback prior to the conference and remember it’s not too late to register and come spend some time with brilliant doers & thinkers in the space.
Yesterday, after Lean Coffee, I had a conversation about agile software methodologies with Joe Justice, somebody I greatly respect. I expressed my feeling that the term “agile” has become a loaded one, with many conflicting meanings, and use of it can incite unintended reactions from the community. At the time I didn’t realize that I shouldn’t have said “the community” , as I now believe that it was too narrow in scope and might’ve derailed our conversation a bit. By “community” I meant the software industry as a whole (See: Agile ruined my life and halfarsedagilemanifesto).
We discussed how certain methodologies emphasize the technical team as the boundary for the new way of thinking…emphasizing divisive principles, like protecting the engineers from “the business” so that they can do their best work without interruption. These methodologies overlooks that “the business” consists of people who are also trying to do their best work toward the same goal. I strongly believe that organizational alignment is vital to work satisfaction, and being happy is vital to doing our best work.
I am certain I made some tired arguments about local optimizations that de-optimize the whole, when Joe put us back on track by explaining what “agile” means to him. His guiding agile principle (see:Principles behind the agile manifesto) is the 7th: “Working software is the primary measure of progress.”
I got to thinking about this and it started to dawn on me that this is a very easily misinterpreted principle. The definition of “Working software” can be very broad indeed. If software compiles without build errors does that mean it “works” or if it runs successfully through the happy path?
Let’s say for the sake of argument that the software is bug free; meaning it works exactly as specified and no defects exist. What if the customer doesn’t want it? Or there is no market for this mythical flawless feature? What if that feature was very expensive to produce? We’ve made working software, but was it an effective primary measure of progress? What if the engineering team worked so tirelessly on producing this software that they all hate their jobs? Eric Ries calls the aforementioned “Achieving Failure”: Delivering on time, and on budget a low defect, high-quality product that nobody wants.
I think working software as a goal is a good one, but when we silo the engineering team and “protect” them from “the business” we create an adversarial environment between groups that have the same goal. To enrich the lives of their users by producing an experience so great as to compel the customer to clamor for it and tell their friends.
Maybe a better wording for that principle could be “Delivering amazing experiences to customers at a sustainable pace is the primary measure of success.”
I could go on about the many ways one could misinterpret those words too, but I’ll leave that to the commenters.
2 weeks ago at Seattle Lean Coffee Michael Wolf shared a story about seeing two colleagues at a conference who had not seen each-other for years reunited without much fanfare. One of them looked at the other and matter-of-factly said “Hey, long time no see, what are you reading?”
Michael felt like this was a powerful question. What we’re reading at a given time could be a great window into our interests and where we are in life. Full disclosure: I’ve never been a big reader. I would still not classify myself as a big reader. I read books because they contain deeper technical and/or theoretical detail into subjects about which I am passionate. I would say presently I only read in a professional context. I read books that I hope will give me new insights into how to do my job as a tester and agile process advocate better.
I would love to hear what my peers and readers of this blog are reading. Maybe we can expose one-another to some new ideas.
Books I’ve finished recently:
Linchpin (Seth Godin): This book talks a lot about the state of our economy and the value of creative emotional workers and their work. Seth makes really insightful points about how following maps at work and being unthinking cogs in a machine will lead to your job being outsourced to a more inexpensive cog somewhere else. Conversely, if you are passionate about your work and you put emotional creative energy into it, you will be irreplaceable. You can easily replace a guy who stamps a piece of metal in a factory with a computerized robot. You can’t replace an artist with a computerized robot. This to me is analogous to the discussion around testing vs. checking. Testing is a challenging sapient intellectual art which you cannot teach a computer to do anymore than you could teach a computer to create an original painting that expresses emotion.
Personal Kanban (Jim Benson & Tonianne DeMaria Barry): This book changed the way I think about every task I tackle in a given day. I found this book very easy to read, entertaining and non-dogmatic. After I read this book I started organizing my backlog in post-its. When I travel places I take a notebook and some post-its so I can manage my flow on the road. Jim and Tonianne have written the definitive guide to turning the stress of a given pile of tasks and transforming it into an innocuous backlog of sticky-notes. Where I once finished a task and forgot about it, I now have a nice satisfying pile of stickies under the “Done” column to celebrate. While I once wondered how I’d ever be able to tackle my busy workload, I now have a nice limited work in progress column. How I have used the concepts learned in this book to change the way I handle my work and home tasks is a blog post in itself. For now I’ll just suggest you read this book. My copy has been abandoned in San Francisco in hopes it’ll help infect my engineering team with these principles an concepts.
Reads in progress:
Specification by Example (Gojko Adzic):This book eats its own dog food. You could have accurately titled this book “Specification by Example by Example” because it’s full of real-world examples of various business and technical challenges surrounding the practice of building living executable documentation in a domain specific language using a collaborative whole team approach to software development. Gojko covers high-level business examples as well as technical details around various approaches and tools useful to solving real-world challenges. I haven’t finished this book yet, (about 80% finished) but so far it’s been really great.
Anything You Want (Derek Sievers): “Anything You Want” is a short book chronicling Derek Sivers’ experience building CD Baby. I was attracted to his book by his videos on Vimeo which I Came across on Twitter. It’s a short book that I accidentally almost finished by virtue of having great difficulty putting it down after I bought the kindle version. Derek was not an aspiring tech startup. He wasn’t at meetups trying to elevator pitch angel investors. He was a musician frustrated with the poor options available for distributing his CD. He taught himself to code so he could make a shopping cart and accept credit cards on his website long before paypal existed or even eCommerce became catchy. Soon his friends started asking if he wouldn’t mind selling their CD too. Slowly his little project expanded to the point where he needed to hire an employee. Eventually CDBaby took off and was wildly successful. Throughout this experience Derek didn’t lose touch with his customers. He never strayed from his mission to help independent musicians get paid for their music even when big labels came around offering bags of money to give their artists special treatment. It’s a quick read but a great one.
Lessons Learned in Software Testing (Kaner, Bach, Pettichord): This book is the exploratory tester’s bible, why haven’t I finished it yet? Because every time I open it and start reading I put it down and go test. I mean it’s like I’m building a marble sculpture and reading a book about sculpting techniques. I read a chapter and run downstairs to my workstation and dive into testing. I would ordinarily say that a book that is hard not to put down is not a book worth reading. But there is too much good stuff in this book for me to sit down and keep reading. I have often considered doing a “Bold Boast Book Club” on this book in order to motivate me to finish it, but I am having too much fun using this book to improve my craft. If you’re a tester, or a programmer, or a product manager, this book will help you to think about software in a different way.
Okay So tell me what are you reading? What do you think about what I’m reading?
A couple months ago I began attending Seattle Lean Coffee. I had first heard of lean coffee last year when Jon Bach and Jim Benson told me about it at my first SEASPIN (Seattle Eastside Area Software Process Improvement Network).
I was highly impressed with the efficient democratic process of using a kanban to run a meetup.
Seattle Lean Coffee is held every Wednesday at Kakao Coffee at 415 Westlake.
Usually somebody (often Jim Benson, or Jeremy Lightsmith) shows up with some post-it pads and sharpies. A kanban is created on the table with a ready, doing and done sticky note marking the swim lanes. The attendees each write down what they’d like to discuss on a post-it sticky note and stick it in under the “ready” column. Once the backlog is populated each attendee takes a moment to describe their topic in a sentence or two. Once we’ve heard all the topics there is a vote. Each attendee marks the topic that interests them most. We’re limited to 2 votes each and less than 5 minutes after we all started, we have a prioritized backlog. We pull the topic with the most votes to the “doing” column and get started talking. Once we move a topic into the “doing” column somebody keeps time on the discussion. The time-box is usually set to 8 minutes. After 8 minutes we have a silent roman vote. The roman vote consists of holding up thumbs. Thumb up means “I’d like to continue this topic” Thumb sideways means “I am ambivalent” and Thumb down means “I no longer have anything to contribute.” If the majority shows passion (thumbs up) or ambivalence (sideways) we set a timebox for half the original time (4 minutes in this case). When I facilitate I’ll adjust the time-box according to passion. If we barely made a “yes” vote I’ll set a shorter box (e.g. 2 minutes) and we’ll continue. Once the majority votes to move on, we pull the current sticky to the “done” column and then start a new time-box on the next topic.
Once the clock strikes 10, we re-iterate that there is no commitment to end on time and either continue the discussions or end Lean Coffee for the day. Once we’ve decided Lean Coffee is over we hold up our hands to give feedback. We call it R.O.T.I. (return on time invested) vote. We all hold out our hands showing anywhere from 1 to 5 fingers. 5 fingers signifies that we could not imagine having spent the last 90 minutes in any better way. 3 fingers is still good, it just equates to a “B” and 1 finger means what 1 finger usually means. Anybody giving an R.O.T.I of 2 or 1 is asked to share what we could have done as a group to make this experience better so we can do so next time.
We get people from all walks of business in attendance. Software Engineers, Project Managers, Manufacturing, Healthcare, and High Tech have all been represented in the few short weeks I’ve attended lean coffee.
The quality of the conversation is always shockingly high. I always learn something and have so much fun being exposed to so many contexts that I would normally never experience. I suppose I’m a process nerd since I get tremendous enjoyment out of trying to apply my experiences in software to health care, and government contexts as well as learning new things from them to apply to my work.
The format is simple and powerful, there is no reason you can’t have lean coffee if you’re not able to come to Seattle. Tweet some tweets or blog to get interest, invite your co-workers to coffee or other like-minded peers and bring a stack of post-its and some pens. It’s that easy! Seriously we can all learn a lot from each other just by getting together and having a conversation.
Update: Change to closing process! (05-31-2012)
Yesterday Jeremy Lightsmith suggested rather than doing a quantitative assessment (R.O.T.I) that we go around the table and each state something we take away from that day’s discussion. Jim Benson had a slew of notes that will make their way into an upcoming series of ebooks, Jeremy came away with a motivation to try and write a personal blog post for each lean coffee he attends. I stole Jeremy’s idea, and came away impressed by how much amazing extra value we got from cementing our experiences with each other at the end. The death of R.O.T.I. is welcome given how much more awesome the “Takeaway” process was. “At the end of lean coffee we go around the table and get take aways from the group. Anybody can pass and choose not to share a take away.” Discontinuous improvement FTW!
Every Wednesday morning I drive down to Kakao Coffee in the South Lake Union neighborhood of Seattle and learn from a panel of esteemed “professors” for free at 
