I just couldn’t resist using the classic spaghetti Western as the title for this instalment of my Going Agile series because it a) it was an awesome movie, and b) it truly sums up that 1^st iteration of ours. My last post was all about the 1^st iteration planning meeting, and how it was such an exciting and productive time for our team. We came out of that meeting a little weary, but extremely motivated to get to work. We were also just a tad naive.

The next 2 weeks were a roller coaster as we cut our teeth with Scrum. First the good:

• Communication: the interaction amongst the team members was definitely improved. If someone needed an answer to something, they immediately sought out help. The team realized that if they didn’t get timely answers, tasks wouldn’t get done. They really didn’t want to say those dreaded 2 words, “nothing finished”, in the daily scrum meeting.
• Meetings: The daily Scrum meetings were kept short and  sweet as everyone said what tasks they had finished, what they were working on, and if there were any roadblocks in the way. If something required further discussion, a break out meeting with the appropriate people was held.
• Energy: This was a high performing team to begin with, but there was now a newfound energy and buzz. This was a fun team to be around!

As the title suggests, there certainly was some bad in that first iteration.

• Testing and documentation: These were the 2 areas that struggled the most in the first iteration (and the next couple as well). They felt that their work was too heavily back loaded, that is, they would receive their stuff too late in the iteration to either test or document properly. Many of the stories were not totally Done because they were either not tested properly or documented with the time they were given.
• Defects and bugs: Because testing happened so late in the iteration, many of the bugs they found could not be addressed in that iteration. These bugs would have to be carried over to the next iteration, meaning the number of new stories would have to be reduced.

Now for the ugly.

• After just a day or so into the iteration, a plethora of unplanned tasks starting showing up on the Scrum board for many of the stories. These stories now had many new hours of tasks added to them, and we fell behind very quickly. This leads into the next ugly…
• The Burndown chart: Talk about a misnomer! We started to affectionately call our chart the burn-up chart, because there was very little down direction going on with it. Our chart would have looked great at a sales meeting, but in our Scrum meeting, not so much.

So as you can see our 1^st iteration had its share of warts, and in fact, the next couple did as well. But we didn’t get frustrated. We learned from our mistakes and changed/added things based on those mistakes. The Retrospective meetings were incredibly useful because they made us all take a hard, honest look at what went well, and what didn’t. The next, and last entry in my Going Agile series will look at the Retrospective meeting.

Now that the New Year is upon us, I thought it would be a good time to add another chapter to my Going Agile series. My last entry left off at the point where we had prepared our backlog, created team rules and defined “Done”. Now we were ready for our first Iteration Planning meeting.

In our “team room” we had all the essentials in place for this meeting: stacks of color-coded cards (for capturing the various to do’s, or tasks), pens and highlighters, our Scrum board (with pins) to stick our tasks onto, and a keg of Red Bull, because we had no clue as to how long this meeting was going to last.

Everyone was anxious to get started, so I (as the Product Owner) introduced the first story that we were going to work on. I gave as much detail as I could about what the feature was, what it should do, the benefits the users would get from it, and so on. The team asked questions, and I answered them as best I could.

Once I was done talking, the most remarkable thing happened:  the team started to write down the various tasks required to complete the story. It started off quietly, as all the team members started writing on their cards, and to be honest, I was a little concerned that this was going to be the way this meeting would go. (Where’s the Red Bull, because this is shaping up to be a long and painful session.) But then the questions started coming from all sides –developers asking other developers questions, testers asking developers questions, documentation asking developers questions, developers asking testers questions, follow up questions, and so on. I vividly remember watching this, and the frenetic pace at which things were happening. I had worked with this team for a few years (doing Waterfall development), but I had never seen this level and intensity of communication and cooperation from the team. Once all the questions were asked (and answered), the task cards were collected and posted to our Scrum board. On to the next story, rinse and repeat…

The meeting lasted another few hours as we worked our way down the backlog and watched the new tasks go up on the Scrum board. By the end of the meeting, we were ready to start our Iteration. As the team left the room, they each moved a task from the “To Do” column to the ‘In Progress’ column, and the Iteration was underway.

It was truly incredible to see this team come together and work as a team so quickly, and to see how motivated they were to move to this new way of developing software. The next chapter in this series will look at the trials and tribulations of that first iteration.

