Friday, 17 January 2014

From Release-Testing to Continous Deployment

Agile Development Methodologies fundamentally changed the way we look at Software. Instead of making sure that everything was developed according to a well laid out plan over months and years to satisfy requirements that are just as old we now focus on Customer or Business Value.

 
And in order to create as much value as possible we need feedback, fast feedback. So this change in the way we develop software also brought change in the way we test it. One of the principles of Agile Development is getting feedback as early as possible which in turn means we need to showcase our product to stakeholders as soon as possible. Scrum for example aims at having potentially releasable code at the end of every iteration (Sprint).

To do this we also need shorter test-cycles, gone are the days were we developed a feature and then handed it over to test just to get back a list of issues (e.g. the new feature broke old functionality etc.). Automated testing allows us to cut down the time from finishing development of a feature to feedback about how well it works and whether it breaks old functionality. In this context there are three Methodologies around automated testing and subsequently also delivery of new features to our customers:

  • Continuous Integration
  • Continuous Delivery
  • Continuous Deployment


On the following lines I want to give a short overview of these three practices and their differences.

Continuous Integration

As explained above, using Agile Development Methodologies we focus on getting stuff out the door much quicker than before in order to get early feedback on what we delivered to be able to create products/features that actually hold value.
Testing is a crucial part of that as we don't want to deliver every 1 to 4 weeks only to discover that the little exploratory testing we did before handing it of to SIT wasn't enough and spend half of the following iteration on fixing what we broke with the last code drop.
This is where Continuous Integration comes in, unit tests, automated integration and acceptance tests can be run periodically or even on every commit to a code repository. This allows us to get early feedback on whether we broke some old functionality during development of the next high-priority feature for our client.
At the end of an iteration the continuous integraton workflow is started once more to check if everything passes and then the code is deployed to the first external system (e.g. SIT) where there are manual tests run on the codebase then moves on to the next stage (e.g. UAT) and is then finally deployed to production.
The important difference to the subsequent practices is that in Continuous Integration the actual deployment process is usually done manually.


Continuous Delivery

Continuous Delivery adds one more step to the Continuous Integration flow shown above: Deployment to Production. It requires your Continuous Integration to be thorough enough so that you feel comfortable releasing the changes to the product at any time all the tests pass. This allows the product to be deployed at any time in its lifecycle with the push of a button.

In short: Continuous Delivery aims to have every change be deployable at any time.

Martin Fowler put up a 4-point checklist on his blog that define continuous delivery:

  • Your software is deployable throughout its lifecycle
  • Your team prioritizes keeping the software deployable over working on new features
  • Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them
  • You can perform push-button deployments of any version of the software to any environment on demand


Continuous Deployment

Continuous Deployment goes one step further, once you have a working Continuous delivery workflow you're in good shape to go the extra mile toward Continuous Deployment.
Continuous Deployment removes the last manual step in the Continuous Delivery pipeline. Code is not deployed on demand but rather at any point the Continuous Integration flow passes (i.e. all tests pass).


Conclusion

Continuous Integration is sort of the "odd one out" in this comparison as it is a fundemantal part of both Continuous Delivery and Continuous Deployment without which they wouldn't exist. The latter two put an even bigger emphasis on the automated tests as they need to be rock-solid in order to prove the system is working without reasonable doubt. Some companies even re-trained their test teams to write automated tests instead of executing their tests manually.

So, which one's better? Well, there's no real answer for that one. It basically comes down to personal and customer preference.

I for one would probably go with Continuous Delivery in a Customer project as it gives them the choice on whether they want the new version deployed or not. I'd maybe even provide them with a simple frontend which lets them press the button themselves not just make the decision that the button should be pressed. Thus putting them in the driver's seat :).

In a product development environment I'd probably opt for Continuous Deployment as it provides an even shorter feedback loop for the developers.

Have you had experiences with these techniques? Let us know in the comments!

Monday, 9 December 2013

Prevent defects, don't find them

Several times I came across the phrase “Acceptance Tests are used to prevent defects (not to find them)”. I want to use the 99 Test Ballons game to illustrate what that could actually mean.



