I recently read a very good blog on the Triangle Offense and Scrum, and it inspired me to write a basketball related item as well.  I used to play a lot of basketball growing up. I played point guard, and was in charge of running the offence, calling out the appropriate play for each time down the court. In order to get the best possible opportunity to score, a lot of things have to go right…1) the proper play for the defence presented must be called; 2) the play has to be communicated properly (from the bench, to the PG, to the rest of the players on the floor at that time) so that everyone understands what to do; 3) Execution…the team needs to execute on the play that was called; and 4) sometimes you need a bit of luck.

Now I’ve been a Product Manager for software companies for a number of years, and developing/releasing a product is very similar  to the basketball scenario above.

1)    Proper play must be called …From a software perspective, this is knowing about the market you play in, as well as the competition you are playing against. You need to understand the weaknesses (or opportunities) so that you can take advantage of it, and get that easy score.

2)    Play has to be communicated properly… Communication is crucial in the development/release of a software product, especially if your team is Agile. Everyone needs to understand the big picture, and this knowledge has to be consistent. What would happen if the PM, chief architect, and VP of Sales all had a completely different understanding of the deliverables for the upcoming release? I’m sure you can figure it out… Also, over-communicate (if that’s even possible). More on communication in an upcoming blog…

3)    Execution… Each team member is a part of that team because they possess a key talent. So whether it is the lead developer, or the QA lead, or the UI designer, they all need to execute ‘the play’ to the best of their ability. If this occurs, then you’re team has given itself a great opportunity to succeed.

4)    Luck… Okay, so back in the day, I’ve hit the odd jumper as a result of a broken play, and while I would like to attribute that to pure skill (ha ha), my reasonable/practical side realizes that there was probably a fair bit (okay, a lot!) of luck involved. Software teams sometimes need a little bit of luck as well because things don’t always go as expected. So when you hear that developer say, I stumbled across this, while fixing that… consider Lady Luck to be on your side.  

I was originally going to write about how software development and golf were related, but other than the amount of cursing I do in both, I couldn’t come up with 3 other good similarities. If you can come up with a few more, then I’d love to hear them. For that matter, I would like to hear how you relate software development to other sports as well…Cricket anyone??

Over the last few weeks, we’ve been working on cleaning up our product backlog, and the one thing that I always find to be the most challenging is the prioritization. I’ve worked on a number of different products over the years, with a number of different teams, and have used a number of different methods to prioritize a backlog, and I thought I would take a few minutes to share them with you now.

1)    Feature rating – This is the method where Excel really shines, because you get to create a cool matrix consisting of your features and a number of categories that are important (such as revenue generation, importance to existing customers, competitive differentiation, and so on). You then put a rating (usually 1-5, with 5 being the most important) in each of these categories for each feature…add them up, and the feature with the highest total becomes “most important feature #1”. Now, you can make this even more interesting by giving a weight to each category, to show which categories are the most important. So, for example if revenue generation is the most important factor in your company, then give that category a .5. Give your remaining categories a weighting, ensuring that the total weighting equals 1. This method can give very clear results, but can tend to be biased (I really like this feature, so I will give it a higher rating than this feature I don’t really like…)

2)    Baseline prioritization – In this method you pick a feature that you feel should be in a release, then compare all other features to this one. If any of the features are more important than that initial feature, then they become a higher priority, and conversely, those that are less important become a lower priority. I have found this method okay, but difficult to get a really good prioritized list…yes you get a list of the most important features, but not really fully prioritized list saying feature 1 is the most important, followed by feature 2, etc.

3)    Gut feel – This method is certainly the least scientific of the bunch, but it still relies on instinct, and can work well if you have a really good grasp of the market and your customer base. In the times I’ve done this, I’ve also tried to take the concepts of method 1 above, and apply that… so for example, Feature A has 6 different customers crying for this, will definitely generate more revenue, and further differentiates our product from our competition…sounds like our top feature for this release! This is the method that I find the most effective because you get to apply a number of concepts from a number of different methods.

There are a number of other methods out there that I haven’t used, so I would be interested to hear what experiences you have had with them, or with the ones I’ve listed above.

There was a recent blog on whether or not you should have bugs (that were not found during the most recent iteration) added to your product backlog, or kept in a separate bug backlog. Here at Klocwork we have a defect database that is closely monitored by Support, dev, PM, and so on…suffice it to say, it has a high degree of visibility within the organization and will probably never go away. Being an Agile company we also have a product backlog that is reviewed daily and prioritized regularly. Every two weeks (coinciding with our iteration planning) PM and Support get together to discuss the highest priority bugs, and to determine if those bugs should/need to be added to the backlog for the next iteration. A key piece to this process is using tools to maintain this backlog. The backlog tool, which also has an integration with our defect tracking system provides a tight correlation between the two, and a level of automation that makes life a little easier for everyone. Once added, these bugs are prioritized just as we do with all of the other features (stories) we have in the backlog. We also have weekly status meetings where the most recent bugs are discussed, once again to ensure they receive the proper attention.

