Some Agile Development Commentary
I’ve written several posts in the past regarding agile development and how we’re leveraging some of it’s benefits internally at the present time. There is a solid post up at Tyner Blain, in which Scott provides some good feedback on a post written by fellow blogger Mishkin Berteig.
There’s a story a friend of mine (who works within a very large organization as a project manager) shared with me a while back. He was sitting in a meeting with a client and his top project team. A piece of QA within the release process for their code had broken down their process, preventing them from essentially, getting shit done.
That’s generally bad.
My good friend recognized something very critical though - why was backend regression testing (the piece of QA in question) occurring for the UX component of the software? They had nothing to do with one another, but were on the schedule and continued to be done.
The response from those around the table was basically, “that’s just how we do things.” Yikes! That answer, right there, can sum up a lot of what’s wrong within long, severely drawn-out release cycles.
We’re trying to get a v1.0 out the door, and will probably end up doing so this week. Now, we’ve been working on this (from the ground up) for the last, say, 2 1/2 months. That’s an incredibly short period of time to a) define a product b) get it through a development cycle c) market it, and d) release it. If, at any time, my response to a question had been, “that’s just the way it’s done” and thus prevented us from completing a key piece of the PDLC faster, I’d have expected I’d be fired partway through the process.
These types of excuses can be directly tied back to a few things:
- Egos - people want to cover their own asses
- Straight-up stupidity and fear - people don’t understand their role / job and are afraid to say, “I don’t know”
- Fear imposed by higher-ups - VPs and directors with no clue and way too much leeway to say, “my way or the high way”
- Silo’d, non product-centric organizations - those that define the company around roles instead of products
That last one is very important and one I remember touching on before. Agility isn’t just about having senior-level developers you can trust with flexible requirements, but it’s about everyone caring and contributing to the products themselves.
Who cares if someone is “in marketing” or “in legal?” Why does that matter? Their sole function is to solve pain for your customers and build great product. That’s why it’s so critical to commit to product management and not make it a half-assed effort just because everyone else is doing it. Get them in the center to do what they do - ensure the planning is place and crap makes sense, and then execute.
I digressed quite a bit, and it’s got nothing to do with how Scott’s post is written. The difference between using waterfall and using agile approaches is very simple - at least in my mind. If you have a complex, workflow-intensive product (like a banking or insurance-level application), you should be planning your PDLC’s using waterfall methods. If not, plan your whole PDLC using agile. No question.
Of course, that’s not to say, product groups within the overall (probably silo’d) organization that make up the individual feature teams or “product” teams if your suite is broken down that way (a la Microsoft) can’t use agile. They should. It would probably help them work faster and more closely together.
Sorry, Scott — I started out by intending to respond to some of your key points, but kinda got off on a tangent.
Time for Help
It’s time for me to get some help.
Ha ha. No, not the white jacket, Lindsay Lohan kinda of help.
But a person to help me manage our existing product portfolio.
I’m starting to realize how drained my time is. And, I suppose, part of getting older is realizing when to put up your hand because you need some time with yourself, your friends, and your family. And start-ups can occupy every waking hour if you let them.
Now, I’m not saying “gee, I really don’t like my job and I want someone to slough stuff off on.”
I love my job. I love being a product manager and the trials and complexities that come with that role.
I also love team building, teaching, learning, and building things with others.
So, I’ll be working this week to build a justification / key points that I can present to the suits (sorry, just watched Entourage tonight) and seeing if I can get a budget to bring in another product manager to be a part of my team.
A large part of wanting this is to ensure that our products succeed and recognizing that I can only focus so much of my time on a certain set of them before burning out and letting them go to the dogs.
I don’t want that to happen. But another person that can actually work with me and learn the market and build cool / great stuff for those customers is very important.
Who’s helping you? I know Bob has made some posts about how he owes his life to his project manager. I’ve seen the light, Bob…
Focus and Vision
The title of this post is so reflective of two key things that are necessary for success. But there are definitely some others. Leadership. And another biggie - making and committing to bets.
In order to really drive a company forward, it needs to have a vision. Say what you will about buzzwords, this is really important, because with a lack of vision, you really do have a bunch of people wandering around wondering what on Earth to do, and how they fit in.
But vision isn’t the only thing.
You need to provide the team / company with the open-area, big room ability to stay focused. They need to have flexibility to respond to the customers and the market, but don’t fire off so many projects that they can’t be effectively managed, and “crap” starts to squeak through the release door because people aren’t paying enough attention to the right things.
Make a bet. Base it on the vision. And the drive that thing to execute. Get the team rallied behind it, and put out quality product.
And when you get a team working all on the same goal (releasing a product for a specific purpose), it’s a beautiful thing to watch everyone react when it’s a success. No kidding.
But where does it all start? Defining vision based on an identified problem and market. This isn’t news here. I’ve been preaching this stuff for a while — all the way back to my Party of Four model.
If you don’t have that excitement going yet around a focused, crystal clear vision, get one going. Foster not only creativity and innovation and market attention, but also quality in your products and what you’re putting out the door.
New People
There’s a lot of excitement when someone new joins a company.
For me, much of that comes from gauging the success of our products and associated halo to that point (docs, marcom, etc…). If someone fresh can figure out what it is we do, and what our products do based on our standard messaging and documentation, we must be on the right path.
The other element associated with this is, how should things be changed to make them more clear? What would have prevented the new hire from being confused? How can the materials and explanations be presented in a clearer way the next time round?
Chances are, if a new employee can’t figure out your products, your prospects and clients are having a hard time understanding them as well. Leverage the new resource to determine what can be improved and go forward from there.
Overarching Ties
For those of you that are in multi-product environments, chances are you are working with more than 1 product manager. I want to get some thoughts down about effective methods to do this.
Now, to me, the most effective organizational structure is to have a Director of Product Management who then has a team of PM’s reporting to him or her. There may be some other groups that report in as well, but that’s for a different post.
There could be a scenario where you have a director, a VP above them, and disparate PM’s across the org. Now, as a PM you need to recognize that you must a) build indirect power and b) know how and when to use it. So, even if your are in a situation where you are a director with 1 associate PM and two other team members reporting to you, you still have responsibility to execute on the role of director.
I’ll leave out VP-level stuff for now, because it’s out of scope to get into things like managing a PM budget and stuff like that. Again, this isn’t hard folks. It’s easy if you think about it enough, employ common sense, and have a good team supporting one another in the company. But again, outside of scope for now.
So, as a director, you will have a team. PM’s should be good and focused on making sure they can be effective managers (because that’s just effective management, which has nothing to do with PM skills), and still be good PM’s. Directors also have the added layer of determining synergies across an entire line, or multiple lines, of products.
The key here, like all effective management, is delegation. You don’t need to get involved in gathering market data for the products the PM’s reporting to you are working with. That’s one example that would be bad. You REALLY don’t want to start telling them how to construct their roadmap. This is especially true if you have older, more experience PM’s working for you. I’m super touchy about my roadmap, and trust a certain group of people to provide input. This is because I OWN it. It’s mine. I’m responsible. I need to track it, modify it based on my hard-earned research, and flag higher-ups down when I know we’re not going to make a release or we’re going to slip a date.
You are asking for trouble if you start meddling, and telling other PM’s how to manage their product. Funny though, eh? This is just effective delegation. The task is, “manage this product” / “lay out a plan to manage this product, then execute.” Sure, you will want to review key deliverables and understand them — but that’s FAR different from saying, “here’s how to create a roadmap — do 1, 2, 3.”
One of the *key* director-ship responsibilities is identifying cross-product relationships. How can other product teams help other product teams? How can 1 product be more successful in the market if it were to work with another? As a PM director, you are in the spot to recognize this stuff, because it’s all feeding into you. If you are drowning in work, you haven’t delegated OR you need to hire additional help. If you are in a startup, there’s probably no budget to do that, so keep it kicked into high gear.
This all ties into milestone reporting, which I talked about in some other posts a while back. Sit down with your PM’s and identify milestones, and manage to those. You don’t need to be Jack Welch, or have 30 years in business to know how to do that. Communicate, walk over to their desks, discuss things, listen, hold team meetings, leverage one-on-one’s, etc… it’s just effective management. And those concepts take time to refine, but not understand or execute.
Also, you are at the higher-leve of air traffic control. You need to help your team leverage others in the organization if they have to. Typically, PM’s will make do themselves just fine. They should be personable, knowledgeable, and driven enough to get in there and get their hands dirty. However, monitor and ensure that if they need help communicating with Sales, get it to them. AND, if Sales isn’t getting the communication they require about a product, make sure they get it. Air. Traffic. Control.
Most of all, live it, love it, breathe it. I’m up late working and thinking about this stuff because of three fundamental things: a) I love product management. It’s a true passion. b) I love the products I work with. c) I have zero patience to restrain my ambition. I’m getting better at understanding it, but that doesn’t mean it’s hindered me from going 1,000 miles a minute.
I don’t know if any of this made sense — much if it I just wanted to write through as it helps me learn. Maybe Jeff will create a post on “If you want to be a BAD director of product mgmt, do all of the product management for your team of product managers,” or something. One thing’s for sure — it would be way more helpful than my ramblings here, I’m sure.