At our last team coaching event we used a game* called 99 Test Balloons to illustrate the importance of Acceptance Criteria. The goal of the game is to draw smileys on balloons, which must meet certain criteria to be accepted (of course in the first round the team does not ask about those). As illustrated in the picture, the size of the eyes must be 2'', the height of the nose 1.5'' and so on. 

The first and most ineffective approach would be to draw a certain number of smileys and afterwards use a ruler to determine if each has the right proportions; this would be called testing. It helps us to find defects and validate if our work meets the requirements. However, this could potentially produce a lot of waste, as we get feedback very late and if adjustments would be needed, we would have to throw away all of them.

So the second approach is to create one smiley and immediately test it after its implementation.  We would get feedback quicker and thereby reduce the changing costs compared to the first approach. However, it is still about finding defects and not preventing them.

The third approach is to create a template (or example) with the exact dimensions first and use it to actually create the smileys. It helps us to prevent defects by using the specification and acceptance criteria/examples itself to form the implementation and build the right product. A prerequisite of course is that the acceptance criteria / examples are created collaboratively and point in the right direction.

James Shore wrote a detailed article about his attempt to prevent defects here.
 ____
*I highly recommend using such games in general, we got great feedback from the team about our exercises. You can find a list of agile games at www.tastycupcakes.com.

P.S. I’d love to talk to you on Twitter: here.

Friday, 6 December 2013

10 Laws of Agility


“It is not necessary to change. Survival is not mandatory.”
–Edwards Deming
Agile methodologies and frameworks are quite popular nowadays. As coaches in this field we are aware that it is often used as a buzz word. Companies proudly announce that they work "agile" and offer employees according benefits. The ugly truth is that more and more companies focus on terms and forget about values. Agile project management needs to follow a set of rules, which lead to agile behaviour of systems. When we want a system to evolve, it's not enough to define roles and do meetings. Remember the lessons of the "Lean Production System" and the "Theory of Complex Systems and Self-Organisation" - in short, keep the following "10 Laws of Agile" in mind to become and stay a real agile team:

1) Work with Short Feedback Loops / in Iterations: One learns by trial and error. Knowledge comes from experimentation. Only if we test our assumptions in real situations, we can know, whether they are correct. So don't be afraid of doing experiments, honor your errors and always remember to measure results.


2) Do the Work "just in time" (decide as late as possible): As project workers or project managers we are used to making huge plans for the future. But we have two keep 2 things in mind. First, a plan is nothing more than that - a plan. It is nothing that has to be applied and it's for sure no prediction of the future. We have to be aware that no planning can ever fully meet actual situations. Especially in complex projects with complex environments adaption is much more useful than detailed planning (and your project is probably more complex than you think). Second, a plan is a useful tool to get an imagination of possible futures, so it helps us to react on different scenarios. But since circumstances change, we also need to adapt our plans. Anyway - a plan can never tell us, what we have to do. We should instead do, what we have to do, when we have to do it.

3) Be Cross-Skilled - Transfer your Knowledge:  Complex systems shouldn't be fully specialised. Depending on a specific challenge you as a team will have to focus on different skills and knowledge. To increase productivity of a team a good approach is to remove bottle necks. That's actually quite easy: Find the bottle necks, figure out, what skills are needed to work on the specific tasks and distribute the required knowledge over the team. That's a sustainable option to improve your performance and avoid the risk of losing your stars. This goal can be reached mainly through lively communication. Most of the knowledge within a team is "tacit knowledge" (in the people's minds and therefore not accessible). Through communication it becomes explicit, so it can be transferred.

4) Work Self Organised and Evolve Continuously through Experience: Using feedback loops also means to adapt and improve steadily. If you manage to increase your performance by only 1% each day, you are almost 40 times (!) as productive after just one year. Evolution needs time for inspection and adaption. Take this time and you'll see success sooner than you would expect.

5) Work with "pull" instead of "push": Motivation comes from autonomy. People want the power to decide, how much they will do, when exactly they will do it how they will do it and with whom they will do it. So give them priorities, but no detailed commands.