Since we are in the bug-finding business, we take bugs very seriously and adding them to our backlog (and as a part of our iteration planning) helps ensure we address them quickly.

There was a recent blog on the top 10 good reasons for Scrum, so in the spirit of equality, I thought I would do one on the top 10 reasons not to go Scrum. Now, before I get started, let it be known that I am a huge fan of Scrum and agile (so much in fact that I am certified as a Product Owner), but there are definitely situations where it just might not make sense to go that route.

1. Your development team is geographically dispersed. In my opinion, this is the main reason why it would not make a lot of sense to go Scrum. Scrum (and agile) are all about communication, and even though technology has made it easier to communicate across the globe, a winky-face over MSN cannot get the same message across as a face to face conversation.

2. If you are currently meeting deadlines and release dates. I’m a big believer in the adage, if it ain’t broke, don’t fix it. Why would you want to mess up something that is working for you? Short answer…you don’t…

3. You cannot get complete buy-in or 100% commitment from management, development, PM, etc. If a PM cannot actively attend meetings, or management wants to make rash decisions outside of the team, then it just will not work…don’t even bother trying.

4. If people need complete clarity about the solution before even starting the project. The very nature of agile/scrum lends itself to this just not happening.

5. You have a fixed deadline, with a fixed set of requirements. This happens all the time…perhaps you have specific functionality planned for a big event, or a big customer. If this is the case, then it might make sense to manage this using more traditional project management methods.

While the original blog that inspired this had 10 reasons, my time this iteration is up, so I will only provide 5. If you have others you’d like to share, feel free to leave a comment.

When I first started at Klocwork, I didn’t really know a lot about source code analysis. I understood the basic concept of how it finds bugs in software, but that is was essentially it. Sure I knew about Memory leaks, but I truly believed that they were only found a day or two before the GA date…at least, that was when our testing team always found them.

In one of my teams prior to joining Klocwork, we used Scrum. We were hard core, with daily 15 minute scrums, retrospective meetings, sprint planning sessions, defining “done”, secret handshakes, the whole 9 yards. We also broke our features down into small tasks, and those tasks were written on cue cards and then stuck to a big wall for all to see. What a great way to see the progress of a sprint. We had green cards for development tasks, blue cards for testing, yellow cards for documentation, and red cards for bugs. I remember how after 2 or 3 days into a sprint, the red cards would start showing up, and developers would then start addressing them. Since one of our team ‘rules’ was each person could only have a single task checked out at one time, our developers had to check-in the green card they were working on in order to tackle a red card. By the end of a sprint there were always a number of red cards left, which by definition, needed to be addressed first in the next sprint. I’m sure you can imagine the enthusiasm of heading into the next sprint knowing there was a wall of red cards to address first.

Anyways, my first few weeks at Klocwork consisted of talking with a lot of people; customers, prospects, etc. These people knew source code analysis, but they only knew the traditional way of source code analysis (SCA), and not the new generation of SCA where developers check their code before they check-in their code. I remember thinking I must be missing something…why is this so hard for these people to understand?  Source code analysis turns a lot of those red cards into green cards.  For more info on how SCA and agile can work together, check out this webinar I recently did…

Ever had to work on a “special” project and really didn’t know where to start? A team I worked with was faced with this not too long ago…we had to put together a complete business plan for our products. This complete business plan included understanding everything about your business, and I mean everything…average deal size, average discount per deal, regional breakdown of deals, deals with multiple products included, SWOT, positioning, and so on. There was a ton of information we needed to pull together in a relatively short time, and we really didn’t know the best approach to take to address this. Having been working on a scrum team for about 8 months, I suggested we try to tackle this using some of the principles of scrum. So we proceeded to break down the effort into a series of tasks, and then prioritized these tasks, thus creating our backlog. Tasks would be assigned, and daily meetings were then used to report our progress on them. If a new task popped up, which usually happened, we added that to our prioritized backlog, and continued on. Everyone on the team knew exactly what had been completed, what was being worked on, and what was still outstanding.

There are probably a number of other approaches you could take to deal with this type of project, but I thought applying some Agile principles worked out very well. Anyone have any other applications of Agile, not related to software development they can share?

I’m starting to get my feet wet with Twitter…I’ll admit I was (perhaps still am) a little sceptical, but it did inspire me to write this short blog on something that, for those who have been practising Agile for some time, tend to take for granted…the stand-ups. While this topic has probably been blogged to death, here is my perspective on what the stand-up (or scrum) should be.

First and foremost, keep it short…if it goes longer than 15 minutes, then something is wrong. Have a clock in the room so that you start on time, and finish within that 15 minute window. Be militant about this. In that 15 minutes (or less) each developer should have the opportunity to discuss what they have finished (since the last meeting), what is next on their plate, and if they have any roadblocks preventing them from doing anything. This meeting is not the time for Bob to ask Mary what the different options need to be in the new UI they’re designing…break that out into a separate meeting.