Tom Johnson’s recent blog article (a must-read, involving ice picks and eyeballs) reminded me of one reason we want to move Klocwork’s user communication content to a Wiki: we want to talk to our users. Crazy idea! Let the doc team talk directly to the users? What stupid things might those literary types say?

I confess that it’s taken me a long time to get to this point. Johnson says tech writers are often subject to figurative lobotomies, like “don’t bother the subject matter experts; they’re busy”, “don’t use your own voice on video tutorials”, and “don’t talk to your users”.

So we’re crippled from the start, and some of us take years to discover that we produce the most helpful help when we become more of an investigative journalist, actively engaged with those who create and test the tools and those who use them. (It seems fitting at this point to mention that one of the writers on the team is a former newspaper girl who recently created a video tutorial for Klocwork Solo, using her own voice.)

I’m also inspired by Sarah Maddox, who regularly blogs and tweets on tech writing, especially on using Wikis for user documentation, chatting with customers about the tools she documents, blurring the line between documentation and product management.

So, we’re going to expose our soft underbellies. We want to hear from our users directly, rather than the usual generic rants transmitted through our product managers (a recent example: “Need better documentation”). When you rant to us, we’re going to want details. How exactly is the help not helpful? What page made you throw up your hands and curse us? And telling us what works can be just as effective as telling us what doesn’t.

There I have said it. As a marketer, I am disappointed in my peers in their attempts to get their message in the hands of their audience.  Over the past couple of weeks, I have attended a few webinars from other organizations selling software development tools that were truly atrocious.  So here are a few pointers for my few marketers on webinars:

• Stop talking down to the audience – treating your prospects as unintelligent blobs is not the way to connect or be heard. These people are senior developers and engineering managers of Fortune 500 companies not kids coming out of school. Yes, there is a need to bring everyone up to speed and get them to the same knowledge level but that can be done in the first few minutes; don’t do it throughout the presentation.

• Slideware hell:
  • Have a congruent theme – pick one major point and each and every slide in the rest of the presentation should support that theme. Don’t over complicate it.
  • Don’t read your slides – I can read too;  I don’t need you to do that.  I need you to tell me why your point is important so that I pay attention and expand into examples and facts that prove your point.
  • Don’t cram every possible benefit on to a slide – this goes with the previous point – at most 4 bullet points – highlight what is important and use your oratory skills to expand
  • Balance your text with meaningful visuals – I am going to scan your slide in 10 seconds and then turn my brain off. So to keep my attention, give me a visual containing information not just data and each slide needs to tell me something new

• Don’t try to garner respect, earn it. Don’t tell me in your previous life you shared their pain; it comes off as false. Product Managers, you especially  have been the ones at fault for this one.  I am not attending to hear about you. I have a problem; I am looking for a solution.

• Respect their time: webinars are a great vehicle to communicate with an audience but don’t overdo it.  I personally don’t sign up to webinars that last an hour.  I am not willing to give you that much of my time and I would hazard to say neither does most of the potential audience.  Check your abandonment or engagement rates.

Enough ranting and berating of my fellow marketers but together we have to get better at what we do.

!(social media)

I will probably get flack for this but I am going to exclude web developers from this discussion of adoption rates about social media in the developer sphere.

Having moved through the technical streams over to the dark side of marketing, I have learned to challenge assumptions and here is one of mine I think needs testing.   In this new age of “social media” and interaction, I have yet to see the leadership in the developer community make any substantive use of it.   I would love to be proved wrong on this one.   Social media, in my view, is really just branding what people have been doing for years: using peers to converse and exchange information on topics and facilitating interaction, even for niche subjects like the merits of static code analysis in mission critical applications.

The adoption rate of the “formal” social media is what I am interested in.  The blogs, twitters, facebook, digg,  etc, you know the brands that I mean.  I have been looking for weeks to find any concrete data on adoption rate and have been hard pressed to find much.

• Technorati  (March 2008- State of the Blogosphere) – 26.4 million blogs vs less than a handful about software development.
• Google Trends indicates that the ratio of software blogging to the main stream is 258 times less.
• Digg has just over 18583 diggs for software development versus over 3 million for marketing
• Twitter volumes are similar 13 900 versus 1.4 million

Why hasn’t the paradigm shift happen here like in other industries?  Online marketers are eating up social networking on Himalayan scale, so why not in development circles.  Speculating on human behaviour is not without its caveats but are technical people so different from say marketers or bus dev people?  In a nut shell – yes.