6) Collaborate with the customer: The customer has the power to fire everyone in the company. When you cannot satisfy the needs of your customer, you will sooner or later run out of business. Everyone knows that. What people are often not aware of, is the fact, that there is only one person who knows the customer needs - that's the customer himself. Don't try to predict the customer needs. Instead just ask him about them. Ask him about problems and ask him about solutions. Show your results again and again until you have a true product/market-fitness.

7) Be a distributed being: To solve complex problems, a network is more appropriate than a hierarchy. Several entities have always more experiences and perspectives to offer than one entity of the same group. That is why you should respect your colleague's opinion, even if it doesn't match with yours. Don't try to know everything, but instead use the "wisdom of the crowd". Through different experiences you can raise the internal complexity of your team - so it's able to handle more external complexity. That means diversity is your friend!

8) Humans can fail - Use Automation wherever possible: A main source of steadily rising productivity is automation. Of the decades we've experienced that many things which were originally  done by humans are nowadays done automatically. This saves not only resources, but also decreases the number of mistakes. So whenever you need to do a work step often try to automate it.

9) Keep things lean and simple: Neither team structures nor processes need to be set up in a sophisticated way. Complexity arises by it's own over time and in the same way it vanishes over time. Start simple and through evolution things will get more complex to meet your requirements. After a while they might get less complex and more efficient again. It's always a question of trial and error. It's evolution. But don't try to "be evolution". Start simple and let it happen (you can see this process in the game "Mine Craft" - simple forms become complex forms).

10) Have Multiple Goals: Quantum mechanics taught us that the measurement determines the state. That means that  for project teams the method of measurement and the object of measurement defines our goals and our output. When you measure mainly your velocity, you might increase velocity, but in the same time reduce quality (and vice versa). Focus on multiple goals to react on different challenges and to stay agile.



Tuesday, 6 August 2013

Learning without a working product - Our first Low Fidelity MVP

Some weeks ago we started our first experiment using a low fidelity Minimum Viable Product for one of our projects (Whatson) and the first questions came up before we even started:
How to structure such an experiment? What are the indicators to mark it as a success? How much time should be invested?


The Low Fidelity Minimum Viable Product

There are different kinds of MVPs and as we are just starting this project, we used a low fidelity MVP. This can be something like a paper mock-up or a landing page describing the most important features and problems you want to solve. Stefan Roock provides a nice illustration and classification of MVPs here
The intention of the Lean Startup way is to test your hypotheses and get customer feedback as soon as possible, even if you do not have a working product yet.
Before we decided to create the landing page, we held customer problem and solution interviews, as suggested by Ash Maurya. Those helped us to improve our understanding qualitatively, but now it was time to present our product idea to a broader audience.

 

Conversion Funnel

When it comes to web based products or mobile apps potential buyers go through different stages before becoming an actual customer. Steve Blank describes this as the "Get, Keep and Grow" Customers Funnel in his book The Startup Owner's Manual

As we do not a have a working product yet the phase we concentrate on is the Get Customers phase, which includes two major steps:

Acquisition: That is when your  potential customer visits your website, by clicking on a paid Google Ad or a Facebook message or whatever channel you are using.

Activation: That is the point were the visitor becomes a customer, by downloading your product, signing up, etc.

The numbers

So the basic question we actually wanted to answer was, do enough people care about the product and do they find it compelling enough to tell their friends.
Without a working product, however, these questions are not that easy to answer, especially the latter.
As we did not have a usable product we were not quite sure what to define as activation. Another unclear point was the number of acquired and activated customers. How many do we need to mark this experiment as a  success?

First we decided  that entering your email address can be counted as an activation, as this is commonly used as an indicator.

Steve Blank defines 44% activations of 5000 visitors is a huge success, whereas if you got just 50 sign ups, you should check what went wrong. Furthermore he suggests to start such an experiment as soon as possible.

Furthermore I found this answer on Quora by Joshua Ledgard, Founder - KickoffLabs.com:

