I decided to pick up this book after the PDF was recommended to me by my boss and president of the company. I’ve always heard of 37Signals and their slew of online products (I even use some of them today). And of course in the development world who hasn’t heard of Ruby on Rails, created by David Heinemeier Hansson, who is a partner at 37Signals. This book was written by them after their experience in the IT startup world and after successfully developing some really cool web applications.

Overall I like the way this short book takes a lot of agile and lean concepts and applies them in the real life of a startup company. It’s even written in an almost point form sort of way, giving you little “lessons learnt”, “how we did it”, and “what we think of that topic” in very short 1 to 3 page sections. Although the content is very quick and to the point, there’s definitely a lot reference to background information alluding to why they think or do things a certain way. From industry cases like that of Steve Jobs to references from the Pragmatic Programmer you can really see the depth of understanding that these guys have for the values and principles which also stem from lean and agile frameworks. This book really shows a reality that can be achieved using the efficiencies brought on by adopting agile and lean values and principles.

Here’s a list of points that stuck out to me while reading this book:

“Scratching your own itch” – Open source developers find it easy to build solid high priority features because they are their own users and will build it when they need it. When you solve your own problem you create a tool that you’re passionate about.

“Constraints force creativity… and drive innovation” – Limiting your resources makes you deal with the most important things first and helps get your product out the door quicker. It also helps you get feedback on your product sooner. Work with what you have.

“Allow emergence” – Simple rules can lead to interesting complex behavior, cultivate an environment built around simple rules and allow for emergent behavior.

“The devils in the details” – Details reveal themselves as you use what you’re building. You’ll know which potholes to pave over because you’ll keep hitting them. Don’t waste time on problems you don’t have yet. Pay attention to the details when they matter.

“Avoid preferences” – Preferences and user options create more code, tests, maintenance, computational complexity, complex usability etc. You make the decision so your users don’t have to on the defaults. Make the best guess and move on.

“Be an executioner” – Ideas are just a multiplier, they are worth nothing unless executed. Execution is worth millions.

“Alone time” – People need uninterrupted time to get work done. Set aside half a work day where interruptions are  This one is a hard one because it’s so hard in our open workspace; interruptions come easy from both inside the team and outside.

“Innovation comes from saying no”  – Make each feature work hard to be implemented. Listen to your users but don’t act hastily. Say no to all but the crucial features. You’ll know what they are don’t worry.

“Can you handle it?” – Build products and offer services you can manage. It’s easy to make promises, but much harder to keep them.

“Promote through education” – Education is a soft promotional technique. Share your knowledge with the community and at the same time promote your product or create a positive buzz with your users. People you educate will become your evangelists.

“Beware of the bloat monster” – Resist bloat. Just because the application is older and more mature doesn’t mean it needs to get more complicated. And new doesn’t always mean improved. You don’t need to up-sell by constantly adding more features, you just need to provide ongoing value.

Definitely a short reading to share with your team! So, I am passing this one on now.

Last week we had a visit from our Angel Investor, Greg Olsen, of GHO Ventures based out of Princeton, New Jersey. He helped eCompliance get off it’s feet 2 years ago. He brings with him an astronomical (pun intended) amount of experience and wisdom that really differentiates us from the other startups in our field. It’s exciting to know that we have support from an accomplished entrepreneur with a wealth of business experience to motivate us along the way.

Our entire team met with him for a few hours and mainly talked about his experience as the third private citizen to go into space. For guy with so many credentials and accomplishments, he’s really down to earth! Truly inspiring.

We’re looking for passionate and talented Agile .NET Developers! Here’s the details:

eCompliance Management Solutions Inc.
eCompliance Management Solutions Inc. (eCompliance.ca) is the leading provider of Occupational Health & Safety (OHS) Management solutions in Canada. eCompliance.ca is a privately held company with its head office based in Calgary, Alberta, Canada. eCompliance.ca focuses on making use of the latest technological advancements to build practical and cost effective solutions for its customers and is the preferred technology partner of Canadian organizations in OHS by providing efficient and effective practical solutions to measure, manage and mitigate Health & Safety Risks in the quest for ‘Zero Incidents’.

The Candidate

