Friday, March 19, 2010

The Application of Pareto's Principle to the Adoption of Agile Practices - Part 1 of N

Starting this evening, I will be attending the Agile Coach Camp in Durham, NC. As the only registration fee for attending the ACC is to submit a position paper on a topic of interest to you, I submitted the following abstract.
The Application of Pareto's Principle to the Adoption of Agile Practices
If you believe in Pareto's Principle (otherwise known as the 80-20 Rule), then you believe that it can be applied literally everywhere. At its heart, Agile practices are about doing what works and ignoring the rest (at least until the time is right). In a world where people are constantly searching for silver bullets, getting distracted by zealot turf wars, and feeling the crunch of deadlines, novice adopters of Agile practices need to learn what out of"agile" is immediately important for their situation, and what they can safely ignore until a latter point in time.
So I figure why not put some more concrete thoughts together before the ACC starts. This post is the first of probably a couple posts on this topic, with probably at least one being a follow-up if my topic gets accepted as a discussion topic. Seeing how I average roughly 5 hits/month on this blog, it wouldn't hurt to get a little more traffic!

I also want to emphasize one important point to avoid having to defend a position that I'm not taking. This opinion of mine revolves around the adoption of agile practices. It in no way is an attempt to water down agile, as every individual practice discussed below certainly adds value and should be part of the full vision for any team attempting to go agile. This opinion simply revolves around the idea of getting the most bang for your buck up front so that you can get all of the nay-sayers on board the agile train sooner than later.

Review of the 80-20 Rule
The 80-20 Rule is typically explained as for any given "effort", the first 80% of the results you are looking for will be accomplished with only 20% of your time and energy, while the final 20% of the results will take 80% of your time and energy. When applying this to the adoption of agile practices in software development efforts, the gist is that only 20% of the ideas/topics will get you 80% of what you were looking for when you decided to start using agile practices.

