o brave new world: Agile Development

Agile or Fragile?

Fri, 03 Aug 2007 23:02:37 GMT

Last week, I had the opportunity to speak to a local group of folks who are into software product management, an organization called the Product Management Consortium. My interest in this group was sparked last year when I attended the UW Extension program on software product management, several of the instructors for which ran or were on the board for the PMC. I'm not yet a full-fledged member, mostly because I don't yet want to drop the required chunk of change for the membership fee, but so far my experience from attending three meetings is that it is very useful forum for those interested in expanding their awareness and opportunities in the burgeoning local software development scene.

The general topic of the meeting was "advanced agile product management," with Bryan Stallings of Solutions IQ leading things off with his low-key but abundantly experienced perspective on some of the more nettlesome questions that product managers invariably face when they undertake an agile project. Deb Rakow, a recent hire at Microsoft brought over from VeriSign, followed with a talk on overcoming both individual and organizational resistance to adopting Scrum. I was invited to share my experience with agile methodologies in my tenure as a product manager for the MSCOM Communities Team (which has been absorbed by the MSDN & TechNet organization), most recently on the Tagspace project.

Feeling Fr/agile

After hearing both Bryan and Deb give their spiels, I admit I was a little unsure whether what I had to say to the group would at all be useful or compelling. Bryan's contribution made it clear to me that our experiences with XP and Scrum were anything but pure in their implementation; he was also the acknowledged expert in the room whose impressive and lengthy list of accomplishments in Agile might make anyone feel just a little bit insecure. What's more, Deb seemed to steal some of my thunder on the difficulties of agile adoption and the importance of communication and tenacious, cajoling team-building.

But what could I do? There I was in front of this group of knowledgeable and experienced individuals, and I sure as hell didn't want to look like a total ass.... So I did the only thing I could do: I started flapping my arms frantically and ran screaming from the room, which caused no small measure of discomfiture among those in attendance.

Stand and Deliver

Ok, in reality it didn't go quite like that. In fact, I gathered my thoughts and simply told my story, sharing the good, the bad, and the ugly of my experience over the past few years--the successes, failures, ambivalent outcomes, lessons learned and what wisdom I might've gleaned along the way.

More specifically, I talked about team structure, roles and responsibilities, using the classic team model of the Microsoft Solutions Framework as a starting point (Microsoft Solutions Framework, "MSF Team Model v 3.1"):

As you can see from this graphic, the classic Microsoft view divides the world of product development between a business focus and a technology focus, the product manager leading the way in the former regard, and the program manager in the latter. I understand that in the broader industry, where roles might not be quite as specialized, the program management and product management aspects are covered more often than not by one person, the "product manager." I thought this was an important point to make because my audience was comprised of folks from many different companies who may not have been familiar with the way Microsoft slices and dices its product management roles and responsibilities among multiple contributors.

I then drew a comparison with how agile teams can be imagined, using a diagram I found on a blog post by Levent Gurses on "Distributed Agile Development":

The important point here was the emphasis on the customer as central to all roles in the scheme, with project managers and business analysts being the primary leaders and requirements conduits for the development team (represented in red above).

Neither model, to my mind, really described well the structure of our team, so I conceived an adapted team model, which effectively combined what I felt to be the most important elements of the previous two:

One of the main points I wanted to make here was that whatever the formal titles may be, whoever works as the customer proxy (or "on-site customer") needs to work very closely with the product owner--the two are essentially respective sides of the same coin, and projects can rise or fall on the strength (or weakness) of their relationship.

I then went into process and artifacts, providing some examples of the kinds of documents I used to help get the project focused and on track so development could begin and we could all be clear, by virtue of our shared understanding and goals, of exactly what we were trying to accomplish. I also made sure to let my audience know that our efforts overall did not result in unalloyed successes, but the fundamental point was that we learned a lot, worked very well as a team, delivered good business value, and even--dare I say?--had fun doing it.

Keepin' It Real, Yo

And that, my friends, was enough, as it turned out. I definitely got the sense that the audience appreciated what I had to say, the story I had to tell, even if it wasn't the perfect project executed perfectly, a perfect exemplar of agile product management. I did my best just to be myself and, um, "keep it real," as the cool kids are wont to say. Several people complimented me on my presentation, and I could tell that the reason it succeeded was because I had managed to communicate in such a way that they could relate to it personally, based on their own varied experiences, feelings and fears. The lesson I draw from this is that, even if we can sometimes feel insecure about our experiences and accomplishments in this brave new world of ours, sometimes it's really the journey that matters, and it's the sharing of it with others that makes all the difference.

