Okay... just kidding with the picture. This is my last work day until the new year so I am waxing philosophical and exploring some stuff I have been thinking about for a little while.
This post originated based on some feedback I've received over the past few weeks on the 'Secret to Organizational Agility' post and more recently on the 'Agile PMP: Teaching an Old Dog New Tricks' webinar from last week.
Both sets of feedback, most of it positive... some of it not, prompted me to give some thought to my intended audience and why I am writing to them at all. When you can't be everything to everyone, you better be damn clear who you are and what you want to be for those that care.
Here is my musing on that subject. Be warned, I start to get a little teary eyed toward the end ;-)
I started writing publicly a little over a year ago. When I started, Leading Agile was originally titled Applied Agile Leadership. My thought was to take some of the agile concepts my team had been working with for the past few years and help others apply them more effectively in a range of situationally specific contexts.
Looking back, there was no way for me to really understand what the year would bring or the value writing would have to me as a professional in this arena. Writing this blog has become essential for me to process and understand these ideas and more importantly, express them to others. I am often asked questions about topics I have blogged on, and not only do I have a prepared answer, but a resource that I can point them to for more information. I have often built entire talks around ideas that started off on these pages.
Why Project Management?
My career has been a love/hate relationship with Project Management. The title implies so much yet means so little. Depending on your organization and the strength of its project management team, the skills and competencies of your project management staff can be so radically different. Some teams are filled with glorified secretaries while others are populated with senior leaders capable delivering large programs and effecting significant organizational change.
In my own quest for personal meaning, I have always advocated that Project Managers need to be seasoned, qualified leaders that are not merely passive participants in the act of project management. They need to be knowledgeable in a wide range of project management best practice, they need to know their particular problem domain, and most importantly they need to be able to interact effectively will all levels of the organization. Project Managers need to be strategic problem solvers, not just note takers and meeting schedulers.
At its very core… this blog is fundamentally a call to action for project managers to become better leaders.
I have always felt that the knowledge of project management process was almost trivial. Read a book, study for and pass a test... call yourself a PMP. Take a two day course on agile management... call yourself a Certified ScrumMaster. It's not the facts that are our challenge, its not the techniques… it is the underlying principles. It is the ability to apply these facts and techniques in your own situationally specific context.
Who is My Audience?
To be honest, I don't know much about the folks that read my blog. I have some anecdotal information based on a few of the folks I have met personally at conferences and talks. I get a little information from the people that comment or reference my blog in their posts (which I really appreciate by the way). Based on my passions and what little I know about my readership, I have constructed a mental model of my reader, a persona if you will, of the person I am talking to on the other end.
NOTE: It would be cool if you guys would let me know the accuracy of my assessment. Reply to this post or drop me a line.
As I mentioned before, I see myself primarily talking to Project Managers. I use Project Manager loosely in this context. Often times we have Development Managers and Directors of Development leading projects. We might have a Product Owner leading a project. Sometimes we have Technical Team Leads or even a QA analyst. Basically, anyone that has taken on a project management role, no matter what their title in an organization.
I am fundamentally trying to help the folks out there making it work… make it work.
My typical reader could be a hard core agilist trying to lead change in their organization. I suspect that many of my ideas might help these folks discover a new way of looking at things or presenting concepts to a traditional management organization.
I suspect that many of my readers are people currently performing a traditional project management role, probably a PMP, maybe somewhat new to this whole agile thing, and struggling to understand and implement agile within traditional organizational constraints.
Same problem… different points of view.
What Can I Contribute?
Most folks I meet are wired to think about process in terms of actionable steps and the supporting documentation. I want to help people think about projects in terms of people. I want them to think in terms of complex systems and interdependent behavior. I want to get up underneath process and people and focus on the kinds of stuff that really cause our projects to fail. More documentation and better defined processes steps don't solve the problem. It is our underlying attitudes and values that matter.
So… I am not sure at this point in my public life I have contributed anything really new. I am clearly standing on the shoulders of the giants that have come before me. I really appreciate the though leadership of Cockburn, Highsmith, and Cohn amongst many, many others. What I do is impossible without them. One thing that I think I can do well, and on my best days, maybe even better than most, is help folks understand these ideas in language that project managers can understand... advocating strategies they can actually implement.
I value thinking about problems in the right way. I want to be right, at the very least I want to be in the ballpark. The fun part about writing publicly and thinking out loud is that I don't have to be right... and I am not scared to be wrong.
Most of the time when someone disagrees with one of my posts, it is really a matter of perspective and a difference in our perceived audience. I don't try to be a pure agilist and I am not talking about applying these concepts in an ideal setting. I grew up professionally trying to understand these concepts in large convoluted organizations. I want to help people untangle the mess, one step at a time. I am passionate about helping people breaking down these concepts and understanding the why behind them, and then building them up in a way that helps their organizations understand.
Is it Working?
This year Leading Agile has seen success so I am guessing my approach resonates with some in the community. This blog has grown from just a few subscribers at the beginning of the year to around 600 or so as of this morning.
I thank Brian Sondergaard for encouraging me to start writing at all. I also want to thank Jurgen Appelo, Artem Marchenko, and Glen Alleman for all the great press and links to my site over the year. Thanks also to those of you that have shared my posts through Google Reader, Twitter, and to those that have referenced Leading Agile in their own blogs. You guys know who you are and I appreciate your help.
I hope that this site fills a valuable void in the marketplace of ideas. I read a great and timely quote this morning that I'd like to share:
“I don’t wish to be everything to everyone, but would like to be something to someone.” ~ Ali Javan.
Tuesday, December 23, 2008
So... Who Reads Leading Agile Anyway?
2008 in Retrospective: Mike Cottmeyer Edition
The end of the year is always a great time to reflect. Somehow the prospect of a new year allows us to break psychologically from our past. The new year gives us an opportunity to learn from our mistakes and move toward a better tomorrow. Whether real or imagined there is power in this annual rite of reflection.
The Need to Change
Toward the end of last year I realized I was frustrated. My career had been a slow steady climb but was not yielding the results I had hoped for. Somehow along the way I had stopped playing to my strengths and allowed myself to start playing to others expectations. I needed something in my life that I could own, something I had created. I toyed quite a bit about going out as independent consultant but was not in a great position to take that kind of risk. The kids have to be fed… the mortgage has to be paid.
CheckFree had been a great gig for several years but I decided it was time for a change. Over the previous few months I had been building a relationship with some of the folks at VersionOne. Early December 2007, after several months of talking, I was offered a role on the VersionOne Services team. This was an opportunity to train and consult and fill my non-billable time with writing, community events, and speaking engagements. Taking this position allowed me to live out my desire to be an independent consultant within the confines of a small but well established company.
Over the past year I have learned that VersionOne is just the kind of gig I am cut out for. The day to day monotony of corporate America is just not my thing... at least not right now... and at least in the kind of jobs I'd been doing the past 18 years. I feel fortunate to have learned this about myself and that I had the opportunity to make a change.
There are some life skills I'll need to develop to make this kind of role work over the long haul. The fun stuff is so compelling it is easy to lose sight of other things that must get done. I learned that I have to be more disciplined about leaving time to change a light bulbs, for balancing my checkbook, and mowing the grass. I need to be more disciplined about diet and exercise and getting enough sleep. I will have to find a way to turn off my work brain every now and again. My wife tries to tell me our life is not an agile project (although I am not sure I agree).
With 2008 just a week or so away… I'm thinking a lot about what I'd like to build on in the upcoming year and what I'd like to do better.
What Worked Well...
While I did spend too much time on the road this year, I really enjoyed getting out and talking with customers. Having exposure to a broad cross-section of companies and leaders at every level of the organization has proven invaluable. These people have helped me sharpen my perspective and given me insight that is just not possible working with only one customer at a time.
These interactions have been the engine behind my writing and helped fuel my creativity. I can't tell you how many times this year when I had nothing else to say that I was inspired by a client to do some of my best work. Blogging and writing has become a form of creative expression and I find myself compelled at times to write. Writing has helped me clarify my ideas and become more articulate expressing them. I am really happy with my body of work so far and look forward to building on it in 2009.
For as much time as I spent traveling this year, I can honestly say that my relationship with Kimi and the kids did not suffer. Catch me offline and you can check in with her yourself, I am confident she will agree ;-) As we move into 2009 I plan to continue my involvement with our school (http://www.hopespringscs.org), with the Boy Scouts of America, and doing many more fun things with my wife and kids. We took some great trips and had some really good experiences. I look forward to more of these special times in 2009.
What I Want to do More Of...
My friends and family give me tremendous grief over the amount of time I spend on Twitter and Facebook. Fortunately, they don't even know about LinkedIn and Plaxo or I'd never hear the end of it. While at least people realize that blogging is part of what I do for a living... my wife is still concerned with the amount of personal information I publish about our family. I find it really hard to separate my personal persona from my professional persona... this is just what I do.
The emergence of social networking is really fascinating and I am excited about the idea of marketing my personal brand. Over the course of the next year I'd like to spend more time developing my message and being better at communicating my unique value in the agile idea space. I can't be everything to everyone but I want to get really good at speaking to my target audience and understanding what they need.
Closely related to the idea of social networking and building a personal brand, 2009 is going to be about spending more time with my real network. You know... the one that has actual people in it? Relationships are going to be key to growing my presence in the agile community and I'd like to create space to actually talk with more people and share ideas face to face. Unfortunately for me and my family, that often means time out speaking and doing community events. My goal will be to make the very most of a lesser number of events.
One of the things that took a hit this year was my involvement in our Church. I am fortunate to have a rich community of people I really like and my soul needs to spend more time with them. One of my goals for the upcoming year will be to find a way to contribute. That contribution needs to be life giving and play to my strengths... without consuming an inordinate amount of time. I want to be involved, but I just can't live there... it is easy to get sucked into doing everything.
Things I Need to do Less Of...
Travel is a necessary part of what I have chosen to do for a living but this year I need to be really careful about what I sign up for and how I pace myself. 2008 was pretty manageable until conference season hit and then I found myself in Toronto, London, Denver, and Orlando over two month period. That would have been fine except that I had to prepare content and do my normal work engagements during that time as well. The net result was that I was on the road, or frantically preparing to be on the road, about 80% for over four months.
My goal for the upcoming year is to be more careful about what I agree to do and how I time the events. This year I was like a kid in a candy store. I was unable to decide on what was important and unable to prioritize... so I tried to do it all. I am still living with the tummy ache from all that fast living. There are some things I would like to do in 2009 that I am just going to have to decline. It is all about prioritization, making good choices, and maximizing value.
In the upcoming year I need to do less procrastinating, deferring, and avoiding. This year I allowed a lot of noise and clutter to accumulate in my life... and that detracts from the joy of living. It is difficult to live in the moment when there is always something else to do or someplace else you need to be. Part of this is prioritization, part is just saying no, and part is being really proactive with those things I choose to let remain.
The Power to Change
Overall… 2008 has been a great year. I am not sure I would have changed a thing. Sure… there are a few things I could have done better… but each of those things taught me a valuable lesson that I really needed to learn. I am thankful for my job at VersionOne and all the great people I have met and worked with this year. I am thankful for my supportive family and a great network of friends, twitter followers, and blog subscribers.
There are days when I am surprised that anyone gives a damn what I have to say. I cannot tell you how thankful I am that any of you guys are willing to listen.
I believe in the power of change and I believe we all have the ability to create change in our lives. We can't fix everything overnight. To me it is a matter of being at peace with where you are but still putting time and energy on where you want to be. Even small steps in the right direction can make a difference.
Have a merry Christmas, a fantastic holiday season, and a happy new year!
Thursday, December 18, 2008
The Unified Process and Scrum
Earlier this year I did a presentation at Agile 2008 on using RUP as a scaling framework for Scrum. The talk was pretty poorly attended and clearly controversial. Earlier this morning I was up on my Slideshare account, pulled the talk up, and did a quick walk through on the presentation.
I really think the concepts here are solid and central to any serious conversation about scaling agile in the enterprise.
If you get a minute over the holidays, take a look at the presentation and give me some feedback. How could we take these foundational concepts and make them more palatable to the broader agile community?
Subscribe to this blog
Subscribe to Leading Agile
Friday, December 12, 2008
But They Like It When I Tell Them What To Do!
This is a re-post from my article on Agile Software Development. Re-posted here for my Leading Agile readers.
Okay… I am unexpectedly out on a client site this week and I have not had time to think, let alone write, let alone write anything interesting or worth reading. So, in lieu of a writing a meaty blog post, I am going to tell you guys a little story.
Earlier today I was talking with a traditional project manager trying to get her head around what it will mean to make the switch to agile. Keep in mind, I have been on this client's site the past two days. We have been breaking down traditional notions of requirements, engineering practices, quality assurance, organizational structure, and team structure. We have discussed self-organization, empowerment, and individual accountability.
As we were wrapping up this afternoon I could see that this lady was struggling. This transition was really going to impact her job and force her to reevaluate her management style and approach to project leadership. We talked briefly again about the idea of empowerment and self-organization and how she was going to have to learn to let go.
She turned to me and said… but Mike… they like it when I tell them what to do.
It was such a profoundly honest comment that told me volumes about her and the state of the team. This project manager derived a certain sense of self-worth from being the person that told everyone what to do. The team liked being told what to do because they were fundamentally absolved from any responsibility for the outcome. They were perfectly content to let the project manager do their thinking for them.
It was a great reminder to stay focused on what often runs underneath the arguments against agile. It is not always rational or logical. More often than not, people find themselves in situations of their own making. They are comfortable just where they are and many have been very successful under the current way of doing things. And you know what? Change can be scary… and it is always uncertain.
A year or so ago I was going through a rough time and came across a great passage from Machiavelli's "The Prince". This passage has often provided comfort when I've grown weary of leading change:
"And let it be noted that there is no more delicate matter to take in hand, nor more dangerous to conduct, nor more doubtful of success, than to set up as the leader in the introduction of changes. For he who innovates will be have for his enemies all those who are well off under that existing order of things, an only lukewarm supporters in those who might be better off under the new?"
Original Post at Artem's Agile Software Development.
Photo Credit: http://max-redheads.blogspot.com/
Monday, December 8, 2008
The Secret to Organizational Agility
Are you ready... here it is... to be agile you must... break dependencies at all costs!
Dependencies are created when any two discrete elements within your organization require each other to do all or part of their job. At the enterprise level, dependencies are everywhere. They are created by the very way we have decided to structure our businesses and how we setup and execute our project work. This makes them very hard to identify and even harder to remove.
I believe that breaking our dependency on dependencies is the core challenge associated with orchestrating any sustainable enterprise agile transition.
Agile transitions don't fail because Scrum is insufficient. They don't fail because people have not sufficiently applied the right XP engineering practices. Our problem is not a fundamental misunderstanding of the Agile Manifesto nor an unwillingness to become the right kind of agile leaders.
While any given organization may have some or all of these problems, they are not our primary concern.
The underlying issue is that agile project management principles, agile engineering practices, and agile leadership philosophies assume you have already eliminated your dependencies! Most teams are trying to become agile without validating that core underlying assumption, no one has even told them they should try!
Think about how we describe our ideal agile implementation...
First, we start with a small team of cross functional individuals with sufficient skills such that anyone can work on any part of the system. Next we allow this team to only work only on a single project during any given sprint.
We then grant this team a dedicated product owner empowered to make decisions on behalf of the business. We allow them to work on small independent functional requirements which can be reprioritized at any time.
We give this team an empowering individual tasked with removing any organizational challenges the team might encounter. We remove any process constraints and allow them to do the work any way they want as long as they deliver working software.
Lastly, we assume they have an object oriented architecture that lends itself to test driven design, continuous integration, and constant refactoring.
This scenario perfectly describes a team with no dependencies. They have 100% of everything they need to get the job done.
Let's look at what many teams deal with trying to adopt agile...
People are typically part of a team of specialists that are matrixed into a cross functional project team. Because these people are specialists, their services are not needed 100% of the time. To maximize the utilization of the individual, they are assigned to multiple projects and any number of teams.
Product owners are doing market research, meeting with customers, and attending trade shows. The team is left with a less than empowered business analyst to make the decisions for the business. In reality, the product owner was just a proxy for a large group of uninvolved stakeholders anyway. No one gets access to real customers or real market data.
Many teams are trying to sprint through product development using a traditional MRD or PRD. They are not using requirements written as functional threads of system behavior that can fully tested at the end of the sprint. These requirements are not able to be reprioritized as we learn more about the evolving system.
Many teams are working with traditional project managers who are doing their best to be agile, but have been trained to manage dependencies and tell people what to do. Even if they want to be agile, they are not usually empowered to do anything about the real impediments the project teams are working through.
Teams are trying to be agile with tightly coupled software architectures, insufficient test coverage, legacy code bases, and unable to do a daily build.
This perfectly describes a team operating under the crushing weight of dependencies created by flawed organizational assumptions.
Let's look at some of our common assumptions that lead to unnecessary dependencies….
We assume that we must optimize for individual performance and therefore we matrix team members across projects. This creates dependencies between projects that did not have to exist. We find ourselves managing who is on what project and when they will be available for other projects. We create a network of dependencies [between projects] that restricts our ability to change course. Any change has a series of painful cascading impacts on our portfolio.
We assume parts of our solution are just too complicated and must be handled by specialists. We choose to assign certain people to specific components. By default, we create dependencies between products that share the same components. We also create dependencies between requirements that impact the same component. We create project dependencies between teams (and between team members) when we have these specialists assigned to a team of specialists.
We assume that our product owners are too busy for the team so we assign someone else to proxy for the business. We create a dependency between the team and the business that results in a tendency to over-document and manage the relationship between contracts. When contracts are used we create dependencies between the team and the business that must be maintained, enforced, and put under change management.
We assume the market is demanding all the features at one time so we do not focus on small functional slices across the entire systems architecture. Why bother, it all has to be done anyway? This thinking leads us to consider everything before we can consider building anything. When the requirements are all dependent on each other, there is no need to prioritize, no ability to change our minds, and no ability to learn from the emerging system. That big up front design document starts to look pretty reasonable.
We assume that architectures cannot be decoupled or that test coverage is too expensive. This causes us to think about making every change when we are making any change. Batched changes are made outside the context of working software. They are integrated and tested all at once... probably near the end fo the project. By creating dependencies between code changes, we loose the ability to learn from our mistakes, refactor, and hold teams accountable for outcomes.
Dependencies force us to measure hours worked, or modules delivered, or lines of code, when what we really want to measure is working software.
Why does all this matter?
Some of these dependencies are real. Many could take years to overcome. Just realize that every dependency you accept, every one you choose to leave in place, is going to fundamentally limit your ability to adopt agile methods.
Every single one will require a trade-off that will reduce your effectiveness and ability to respond to change.
By focusing on project management technique, engineering practices, or even leadership philosophy first… we miss the mark. We are inclined to pick from a smorgasbord of tactics and choose what can work for our particular organization. We are not forced to deal with the foundational problem, and therefore pick and choose our way into a meaningless agile implementation, one that will not deliver the essential value the organization is trying to deliver.
By focusing on the relentless pursuit and elimination of dependencies, we position our organization to potentially adopt ALL of the agile best practices. We can then pick and choose based on our values and principles, not on the constraints of our tangled up dependency based organizations!
Reduce dependencies at all costs. This is going to become my mantra for 2009. Expect to hear more on this topic as the year unfolds!
Monday, December 1, 2008
Why Project Managers Like Documentation
Reposted from Artem's Agile Software Development Blog
Most software project managers have very little power in an organization. They are on the hook for delivery, but have very little control over the actual resources required to get the job done. Project managers have to broker agreements, hold people accountable, and get people to do things that they are not otherwise incented to do.
Fixed Constraints and Up Front Design
Requirements documents are created early, and often with little input from the delivery team. Budgets are set and timelines negotiated, prior to the project team even being engaged.
In other words… project managers are in a pretty bad spot. They are trying to manage in a situation where the triple constraints are all set for them, they have little direct control over resources, and the resources they have are matrixed across several projects with competing priorities and differing agendas.
Project Managers Want to Succeed
Project managers are often very driven people. They are detailed oriented and focused. Believe it or not, project managers don't want to fail. Project managers are people that are committed to being successful… they want to deliver and do a good job.
So… what can a project manager do to ensure success? Focus on paperwork and process.
Paperwork and Process Defines Success
Because project managers are in an impossible situation, they retreat into self-preservation mode. They focus on comprehensive documentation and sign-off to hold people accountable. They put process and documentation over working software because the constraints of the organization ensured failure from the very beginning.
Over time, people get used to operating in this manner. Project managers get promoted and run PMOs. They run development organizations. They become a part of the business. The challenge is that they carry these self-preservation attitudes with them as they move up the ranks.
We have ended up with a bunch of leaders that think this is the way software gets created. They think that paperwork and process is the way software gets delivered to market. The thinking is so pervasive, no one even questions how we got here.
Changing Behavior Will Take Time
If we want to change this behavior and begin to tear down these walls, we need to encourage transparency and create an environment of trust. Project managers need to be able to bring the difficult issues to the business and be assured that the business will not punish them for their integrity.
Companies need to create a culture where assumptions get validated, and when they are not valid, the plan changes. We need to create a culture where risk is managed, but when it is realized, we accept responsibility for our mitigation strategies. We can talk about change management, but we have to understand that change is not free.
I understand it is difficult to run an uncertain business. We can't wish that uncertainty away and we need structures and frameworks to help deal with it. Agile project management is just such a framework. Agile help us embrace uncertainty and deal with it.
Holding Project Managers Accountable
Hold project managers accountable for effectively managing assumptions and risk, good decision making, and proper escalation to the right people. Hold them accountable for how well they communicate and keep the business informed. Reward them for coming up with creative proposals and implementing effective strategies.
Unless we want mountains of documentation no one will ever read, let's stop holding project managers accountable for plans that should never have been laid in the first place.
Photo Credit: www.polaricecapz.com/