A couple of other minor things about stand-ups…as a product manager, I always tried to be at as many as possible to lend support for the team, and to just be available for them. Secondly, feel free to make the stand-ups open to anyone in the company…but as observers only…for those of you familiar with the chicken and pig story, remember, these observers are chickens and as such, should stay silent in this meeting.

There is certainly more that could be discussed about stand-ups , but my clock is showing me that I’m out of time…
Technorati Tags: agile, scrum, stand up, product management

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.

I thought for today’s topic I would delve into something that many organizations have to confront when moving to Agile that is, how to structure their iterations. Many organizations will find that iterations work better if development, testing, and documentation are all done within the same iteration period. Other organizations prefer to offset the testing and/or documentation ½ or a full iteration period after the development is complete. Having lived through both, I thought it might be useful to briefly list the good, and not so good of iteration offsetting.

First the good:

* Testing and documentation are not given features that have been completed at 5 pm on the last day of an iteration, and then expected to have their work done by the following Monday.
* Many dev features are totally complete prior to documentation or testing, so the doc and test teams can start their iteration running, rather than crawling.
* The documentation team is provided with some insight as to the “big picture” of a feature (and not just a standalone story in an iteration) and can plan their documentation for those features with that information in mind. This could help reduce rework on their part.

Now the not so good:

* Development can be drawn back into a previous iteration for bug fixes.
* If demo’ing iterations is a standard part of your process, it could contain a number of bugs since it hasn’t been through any formal testing yet.
* Communication is fragmented…some teams talking about Iteration x, some about Iteration x-1.
* Possible confusion, and more difficult to manage since there are multiple iterations on the go.

Is this list complete? Probably not…but hopefully it will give you something to think about if you’re either starting Agile development, or are struggling with your current implementation. For many projects, the negatives outweigh the positives on this list. As a Product Manager, I’ve seen that many situations where offsets as described above just don’t work. If that’s the case for you, then one possible approach that I’ve seen work is to implement a code freeze 3 days prior to the end of an iteration, and the developers then become part of the testing team.

My personal preference having worked in both scenarios, is to have dev, test, and documentation all occur within the same iteration. Now, my reason is somewhat selfish…when an iteration finishes, I want to show what we’ve done with some level of comfort of the quality and then be able to close the book on that iteration at that point. If that is the approach you prefer, here is a good blog about how to set up such an iteration. Of course, as with most things Agile, there’s never a “right” answer; it’s about finding the right iteration methodology that works for your team’s culture and project goals.

I like statistics. I always have and always will. I remember manually keeping track of all the statistics for my favourite baseball team by going through the box scores everyday in the newspaper (obviously this was well before the internet came around).  I would manually calculate batting average, slugging percentage, strikeouts per 9  innings and so on. Yup, I lived a pretty exciting youth! Anyways, that love for statistics continued with me, but now I like to know things like how much snow has fallen overnight, and how much more we can expect over the next few days, or what my accuracy is in Guitar Hero, so I can try to beat my 9 year old daughter on Black Sabbath’s Paranoid.

Why am I telling you about all this? Well, I was recently participating in a tour of 5 different cities in Scandinavia over a 5 day period, delivering a presentation on how Source Code Analysis fits in Agile development environments. Fun topic really, but one of the points I raised in each of the 5 sessions I did was that more and more organizations using Waterfall development techniques are moving to Agile.

After being asked by one of the participants to provide an example of this, I brought up some things that I have personally seen over the past couple of years. So I rattled off how in a previous “life” I worked in a mid-sized company where my team was the first Agile team formed. Over the course of 6 months I saw a few more teams show up, and that continued on (and still does from what I hear). I then pointed to the Agile 2008 Conference which, from what I understand, grew in both attendees and vendors, from the previous year, and the expectation is for that trend to continue for 2009. Finally, in talking to people at different trade events (non Agile), training sessions, or customers, etc. I just keep hearing that more and more teams are adopting Agile. But I didn’t have any concrete numbers that illustrated that Agile really was becoming widely adopted.

So I spent a couple hours later that evening (after the usual trains, planes, trains, taxis routine) to try and find some real statistics on this. Well, to continue with the baseball metaphors, I probably hit a solid double. I was able to find a lot of good statistics on typical length of iterations, whether an organization has adopted one or more Agile “techniques”, average Agile team size, and so on, but I just could not find a definitive statistic saying that Agile now is being done in x% of development organizations worldwide. What is Agile’s worldwide market share? That is all I really want. Then I’ll know without question or hesitation that Agile is the approach of choice for software development.

So, from everything I’m *hearing*, I have to believe that Agile is really becoming more and more prevalent. It would just be nice to open up the paper, and see in black and white if Agile is a singles hitter or a home run hitter.

BTW, here are a few other statistics I gathered while on my trip:
•    93% of plane/train food is bad regardless of the carrier.
•    I forgot my hotel room number 60% of the time while over there.