- dave

On Agile Development and the Role of Product Management

Thu, 16 Nov 2006 03:30:25 GMT

Something a bit off the main topic these days (viz, Tagspace), but still relevant...

Our team is building tagging and social bookmarking services for MSCOM and related Web sites (and possibly beyond, depending on a myriad of factors), and we're using agile development methods to do so. I've sometimes struggled with determining what my proper role should be in the process, as the ostensible business requirements guy, the dude who helps think up and define what needs to be developed, helps see the development project through as the business owner, and is responsible for the so-called "marketing spin." You see, I'm the product manager, a title that means many things to many people, but what I've come to understand to be fundamentally synonymous with the expression of customer need. I can't say I'm always mindful of this, and certainly not always successful at it, but I am increasingly aware of its importance as a guiding principle: be the voice of the customer.

(Silly aside: I'm reminded for some odd reason of Ty Webb's exchange with Danny Noonan in Caddy Shack:

Ty: Just be the ball...be the ball...be the ball. You're not being the ball, Danny.

Danny: It's kinda hard when you keep talking like that.

Ty: Ok, sorry. I'm not talking now...I've stopped talking...Not talking. Just be the ball.)

Now, agile definitely has its proponents and it certainly has its skeptics and detractors. Regardless of what anyone says, our experience has been telling us that it just makes sense, especially for small teams engaged in Web development. We simply don't have time for lengthy, process-encumbered development efforts--or at least, we've seen where they've gotten us, and it hasn't been particularly pretty or compelling. So let me get back to my original question: what is the role of the product manager in agile? If you believe Scott Bellware, "marketing parasites"--among whom we might reasonably count product managers--should have no role and merely get in the way of the creative and truly innovative work of the virtuous developer. They just do silly, useless things like pigeon-hole users into two-dimensional caricatures known as "personas." They lack the requisite skills to be taken seriously, and have no legitimate claim to "steer our very own ship." This is, I think, a representative passage from Scott's diatribe:

As we align ourselves around Microsoft's persona's [sic] we ultimately conform to these shallow and less-capable visions of being a developer. As we debate the merits of Genital Mort Warts versus Elvis Pelvis Lesions, we're loosing [sic] our ability to see beyond the constraints and limits of these identities. In the end, we're only making marketing parasites [sic] lives easier at the expense of the progress of our own chosen field of endeavor. We're letting folks who don't have the guts, brains, and perseverance to make it as software professionals steer our very own ship. Neither Mort, nor Elvis, nor Einstein [sic] can be a multifaceted developer - they simply aren't design [sic] to be that way. These personas were crafted to limit software developers so that people with fewer intellectual expectations of themselves could better dictate to us how they would like us to behave in absence of their own ability to stretch, to reach, and to adapt to the extent to which we are called to do every darned day of our lives.
Software development isn't too hard. Software development is fun. It's a challenge - of that there's no doubt. And sometimes it's a tiger that won't be tamed. But software is never fun when it's undertaken on a traditional team in a traditional organization that is hell-bent on sticking to antiquated value systems and practice systems that have rarely produced the kinds of successful products and people that practice systems like Extreme Programming produce. Software development with Mort, Elvis, and Einstein is utter torture. After working with agile teams and agile projects, working with a group of Microsoft persona clones would simply be something that I don't think I would ever want to inflict upon myself again.

Well, as you can imagine, while I agree that agile (or Extreme Programming) has its merits, I think Scott is much, much too dismissive of the role of us marketing types--again, among whom we must count product managers--in successful development efforts. And I don't think I'm just being defensive and trying to self-servingly justify my existence to my technical betters. It is not in the creation and use of personas that we fail to do our job or fail to add value. Personas are just one tool among many intended to help development teams understand for whom they are developing product. They should only be taken seriously in so far as they add some clarity, help in decision-making, or spark ideas and discussion. A dogmatic use of any tool is surely not healthy. Rather, our failure as product managers lies in our forgetting that we must use all the tools we have at our disposal to define solid requirements in a collaborative and iterative undertaking, serve as the liaison between customers/stakeholders and the development team, maintain communications with all involved parties through the life of the project, and above all--you guessed it--be the voice of the customer.

- dave