Lean Startups

Agile approaches are very much about adapting and using short increments when dealing with uncertainty. Starting a new company comes with a lot of uncertainty. Agile principles can help reducing risk and improving the odds of success.

Eric Ries is the inventor/initiator of the “Lean Startup” movement. His concept is to incrementally develop your customers and your business. By running experiments, some people also call them spikes, you learn a lot about the business idea you are working on. By using small increments you avoid spending months or years building a product or offering a service that in the end is fantastic but nobody is willing to spend money on. Eric Ries helps you de-risk your business idea.

A complementary technique is customer development a term coined by Steve Blank. While product development important (your product can also be a service) it is equally important to also develop your customer base. In his book “Four Steps to the Epiphany” he describes this process in details. His book is a work book, so be prepared that you will have to do homework.

Why am I mentioning these two? The work of both of them is based on agile principles. Therefore if you are considering to test one of your business idea then the work of these two authors should be part of your preparation. And both are not limited to new companies. If you are tasked to build that brand-new product in your company then you are basically running a start-up. The only difference is that you run it in the context of an existing company, which can be beneficial (e.g. financial backup) or a hindrance (e.g. bureaucracy).

Mass Customization

If you find yourself in a project where you need to deliver and maintain a large number of customized versions of an otherwise standard product you may want to consider designing your processes in support of mass customization.
There are a number of prerequisites that you’ll need to have in place. For one you need a base product that you want to customize. That base product needs a mechanism in place that allows customizing it. For example you could design it so it supports plug-ins.
Next you need a fully automated process for building the base product plus all plug-ins. Ideally you have a continuous integration solution and an extensive automated and virtualize test environment. The latter allows automatic instantiation of different target environments and testing of various product configurations in those environments.
One option for mass customization is then to create a custom package for each individual customer, e.g. by creating an installer containing the base product and plug-ins for just that customer. While the installer might be a good option for a shrink-wrapped product, continuous deployment in a hosted environment will typically benefit from a different approach. For example instead of packaging different installers, you might have a different deployment for each customer. Only the plug-ins for that particular customer would be included to be deployed in their environment.
You can drive this one step further, for example by providing a web site where your customers can select the base product and the plug-ins they want. If they are self-hosted they would receive the custom installer. If they are hosted their deployment in the hosting environment would be maintained accordingly. This web site could include integration with payments systems or with your internal accounting system, e.g. to check whether a maintenance payment was received.
Alternatively instead of having custom installers or custom deployments, the availability of plug-ins can also be controlled through the use of licensing in the deployed product. All plug-ins are installed but only the ones that were licensed are loaded and available.
Of course there are number of other factors that must be considered, e.g. how to design the process and the product so it can be upgraded without downtime. Once you have this in place, though, you will enjoy a scalable solution that allows mass customization.

Navigating Difficult Times

I chose the word "navigating" deliberately. The current economic climate is very difficult for many people and companies throughout the world. And chances are that you are affected in some shape or form as well.

It appears that no 'rule' that worked in the past applies to the current situation. Is that really true? I think it doesn't really matter. The important bit is that if you carefully choose an approach that lets you quickly respond to whatever is waiting for you around the next corner then you will be better off in all likelihood.

Some people and companies still try to come up with a grand plan for how to go forward. And as long as that plan is really more like a description of the direction and the principles to be used I think that is fine. But what good would it do to you if you would spend planning time right now on what you would be working on in 12 months time if all that matters is what you are going to do next month, three months from now, or six months from now!

Respond and adapt. Do both as quickly as needed (but not faster!). Instead of locking down your plans for the next 12 months use rolling plans (a planning tool, actually), e.g. for the next 3 months or for the next 6 months. Then update these plans on a regular basis, either monthly or triggered by new relevant information that warrants a revisit of your plans. If your plans cover 3 months they are much easier and faster to adapt to new insights than plans at the same level of detail that cover 12 months. Trying to update plans that cover a larger time frame tends to result in a lot of waste.

Navigating these difficult and uncertain times is definitely easier if you choose an approach that allows for much faster response and adaptation to the changing environment. At the same time you will be much better off once your markets start to improve again.

MindManager 8

I have written about MindManager before (here, here, here and here). A few months ago I finally took the step and tried out version 8. I never bothered installing version 7 let alone trying it out after I have received comments that other users had similar issues (in particular performance) in version 7 that I observed in versions 5 and 6.

Now here is the nice surprise: Finally the software is a useful tool from a performance perspective. And I don't have to switch off hardware acceleration.

And apparently some more work went into improving the tool. It has become easier to to selection the handles to modify the curves representing a relationship between two nodes. In previous versions it sometimes took selecting other elements, then selecting the relationship again to be able to hit the handle. It's not perfect yet but at least usable.