Review of Agile topics
For the sake of discussion, I'm going to use part of James Shore's table of contents from his book The Art of Agile Development. The following is Part II - Practicing XP from his ToC, as these are the concrete practices that his book discusses:
5. Thinking (1. Pair Programming, 2. Energized Work, 3. Informative Workspace, 4. Root-Cause Analysis, 5. Retrospectives

6. Collaborating
(1. Trust, 2. Sit Together, 3. Real Customer Involvement, 4. Ubiquitous Language, 5. Stand-Up Meetings, 6. Coding Standards, 7. Iteration Demo, 8. Reporting)

7. Releasing
(1. "Done Done", 2. No Bugs, 3. Version Control, 4. Ten-Minute Build, 5. Continuous Integration, 6. Collective Code Ownership, 7. Documentation)

8. Planning
(1. Vision, 2. Release Planning, 3. The Planning Game, 4. Risk Management, 5. Iteration Planning, 6. Slack, 7. Stories, 8. Estimating)

9. Developing
(1. Incremental Requirements, 2. Customer Tests, 3. Test-Driven Development, 4. Refactoring, 5. Simple Design, 6. Incremental Design and Architecture, 7. Spike Solutions, 8. Performance Optimization, 9. Exploratory Testing)
The above chunk of his ToC represents a total of 37 practices across 5 concepts areas. As this opinion paper is not about paraphrasing James Shore's book, I will not make any attempt to describe any of the above practices any more than is necessary to make my points. If you are unfamiliar with any of the valuable practices that he describes, buy and read the book.

My 20% - Take 1
Seeing how James broke out the 37 practices into 5 concept areas, that makes it easy for me to make my first arbitrary application of the 80-20 Rule and grab Chapter 7 (Releasing) from above as the one concept area that you will get the biggest bang for your buck on. As software developers we get paid to produce working software. I've seen many a team over the past 15 years get caught up when releasing new versions of their software. Some developers spent days to weeks just trying to get the code to compile. Others had to "wing it" during the deployment of the code to a test server (the consummate "it worked on my machine" excuse). If you can't look at your current situation and proudly say we have the whole release process down pat and can consistently get new releases out with minimal effort, then start with this chapter.

My 20% - Take 2
Given the first application of the 80-20 Rule above to the 5 concept areas, this second application of the rule is going to be across the 37 practices (20% of 37 = 7.4 practices). My list of the 8 practices out of James Shore's 37 practices are:

#1 - Thinking - Root-Cause Analysis

James Shore's 99 words description:

When mistakes occur, blame your process, not people. Root-cause analysis helps. What allowed the mistake to happen? What will prevent them in the future? Assume people will continue to make mistakes and build fault-tolerance into your improvements.

One approach: ask "why" five times. Use it for every problem you encounter, from the trivial to the significant. You can apply some solutions yourself. Some will require team discussion, and others need coordination with the larger organization.

When mistakes become rare, avoid over-applying root-cause analysis. Balance the risk of error against the cost of more process overhead.

My take on it:
This practice is actually a twist on the 80-20 Rule in that it focuses you in on the issue that actually does need to be worked on rather than the issue that you either think needs to be worked on or worse case, the issue that you simply would like to work on.
#2 - Collaborating - Trust

James Shore's 99 words description:
For maximum productivity, team members must rely on each other for help. They must take joint responsibility for their work. Trust is essential. To improve trust, foster empathy. Learn about your teammates' joys and concerns. Sitting together helps, as does eating together. Preserve productive teams by keeping them together for multiple projects.

Organizational trust is also essential. Be energetic, deliver on your commitments, and be honest about problems. Show that you care about your stakeholders' goals. Promote your work through friendly openness. Always be honest about your achievements. Avoid the temptation to whitewash problems or misrepresent partially-done work.
My take on it:
In life as a whole a lack of trust leads to a constant downward spiral of every relationship. In agile, we are talking about teams, including both developers and customers, and therefore we are talking about relationships. Without trust, the process is going to fail.
#3 - Collaborating - Real Customer Involvement

James Shore's 99 words description:
To widen your perspective, involve real customers. The best approach depends on your market.

Personal development: you are the real customer. Congratulations. Go forth and write algorithms.

In-house custom development: turn your real customers into on-site customers.

Outsourced custom development: get real customers to be on-site customers. If you can't, stay in touch and meet face-to-face frequently.

Vertical-market and horizontal-market software: beware of giving one customer too much control. Appoint a product manager to understand customer needs. Create opportunities to solicit feedback. Examples: customer review board, beta releases, and user experience testing.
My take on it:
In my corner of the world, teams of "consultants" attack projects with little to no subject matter expertise but armed with years of experience in producing working software. This demands that customers are involved throughout the process, as only the customers have the subject matter expertise necessary for the project's success.
#4 - Releasing - "Done Done"

James Shore's 99 words description:
A story is only complete when on-site customers can use it as they intended. In addition to coding and testing, completed stories are designed, refactored, and integrated. The build script builds, installs, and migrates data for the story. Bugs have been identified and fixed (or formally accepted), and customers have reviewed the story and agree it's complete.

To achieve this result, make progress on everything each day. Use test-driven development to combine testing, coding, and design. Keep the build up to date and integrate continuously. Demonstrate progress to your customers and incorporate their feedback as you go.
My take on it:
Seeing how I called out Releasing as the single most important concept area, I'm going to go forward and proclaim that this particular practice is the single most important practice of all. Teams must be able to demonstrate progress daily and the sub-practices of test driven development and continuous integration are fundamental to enabling that.
#5 - Planning - Vision

James Shore's 99 words description:
Every project needs a single vision, and the product manager must unify, communicate, and promote that vision.

Distance between visionaries and the product manager increases error and waste. If you only have one visionary, the best approach is for him to be product manager. Alternatively, use the visionary's protogé.

Some projects have multiple visionaries. They need to combine their ideas into a unified vision. The product manager facilitates discussion and consensus.

Document the vision with what success is, why it's important, and how you know you've achieved it. Post it prominently and involve your visionaries in planning and demos.
My take on it:
Without a vision, a team can never confidently answer the question "is this topic important?" And without being able to answer that question, teams can get caught up in building software that they think is needed, without being able to justify it. That ultimately leads to lost productivity when they incorrectly answer that question.
#6 - Planning - Release Planning

James Shore's 99 words description:
Maximize your return on investment by:

1. working on one project at a time;
2. releasing early and often;
3. adapting your plans;
4. keeping your options open; and
5. planning at the last responsible moment.

Use timeboxing to control your schedule. Set the release date, then manage scope to meet that date. This forces important prioritization decisions and makes the endpoint clear.

Prioritized Minimum Marketable Features (MMFs) and stories form the body of your plan. Demonstrate your progress as you develop and use that feedback to revise your plan.

To minimize rework, develop the details of your requirements at the last responsible moment.
My take on it:
Some adopters of agile think that agile is all about "no documentation and no planning". They couldn't be more wrong, and thus why I'm including this practice. As James Shore points out, agile planning is about planning and adapting to changes.

This is in contrast to project managers of the past who created a project plan in MS Project at the beginning of the project and God help you if you as a developer created a situation where that project manager had to open MS Project after the project started to adjust the plan based on new information.

While I don't believe that there is anything particularly wrong with using MS Project, when using it in an agile environment the project manager maintaining the plan must update it weekly. If they don't do this, then they need to either throw out agile or throw out MS Project.
#7 - Developing - Test Driven Development (TDD)

James Shore's short description:
We produce well-designed, well-tested, and well-factored code in small, verifiable steps.
My take on it:
From a code construction point of view, if your team is not already using TDD, adopting TDD will raise the level of quality of the software that your teams are delivering. Simple as that.
#8 - Developing - Incremental Requirements

James Shore short description:
We define requirements in parallel with other work via living requirements documents and working incrementally.
My take on it:
Even in the best of the waterfall projects of days gone by that I worked on (and apparently even on the ones that I didn't), the up front requirements phase never produced a complete set of requirements. The agile practice of incremental requirements simply accepts that as a fact and creates a solution framework for continually dealing with it as the norm, rather than treating it as scope creep and denouncing it as something unexpected and bad.
Closing Thoughts
Hopefully this sparks some level of discussion for this weekend's Agile Coach Camp. If not oh well...

Wednesday, January 27, 2010

Apple iPad and Text Books

I'm probably not going to be the first one to mention this, but I want to go on record as early as possible that the single "killer app" for the newly released iPad is college text books.

I've been an iPhone 3GS owner since the day it was released and have loved every second of it. That is in stark contrast to the prior years of owning Palm and Windows Mobile phones, of which to say were terrible is in understatement. I've also been a huge iPod supporter for years now too, having recently bought my third one.

That said, I personally don't see any use for the new iPad. I currently use my iPhone for email and web surfing, and could see where using an iPad would be nicer, given its bigger screen. But I would never take the iPad anywhere other than the living room couch with me, as the form factor is simply too big (compared to the iPhone which nicely fits in my pants or jacket pocket). And since I can type on a regular keyboard at over 60 words per minute, I don't think that the iPad and its 10" screen is going to replace my regular desktop/laptop with its 24" screen anytime soon either.

But back to the college text book thing... if Apple were to be able to pull off selling college text books (and K-12 text books too) for use on this thing at say 25-50% the normal price of hard copy text books, the iPad would pay for itself in one or two semesters. And students get to stop carrying around the back breaking backpacks filled with the text books that they currently have too. And that's not even taking into account the added technological aspects of having ebooks that you can mark up as you please. Now THAT would lead to Apple selling millions upon millions of these things. Maybe that current stock price of $208 is low after all...

Friday, January 8, 2010

Review of NDepend


Patrick Smacchia, the creator of NDepend, offered me a free license for NDepend Pro if I took the time to review the product and write this review on my blog. While I have not used NDepend prior to doing this review, given the fact that I have been reading Patrick's blog for quite some time now, along with the fact that I'm a big fan of static code analysis (for the regular identification of problematic areas in your source code), I happily agreed to his offer.


The installation of NDepend is a simple unzip and xcopy to your desired location. Seriously as simple as it gets. Once it's there, fire up the VisualNDepend executable and point it at some .NET/C# assemblies you have.

I decided to run NDepend against a code base that had been handed down to me from a number of prior developers. While the customer is happy and the application has been running in a production environment for a couple of years now, the application is also a serious legacy code development situation, and a great sample project to see what NDepend has to offer for people in my shoes.

So after loading up the half dozen assemblies in the given application, NDepend made quick work of analyzing everything and producing a nice HTML report. It also shows the results in the Visual NDepend results browser, allowing you to quickly navigate around your code base.

Usage Scenarios
After immediately showing a peer of mine the tool what it does, I started rattling off to him the following list of scenarios that describe how I think NDepend can be useful to developers.

#1 - Newbie - Never used NDepend before and barely understands static analysis or any of the metrics used by NDepend.

In this scenario, much like in my code base above, NDepend will quickly point out problematic areas of your source code so that you can immediately start addressing those issues.

Now I'm sure that plenty of readers will immediately start screaming that the metrics aren't useful.

In response, I say that when you're reviewing a code base, and the documentation says that a Cyclomatic Complexity rating above 15 means that a method is complex, and above 30 is nearly impossible to comprehend, that if you're staring at a list of 20 methods with a rating above 30, including 5 with a rating above 40 and 1 with a rating above 80, you can't for a second argue with me that the tool isn't immediately useful in helping focus you in on the sections of your code base that you REALLY might want to stop and clean up. In other words, this is all about quickly focusing you in on the sections of your code base that just aren't good, no matter what your opinion is on the specific threshold for a particular metric.

#2 - Novice/Intermediate - You're familiar with the tool and the concepts and your code base is generally ok per the tool.

In this case, you're looking at integrating NDepend into your (hopefully pre-existing) continuous integration environment so as to ensure constant feedback to yourself and/or your team regarding the "health" of your code base. The value here is that NDepend comes with pre-existing plug-ins for NAnt, MSBuild, and CruiseControl.NET which means you can very quickly get NDepend integrated into your automated process.

#3 - Expert - You're already highly automated and compliant, but feel the itch for more.

In this case, NDepend really shines given the existence of CQL, it's own built in query language, that allows you to run queries against the metrics that it collected during the analysis phase. All of the functionality that #1 and #2 are leveraging is simply based on a set of pre-built CQL queries. But for the expert who is obsessed with perfection, automating their perfection seeking is even better. And being able to either tweak the pre-built queries, or better yet, build a series of custom queries is priceless.

It wouldn't be right to review something and not offer some advice. That is what I get paid for in my real job! Anyway, one big thing that jumped out at me that was annoying was that I quickly found myself lost in the UI. I think that this is due to the specific UI controls and the docking layout stuff that is used by NDepend to try and organize the eleven navigation and results windows. I actually got things so messed up that thankfully NDepend has a "Reset Views" menu item that puts things back to how they were when I first launched it. I also found that once I got the set of windows that I found useful (for scenario #1 above) in view and the rest hidden, things were much smoother.

I think that to help resolve this in general, it would be nice to have a set of additional pre-built views, as there are a couple of task specific ones that already exist, that fit more in line with the three usage scenarios above.

I'd list price as an issue here too, but more from the point of view that I think Microsoft should simply pay Patrick a chunk of change and integrate NDepend into Visual Studio. Now that we've finally got people on board with automated unit testing (hopefully you're already doing this), now's the time for fully automating and enforcing code quality metrics! Unfortunately, unless a developer already knows about and has respect for static analysis, they probably aren't going to hunt down and pay a couple hundred dollars for a tool like NDepend. And then you have teams such as the one I'm currently on that simply doesn't have the budget for ANY tools, so we aren't going to use it either.

So in the end, NDepend simply rocks! While I had issues with the UI, that's something that after 5-10 minutes of use you don't really even notice. The immediate impact that NDepend can have on a code base is priceless. Just think, all of those code reviews everyone says they should be doing but never have the time to do can now be automated, and team members are simply responsible for maintaining the code quality ratings of the code they write.

Thanks to Patrick for giving me the chance to review what turned out to be a great tool. Using NDepend coupled with ReSharper and FxCop, code bases simply have no excuse to end up in the mess that so many of them are today.