Last week I mentioned that I was pretty much consumed with some big things going on in my life. Well... I am finally ready to share some really big news. This week I am leaving VersionOne and joining Pillar Technology. It is a bittersweet announcement... so I want to accompany this announcement with a little backstory.
Two years ago when I joined VersionOne... I set off on a journey. At the time, joining VersionOne felt like a huge risk. I was going from a company that had twenty thousand or so employees to a company that had less than 100. I was going from a company with a diverse product set to a company that really only had one. I was going to stop managing projects for a living and become a trainer and consultant.
My wife and I talked about the fact I would now be on the road more... sometimes with only a few days notice. I'd be travelling overseas and going to conferences. We talked about what this change would mean for our kids... my career... our finances... and my employability should I ever decide to do something different. It was just a huge unknown... but it was exciting. It felt like the right thing to do and the risk seemed manageable.
Looking back with a little hindsight... it was the best of all possible opportunities. I've had the chance to work with some great people... the VersionOne folks are truly the best in the industry. I've had the chance to work with some excellent companies... companies who recognize that the status quo is no longer going to be enough. I've had to the opportunity to work with, and become and expert on, the best agile project management platform on the planet. I've had the opportunity to become a public speaker... find my voice as a blogger... and now as an actual author.
I really love working for VersionOne but for the past few months I've been thinking that it might be time to get back into the world of delivering projects. Even though having exposure to a diverse set of companies is huge and my pre-VersionOne experience was still extremely relevant... I wanted to get back out and build longer term relationships with people that are in the thick of building agile organizations. I wanted to get in and help lead change in a more meaningful way. I wanted to be a part of building the enterprises that I write about here on Leading Agile.
I didn't really know what life after VersionOne might look like. I always felt that if I worked hard and made a positive contribution to the community... things would play out. I recently started toying with the idea of becoming an independent coach or possibly starting a boutique consultancy. Having a stay at home wife... a mortgage... and three kids that like to eat... those options always felt pretty risky. I wasn't sure as a start-up that I'd be able to have the kind of impact that I really want to have. I need to be able to scale... and scale fast.
Enter Pillar Technology.
I first encountered Pillar Technology last year at the Agile Coaches Camp in Ann Arbor. I was impressed with them from day one. Everyone I have ever met from Pillar has been top notch... not just from a technology perspective... but as human beings. Pillar does great work and has fun doing it. I liked these guys before I ever started thinking about working for them... so when we started talking it felt like it could be a good fit.
What makes this move more interesting for me is that I am not going to Pillar as just an agile coach... I am going to build an agile consulting practice in the Southeast. Pillar is already the premier agile consultancy in the Midwest... I am going to help them go nationwide. I'll have the resources... and the talent... at my disposal to really help organizations lead the kind of transformations I am so passionate about. Now when I talk about learning to do small team agile... I can bring in the developers and coaches to help make it happen. I will be able bring in the kinds of leaders that can help organizations learn what it means to do agile project and portfolio management. We can help lead real... enterprise level transformations.
While the move to Pillar comes with some mixed feelings... joy over the new opportunity... sadness over leaving my friends at VersionOne... I am convinced this is the right 'next move' for me and my family. Pillar Technology is a VersionOne business partner and I am still just a few miles away from the VersionOne offices. I am looking forward to co-branding a few white papers and doing some joint webinars over the next year. I'll still be representing VersionOne at the PMI Global Congress and helping out with the upcoming Agilepalooza in Boston next month. There is tremendous synergy between our shared missions.
I will say though... if you ever thought... hey! it would be cool to have that Mike Cottmeyer guy come and do some work for my company... now might be a good time to reach out. For now... you can contact me on my personal email mike [@] cottmeyer [dot] com. Let me know what I can do to help. Even though I am going to focus on the Southeast US... there is no limit on where we can work together.
One last story and then I'll let you guys get back... when my wife got pregnant with our first son, we were living in Michigan. We knew that wasn't where we wanted to live so we started making plans to move. During that time, we were saving a down payment on our first house, getting ready to move to Georgia, getting ready to have a kid, Kimi was going to be a stay at home Mom, and I was going to start a brand new job within my company.
Over the past 10 or 15 years our family has probably experienced at least two more... maybe three... periods of extremely disruptive change. Some periods centered around kids... some around jobs.. and others around changing location. Most seemed to have something to do with all three. So while we don't have any more kids on the way... I am still planning to birth my book... build a business.. and maybe a few other things I've been noodling on. When I decide to shake things up... I really like shake things up ;-)
Need training, coaching, or help leading an agile transformation?
email: mike@cottmeyer.com or call: 404.312.1471
Saturday, September 26, 2009
Change is the only constant...
Thursday, September 3, 2009
Agile Chronicles has Moved!
Hey... most of you guys know that I write both here and at Agile Chronicles. But... did you know that I'm not the only one who writes for Agile Chronicles? We've got quite a few folks that post every now and again... and every one of them is worth reading. Here's the deal... VersionOne upgraded our blog and we have a new look... a new URL... and a new RSS feed.
Thursday, October 30, 2008
How to Talk to Project Managers
Last week, I had had the distinct pleasure, the rare opportunity, to attend the PMI Global Congress in Denver, Colorado. I missed the deadline to propose a talk but there were at least 5 agile presentation happening over the course of the event. That is really good news. The PMI crowd is interested and trying to understand what this agile stuff is all about.
I was working the VersionOne booth, so while I had a full conference pass, I did not get to go to any of the talks... bummer.
Note: This post was written last week, so I am writing like I am there now. I decided to leave the language that way... hope it is not too distracting!
Talking to Project Managers
It has been really fun talking to all the folks that have come by to see our software. The people that stop to talk to us have already been exposed to agile on some level, so my perspective might be biased, but there are many more agile friendly people that I expected. Again, people are interested and want to know more.
After my first full day of meeting and greeting the conference attendees, there is one thing I would like to share with the agile community. When you talk to a traditional PM about agile project management, you need to be prepared to speak their language. While teamwork and collaboration are important, that is not the language of the PMI crowd. Empowerment is essential but can be very threatening to someone that is accustomed to being "in control".
I've found that a good place to start is with a discussion of the triple constraints.
Managing the Triple Constraints
Most traditional projects start with some assessment of scope; an assessment of what the stakeholders want to be built and what they are willing to invest money to have. From there the team does some analysis, figures out how big the request is, and what will be involved in building it. We do an assessment of the team, understand who is available (and when), and begin to lay our dependencies and calculate the critical path. From there we determine a date.
Ask your PM friend if that sounds much like their personal experience? They will inevitably nod 'yes' because that is what project managers are taught to do. Next ask them what happens after they communicate the project costs and delivery date of the project? I would bet money that their response will be somewhere along the lines of: we are given a date, we are given a budget, and then we start de-scoping the project.
Sometimes, if management really does not care about successful delivery, they are just given the date, and the budget, and are made to deliver all the requirements anyway.
Our Real Project Drivers
This is where you can explain that they are given the date and the budget because those were really the project constraints to begin with, not the requirements. We pretend the requirements are the constraint because, like most people, stakeholders hope that we will be able to get everything we want for what they are able to spend. Most of the time that is not the case.
So, where do we go from here? I will typically explain that agile project management starts with time and cost as the primary constraints and introduces techniques that enable the business, in partnership with the team, to decide what is the best set of requirements to build. After delivering this line, be prepared for the blank stares.
But I Have to Deliver Everything
The blank stares are because project managers are trained that they have to deliver everything. The executives demand it and the stakeholders cannot take the product to market unless they have everything. Now it is time for more questions. Ask them if that approach ever works? The answer is always 'no'. Ask them what happens when projects start this way. They will answer that the project is always late or over budget.
The reality is that by demanding ALL the scope, in the face of data that says otherwise, the business is making the implicit decision that their project will be late. You are generally not rewarded, or very popular with your stakeholders, if you bring this to their attention. Project managers are often incented to keep their heads down, do their best, and take their lumps when things are late.
As a quick aside this is the main reason most project managers rely so much on process and documentation. It allows them to cover themselves and be 'successful' in an impossible situation.
Most Project Managers Don't Make the Call
The reality in many businesses is that the project managers are not empowered to make the time, cost, and budget decision; and even if they bring these issues to the attention of senior management, they may be forced to proceed with the project anyway. This is your hook to talk about why agile can be such a valuable addition to their PM toolkit.
Delivering in short cycles and measuring done gives you real data about the health of your project. Managers often assume the team has overinflated the estimates. They assume the team is sandbagging. Agile gives you real empirical data about the status of your project and what the team is capable of delivering. Agile gives the business real data, and real options; options that go beyond just how late and over budget do you want the project to be.
Put the Business Back in Control
Agile gives the business the opportunity to effectively de-scope on the fly, to change their mind, to increase the cost of the project, to lower the cost of the project, to deliver early, to deliver late, or to kill the project all together if the business objectives cannot be met. They get this information early, when there is still time to deal with it and make a rational business decision.
The senior managers I have worked with will make good decisions when presented with good data and real alternatives. Bad decisions are made in low trust environments with poor information.
Now Let's Talk Agile
So, with that groundwork in place, you can start talking about teamwork, collaboration, and empowerment. You can start talking now about pair programming, continuous integration, and test driven development. Those things just don't mean much to the PM community until you help them understand how agile will fundamentally put them in a position to deliver quality projects: on time, on budget, and with the highest value that can possibly be delivered.
Until then, people are just not going to get it. So next time you are talking to someone with a PMP next to their name, make sure you are speaking a language they can really understand. The traditional community is willing to listen, we need to make the most of our opportunity.
Reposted from Artems Agile Software Development blog: http://www.agilesoftwaredevelopment.com
Monday, June 23, 2008
Announcing the 3rd Annual "State of Agile Development' Survey
It is that time of year again - Version One has launched it's 3rd Annual 'State of Agile Development' Survey.
