Free or Almost Free Software to Run Your Business

It is a challenge these days to start a small business and get it up and running. This article provides information and links to vendors who provide free or almost free cloud based software.

Many vendors are using a pricing model where they provide software free or almost free for small teams. The hope is that the firms and teams will grow and need to add seats to the subscription. Larger teams typically pay more per seat than small teams do but as they grow the extra cost can be justified. Most of these vendors also have a free trial period.

The focus of this software is professional services and consulting type firms but much of the software discussed here will be useful to other firms. My belief is that this software is so inexpensive there is no reason or excuse not to use it.

I have used or am using each of the solutions mentioned in this analysis so I have real world experience with the software.

Type	Description	Vendor	Cost
CRM	If you manage or sell to any type of customer, Customer Relationship Management (CRM) software is useful. You manage leads, convert them to opportunities and manage accounts and contacts. Everything is in one place.	Zoho CRM	Free – Leads, Accounts and Contacts for 3 users. Provides basic sales services. $12 / User / Month – adds forecasting, document storage and dashboards. Indented for small business. $20 / User / Month – adds workflow, email integration and role based security. $35 / User / Month – adds territories, advanced workflow and call centers. Price Details
Web Site	Every firm needs a website. There are many solutions for this. Squarespace is the best I have seen and is the product I use.	Squarespace	Prices are for annual billing $8 / Month – 20 pages, 500gb bandwidth, 2 GB storage, 2 Contributors $16 / Month – Unlimited $24 / Month – adds eCommerce Price Details
Wiki	It is common to have a need for documentation and collaboration. A wiki is a great solution for this. The best wiki I have seen is Confluence by Atlaassian. Pricing is per groups of users. A license seat is not required to view content.	Atlassian Confluence	$10 / Month – 10 Users $50 / Month – 15 Users $100 / Month – 25 Users $200 / Month – 50 Users $300 / Month – 100 Users $500 / Month – 500 Users $1000 / Month – 2000 Users Price Details
Task and Project Management	Jira is a task and issue management tool. You may manage tasks, defects and workflow for many business needs and process.	Atlassian Jira	$10 / Month – 10 Users $50 / Month – 15 Users $100 / Month – 25 Users $200 / Month – 50 Users $300 / Month – 100 Users $500 / Month – 500 Users $1000 / Month – 2000 Users Price Details
Agile Delivery	Jira Agile is an add-on for Jira. It is a full featured agile tool that supports Scrum and Kanban. It requires Jira.	Atlassian Jira Agile	$10 / Month – 10 Users $50 / Month – 15 Users $100 / Month – 25 Users $200 / Month – 50 Users $300 / Month – 100 Users $500 / Month – 500 Users $1000 / Month – 2000 Users Price Details
Kanban	Kanban is a great way to manage workflow and work Items. I use this to manage my open items is in very easy manner. See my blog Personal Kanban.	Lean Kit	Prices are for annual billing Free – 10 users and 3 Kanban Boards. $15 / Month – unlimite3d boards, unlimited users, Taskboards. $19 / Month - Unlimited Users, Unlimited Boards, Role-based Security, Advanced Metrics, Advanced Taskboards, Portfolio Dashboard Pricing Details

For 90 Seconds You Have Little Control - After That it is up to You !

I learned something very interesting this week at my therapist. She told me that scientific studies have found that when a person is exposed to negative emotional situations like anger, surprise or stress it takes 90 seconds for it to pass through your system. During this time, you have very little control.  This is a physical fact, like gravity.

Our mothers told us to count to 10 when we get angry before we do or say anything. Turns out, we should count to 90. Even though our mother was off by a few seconds, the idea was the same, hang tight for a while before you do anything.

How does this relate to Agile process and servant leadership?

We all have encountered situations that invoke negative emotional feelings. With this knowledge under our belt, we know to wait a bit before we begin to formulate a response and then act. After this 90 seconds passes, we do have control but we have to wait.

Let the 90 seconds pass, then figure out what to do. After the 90 seconds, it is up to you!

Read More

How to Control Your Emotions in Any Situation

Exploring Three Agile Principles - Design Excellence

This article explores three of the Agile Manifesto Principles that I have categorized as Design Excellence.

If we hope to maximize an agile approach we need to design and build excellent software solutions. These principles emphasize these points and allow us to accommodate change. Design excellence is not a once-and-done thing. Like most of agile it is a journey that requires vigilance and attention to changing events.

Continuous attention to technical excellence and good design enhances agility

We need to pay close attention to technical excellence and design as our product evolves. There is a balance between “Building the Right Thing” and “Building the Thing Right”.

We must also be wary of delivering fragile systems. If we make a few changes and our application falls apart like a house of cards we are not in a good place.

Extreme Programming and to some degree Scrum recommend Test Driven Development and automated builds as a way to avoid fragile solutions.

When we have a set of proper automated unit tests that are included in some sort of automated build, we see problems every time the build runs. The higher our code coverage is and the closer we get to continuous integration the better our solution will be. It is all about balance.