• You are looking for an exciting and rewarding career using the latest tools and technologies.
• You are highly motivated and passionate about developing software that impresses your colleagues as well as the customers you are building it for.
• You are a software craftsman who wants to make a difference both in the software industry and the domain in which you work.
• You believe that the ALT.NET movement will change the development industry and want to be a part of it!

Skills and Qualifications
Must Have

• Post secondary degree in Computer Science or similar technical training.
• 3+ years developing applications using C# and .NET Framework.
• 3+ years experience building large scale web applications using the latest technologies.
• 2+ years experience with the latest Microsoft technologies as well as open source projects/tools that integrate well with an Agile development environment.
• Good communication and team skills.

Highly Desirable

• 2+ years experience with Agile Development practices and working in an agile team using XP and Scrum.
• 2+ years experience with test-driven development (TDD), object oriented design (OOD), domain driven design (DDD), and design patterns
• 2+ years experience building windows desktop applications or .NET Smart Clients is an asset.

Additional Perks

• Comprehensive health benefits package
• Company Stock Option Plan after 1 year of employment
• Flexible team work schedule
• Training opportunities and monthly book allowances

Bottom Line
This is an opportunity to work in a fun and collaborative environment where a ton of learning and contribution to the development community is supported. If you are or want to be a top-notch .NET developer then this is the place for you!

Please submit your resumes to careers at ecompliance .ca  attention Luu Duong (let me know that you saw this on my blog). Candidates must be Canadian citizens or permanent residents living in Calgary area.

For more information ‘About Us’ please visit www.ecompliance.ca

Ha ha, this is hilarious! It might not make much sense to people outside of software development but it’s just as funny if you only get the gist of it. I like the part where he mentions the bagels and lunches!

www.youtube.com/watch?v=l1wKO3rID9g

Thanks for the link Joel.

What’s 80-20 rule?

Also known as the Pareto Principle, the law of the vital few, and the principle of factor sparsity, states that, for many events, roughly 80% of the effects (output) come from 20% of the causes (input). In the early 1900’s it was observed by an Italian economist Vilfredo Pareto, that there was an unequal distribution of wealth in his country where 80% of the land was owned by only 20% of the population. While originally pertaining to economics, this phenomena was observed by other professionals in their own areas of expertise.  In business for example, 80% of your sales come from 20% of your clients. In the software domain, many experts note that if you develop 20% of the highest priority features, you’ll satisfy 80% of the business needs. Moving on…

What’s The Standish Group’s statistics on software usage?

Jim Johnson, Chairman of Standish Group, reported at the Third International Conference on Extreme Programming (XP2002) that in typical software systems 64% of features are never or rarely used in reality. This was largely apparent in systems where up-front plan and design were done before business ROI was considered or even knowable. What’s more interesting is that from a positive point of view, 20% of these features are used always or often used!

Merging the two to get the highest return on investment for the business!

So, it should follow that if we can prioritize our requirements (stories) and work on the most important 20% of our backlog (list of epic stories), then we could ultimately satisfy 80% of the business needs. At the same time; once this initial 20% of the features are in production, it will also be used by the business predominantly (always or often). The most important part of doing this effectively is finding that initial 20% of the requirements that return 80% of the clients satisfaction. An valuable Product Owner will be able to prioritize and understand that not every feature is high priority. I believe that the more you understand your business, the easier it is to arrange your priorities. That’s why an effective PO is the foundation of delivering valuable business features.

In Practice:

I’ve witnessed the 80-20 rule apply itself over and over again in our industry and also in my position. Software products developed where an equal amount of effort was put into building low priority features as it was to build the high priority features. At the end of the day, the return on investment was inherently lower on those features which customers rarely or never used or were unimportant. Effort is lost or wasted, which could have been allocated to more important features or features that that will be used more often. If you’re working on a project with unlimited budget then this could be OK, but I’ve yet to see one in real life (nor do I ever expect to).

This is not to say that any feature that is not used often or always is unimportant. Sometimes a feature that is used rarely is important to the business; in that case the priority would be high and likely moved up the priority list. But more often than not, if a feature is used often or always, it is likely to be a higher priority feature versus features that are used rarely or never (obviously). The better the Product Owner, the more fine grain each priority will be.

My humble advice:

