Agile 2009: A reminder of why each team needs leadership

-

:: Originally Posted on the Pathfinder Development's Blog ::

Last week I presented at Agile 2009 a workshop for those new to Agile entitled: The Agile Game: An Experiential Workshop. I love this workshop because it allows those new to Agile to experience the rhythm of an agile project in action and learn first hand many of the practices in a non-threatening, non-technical, and fun way. I have used this workshop for clients a number of times and it works. The feedback from this session was overwhelmingly positive too. Comments such as, “Fun game, good to demonstrate how teams do and don’t work together” and “Very, very, practical way to get concept through” are always great to see.

Recently I had been wondering if Project Management was a questionable career choice. I have spent the last couple of years surrounded by talented individuals who seemed to be able to work fine without me. The test is always when the project manager (me) goes on vacation. Has the team fallen apart? Are they forgetting all of the practices they were doing? Is stuff getting delivered to clients? I was finding that I had a backlog of chores when I came back, but overall things were still humming along.



The Agile 2009 session reminded me of the road I took from software developer to a project manager and why. Early in career I generally found project managers provided little value. I asked a lot of questions and I caused a lot of trouble for those “managing” me. Eventually somebody said the equivalent of, “If you think you could do it better, do it.” No introduction to the subject tells you that, simply, good project managers are good leaders. They optimize what resources they have available, point out areas for improvement, and occasionally carry a stick. An Agile project manager, freed from the burdens of heavy process, can’t stay busy with chores long and must produce a good team quickly. I found that through focusing on how the team could work best together and gently pushing during retrospectives, I left a trail of happy teams on successful projects.

It may not be the most glamorous job, but each team needs one. To continue the sports theme from my last post: Most teams populated by very talented athletes. However, its take a good coach to help each of them reach potential together as a team. Now, back to leading my team.

Popular posts from this blog

Your Inconsistent Design Makes Me Worry About Your Entire Product

-
Image
This is from a product I use daily. Who wrote this code and thought they were done? Who approved these two button styles next to one another? I have this vision of a developer choosing a library that made their development life easier. I picture this code going straight into production use without review. Next, I picture the designer who works there rolling their eyes, checking out, and heading to LinkedIn to see what other opportunities exist. I'm being unfairly harsh, but it makes me wonder what other sloppiness is happening inside this product.
Read more

Goodbye

-
When I started this blog, Agile was not yet the lingua franca of product development. I was passionate about teaching the Chicago community about Agile. I helped start the Chicago Agile Project Managers Meet Up. I presented at the international Agile conference. I was coaching organizations to use Agile practices and how to integrate user centered design into product development. Good times. Based on this blog’s old google analytics data I can see that I was able to help a lot of people.  Today I find myself spending very little time on blogs - reading or creating. My go to places to find content to learn and grow professionally didn’t exist when I started Planning for Improvisation. This blog isn’t needed anymore. As I have moved on, this blog can too. -Kal
Read more

Applying user centric design to your business plan

-
Image
Image by Lars Plougmann I got asked by an investor recently how we at Digital H2O do design. I liked the conciseness of my response and thought it was a good example of how to tie user centric design into a business plan. Here goes: Our design philosophy is best described as user centric design. Our goal is to only design and build features our current, or potential customers, find valuable and that substantially help our business continue to grow. We spend significant time listening to our customers’ needs throughout the sales process. We then form hypothesis what customers’ needs are and what they can accomplish in the application. While designing features we show mock-ups and prototypes to customers in order to get feedback and incrementally improve the design. After the product is built and released we continue to test our hypotheses about how customers will use features we have built. We utilize automated event tracking in the app to monitor u
Read more