Over time, our solution will accumulate technical debt. As we weigh the tradeoffs between building it right and building the right thing, this is bound to happen. It is best to only include a few technical debt features in sprints when they are required so each sprint is delivering business value.

Simplicity--the art of maximizing the amount of work not done--is essential
Agile is all about doing the right amount of something at any given time and no more. We should author user stories with the detail necessary to get the job done and no more. We should build what we know we need now. We should not build some huge framework we think we may need someday.

It is critical to have a complete and thorough understanding of the software frameworks we use. Code is evil and we can eliminate quite a bit if we have a good understanding of our chosen frameworks.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage
This principle will scare teams who are used to waterfall projects. It first glance, it seems crazy to welcome change late in the development process.

First, we must be successful at implementing the first two principles in this section. If this is not happening, welcoming change is impossible.

Late in development means late in the release of the complete product. Scrum delivers features in short sprints. We do not welcome changes in a sprint that has already begun. Because we are delivering features in short cycles, change is part of the whole process.

In scrum, the change is directed by the Product Owner. It is up to the Product Owner to understand what the competitive advantage is for the features in the backlog.

Learn More

·         Agile Product Ownership in a Nutshell

·         Coaching Agile Teams

Agile Estimating and Planning 

An Agile Perspective Why Bother

I thought I would step back a bit for this blog post and revisit the reason why we are even doing this. Why completely change the way we deliver software?  So, in this article, we will discuss some of the aspects that make Agile successful and introduce some important ideas that are at the heart of the Agile methodology.

First, it is essential to understand that Agile, as with any methodology, is not a silver bullet.  There are plenty of examples where Agile failed.  While the essence of Agile is straightforward, the challenges lie in understanding the business need(s), sticking to the principals you believe in, being patient, and focusing on transparency, communication and accountability.

Agile Manifesto

In 2001, a group of software experts got together at a ski lodge in Utah and developed the Agile Manifesto. This group identified a short set of values that helps guide much of the agile movement.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

They believed that while there is value in the items on the right, the focus should be on the bold faced items on the left.  Agile has gotten a bad rap for a misinterpretation of these values. I hope to help set the record straight as I explore Agile software delivery.

One of the primary pillars of Agile is to do the right amount of something, and no more.  This varies greatly based on the circumstances of a given project.  A start-up with a small budget and a short time to market will require much less formal process and documentation than a larger organization implementing a product regulated by the FDA.  Each of these projects will benefit from using the principals of Agile.

Individuals and Interactions

Many projects using sophisticated tools and processes have failed.  Much of the Agile process was designed to be implemented using 3x5 cards and a white board.  In fact, many Agile professionals prefer this approach.  By meeting regularly with the Product Owner and developing the features they want delivered in the priority they specify, we will be on a path for success.  These features are maintained in a prioritized list called the Product Backlog.  The Product Backlog is then broken down into 2-4 week Sprints.  I will talk about Sprints in more detail below in the Working Software section.

During a Sprint a daily standup team meeting is conducted every day.  The meeting is time limited to 15 minutes and focuses on reporting progress on the features included in the current Sprint.  Each team member reports what they did yesterday, what they have planned for today, and any impediments they face in completing their work on time.

The trick, as with much of Agile, is knowing the proper level of detail for your given project.

 Working Software

Agile believes that working software is the primary measure of progress and that the project owner (usually the business owner) will learn more through a set of short delivery cycles called Sprints.  Sprints are typically two to four weeks in duration and deliver the Features the Product Owner has identified.

Features are identified in a way for them to be self-contained and small enough to be completed in a single Sprint and to be Potentially Shippable.  This means that each feature is coded, reviewed, tested and deploy-able at the end of each Sprint.

This is one of the most powerful aspects of Agile.  It is very common for developers to start working on one thing, get sidetracked, and begin working on something else that is cool.  Using Agile, the team completes the features the Product Owner wants 100% in each Sprint.

Customer Collaboration & Responding to Change

Many projects that have very elaborate and long specifications, detailed contracts and project plans have failed  Experience has shown that it is virtually impossible to spend weeks or months developing long specifications and deliver what the business needs.  I was once told, "You delivered exactly what I asked for but, that is not what I need."  Even if it were possible to develop a perfect specification, it is likely that the business needs have changed since the time the requirements were gathered.

As we progress Sprint by Sprint, the Product Owner learns things they need just by seeing the product evolve.  Often we discover features late in the game that were never even considered early in the project.  As long as the new features add quantifiable business value, this is a good thing.  If we discover a set of features we never imagined and it saves our company more than it costs, we are happy.

Sometimes we actually stop development before we complete the product.  During Release Planning we carefully review the Product Backlog and deliver the high value features first.  We all know that most people typically only use a small percentage of the features in a given product.  Microsoft Word is a good example of this.

By following the rule of doing only the right amount of something and no more, we can often save money by delivering only a portion of what we originally intended.  Of course it is up to the Product Owner to make that call.

The Agile Manifesto and the simple elegant ideas it professes are the most important change to how we deliver software that I have seen in my decades of experience in this field.  I will never deliver software any other way!