If given adequate time on a project, module, or epic story, by working on the highest priorities first, as soon as you reach the most important 20% anything after that is bonus. Continue working on the time-boxed iteration or release plan, delivering beyond the initial prioritized 20% if you can (reach 55%), but remember that your effort-to-results ratio will diminish dramatically the further you go to fulfill 100% of the features. You could move on after the initial 20% to another important module, or work until the time-boxed iteration (fixed amount of money) runs out. A good idea after building the initial priorities is to stop and get feedback. Feedback is a time for the business to learn and for the development team to adjust if necessary. I can almost guarantee that the business will ask for something else that they originally didn’t plan to or have other opportunities come up that change priorities for what is important now.

Focus on the 20% that matters:

It’s not to say that the other parts of the software are not important, but that you’ll get more return for your efforts if you focus on the most important 20%. Here’s an example of how this works:

By working on the highest priority features first, and releasing early the customer has an opportunity to learn from the market (2 pre-releases occur before the project release date). Also the business has a chance to realign it’s next priority needs if necessary. The highest prioritized features are delivered earlier in the project, usually before the project is over or the money runs out. These features are the ones that will be used always or often by the business. An added bonus is that the company can actually start making money (earlier than expected “$” shown on the diagram) during these initial releases. As a consequence the software is bringing income into the project allowing it to partially fund itself. I’ve witnessed many projects partially funding itself first hand so this is not a hypothetical situation. If time/money does run out before the entire product backlog is complete then you’re still in a good position because you’ve already met at least 80% (if not more) of the business needs. In the example diagram above, we’ve delivered over 55% of the features. What’s remaining in terms of features are never used (according to the Standish Groups report on software usage). I wouldn’t go so far as to totally ignore the remaining features, but I would agree that they are far less appealing and less rewarding to work on than the initial 55%.

Prioritize and focus on what matters the most, you’ll see more benefits emerge with less effort. Ask yourself the question “What are the priorities and are we working on the ones that we value the most“. You’ll see it applies to many other aspects of life, not only the software business!

Thanks to everyone who attended the 2008 December Calgary Agile Methods User Group (CAMUG) meeting yesterday. We received a lot of questions during the presentation and good feedback after the presentation. Some people asked for a copy of the powerpoint slides, here it is. The slides don’t tell you too much about the actual content of the presentation because most of it was elaborated by the presenter, but it should give you a good idea of the points. Here is the presentation synopsis:

Under the Agile software development umbrella there are many principles, processes, methodologies, and practices that fit this style of development. Many companies are relentlessly seeking and implementing ways to continually improve how they design, develop and deliver software. We believe and have found in practice that the Agile way of software development enables, supports and drives this continuous quest for efficiency and improvement. One of the primary goals of Agile software development is to satisfy customer needs through early and continuous delivery of valuable software. We find that most of the business value comes from creating an environment where a shorter feedback loop allows our team to be more proactive and adapt quickly as and when necessary. In this presentation we will share and walk you through a typical sprint/iteration at eCompliance.ca and highlight to where we have shortened the feedback loop and increased efficiency and feedback quality.

See Mo’s blog for pictures of the audience.

Presentation at a glance:

If you’re interested in knowing about how Toyota became the world’s most profitable car manufacturer then this book is for you!

For more than 50 years Toyota has applied and refined it’s lean manufacturing principals, also called TPS or the Toyota Production System. Without going into the details of this book (for now) here are some Japanese terms I thought would be very suitable for agile developers and the agile community at large.

Kanban – Card or ticket or sign board. Used to signal to the previous step when its part needs to be replenished. Kanban is a signaling system to trigger action. This creates a “pull” system

Heijunka – Level out the work load. A production scheduling and load leveling tool. Distribute kanban cards in an efficient manner.

Muda – Waste or non-value-add work. Eliminate waste or non-value-add is a top lean philosophy and is said to be the focus of most lean efforts.

Muri – Overburden or pushing beyond limits. Overburdening machines causes breakdowns and defects and pushing a person beyond their natural limits causes safety and quality problems.

Mura – Unevenness. Muda will be a result of Mura. Unevenness results from an irregular production schedule or fluctuating production volumes, indicating internal problems. In lean manufacturing you need to balance production volumes.

Jidoka– Built-in quality. Also referred to as “autonomation”, equipment endowed with human intelligence to stop itself when it has problems. Used as a quality control system to build a culture of stopping to fix problems and getting quality right the first time.