With regards to the performance I need to be more specific. The load time is now a little bit of an issue. I sometimes think for a moment whether I really want to close the program since starting takes quite some time. I'm not sure what it is doing, maybe counting each bit of my laptops memory? Once it's loaded working with maps is very smooth.

There are items in version 8, though, which would benefit from putting some more thoughts into them.

The Outlook addin doesn't seem to be up to it's job. After I installed it Outlook became very unstable. After I disabled the addin things went back to normal. So in the meantime I'm not using the Outlook addin. And quite frankly: I'm not missing it! What exactly were the benefits of the addin?

Another area worth considering is how call-outs can be placed in a map. Sometimes I wish I could place them further out on a map or close to the node that it is related to. However, if that node has many children and all are expanded the call-out has to be above or below all of them in terms of vertical position. That way the call-out ends up to be very far away. The layout algorithm should allow more freedom for call-outs.

So bottom line we are now looking at a product that has reached the maturity that as a leader you would expect from productivity tools. A few minor areas remain that MindJet should consider. But for now MindManager 8 is a very valuable piece of software and I use it on a daily basis.

Note: I'm not affiliated with MindJet or have any financial interest in the company or the product. The opinions expressed in this post are entirely my personal view and are not paid for.

Introducing new tools

As a leader you may find yourself in the situation of having introduced a new tool. And then maybe you observe that the team doesn't know how to use it. The reason might be that they haven't yet fully understood the underlying principles and so if they hit a road block they might not be able to adapt.

Resist to the temptation of then doing the work for them. It's not worth it and doesn't scale. Instead work with the team and demonstrate to them how the tools is supposed to be used. Then give them another try encouraging them to come back to you for more assistance if they get stuck.

For instance: Assume you have introduced a spreadsheet based tracker (for an example see the Agile Tracker) including a backlog and a burn down graph. One way of introducing this could be to identify a significant portion of the work that is very similar and of which the items can be counted. The resulting backlog may not contain all the full piece of work required. Hence you and your team don't know yet whether the work can be completed on time. Ask them to include every single piece of work that is required. Ask them to prioritize - or if necessary triage - all tasks. If they struggle how to do that, use a few examples to demonstrate the use of the tool (the tracker in this case), then ask them to try the rest by themselves.

I believe this works better than if as a leader you would be involved all way through. Be available when needed. Make sure it is understood that asking for assistance is not a sign of weakness but a sign of strength. Briefly discuss their experience so far. What went wrong? What worked? Then provide just enough to get them going again.

Two More Thoughts About Selecting Tools

In a previous post I shared a thought about selecting tools, in particular whether you should decided for a tool just because you happen to be a partner of the vendor.

Here are two more thoughts about selecting tools.

Driving Towards A Decision

The first one deals with ensuring that the decision making doesn't take forever. Sometimes teams discuss about tools for weeks or months without coming to a conclusion. As a result they don't have the tool. And as a consequence they don't enjoy the benefits.