"5% is bad.
10% is OK.
20% is ideal.
30% is ahead of the curve."


Draw a line in the sand 

Even though we now knew the percentages, we still had to come up with absolute numbers. The book Lean Analytics confirmed what we actually thought: draw a line in the sand. That means, at the beginning pick any reasonable number and define a goal. It is more important to compare the result afterwards and most of the time you will be somewhere in the middle anyway.

  

So here is what we came up with. We divided the activation step into two different parts:
Customer giving us their email address and customers liking us on Facebook.

Our goal for the next 2 weeks: 150 Facebook Likes, 20 email addresses and a conversion rate around 30%.
Channels: Google Adwords, Virality through chosen friends, Online forums

We did not acquire anybody through Facebook or Twitter status updates or invite people directly, but included some of our friends. We sent a prepared message to around 30 of our friends and asked them to spread the word.  

Result

After optimizing our Google Adwords campaign (using this great article from KISSmetrics) we had a good enough click-through rate and about 30% of the visitors entered their email address.

Unfortunately we did not have exact numbers on the people that were reached on Facebook, which made it hard to argue that a page-like counts as an activation.
So we decided to make another experiment and verify the engagement of our page-fans. We created an account on Next-Fat-Business and asked our page-fans to give us their vote. At that time we had 115 likes and ended up with around 45 votes.

This was all done within 2 - 3 weeks, which is not that long. During that time we invested some hours per day to promote the product, improve the Adwords campaign, talk to the potential customers and tweak the landing page itself.

Lessons Learned

Facebook does not provide such a virality as it used to. After having 100 likes it is quite hard to acquire new customers without paid ads. Of course it is quite difficult to create virality without a product or fancy video.

Verify the engagement of your Facebook fans and activate them with a second experiment.

Activation can be anything: entering an email address, a fake sign up or a call for action.

We think that absolute numbers are not that important, but the trend and a little bit of gut feeling. 

Use this experiment to evaluate your channels, because acquiring new customers won't be easier even with a working product.
 
Friends promoting a product to their friends works really well.

After two to three weeks you get a first impression of how appealing your product is. If at any time the conversation rate drops below 10 % stop the experiment and verify why. Furthermore promoting your landing page and product should be something you do consistently from the beginning.  


Did you have any similar experiences? How did your experiments do?

P.S. I’d love to talk to you on Twitter: here.

** You might also like: How to get Customers' Attention **

Thursday, 1 August 2013

How to get Customers' Attention - 7 Must Haves for your Landing Page

As a Startup the biggest disadvantage of our products is that nobody knows them. Before people can start using your products (and pay for them), they must recognize that you even exist. A first important step in this process is a well designed Landing Page.



At the moment we struggle to get our first customers for our products (even if we haven't launched any product yet, pre-sales has already started). We are neither a famous nor a big company, we need to look for proper customers right from the beginning. Those who are really interested in our product. These are the first ones you have to convince. One way to do so, is to create a landing page with all important information of your product in short form. Most people don't stay longer on an unknown website than 7 seconds, so you have to use your time efficiently. Here are the 7 most important steps to pitch your product via Landing Page.


1) Pitch the idea in 10 words or less - the title of a product will probably not tell that much about it's key features. Give your customers an insight of the idea behind the product. What's the new delighting thing about it? What's the difference to similar products? After reading the pitch, potential customers need to be curious about the product and ready to read more.

2) List the key features - bring your product down to your most important key features. Your Unique Value Proposition. What is it that makes you special and why should someone use your product? Name 3 - 5 reasons and describe them with a few words.

3) Add icons to the features - Never forget that the attention of the average customer lasts only for a few seconds. Icons next to the paragraphs help him to understand in no time what it is all about. Moreover they will help him to make the product stick in his mind. 

4) Show them what they'll get - If you produce a smart phone app or an online service display a screenshot.  The image doesn't need to represent the actual product, but gives a first impression of the look and feel.

5) Give them the possibility to contact you - You will need early adopters and constant customer feedback. So give them a possibility to leave their mail adress. So you can mail users easily, activate them by doing so and ask for their feedback.