Andon  – Light signals or cords that could be pulled for help. Used to stop or warn the production line in a specific section or work center.

Kaizen – Continuous improvement. The process of making incremental improvements, no matter how small, to add value. Defines Toyota’s basic approach to doing business.

Genchi Gembutsu – Go to the source to thoroughly understand the situation.

Nemawashi – Literally translates to “going around the roots” or closely translated as “laying the groundwork”. Discussions between many people giving input and helps everyone to be in agreement when a decision or change is made.

Hansei – Reflection, become a learning organization through relentless reflection. Hansei go hand in hand with kaizen, without reflection you cannot have continuous improvement.

Hoshin Kanri – Policy deployment. Directing and motivating organizational process by cascading objectives from the top of the company down to the work group level.

Sensei – One who provides mentoring, teacher who has mastered the subject.

There’re probably some more Japanese terms in this book that I missed but these ones stood out to me the most. I see many resemblances to Agile Software Development thinking, processes, methodologies, etc. in the terms above. Can you do the agile translation of the of these Japanese words/phrases?

Like Firefox 3.0? Need a quick and easy-to-use prototyping tool? Just download this add-on called The Pencil Project http://www.evolus.vn/Pencil/ for Firefox 3 and sketch away! I wanted a tool that is lightweight and unobtrusive that allows me to quickly sketch my prototypes without the need for visual studio or a similar developer tool. This add-on to Firefox was just that! I was able to get good looking interfaces within minutes of downloading the tool. It’s free, only 400 KB and it’s platform independent. If you (like me) find that other tools out there are too complicated or do too much for your simple prototyping needs then try this one!

I thought this would be useful “swag” for any teams out there starting Agile estimating techniques or any teams who want to improve at estimating development tasks.  I’m not going into the details of how it’s done, you can read for yourself http://www.planningpoker.com/detail.html. I first read about planning poker in Mike Cohen’s book Agile Estimating and Planning. You can also get actual planning poker cards from his company’s web site http://www.mountaingoatsoftware.com/products/planning-poker-cards, what a great idea!

Back when our team was learning Agile estimating I had these documents made to help us play planning poker. I thought these would be useful to anyone in the learning phase or wants some tools that can help with the process. So here it is, FREE planning poker cards that you can take to your favorite print shop and get printed (download the attached PDF’s).

Planning Poker Playing Cards pg01_front – Planning Poker Page 1 Front

Planning Poker Playing Cards pg01_back – Planning Poker Page 1 Back

Planning Poker Playing Cards pg02_front – Planning Poker Page 2 Front

Planning Poker Playing Cards pg02_back – Planning Poker Page 2 Back

Then I took this one step further and made use of our company’s business cards which needed to be reprinted anyways! Instead of just getting new business cards printed, why not take this opportunity to make planning poker cards out of them? Dual purpose Agile business cards! The front of the cards have the generic company branding as well as the individual contact information. The back of the cards have our division brand (ThirdAngle) and a unique number used for estimating. It’s also a good conversation starter when you give out your business cards :-).

Next time you see the team you’ll have to ask for each of us for our business cards so you can have the set.

Here’s a good 5 minute video from www.outsystems.com on the time-value of Agile Software Development titled “Why does Agile Software Development pay?”…

In my opinion, at the point where traditional software development makes it’s first release versus where Agile is at that time (many releases in), I think the Agile value is much higher than the video suggests because of the empirical feedback the end-users have put in along the way and the ability to change quickly based on real-time prioritized business needs. It’s a powerful visual representation of Agile Software Development that businesses wishing to build software, either in-house or using a vendor, should really look into. For businesses that are currently building software, can you ask yourself these questions?

• Are you able to use and go into production with your software at consistent intervals (weekly ,bi-weekly, or at most monthly)?
• If you do get software at consistent intervals, are you recommended to give feedback without it costing you more money?
• Is working software that meets business needs in a timely manner more important than contract negotiation?
• Are changes in priority and/or features embraced by the development team?
• Does software development respond to your business changes in a real time manner? The time it takes for your business ideas to be turned into revenue generating software is weeks not months or years?
• Does communication occur daily between the business and the development team, can it, is it face to face?

If you can answer “yes” to all of these then that’s great, if not then wouldn’t you want to? At least give it a try with an experienced Agile shop to see if your business can achieve a much higher return on investment and client satisfaction.