For instance you are considering adding a particular type of test tool to your tool set. Of course there is the danger that you may select the wrong tool (I'll discuss below how to mitigate that risk). On the other hand even a tool that is not a perfect fit but at least does a perfect job is better than no tool at all. No testing tool is even worse than a testing tool that may be usable only for very specific test cases.

Therefore it is important to drive to a decision. And the best technique is time boxing. Give your time a time box and insist on a decision by a specific time. Only extend the time box if an excellent reason is given. That way as a leader you can steer the team towards a decision.

And if the the team can't come to a conclusion? Well, you can always use the threat to make the decision yourself....

Homeworks

While it is important to reach a conclusion you also want to make sure that the team makes a proper assessment of the different options. I usually expect that the major player are being looked at and compared. As a tool I recommend a decision making matrix by which the columns are the different products and the rows are the selection criteria.

To get the team started I describe to them how the tool works. Don't assume they already know. Make sure they do. Next I also tell them that I won't provide them with the full list of selection criteria but that I expect them to choose those as well before they start the assessment. I guess the management speak for that would be "empowerment".

Usually I make a small number of selection criteria mandatory. For tools these are:

• Ability to be launched from a command line
• Ability to deliver the result as an XML file (or other standard format)
• Price for chosen configuration, e.g. based on number of license required

The first two items are important from my perspective since a tool needs to be easy to integrate into automated processes. By using command line and standard-format based files (XML preferred) only little 'glue code' is required if at all.

Why the decision making matrix? First, you will notice that the team will then have a recipe for their assessment. They know what questions to ask and what to find out about the tool. Second, the team will gain an overview of the major players for each tool. Often team members have different backgrounds and experience with different tools. By working together the decision will become data-driven and facts-based as opposed to 'I like tool A more than tool B'. Also the team will have a basis on which they can have a meaningful discussion. The result is much more detailed and specific.

And finally, you will observe that all the sudden all major vendors are looked at and a better decision is made. You can take the outcome including the decision making matrix to create the business case that you may need for the purchasing process anyways. And even if such a business case is not required it still is an excellent exercise to go through some number crunching to determine by when a particular tool is fully paid off and what ROI it creates.

A Thought About Selecting Tools

Once you are an XYZ partner (replace XYZ with your favorite partner vendor) this means that you should be using all XYZ tools. After all you get them all cheap or even for free. So choosing them must be right!

Wrong! Check what the primary reason is why your company is in business. Is it being an XYZ partner? Or is it delivering good products and services to your customers? I bet that it is the latter.

And if you deliver good products and services to your customers using XYZ technologies or tools might be the right choice. But maybe it's not. If you believe you can choose only from XYZ's product list then chances are that you miss out on the best opportunities to improve what you do and how you work.

For example, XYZ may just have large monolithic applications that require training for users and specialists for configuring and maintaining it. And maybe those large applications that try to be everything to everyone become so flexible that all that flexibility makes it hard to change and quickly adapt your processes to your environment. Do you want your tools to support your processes? Or do you want your tools to dictate your processes?

Bottom line: Don't let you limit yourself by being an XYZ partner thinking that you can use only their tools!

Quality!

What is the important bit about quality?

Just calling for it doesn't do the job. You've got to put your money where your mouth is!

So when you ask for improving the quality it might pay also off to think about W. Edwards Deming's "Red Beads Experiment" (description for example here). Why is this relevant?

In essence the experiment describes how you limit the quality any process can achieve by not allowing the employees to improve the tools and processes to do their work. In fact allowing for continuously improving tools and processes is one of the most powerful mechanisms to improve quality. And as Deming points out, the decision to empower or prevent employees from doing this improvement comes from management. So, if you ask for quality improvements and at the same time deny your team tool or process improvements you shouldn't be surprised if the quality level doesn't go up at all or not as quickly as you'd like to.

Monitoring and Tracking Projects

Need a template for monitoring and tracking your project? Here you go. We have created a simplified version of the tool we are using in our projects, too. The spreadsheet is prefilled with a sample backlog for a hypothetical project. It assumes sprints of 1 week and a release cycle with 12 sprints.

The template includes graphs for the actual velocity and a burn down graph. If you have questions and/or suggestions for improving the template please use the contact details at the Agile Utilities web site.

Oh, and here is the most important link, the link to Agile Tracker. And of course this template is free.

Are We Using The Wrong Tools?

Frequently I'm asked why software development can't be faster, cheaper, etc. and actually today I found some information on the internet that really made me think whether we are using the proper tools.

"The new features of the ... development environment allows developers ... to ... automatically generating 100 percent of their applications."

(Source: Oracle Investor Relations)

Now I wonder why we have software engineers in the first place....

Cards Or Planning Tools?

In one of the newsgroups I monitor there was recently a discussion on Project Planning and Tracking Tools. I'd like to add another experience to this.

In a project for which I started coaching earlier last year, I introduced index cards for stories initially. People looked at it as something very "unprofessional". Paper and pen? How could that possibly work?

Well after a while the team decided that they wanted to introduce XPlanner. After yet a while some customers on the team decided that they were not exactly getting what they were asking for. As a consequence they started to put more details into the tool. Sometimes there were a lot of details even for how to lay out widgets on a screen and what colors to use. Screenshots of mock-ups were eventually added.

Yet another while later the team discovered that this didn't really help. Now the stories were very big and therefore hard to put into a short iteration. And the bigger they were the higher the likelyhood that they were underestimated. An extreme case was a story that was estimated at 47 units but which took 228 units in the end to implement. It actually consisted of a sequence of four stories.

It was clear to them that they had a problem. Now they have reverted back to using index cards. Writing or even drawing on an index card limits the amount of information you put on it. The team decided that the best and most important information on a card was the business value that the completed story tries to provide.

Having less details on the cards themselves has triggered more and better conversations or negotiations between the customer and the engineers. More options are discussed and it is much easier to move storie around. Estimation is better, and the geam gained more flexibility with regards to how to implement a story.

Bottom line: You might have an excellent justification to introduce a software based planning and tracking tool. But sometimes it is better to just go using simpler tools. If your team is co-located you certainly have more options, but even for distributed teams it is worthwhile to look for alternatives. Simple tools may lead to simpler and better solutions.