It’s  not to say developers aren’t social, in many ways the development community has been the leading the wave [Yes, that is an intentional pun for the upcoming Google Wave]. I would argue that software development has been social for well over a decade as best exemplified by the open source movement.  Some of the greatest advancements in software design and productivity have come from major collaborative efforts such as the  LAMP stack, OpenOffice and Android just to name a tiny few and open source has lead to the rise and fall or changed of direction in many a company – see Apple adopting the Linux kernel etc.

My conclusion on all this: the software development community has voted with their feet.  They do not need yet another vehicle to find their voice when they already use mechanisms (open source collaboration, forums, community websites etc) that do the job quite nicely thank you very much.

So if you disagree, take up the sword and prove otherwise.

PS. And yes I get the irony of writing a social media piece about software development on a blog. :-)

The hype has been on for years and although the frustrations of continued dropped cell calls  haunts us all, the future has arrived in full swing….pardon the pun!!! I thought this article between “Mad Money Cramer” and MLB is a fantastic illustration of a dream unfolding before everyone’s eyes.

This month has been a time to reflect upon the historic moment 40 years ago of man’s first walk on the moon.  I am sure just about everyone can remember where they were when the first televised pictures captivated the world.  For the legions of people that made that historic event a reality, they undoubtedly felt they  were living on the bleeding edge of technology with as many known’s as unknowns. But for the rest of us, it was a completely controlled event.  One we marveled at but did not participate in. One we were all touched by, but could not touch.

Contrast that event to what is transpiring today. We are in the midst of an “explosion of the mobile Internet”, but it hasn’t arrive with a single defining moment.  It has crept up on us virally, gradually becoming more pervasive and entrenching itself in our daily lives.  Even trying to quantify the market potential is difficult to predict, as Cramer exemplifies  - “Until you see these applications, you don’t understand how this thing is going to take over the world. It’s the definition of why I value the Mobile Internet as the biggest investable trend I’ve ever seen.”

There was a time when many of us tech-maniacs would hear from our significant other “are you ever going to put that damn thing down”  referring to our iPhone or Blackberry.  Now I for one watch in stunned silence as my kids and significant other are constantly glued to either their iPhone or Blackberry.  What was once the exclusive domain of the workaholic, semi-obsessed information junkie,  has become the “always connected” device of…well everyone I know.  It is no longer a “work device”  it is “my device.”

The transformation was fairly seamless and uneventful except for one subtle difference….one by one we are all participating in this event…not just witnessing it. Experts in the varied  fields of human behavior must be licking their chops as this new era spreads across humanity like the rising sun across the horizon.

The world has changed and I sometimes wonder if we now have “a new world disorder.”  A world where snippets of information are all anyone has time or interest in, a world where one on one communication is not the norm, a world where if we are not connected we are not comfortable.

Somehow it all seemed more managed when it was a “work device” as opposed to “my device.”  Time will tell how far out in front the “explosive mobile internet” progress is over the process necessary to support it.

As a Product Manager, I’m a huge fan of Agile. Sure there are the obvious issues to contend with such as trying to nail down an exact date to release the product, or the fact that it doesn’t work real well with larger development teams, or that it can suffer the classic, “that’s not how we used to do things” syndrome. In my opinion, these all pale in comparison to the benefits that I, as a PM, get from Agile.

First, is there anything cooler than showing a totally awesome new feature to a customer and be in the position to gather their feedback (usually applause and cheers of joy…sometimes not so much…) right then and there…not after the release?  It is great to know that you are hitting the right notes so early on, and if not, then having the time to adjust. If you’re not able to demo to a customer liver, then take a few minutes and record a demo for each feature and post it somewhere they can retrieve it from. This is a great way to scale and while the feedback may not be immediate, it still comes in. Secondly, no more Requirements documents that are obsolete a week after delivery of them to development…again, requirements need to be well defined and communicated, but continuously revving a document gets old very quickly. Finally, I love the fact that people (whether internal or external) know stuff about the release. Try running Iteration planning meetings at the start of every iteration, and invite all relevant stakeholders. Here you can outline what is coming for that iteration, and for those unable to attend, post the decks for their review later. This is a great way to increase awareness and communication both within and outside of the team. Surprises are minimized (for those that paid attention), and if done right, these people have had their chances to provide feedback throughout the release cycle. No more Monday-morning quarterbacks telling you that you should have done this or that…

So, if you’re a Product Manager and you’re hearing rumors about your organization going Agile…jump on board, I think you’ll like it.