6) Use social media- Maybe the customer doesn't want to give you his email address. In this case it's more likely for him to press the "like-button". Due that you can contact him easily through Facebook, Google+ or Twitter. Moreover it's free advertising for your product, since his friends will notice what he likes. So insert social media buttons.

7) Finally it's all about entertainment - Show your visitors something special. The best way to do so is a creative video. There are many catchy, touching and/or hilarious videos of start ups on the web (especially on kickstarter). We haven't used this tool yet, but it's the most effortless way for the customer to get informed about your product; and it's probably much more emotional and personal than just plain text.

Keep this ideas in mind and you Landing page will have tremendous success as we have it with those two:
http://park-bank.simplelander.com/ and http://friendly-alien.simplelander.com/ :)

Wednesday, 24 July 2013

TIL #3: How to influence buying decisions


In the book Predictably Irrational Dan Ariely explains how relativity is used to manipulate people. Comparing things is in our nature and we are actually better in estimating relations (an apple is bigger than an apricot) than absolute numbers (this apple is 6.43 cm big).

However this great ability can also be taken against us. Imaging you have to choose the destination for your next holiday:

- Paris (without breakfast)
- Rome (without breakfast)
- Rome (with breakfast)

Chances are very high that your next trip will go to Rome, as it is easier for us to compare the two Rome options than Rome to Paris. Another example that was used in the book:

An Economist online subscription:
- Internet-only subscription           59$
- Print-only subscription              129$
- Print-and-Internet subscription  129$

Through his experiments he found out, that  the mere presence of the Print-only option is enough to make people choose the Print-and-Internet subscription. When he did a second run without the Print-only option the Internet-only subscription was chosen by 68%.
As in the example above we automatically tend to compare two similar options, even though it objectively might not even be the best choice.

P.S. I’d love to talk to you on Twitter: here

** You might also like: Tasks should be SMART too **


Thursday, 11 July 2013

Closing the Gap - How to Build a Bridge between two Worlds


Mia Weidl about the idea and her experiences working on a project that aims more cultural tolerance between Austria and Senegal



We, the Team of „DIISOO – Association to Promote Cultural Exchange“ have the aim to create space where people can meet and get to know each other. Therefore Austrian and Senegalese people will encounter to share individual experiences and extend their personal knowledge - organised and accompanied by DIISOO, a non-profit organisation for the publics benefit.

All the members walked different paths until we met, got to know each other better and started the project DIISOO. With those different personalities we can bring together a grand repertoire on backgrounds, which helped us to build an association which considers various perspectives and points of view. Thus, we overcame all upcoming difficulties so far.

Workshop September
In September we’ll reach our first big goal - we managed to establish a workshop in Senegal where more then 30 Senegalese and Austrians will work together. We’ll meet in a village about 100 km south-east of Dakar, the capital city of Senegal. In the village “Kër Sara Badiane” we’ll spend as much time as possible together to get to know each other and share our cultural qualities as well as our experiences of life. We want to get understanding and access in “different” culture – as a matter of course, on both sides.

Vision
Due to the promotion of cultural exchange, we want to bring all participants to open up their ways of thinking and expand their minds through cross-cultural competences. We, the Team of DIISOO, see ourselves as a platform, where contacts arise and get carried forward to spread experiences to a wider community.
Starting now, we want to win more and more educators from Austria and Senegal to join DIISOO, our workshops and events. With the help of those, we can assure that our vision will spread.
We really appreciate that our association is growing from day to day and there are already many institutions that share our ways of thinking and want to join our project. Even the “University of Teacher Education Styria” wants to offer classes where we can introduce DIISOO.

What can you do?
First of all, we would be happy if you visit our homepage www.diisoo.at or join us on Facebook http://goo.gl/9U3gF!
There you can find further Information about our work and read our latest news.
Get a member of DIISOO and share your ideas and experiences with us! Contact us via our homepage or write us an e-mail to office@diisoo.at. Also let us know, if you’re interested in our newsletter!

And even if you don’t want to join us, don’t worry - just always keep your mind open for the new