Years ago I read the books “Seven habits of highly effective people” and “Switch”, in my research in to how to become more effective I came in to contact with GTD and decided to try it out. In this post I want to show people who have heard about GTD how I use it and how it helps me.

For those who don’t know GTD or haven’t heard about the two books I mentioned please follow the links Getting things done Seven habits of highly effective people Switch and have fun.

How do I use GTD?
Because of my experience before GTD I knew I needed a digital list that I could access from my phone, laptop or tablet. It was also crucial for me to be able to have multiple lists and reminders. Because of these requirements I settled on using Todoist after having evaluated others as well.

I have couple of main groups like Personal, Work, Read-me, Someday & Maybe, Home etc.. In those lists I have topics like Xebia, CustomerX, CustomerY etc.. And in those topics I have the actual tasks or lists with tasks that I need to do.

I write everything in to my Inbox list the moment a task or idea pops up in to my mind. I do this because most of the time I don’t have the time to figure out directly what I want to do with it so I just put it in to my Inbox and deal with it later.

As a consultant I have to deal with external lists like team scrum boards. I don’t want to depend on them so I write down my own tasks with references to them. In those tasks I write the things that I need to do today, tomorrow or longer if it is relevant in making decisions on the long run.

Every day I finish my work I quickly look at my task list and decide on priorities for tomorrow, then every morning I evaluate my decisions based on the input of that day.

As a programmer I like to break down a programming task in to smaller solutions so therefore sometimes I use my list as a reference or micromanagement of tasks that take couple of hours.

To have a better overview of things in my list I also use tags like tablet, PC, home, tel so it helps me pick up tasks based on context I am in on that moment.

Besides deciding on priorities every day I also do a week review where I decide on weekly priorities and add or remove tasks. I also specify reminders on tasks, I do this day based but if it is really necessary I use time based.

Because I want to have one Inbox I am sticking to zero mail in my mail Inboxes. This means every time I check my mail I read it and then either delete it or archive it and if needed make a task to do something.

What does GTD do for me?
Pros:
The biggest win for me is that it helps me clear my mind because I put everything in there that I need to do, this way my mind does not have to remember all those things. It is also a relaxing feeling knowing that everything you need to do is registered and you will not forget to do it.

It gives me structure and it allows me to make better priorities and decisions about saying yes or no to something because everything is in one place.

Having a task registered so that you can cross it off when it’s done gives a nice fulfilling feeling.

Cons:
Having a big list of things that you think you need to do can be quite overwhelming and in some cases it can also feel like a pressure because you haven’t done a list of tasks that is there for a long time. That’s why I keep evaluating tasks and remove things from it after some time.

Task lists and calendars can sometimes collide so it is importent to keep your agenda as a part of your list although it’s not a list.

What am I still missing?
Right now from the GTD’s point of view I miss a better time management. Besides that I would like to start a journal of relevant things that happend or people I spoke to but also incorporate that with my GTD lists (for example combining Evernote/OneNote with my Todoist lists).

Everything else I miss is technical:

I miss a proper integration of all my mail where all the calendar invites are working without having to connect all accounts on all different devices. I also miss a proper integration between my mail and Todoist for creating and referencing mail.

Because I write down every task/idea that pops up in to my mind it would be great if voice recognition would work a little better for ‘me’ when I am in a car.

Conclusion
GTD has helped me structure my tasks and gave me more controle in to making decision around them. By writing this post I am hoping to trigger somebody else to look in to GTD and maybe have an impact on his or hers effectiveness.

I am also curious in what your opinion is on GTD or if you have any tips for me regarding GTD?

Most of the software we work with at Xebia is open source. Our primary expertise is in open source technology, which ranges our entire application stack. We don’t just consume open source projects, we also contribute back to them and occasionally release some of our own. Releasing an open source project doesn’t just mean making the GitHub repository public. If you want your project to be used, it should be easy to consume. For JavaScript this means publishing it to npm, the package manager for JavaScript code.

Nowadays we write our JavaScript code using the ES6 syntax. We can do this because we’re using Babel to compile it down to ES5 before we run it. When you’re publishing the code to npm however you can’t expect your package consumers to use Babel. In fact if you’re using the Require Hook, it excludes anything under node_modules by default and thus will not attempt to compile that code.

Prepublish

The reality is that we have to compile our code to ES5 before publishing to npm, which is what people writing libraries in CoffeeScript have been doing for a long time. Luckily npm provides a helpful way to automate this process: the prepublish script. There’s a whole list of scripts which you can use to automate your npm workflow. In package.json we simply define the scripts object:

{
  "name": "my-awesome-lib",
  "version": "0.0.0",
  "scripts": {
    "compile": "babel --optional runtime -d lib/ src/",
    "prepublish": "npm run compile"
  },
  "main": "lib/index.js",
  "devDependencies": {
    "babel": "^5.8.23",
    "babel-runtime": "^5.8.24"
  }
}

This will make npm automatically run the compile script when we run `npm publish` on the command line, which in turn triggers babel to compile everything in ./src to ./lib (the de-facto standard for compiled sources in npm packages, originating from CommonJS). Finally we also define the main entry point of our package, which denotes the file to import when require(‘my-awesome-lib’) is called.

An important part of the above configuration is the runtime option. This will include polyfills for ES6 features such as Promise and Map into your compiled sources.

Ignoring files

It’s easy to simply publish all of our source code to npm, but we don’t have to. In fact it’s much nicer to only publish the compiled sources to npm, so package consumers only have to download the files they need. We can achieve this using a file called .npmignore:

src/
test/

This file is very similar to .gitignore, in fact npm will fall back to .gitignore if .npmignore is not present. Since we probably want to ignore ./lib in our git repository because it holds compiled sources, npm would normally not even publish that directory, so we have to use .npmignore to get the desired result. However if you want your library to also be directly consumable via a git URL you can commit ./lib to git as well.

Publishing

Now that everything is set up, the only thing left to do is publish it. Well, not so fast. First we should specify our version number:

npm version 1.0.0

This will update package.json with the new version number, commit this change to git and make a git tag for v1.0.0, all in one go. This of course assumes you're using git, otherwise it will just update package.json. An even better way is to have npm automatically determine the next version number by specifying the scope of change. We should also specify a commit message:

npm version patch -m "Bump to %s because reasons"

For more options check out the npm documentation. Now finish up by pushing your new version commit and tag to GitHub and publish our package to npm:

git push --follow-tags
npm publish

The reason I chose union-find for this blog is that it is relatively simple. It is a classic algorithm that is used to solve the following problem: suppose we have a set of objects. Each of them can be connected to zero or more others. And connections are transitive: if A is connected to B and B is connected to C, then A is connected to C as well. Now we take two objects from the set, and we want to know: are they connected or not?
This problem comes up in a number of area's, such as in social networks (are two people connected via friends or not), or in image processing (are pixels connected or separated).
Because the total number of objects and connections in the set might be huge, the performance of the algorithm is important.

Quick Union

The implementation I chose is the so called Quick Union implementation. It scales well but there are still faster implementations around, one of which is given in the references below the article. For this post I chose to keep things simple so we can focus on comparing the two implementations.

The algorithm keeps track of connected elements with a data structure: it represents every element as a Node which points to another element to which it is connected. Every Node points to only one Node it is connected to, and this Node it is called its parent. This way, groups of connected Nodes form trees. The root of such a connected tree is a Node which has an empty parent property.
When the question is asked if two Nodes are connected, the algorithm looks up the roots of the connected trees of both Nodes and checks if they are the same.

The tricky part in union find algorithms is to be able to add new connections to a set of elements without losing too much performance. The data structure with the connected trees enables us to do this really well. We start by looking up the root of both elements, and then set the parent element of one tree to the root of the other tree.

Some care must still be taken when doing this, because over time connected trees might become unbalanced. Therefore the size of every tree is kept in its root Node; when connecting two subtrees, the smaller one is always added to the larger one. This guarantees that all subtrees remain balanced.

This was only a brief description of the algorithm but there are some excellent explanations on the Internet. Here is a nice one because it is visual and interactive: visual algo

The Impure Implementation

Now let's see some code! The impure implementation:

import scala.annotation.tailrec

class IUnionFind(val size: Int) {

  private case class Node(var parent: Option[Int], var treeSize: Int)

  private val nodes = Array.fill[Node](size)(new Node(None, 1))

  def union(t1: Int, t2: Int): IUnionFind = {
    if (t1 == t2) return this

    val root1 = root(t1)
    val root2 = root(t2)
    if (root1 == root2) return this

    val node1 = nodes(root1)
    val node2 = nodes(root2)

    if (node1.treeSize < node2.treeSize) {
      node1.parent = Some(t2)
      node2.treeSize += node1.treeSize
    } else {
      node2.parent = Some(t1)
      node1.treeSize += node2.treeSize
    }
    this
  }

  def connected(t1: Int, t2: Int): Boolean = t1 == t2 || root(t1) == root(t2)

  @tailrec
  private def root(t: Int): Int = nodes(t).parent match {
    case None => t
    case Some(p) => root(p)
  }
}

As you can see I used an array of Nodes to represent the connected components. Most textbook implementations use two integer arrays: one for the parents of every element, and the other one for the tree sizes of the components to which the elements belong. Memory wise that is a more efficient implementation than mine. But apart from that the concept of the algorithm stays the same and in terms of speed the difference doesn't matter much. I do think that using Node objects is more readable than having two integer arrays, so I chose for the Nodes.

The purely functional implementation

import scala.annotation.tailrec

case class Node(parent: Option[Int], treeSize: Int)

object FUnionFind {
  def create(size: Int): FUnionFind = {
    val nodes = Vector.fill(size)(Node(None, 1))
    new FUnionFind(nodes)
  }
}

class FUnionFind(nodes: Vector[Node]) {

  def union(t1: Int, t2: Int): FUnionFind = {
    if (t1 == t2) return this

    val root1 = root(t1)
    val root2 = root(t2)
    if (root1 == root2) return this

    val node1 = nodes(root1)
    val node2 = nodes(root2)
    val newTreeSize = node1.treeSize + node2.treeSize

    val (newNode1, newNode2) =
      if (node1.treeSize < node2.treeSize) {
        val newNode1 = Node(Some(t2), newTreeSize)
        val newNode2 = Node(node2.parent, newTreeSize)

        (newNode1, newNode2)
      } else {
        val newNode2 = FNode(Some(t1), newTreeSize)
        val newNode1 = FNode(node1.parent, newTreeSize)

        (newNode1, newNode2)
      }
    val newNodes = nodes.updated(root1, newNode1).updated(root2, newNode2)
    new FUnionFind(newNodes)
  }

  def connected(t1: Int, t2: Int): Boolean = t1 == t2 || root(t1) == root(t2)

  @tailrec
  private def root(t: Int): Int = nodes(t).parent match {
    case None => t
    case Some(p) => root(p)
  }
}

Comparing to the first implementation, some parts remained the same. Such as the Node, except for the fact that it is not an inner class anymore. Also the connected and the root methods did not change.
What did change is the method which deals with updating the connections: union. In the purely functional implementation we can't update any array, so instead it creates a new FUnionFind object and returns it at the end. Also two Node objects need to be created when subtrees are merged; the root of the smaller one because it gets a new parent, and the root of the larger one because its tree size needs to be increased.
Perhaps surprisingly, the pure implementation needs more lines of code than the impure one.

The Performance

The pure implementation has to do a bit of extra work when it creates the new objects in its union method. The question is how much this costs in terms of performance.
To find this out, I ran both implementations through a series of performance tests (using ScalaMeter) where I added a large number of connections to a set of objects. I added a (impure) Java 8 implementation to the test as well.
Here are the results:

Not surprisingly, the time grows with the number of connections and elements. The growth is a bit faster than linear, that's because the asymptotic time complexity of the quick union algorithm is of the order n log(n).
The pure algorithm is about 65% slower than the impure implementation. The cause is clear: in every call to union the pure algorithm has to allocate and garbage collect three extra objects.

For completeness I added Java 8 to the test too. The code is not given here but if you're interested, there's a link to the complete source below the article. Its implementation is really similar to the Scala version.

Conclusion

Purely functional code has a couple of advantages over non pure implementations; because of the lack of side effects it can make it easier to reason about blocks of code, also concurrency becomes easier because there is no shared state.
In general it also leads to more concise code because collection methods like map and filter can easily be used. But in this example that was not the case, the pure implementation even needed a few lines extra.
The biggest disadvantage of the pure union-find algorithm was its performance. It depends on the requirements of the project where the code is used if this is a showstopper, or if the better concurrent behavior of the pure implementation outweighs this disadvantage.

Explanation of a faster union-find with path compression
All the source code in the article, including the tests

System.err

Any exception or error is written to System.err automatically. System.err writes to the standard outputstream of the process, which normally is the console. I want to change this for our server, so at the startup of the server I redirect System.err to a custom outputstream of my own, called LoggingOutputStream, like this:

import org.apache.log4j.{Level, Logger}

System.setErr(new PrintStream(new LoggingOutputStream(Logger.getRootLogger, Level.ERROR), true))

The LoggingOutputStream will write anything that would normally go to System.err to log4j's RootLogger instead, with log level ERROR.
What's left is the implementation of our LoggingOutputStream:

import java.io.{IOException, OutputStream}

import org.apache.log4j.{Priority, Category}

class LoggingOutputStream(category: Category, priority: Priority) extends OutputStream {
  private val LINE_SEPARATOR = System.getProperty("line.separator")
  private var closed = false
  private var buffer = new Array[Byte](2048)
  private var count = 0

  override def close() {
    flush()
    closed = true
  }

  @throws(classOf[IOException])
  override def write(b: Int) {
    if (closed) {
      throw new IOException("The stream has been closed!")
    }
    if (b == 0) {
      return
    }

    if (count == buffer.length) {
      // The buffer is full; grow it
      val newBuffer = new Array[Byte](2 * buffer.length)
      System.arraycopy(buffer, 0, newBuffer, 0, buffer.length)
      buffer = newBuffer
    }

    buffer(count) = b.toByte
    count += 1
  }

  override def flush() {
    if (count == 0) {
      return
    }
    // Don't print out blank lines; flushing from PrintStream puts these out
    if (!isBlankLine) category.log(priority, new String(buffer.slice(0, count)))
    reset()
  }

  private def isBlankLine = (count == LINE_SEPARATOR.length) &&
    ((buffer(0).toChar == LINE_SEPARATOR.charAt(0) && count == 1)
      || (buffer(1).toChar == LINE_SEPARATOR.charAt(1)) && count == 2)

  private def reset() {
    count = 0
  }
}

Of course this solution is not specific for Akka, it will work in any Scala application.

• How do you develop awesome products?
• How do you bootstrap a successful mega project using Agile contracts?
• How do you use Agile and Lean thinking to turn a stagnant company around?

We then picked the brains of people from real companies who have been there and done it. Listen to how companies like King and Spotify evolve their products in a global market. How Åre Skidfabrik developed an award winning product together with a community in no time.  We have more great stories to share on this special day.

Check out the Stop Starting 2015 agenda at: http://fastfeedback.se 

.. and register now to reserve your seat on October 20:th, here in Stockholm. It’s worth the trip, we promise!

A short intro video ( ..who the heck let these guys out?

This post is part of a series of ES2015 posts. We'll be covering new JavaScript functionality every week!

One of the new features of ECMAScript 2015 is the WeakMap. It has several uses, but one of the most promoted is to store properties that can only be retrieved by an object reference, essentially creating private properties. We'll show several different implementation approaches and compare it in terms of memory usage and performance with a 'public' properties variant.

A classic way

Let's start with an example. We want to create a Rectangle class that is provided the width and height of the rectangle when instantiated. The object provides an area() function that returns the area of the rectangle. The example should make sure that the width and height cannot be accessed directly, but they must be stored both.

First, for comparison, a classic way of defining 'private' properties using the ES2015 class syntax. We simply create properties with an underscore prefix in a class. This of course doesn't hide anything, but a user knows that these values are internal and the user shouldn't let code depend on its behaviour.

class Rectangle {
  constructor(width, height) {
    this._width = width;
    this._height = height;
  }

  area() {
    return this._width * this._height;
  }
}

We'll do a small benchmark. Let's create 100.000 Rectangle objects, access the area() function and benchmark the memory usage and speed of execution. See the end of this post on how this was benchmarked. In this case, Chrome took ~49ms and used ~8Mb of heap.

WeakMap implementation for each private property

Now, we introduce a WeakMap in the following naive implementation that uses a WeakMap per private property. The idea is to store a value using the object itself as key. In this way, only the accessor of the WeakMap can access the private data, and the accessor should be of course only the instantiated class. A benefit of the WeakMap is the garbage collection of the private data in the map when the original object itself is deleted.

const _width = new WeakMap();
const _height = new WeakMap();

class Rectangle {
  constructor (width, height) {
    _width.set(this, width);
    _height.set(this, height);
  }

  area() {
    return _width.get(this) * _height.get(this);
  }
}

To create 100.000 Rectangle objects and access the area() function, Chrome took ~152ms and used ~22Mb of heap on my computer. We can do better.

Faster WeakMap implementation

A better approach would be to store all private data in an object for each Rectangle instance in a single WeakMap. This can reduce lookups if used properly.

const map = new WeakMap();

class Rectangle {
  constructor (width, height) {
    map.set(this, {
      width: width,
      height: height
    });
  }

  area() {
    const hidden = map.get(this);
    return hidden.width * hidden.height;
  }
}

This time, Chrome took ~89ms and used ~21Mb of heap. As expected, the code is faster because there's a set and get call less. Interestingly, memory usage is more or less the same, even though we're storing less object references. Maybe a hint on the internal implementation of a WeakMap in Chrome?

WeakMap implementation with helper functions

To improve the readability of above code, we could create a helper lib that should export two functions: initInternal and internal, in the following fashion:

const map = new WeakMap();
let initInternal = function (object) {
  let data = {};
  map.set(object, data);
  return data;
};
let internal = function (object) {
  return map.get(object);
};

Then, we can initialise and use the private vars in the following fashion:

class Rectangle {
  constructor(width, height) {
    const int = initInternal(this);
    int.width = width;
    int.height = height;
  }

  area() {
    const int = internal(this);
    return int.width * int.height;
  }
}

For the above example, Chrome took ~108ms and used ~23Mb of heap. It is a little bit slower than the direct set/get call approach, but is faster than the separate lookups.

Conclusion

• The good: real private properties are now possible
• The bad: it costs more memory and degrades performance
• The ugly: we need helper functions to make the syntax okay-ish

WeakMap comes at both a performance as well a memory usage cost (at least as tested in Chrome). Each lookup for an object reference in the map takes time, and storing data in a separate WeakMap is less efficient than storing it directly in the object itself. A rule of thumb is to make sure to do as few lookups as necessary. For your project it will be a tradeoff to store private properties with a WeakMap versus lower memory usage and higher performance. Make sure to test your project with different implementations, and don't fall into the trap of micro-optimising too early.

Test reference

Make sure to run Chrome with the following parameters: --enable-precise-memory-info --js-flags="--expose-gc" - this enables detailed heap memory information and exposes the gc function to trigger garbage collection.

Then, for each implementation, the following code was run:

const heapUsed = [];
const timeUsed = [];

for (let i = 1; i <= 50; i++) {
  const instances = [];
  const areas = [];

  gc();
  const t0 = performance.now();
  const m0 = performance.memory.usedJSHeapSize;

  for (let j = 1; j <= 100000; j++) {
    var rectangle = new Rectangle(i, j);
    instances.push(rectangle);
    areas.push(rectangle.area());
  }

  const t1 = performance.now();
  const m1 = performance.memory.usedJSHeapSize;

  heapUsed.push(m1 - m0);
  timeUsed.push(t1 - t0);
}

var sum = function (old, val) {
  return old + val;
};
console.log('heapUsed', heapUsed.reduce(sum, 0) / heapUsed.length);
console.log('timeUsed', timeUsed.reduce(sum, 0) / heapUsed.length);

Heres the simplest case, where all activities are launched with the "android.intent.action.MAIN" action:

@SmallTest
@RunWith(AndroidJUnit4.class)
public class MainActivityTest {

    @Rule
    public ActivityTestRule<MainActivity> mActivityRule =
            new ActivityTestRule<>(MainActivity.class);

    @Test
    public void someTest() {
        /* Your activity is initialized and ready to go. */ 
    }
}

Here's how to make all methods in your test class use the same intent, with extras:

@SmallTest
@RunWith(AndroidJUnit4.class)
public class MainActivityTest {

    @Rule
    public ActivityTestRule<MainActivity> mActivityRule =
            new ActivityTestRule<MainActivity>(MainActivity.class) {
                @Override
                protected Intent getActivityIntent() {
                    Context targetContext = InstrumentationRegistry.getInstrumentation()
                        .getTargetContext();
                    Intent result = new Intent(targetContext, MainActivity.class);
                    result.putExtra("Name", "Value");
                    return result;
                }
            };

    @Test
    public void someTest() {
        /* Your activity is initialized and ready to go. */ 
    }
}

If you want each test method to provide its own set of extras, you can do that too:

@SmallTest
@RunWith(AndroidJUnit4.class)
public class MainActivityTest {

    @Rule
    public ActivityTestRule<MainActivity> mActivityRule =
            new ActivityTestRule<>(MainActivity.class, true, false);

    @Test
    public void someTest() {
        Context targetContext = InstrumentationRegistry.getInstrumentation()
            .getTargetContext();
        Intent intent = new Intent(targetContext, MainActivity.class);
        intent.putExtra("Name", "Value");

        mActivityRule.launchActivity(intent);

        /* Your activity is initialized and ready to go. */ 
    }
}

I have put a complete, running example on GitHub at barend/android-espresso-intent-sample.

To reopen the discussion, JavaScript guru Dr. Axel Rauschmayer recently asked the question: Is Isomorphic JavaScript a good term? I’ve already left a comment explaining my view of things, but I’d like to explain a little more. I used make the distinction between Functional Isomorphism and Technical Isomorphism. In my talk at XebiCon I explained the difference. Having the server render the HTML on first page load is the functional part, the thing that provides for a better user experience. The technical part is where we use the same code in both environments, which no user ever asked for, but makes a developer’s life easier (at least in theory).

Continue reading at Medium.com

In a series of blogposts, we would like to make a case for the Robot Framework, by showing its greatness through a number of hands-on examples from my upcoming workshop. Next to demonstrating its advantages and strengths we will also expose some of its drawbacks and limitations, as well as touch upon certain risks that flow from harnessing some of its unique features.

Our first three posts will give an introductory overview of the RF, laying the conceptual foundation for the remainder of the series. Therefore these three articles will not concentrate on practical, hands-on examples or instructions, but instead have a more theoretical feel. Moreover, several of the fundamental concepts laid out in them, are applicable not only to the RF, but to most (if not all) test automation frameworks. Consequently, these first three posts target those that miss a basic understanding of test automation (frameworks) in general and/or of the RF in particular. The remainder of the series will be also of interest to more seasoned automation engineers.

We will first look into the basic architecture that underlies the framework and discuss the various components that it is being comprised of. In the second post we will discuss the nature of the keyword-driven approach that the RF entails. The third post will detail a typical test automation work flow.

For a first-hand experience of the pros and cons of the RF, you might want to join the first Robot Framework meetup in the Netherlands.

Robot Framework stack

The RF is written in Python. Consequently, it runs on Python, Jython or IronPython. The framework can thus be used with any OS that is able to run any of these interpreters, e.g. Windows, Linux or OS X. Unless you have a specific reason to do otherwise, the RF should run on Python. A typical situation that would require e.g. Jython, would be automating against a Java application or implementing your own RF test library in Java (more on this in a later post). A disadvantage of running on Jython is that quite a few of the low-level test libraries within the RF ecosystem will not be available. Moreover, running in Jython will slap you with a performance penalty. Fortunately, in the mentioned situations, one could still run the stack on Python, through the usage of the so-called Remote Library Interface mechanism, that can be harnessed to connect the Python stack to an application and/or a test library running in a JVM (on the same or a remote system). We will be addressing the latter subject, as well, in one of our follow-up articles.

A possible, though highly simplified, set-up of an automation framework is the following:

Generic framework high-level design

Green signifies framework components whereas grey refers to components or artefacts, such as test code and product code, that are to be created by the development organization. The numbers indicate the order in which a typical test execution run would flow (more on this in the third post). The framework components are typical of all of today's test automation frameworks. Obviously, this schema is a simplification of a real-life set-up, which would result in a more complex infrastructural model so as to account for topics such as:

• a possible distributed setup of the test engine and/or test driver
• parallel testing against a variety of interfaces (e.g. against REST and some UI) or against a multitude of product configurations/stacks/databases
• integration within a continuous delivery pipe line and with the test code repository
• etc.

Mapping these generic components onto concrete run-times within the RF stack, we get the following:

Robot Framework high-level design

The RF itself functions as the central framework engine. It is the core framework, that is being augmented by various tools and libraries that have been developed within the RF ecosystem, to form the larger, broader framework. (To be precise, in the given example, Selenium Webdriver does not belong to the RF ecosystem. But most of the other available low-level test libraries do.)

Let’s elaborate somewhat on the various components of the framework stack.

Test editor

The test editor is what we use to write, maintain and structure our automation code with. Test code not only consists of test cases, but also of various layers of abstractions, such as re-usable functions (keywords), wrappers, object-maps and global variables.

In the case of the RF, the editor can be anything, ranging from the simplest of text editors to a full-blown IDE. The Robot Framework comes with various editors, such as the RF Integrated Development Environment (RIDE), and with several plug-ins for popular IDE’s and text editors such as Eclipse, IntelliJ, Atom, TextMate or even Vim. But of course, you could also use a separate text editor, such as Notepad++. Which editor to use may depend on factors such as the required complexity of the test code, the layers to which one has to contribute (e.g. high-level test cases or re-usable, low-level test functions), the skill set of the involved automaton engineers (which may be business stakeholders, testers or developers) or simply personal taste.

Depending on the editor used, you may additionally benefit from features such as code completion, syntax highlighting, code extraction, test cases management and debugging tools.

Note that ‘official’ test runs are typically not initiated from within the editor, but through other mechanisms, such as build steps in a CI server or a cron job of some sort. Test runs are initiated from within the editor to test or debug the test code.

Test engine

The test engine, in our case the RF,  is the heart of the framework.

That is, it is the central component that regulates and coordinates and, as such, ties all components together. For instance, some of the tasks of the engine are:

• Parsing the test case files, e.g. removing white spaces, resolving variables and function calls and reading external files containing test data (such as multiple username/password pairs)
• Controlling the test driver (e.g. Selenium Webdriver)
• Catching and handling test library return values
• Error handling and recovery
• Aggregate logs and reports based on the results

Test driver

A test engine, such as the RF, is a generic framework and, as such, cannot itself drive a specific type of application interface, may it be UI (e.g. mobile or web) or non-UI (e.g. a SOAP service or an API). Otherwise it would not be generic. Consequently, to be able to drive the actual software under test, a separate layer is required that has the sole purpose of interacting with the SUT.

The test driver (in RF terms a 'test library' or 'low-level test library') is the instance that controls the SUT. The driver holds the actual intelligence to make calls to a specific (type of) interface. That interface may be non-UI (as would be the case with testing directly against a SOAP-service, http-server, REST-API or jdbc-database) or UI (as would be the case with testing against a web UI or Windows UI).

Examples of test drivers that are available to the RF are Selenium Webdriver (web UI), AutoIt (Windows UI) or the RF test libraries: Android library, Suds library (SOAP-services), SSH library, etc.

The latter are examples of ‘native’ RF test libraries, i.e. libraries that have been developed against the RF test library interface with the express intent of extending the RF. Some of these RF test libraries in turn re-use (that is, wrap) other open source components. The http library, for instance, reuses the Python ‘requests’ http client.

The former are existing tools, developed outside of the RF ecosystem, that have been incorporated into that ecosystem, by creating thin layers of integration code that make the external functionality available to the framework. Which brings us to the integration layer.

Integration layer

The main responsibility of the integration layer is to expose the functionality, as contained within an external tool or library, to the rest of the framework, mainly the engine and editor. Consequently,  the integration layer can also form a limiting factor.

Through the integration layer, the test code statements (as written in RFW syntax) are ‘translated’ into parameterized instructions that adhere to the syntax of the external tool. For instance, in the case of Selenium Webdriver, the RF integration library (called ‘Selenium2Library’) consists of a set of Python (module) files, that contain small functions that wrap one or more Webdriver functions. That is, these Python functions contain one or more Webdriver API-compliant calls, optionally embedded in control logic. Each of these Python functions is available within the framework, thus indirectly providing access to the functions as are exposed by the Webdriver API.

For example, the following function provides access to the Webdriver click() method (as available through the webelement interface):

def click_element(self, locator):
 self._info("Clicking element '%s'." % locator)
 self._element_find(locator, True, True).click()

Within your editor (e.g. RIDE), the function ‘Click element’ can be used in your test code. The editor will indicate that an argument $locator is required.

These Python functions, then, are basically small wrappers and through them the integration layer, as a whole, wraps the external test driver.

As mentioned before, an integration layer is not necessarily part of the stack. Test drivers (test libraries) that have been written directly against the RF library API, do not require an integration library.

Our next post will elaborate on the keyword-driven approach to test automation that the RF follows.

In the blog we will show you that Amazon ECS can be as fast, by presenting you a small utility named ecs-docker-run which will allow you to start a Docker container almost as fast as with Docker stand-alone by interpreting the Docker run command line options. Together with a ready-to-run CloudFormation template, you can be up and running with Amazon ECS within minutes!

ECS Lingo

Amazon ECS uses different lingo than Docker people, which causes confusion. Here is a short translation:

- Cluster - one or more Docker Hosts.
- Task Definition - A JSON representation of a docker run command line.
- Task - A running docker instance. When the instance stops, the task is finished.
- Service - A running docker instance, when it stops, it is restarted.

In the basis that is all there is too it. (Cutting a few corners and skimping on a number of details).

Once you know this, we are ready to use ecs-docker-run.

ECS Docker Run

ecs-docker-run is a simple command line utility to run docker images on Amazon ECS. To use this utility you can simply type something familiar like:

ecs-docker-run \
        --name paas-monitor \
        --env SERVICE_NAME=paas-monitor \
        --env SERVICE_TAGS=http \
        --env "MESSAGE=Hello from ECS task" \
        --env RELEASE=v10 \
        -P  \
        mvanholsteijn/paas-monitor:latest

substituting the 'docker run' with 'ecs-docker-run'.

Under the hood, it will generate a task definition and start a container as a task on the ECS cluster. All of the following Docker run command line options are functionally supported.

All other Docker options are ignored as they refer to possibilities NOT available to ECS containers. The following options are added, specific for ECS:

Hands-on!

In order to proceed with the hands-on part, you need to have:

- jq installed
- aws CLI installed (version 1.7.44 or higher)
- aws connectivity configured
- docker connectivity configured (to a random Docker daemon).

checkout ecs-docker-run

Get the ecs-docker-run sources by typing the following command:

git clone git@github.com:mvanholsteijn/ecs-docker-run.git
cd ecs-docker-run/ecs-cloudformation

import your ssh key pair

To look around on the ECS Cluster instances, import your public key into Amazon EC2, using the following command:

aws ec2 import-key-pair \
          --key-name ecs-$USER-key \
          --public-key-material  "$(ssh-keygen -y -f ~/.ssh/id_rsa)"

create the ecs cluster autoscaling group

In order to create your first cluster of 6 docker Docker Hosts, type the following command:

aws cloudformation create-stack \
        --stack-name ecs-$USER-cluster \
        --template-body "$(<ecs.json)"  \
        --capabilities CAPABILITY_IAM \
        --parameters \
                ParameterKey=KeyName,ParameterValue=ecs-$USER-key \
                ParameterKey=EcsClusterName,ParameterValue=ecs-$USER-cluster

This cluster is based upon the firstRun cloudformation definition, which is used when you follow the Amazon ECS wizard.

And wait for completion...

Wait for completion of the cluster creation, by typing the following command:

function waitOnCompletion() {
        STATUS=IN_PROGRESS
        while expr "$STATUS" : '^.*PROGRESS' > /dev/null ; do
                sleep 10
                STATUS=$(aws cloudformation describe-stacks \
                               --stack-name ecs-$USER-cluster | jq -r '.Stacks[0].StackStatus')
                echo $STATUS
        done
}

waitOnCompletion

Create the cluster

Unfortunately, CloudFormation does (not) yet allow you to specify the ECS cluster name, so need to manually create the ECS cluster, by typing the following command:

aws ecs create-cluster --cluster-name ecs-$USER-cluster

You can now manage your hosts and tasks from the Amazon AWS EC2 Container Services console.

Run the paas-monitor

Finally, you are ready to run any docker image on ECS! Type the following command to start the paas-monitor.

../bin/ecs-docker-run --run-as-service \
                        --number-of-instances 3 \
                        --cluster ecs-$USER-cluster \
                        --env RELEASE=v1 \
                        --env MESSAGE="Hello from ECS" \
                        -p :80:1337 \
                        mvanholsteijn/paas-monitor

Get the DNS name of the Elastic Load Balancer

To see the application in action, you need to obtain the DNS name of the Elastic Load Balancer. Type the following commands:

# Get the Name of the ELB created by CloudFormation
ELBNAME=$(aws cloudformation describe-stacks --stack-name ecs-$USER-cluster | \
                jq -r '.Stacks[0].Outputs[] | select(.OutputKey =="EcsElbName") | .OutputValue')

# Get the DNS from of that ELB
DNSNAME=$(aws elb describe-load-balancers --load-balancer-names $ELBNAME | \
                jq -r .LoadBalancerDescriptions[].DNSName)

Open the application

Finally, we can obtain access to the application.

open http://$DNSNAME

And it should look something like this..

Perform a rolling upgrade

You can now perform a rolling upgrade of your application, by typing the following command while keeping your web browser open at http://$DNSNAME:

../bin/ecs-docker-run --run-as-service \
                        --number-of-instances 3 \
                        --cluster ecs-$USER-cluster \
                        --env RELEASE=v2 \
                        --env MESSAGE="Hello from Amazon EC2 Container Services" \
                        -p :80:1337 \
                        mvanholsteijn/paas-monitor

The result should look something like this:

Note how the rolling upgrade is a bit crude. The old instances stop receiving requests almost immediately, while all requests seem to be loaded onto the first new instance.

You do not like the ecs-docker-run script?

If you do not like the ecs-docker-run script, do not dispair. Below are the equivalent Amazon ECS commands to do it without the hocus-pocus script...

Create a task definition

This is the most difficult task: Manually creating a task definition file called 'manual-paas-monitor.json' with the following content:

{
  "family": "manual-paas-monitor",
  "containerDefinitions": [
    {
      "volumesFrom": [],
      "portMappings": [
        {
          "hostPort": 80,
          "containerPort": 1337
        }
      ],
      "command": [],
      "environment": [
        {
          "name": "RELEASE",
          "value": "v3"
        },
        {
          "name": "MESSAGE",
          "value": "Native ECS Command Line Deployment"
        }
      ],
      "links": [],
      "mountPoints": [],
      "essential": true,
      "memory": 256,
      "name": "paas-monitor",
      "cpu": 100,
      "image": "mvanholsteijn/paas-monitor"
    }
  ],
  "volumes": []
}

Register the task definition

Before you can start a task it has to be registered at ECS, by typing the following command:

aws ecs register-task-definition --cli-input-json "$(<paas-monitor.json)"

Start a service

Now start a service based on this definition, by typing the following command:

aws ecs create-service \
     --cluster ecs-$USER-cluster \
     --service-name manual-paas-monitor \
     --task-definition manual-paas-monitor:1 \
     --desired-count 1

You should see a new row appear in your browser:

Conclusion

Amazon EC2 Container Services has a higher learning curve than using plain Docker. You need to get passed the lingo, the creation of an ECS cluster on Amazon EC2 and most importantly the creation of the cumbersome task definition file. After that it is almost as easy to use as Docker run.

In return you get all the goodies from Amazon like Autoscaling groups, Elastic Load Balancers and multi-availability zone deployments ready to use in your Docker applications. So, check ECS out!

More Info

Checkout more information:

• ecs-docker-run
• Amazon EC2 Container Service Documentation
• Amazon ECS CloudFormation Types

After being in the working draft state for a long time, the ES2015 (formerly known as ECMAScript 6 or ES6 shorthand) specification has reached a definitive state a while ago. For a long time now, BabelJS, a Javascript transpiler, formerly known as 6to5, has been available for developers that would already like to use ES2015 features in their projects.

In this blog post I will show you how you can integrate Webpack, a Javascript module builder/loader, with Babel to automate the transpiling of ES2015 code to ES5. Besides that I'll also explain you how to automatically generate source maps to ease development and debugging.

Webpack

Introduction

Webpack is a Javascript module builder and module loader. With Webpack you can pack a variety of different modules (AMD, CommonJS, ES2015, ...) with their dependencies into static file bundles. Webpack provides you with loaders which essentially allow you to pre-process your source files before requiring or loading them. If you are familiar with tools like Grunt or Gulp you can think of loaders as tasks to be executed before bundling sources. To make your life even easier, Webpack also comes with a development server with file watch support and browser reloading.

Installation

In order to use Webpack all you need is npm, the Node Package Manager, available by downloading either Node or io.js. Once you've got npm up and running all you need to do to setup Webpack globally is install it using npm:

npm install -g webpack

Alternatively, you can include it just in the projects of your preference using the following command:

npm install --save-dev webpack

Babel

Introduction

With Babel, a Javascript transpiler, you can write your code using ES2015 (and even some ES7 features) and convert it to ES5 so that well-known browsers will be able to interpret it. On the Babel website you can find a list of supported features and how you can use these in your project today. For the React developers among us, Babel also comes with JSX support out of the box.

Alternatively, there is the Google Traceur compiler which essentially solves the same problem as Babel. There are multiple Webpack loaders available for Traceur of which traceur-loader seems to be the most popular one.

Installation

Assuming you already have npm installed, installing Babel is as easy as running:

npm install --save-dev babel-loader

This command will add babel-loader to your project's package.json. Run the following command if you prefer installing it globally:

npm install -g babel-loader

Project structure

webpack-babel-integration-example/
  src/
    DateTime.js
    Greeting.js
    main.js
  index.html
  package.json
  webpack.config.js

Webpack's configuration can be found in the root directory of the project, named webpack.config.js. The ES6 Javascript sources that I wish to transpile to ES5 will be located under the src/ folder.

Webpack configuration

The Webpack configuration file that is required is a very straightforward configuration or a few aspects:

• my main source entry
• the output path and bundle name
• the development tools that I would like to use
• a list of module loaders that I would like to apply to my source

var path = require('path');

module.exports = {
  entry: './src/main.js',
  output: {
    path: path.join(__dirname, 'build'),
    filename: 'bundle.js'
  },
  devtool: 'inline-source-map',
  module: {
    loaders: [
      {
        test: path.join(__dirname, 'src'),
        loader: 'babel-loader'
      }
    ]
  }
};

The snippet above shows you that my source entry is set to src/main.js, the output is set to create a build/bundle.js, I would like Webpack to generate inline source maps and I would like to run the babel-loader for all files located in src/.

ES6 sources

A simple ES6 class

Greeting.js contains a simple class with only the toString method implemented to return a String that will greet the user:

class Greeting {
  toString() {
    return 'Hello visitor';
  }
}

export default Greeting

Using packages in your ES2015 code

Often enough, you rely on a bunch of different packages that you include in your project using npm. In my example, I'll use the popular date time library called Moment.js. In this example, I'll use Moment.js to display the current date and time to the user.

Run the following command to install Moment.js as a local dependency in your project:

npm install --save-dev moment

I have created the DateTime.js class which again only implements the toString method to return the current date and time in the default date format.

import moment from 'moment';

class DateTime {
  toString() {
    return 'The current date time is: ' + moment().format();
  }
}

export default DateTime

After importing the package using the import statement you can use it anywhere within the source file.

Your main entry

In the Webpack configuration I specified a src/main.js file to be my source entry. In this file I simply import both classes that I created, I target different DOM elements and output the toString implementations from both classes into these DOM objects.

import Greeting from './Greeting.js';
import DateTime from './DateTime.js';

var h1 = document.querySelector('h1');
h1.textContent = new Greeting();

var h2 = document.querySelector('h2');
h2.textContent = new DateTime();

HTML

After setting up my ES2015 sources that will display the greeting in an h1 tag and the current date time in an h2 tag it is time to setup my index.html. Being a straightforward HTML-file, the only thing that is really important is that you point the script tag to the transpiled bundle file, in this example being build/bundle.js.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Webpack and Babel integration example</title>
</head>
<body>

<h1></h1>

<h2></h2>

    <script src="build/bundle.js"></script>
</body>
</html>

Running the application

In this example project, running my application is as simple as opening the index.html in your favorite browser. However, before doing this you will need to instruct Webpack to actually run the loaders and thus transpile your sources into the build/bundle.js required by the index.html.

You can run Webpack in watch mode, meaning that it will monitor your source files for changes and automatically run the module loaders defined in your configuration. Execute the following command to run in watch mode:

webpack --watch

If you are using my example project from Github (link at the bottom), you can also use the following script which I've set up in the package.json:

npm run watch

Easier debugging using source maps

Debugging transpiled ES5 is a huge pain which will make you want to go back to writing ES5 without thinking. To ease development and debugging of ES2015 I can rely on source maps generated by Webpack. While running Webpack (normal or in watch mode) with the devtool property set to inline-source-map you can view the ES2015 source files and actually place breakpoints in them using your browser's development tools.

Running the example project with a breakpoint inside the DateTime.js toString method using the Chrome developer tools.

Conclusion

As you've just seen, setting up everything you need to get started with ES2015 is extremely easy. Webpack is a great utility that will allow you to easily set up your complete front-end build pipeline and seamlessly integrates with Babel to include code transpiling into the build pipeline. With the help of source maps even debugging becomes easy again.

Sample project

The entire sample project as introduced above can be found on Github.

This challenge was taken on by the Medical HW manufacturer Optinova in August. Over the course of two days, we pushed the limits of “what is possible” by applying Agile in a HW environment.

Our hypothesis was that Agile would be a good fit in product development and innovation scenarios. And the result so far from the work that we have been doing with Optinova is promising.

Cross-functional teams, focus, rapid prototyping, close customer feedback and visual overview work just as well in hardware as in software. The training setup we used was as follows:

• Day 1 – Learn basic Agile practices and principles
• Day 2 – Applying them – developing three product ideas from scratch in one day, in a rapid prototyping workshop.

The result: All three participating teams managed to take an idea to working prototype in a day. One team went so far as submitting a bid to a real customer the following day based on their prototype. That’s high speed, even in software terms. But the most important thing wasn’t the result, it was the lessons learned. When we asked the participants if they wanted to continue to build products this way, the votes were unanimously in favor. If we can get it to work, this would help build a competitive and innovative company.

This is what the teams said that made them fast:

• Cross-functional / cross-department collaboration
• Experience in the field
• Focus!
• Prototype often
• It’s ok to fail!

Ok, that seems pretty logical. The more interesting question is: how often does this actually happen on a regular work day?

Here are the more unexpected findings during the rapid prototyping workshop:

• Most teams dropped sprints in favor of regular stand-ups, Kanban and shared designs during the day. One obvious reason was because the sprint lengths chosen by the teams were too short to produce anything worth demo-ing.
• When the teams started to produce designs together, it was no longer necessary to have updated post-its. My take on this is that the team needs to get an overview of what needs to be done, and in what order. If they can accomplish this in a simpler way than using post-its, then so be it

Note: Being process compliant was an explicit non-goal during this exercise. We gave the teams quite a bit of slack to find a way that worked for them, but stayed close to pick them up if they hit a dead end.

Validating tolerances

Cross functional team experimenting in Lab

So, we can tell you that using Agile in Hardware, especially in product development scenarios actually works!

Del 6 är i serien “TDD på svenska” handlar alltså om detta och har precis nu publicerats på vår YouTube-kanal “Crisp Agile Academy”.

Du hittar som vanligt de tidigare delarna i serien och mycket annat producerat av mina kollegor. Speciellt tack till Jimmy Janlén för foto, regi och klipp

Turen har kommit till att berätta om Wunderkraut, som använt Agila kontrakt sedan 2010. Det intressanta är hur de i den ombytliga webb och reklamvärlden, framgångsrikt bygger långvariga relationer med sina kunder. De har tagit steget från att se Agil utveckling som “något som sker inom IT” – till något som driver bättre affärer. Agila kontrakt är av nycklarna. Läs hela storyn här.

Psst:  Häng med på vårt frukostseminarium den 16 Oktober om upphandling med Agila kontrakt som vi samarrangerar med Wunderkraut. Varför inte ta chansen och träffa oss båda? Anmäl dig på: http://akademi.wunderkraut.se/frukostseminarium-agil-upphandling

Därför att du kommer inte kunna dra nytta av det agila arbetssättet. pm³ är baserat på en helt annan världsbild. pm³ bygger på årsplaner och att verksamheten beställer från en leverantör, typiskt den egna IT-avdelningen.  Agilt har som en grundläggande värdering att reagera på förändringar i stället för att följa en plan. Det agila arbetssättet drivs proaktivt genom utforskande i motsats till att vara en mottagare av beställningar.

Vi har sett flera försök att implementera pm³ och de har ofta misslyckats på grund av att pm³ bygger på tankar om att verkligheten kan förutsägas 18 månader i förväg, att användarna vet vad de vill ha och att det är viktigt att ha en skarp linje mellan verksamhet och IT. Vi hävdar (och flera med oss törs vi lova) att inget av detta är varken sant eller bra.

Kan framtiden förutsägas?

De implementationer av pm³ vi har sett bygger alla på årsplaner. Verksamheten förväntas skriva en förvaltningsplan där de förändringar de vill ha i sin verksamhet och sitt IT-stöd ska beskrivas. Eftersom detta ska gå i symbios med en budgetprocess där pengar ska äskas till dessa förändringar, krävs det att man börjar arbeta med planen i god tid. Man måste ju tänka efter ordentligt när man ska göra en plan! Detta leder ofta till att planeringsarbetet påbörjas direkt efter sommarsemestrar om planen ska vara klar till årsskiftet.

Det ironiska i det här arbetssättet är att för att kunna få till en vettig plan för förändring av IT-stöd måste IT-avdelningen blandas in, vilket tar tid från den förra planens planerade initiativ. Så då måste det ingå planering i planen. Det blir en negativ spiral.

Men det stora problemet med det här arbetssättet är inte lustifikationer i planeringen, utan att ens tro att det går att förutsäga framtiden ett och ett halvt år i förväg. För att det ska fungera måste tre hypoteser stämma;

1. Verksamheten vet alltid vad den vill ha
2. IT vet hur det ska realiseras
3. Verkligheten står still i dessa 1,5 år

Naturligtvis är det inte så, snarare så här:

1. Verksamheten upptäcker vad den behöver efter hand
2. IT inser efter hand hur det ska realiseras
3. Mycket händer i verksamheten på 1,5 år

Det här är en av orsakerna att agila arbetssätt har utvecklats. När vi jobbar agilt så gör vi en ansats, realiserar den, mäter och utvärderar (vad verksamheten tycker), och tar sedan hänsyn till resultatet och integrerar det i nästa ansats.

Istället för att först göra all planering och sedan all implementation, så delar vi upp planeringen och implementationen i små, hanterbara bitar, och ser till att mäta och utvärdera resultatet däremellan.

En skarp linje mellan verksamhet och IT

Ett införande av pm³ i din organisation leder till en tydlig separation mellan verksamheten och IT, beställare och leverantör (se bild nedan). Den inför också en dubblerad hierarki i din verksamhet och din IT-avdelning.

pm³:s förvaltningsmodell

Inom agilt arbete strävar man istället efter att överbrygga alla kommunikationshinder och föra verksamhet och IT närmare varandra. Förändringar i IT-system förändrar verksamheten som i sin tur förändrar behoven av IT-stöd i en ständigt pågående symbios. Standish Group har sedan 1994 publicerat sin CHAOS report². I den presenteras framgångsfaktorer för att IT-projekt ska lyckas. Varje rapport sedan 1994 har haft “User Involvement” på första eller andra plats¹.

En agil produktägare står inte mellan intressenter och utvecklare, en produktägare faciliterar kommunikationen så att den blir så direkt som det går utan att störa. Genom ständiga utvärderingar så formas det agila arbetssättet så att det passar just den organisation där den verkar.

Produktägaren faciliterar kommunikationen mellan verksamhet och IT

Scrum löser inte alla problem

Vi vet att agila metoder inte löser alla problem. T ex så är Scrumguiden bara på 16 sidor och beskriver bl. a. inte hur man gör när man har många team, eller om ett team har många produkter. Men det är inte heller meningen. Meningen är att man kontinuerligt ska jobba vidare med sin process för att skapa den process man behöver. Detta då till skillnad från färdiga hyllprodukter som t ex pm³, där man ska anpassa sin organisation efter processen.

Kan man inte ta det bästa av båda världar då? Vi hävdar att det inte går och det beror på de grundläggande värderingar skiljer sig åt.

Gillar du pm³ så kör på det, gillar du agilt så kör på det, men kombinera inte de två.

Kom dock ihåg att all information om agilt arbetssätt är öppen och tillgänglig medan pm³ är en proprietär produkt som du betalar licens för.

Referenser:

1. http://www.cafe-encounter.net/p1183/it-success-and-failure-the-chaos-report-factors#gsc.tab=0
2. http://www.projectsmart.co.uk/docs/chaos-report.pdf

Kanban in 30 days

Designed as a 30-day action plan, this book will help you understand and implement Kanban – and start seeing results – in a month.

Analyze your current situation and define your goals and wider strategic aims, and begin developing a plan to help you and your team confidently work towards achieving them. Involve your team into driving cultural change, learn how to prioritize, and organize tasks and projects to efficiently use your time and resources.

Create your own value stream map to better understand your processes and identify improvement areas, and adapt and use the features, tips, and examples to overcome challenges you may face when implementing Kanban. Pick up this book and experience the full results of this vital Agile methodology-fast.

Who this book is written for

If you want to simplify your processes, improve collaboration, and manage projects successfully, this guide to Kanban is an essential companion. Created primarily for software developers, but packed with insights and tips for anyone who understands the challenges of project management, this is your rapid route into innovative and Agile ways of working.
> Learn the fundamentals of Agile and Kanban
> Analyze your current processes and identify areas of improvement
> Develop a Kanban board to manage your projects by using and adapting the featured examples
> Develop a coherent strategy for collaboration
> Improve your processes with tips and tricks to promote efficiency > Follow each step in this 30-day plan to ensure a smooth Kanban implementation

All this in only 95 pages. The value is not the number of pages to read – it’s the number of pages you don’t need to read.

Buy it at Amazon, Bokus or Adlibris.

I hope you will enjoy reading it.

/Tomas

Learn how we:

• Improved the full value chain by using Enterprise Kanban.
  (Find out how we improved time to market and shifted focus from Sprints to Flow to deliver customer value in a traditional company.)
• Boosted engagement, teamwork, and flow in change management and operations.
• Saved a derailing project with Kanban.
• Helped an office team outside IT keep up with growth using Kanban.

Inside each case story, you’ll find guerilla techniques on how we made improvements happen (including cases where we #failed). I also walk through why focusing on “improving IT” can make you miss your biggest improvement opportunity (the front end part of your value stream) as well as the 5 system “enablers” that guided our long term improvements.

Get “Real World Kanban” from:

• http://www.amazon.com/Real-World-Kanban-Less-Accomplish-Thinking/dp/1680500775/

I den stunden myntades ett nytt begrepp – “behovsställan”.

Insikten hade hon fått genom att vi hade gjort övningar i att gemensamt definiera målgrupper med gemensamma behov, och sedan titta på vilka dom behoven var genom att göra user journeys. Insikten att vi definierar befintliga beteenden och hittar problem som utgångspunkt i upphandlingen gjorde stor skillnad i att förstå att en lyckad upphandling måste vara en upphandling som utgår från behov och löser riktiga problem för riktiga användare.

Ett skifte som många behöver göra

Ofta när jag jobbar på produktföretag, oavsett storlek, så ser jag att just detta är är ett skifte som behöver göras. Många företag fokuserar direkt på vad lösningen är genom att beskriva en detaljerad lösning, i stället för att först titta på VARFÖR och för VEM, vad är behovet och vilka problem ska vi lösa? Har vi inte förstått vad problemet är och för vem, så kan vi inte heller hitta den rätta lösningen. Det faktiska utförandet av lösningen bör ligga i teamet, och inte hos beställaren, det är dom som har kunskapen och verktygen att bygga lösningen på rätt sätt, beställaren bör fokusera på att man bygger rätt sak.

De vanligaste upplevda problemen för upphandlare

När jag frågar de som gör upphandlingar av digitala tjänster och produkter så brukar de största upplevda problemen vara att det är svårt:

– Att i förväg definiera alla “kraven” rätt.
– Att få med “allt” i upphandlingsunderlaget.
– Att få leverantören att leverera något som fungerar.

Allt detta löser man om man upphandlar utifrån behov och effekt, i stället för att upphandla utifrån en fix lösning – som man sedan oundvikligen kommer att upptäcka var fel lösning.

Endast en bråkdel av systemen används av användarna

Wasten i de flesta IT-projekten ligger över 60%

På grund av att upphandligar ofta görs så att man fixerar lösningen från början och inte tillåter sig upptäcka vilka behoven och lösningarna är, så ser vi i dag i de flesta system att endast 20% av systemets funktioner används ofta, och ytterligare 20% som används sällan. Hela 60% av funktionerna i de flesta system används ALDRIG! Det här är självklart en katastrof både för beställaren som betalar för något helt i onödan, får ett system som är onödigt dyrt att underhålla,får en senare leverans än nödvändigt, och även användaren så klart, som drabbas av gränssnitt som är oanvändarvänliga på grund av dålig struktur, för många val och information och funktioner som ligger ivägen för det man egentligen vill göra. Tänk vilken skillnad det skulle göra inom verksamheter som tex ett sjukhus om man hade IT-system var byggt efetr behov, som gav rätt stöd till läkare och sjuksystrar, som inte krävde att man lade in samma information 4 gånger i 4 olika system för att hantera ett litet ärende. Och tänk vilken ekonomisk skillnad det skulle göra för Landstingen.

Lösningen ligger delvis i att vända på upphandlingsförfarandet och “behovsställa” i stället för “kravställa”. Jag hoppas det blir den nya standarden, och att fler drabbas av samma aha-upplevelse som både jag och min kursdeltagare.

Agila kontrakt – den röda tråden som löper från behovställan till användande och skapar effekt

Ett sätt att få behoven i fokus hela vägen till leverans och implementation är genom att använda Agila kontrakt. Agila kontrakt möjliggör behovsställning, och ger beställaren möjlighet att sätta effekter som mål och tillåter en lärande process tillsammans med leverantören genom att man får byta ut “krav” om man upptäcker att dom är felaktiga. Du kan läsa mer om agila kontrakt och se lyckade case på den dedikerade webbplats som jag har skapat tillsammans med min kollega Mattias Skarin.

Agilakontrakt.se

Agilakontrakt.se

Goda exempel på lyckade upphandlingar med Agila kontrakt

För att lyckas i vår strävan att förändra och förbättra världen insåg vi att vi behövde visa lyckade exempel. Därför började Mattias att leta över hela Norden och intervjua företag och organisationer som har gjort lyckade upphandlingar och affärer. Det kommer nya uppdateringar löpande i form av intervjuer och artiklar med nyttig information. Här är ett smakprov på de vi har för närvarande:

1. Lyckas med användbarhet i IT upphandling – intervju med Clas Thorén

En viktig komponent för att lyckas med ett IT system är fokus på användbarheten. Ett Agilt kontrakt är ett sätt att formalisera detta. Oavsett kontraktsform kan man ställa sig frågan: kan jag kravställa användbarhet? Svaret är ja – både i offentlig och privat upphandling. Vi har intervjuat Clas Thorén, som berättar vad man bör tänka på. Clas har arbetat som upphandlare i många år och är användbarhetsspecialist vid upphandlingar. Clas är medförfattare till ”Att beställa användbara it-system” som beskriver ett antal upphandlingscase som haft användbarhet i fokus, bland annat Ekonomistyrningsverket (ESV) .
Läs hela intervjun på agilakontrakt.se >

2. Agila kontrakt i större projekt – ERST.dk

Hur kan man lyckas med Agila kontrakt i ett större projekt? Låt oss lära oss av ERST.dk – motsvarigheten till Svenska Bolagsverket. 2010 fick myndigheten medel för att lyfta och modernisera 20 system till ny arkitektur. Förutom gammal arkitektur var licenskostnaderna för tekniken betydande. Tidigt satte två effektmål för moderniseringen – Effektivitet och Användarvänlighet. Det explicita effektmålet sammanfattades i att ”det skall vara enkelt att vara ett företag i Danmark”.
Läs hela artikeln på agilakontrakt.se >

3. Erfarenheter från en riktig Agil upphandling : Intervju med Tomer Shalit från Ping Pong

Mattias Skarin intervjuar Tomer Shalit tidigare Utvecklingschef på Ping Pong AB, ett företag i e-learning branschen med offentliga kunder såsom landsting, universitet, kommuner och även större privata företag. Under vintern bistod han ett företag inom utbildningsväsendet att utföra en större Agil upphandling.

M: Vad var er tidiga erfarenhet med att arbeta Agilt med era kunder?

T: Vår tidiga erfarenhet av att jobba agilt kom från arbete med våra befintliga kunder. Vi hade genomfört gemensamma projekt där de gjort en nogrann kravspec, de fått vad de beställde men vid leverans insåg de att det inte var det de vill ha. Det var frustrerande och dyrt för alla parter. För de kunderna var det inte så svårt att komma överens om att istället försöka med ett agilt arbetssätt, där de kunde justera beställningen under leveransens gång.
Läs hela intervjun på agilakontrak.se >

4. Att beställa användarvänliga system inom ramen för LOU

Det finns goda exempel på systemlösningar som upphandlats inom ramen för LOU men med fokus på användarvänlighet. Något som brukar komma i andra eller tredje rummet för att vi tror att det inte går utvärdera objektivt eller för att det faller bort i konkurrens med funktion och pris.
Läs hela artikeln på agilakontrakt.se >

5. Hur Wunderkraut håller budget och bygger långsiktiga relationer med Agila kontrakt

”wundkraut_personernaSom kund skall man kunna göra karriär genom att jobba med oss”
Vad är Wunderkraut? Wunderkraut är en helt ovanlig webbyrå i Stockholm. Som många andra dynamiska och kreativa byråer sitter de i klassiska renoverade fabrikslokaler med högt i tak, öppna ytor och med ett trumset i mitten. Men det som utmärker är ledningens nyfikenhet, engagemang och passion för sin personal. Och hur långt man har kommit i att använda agila metoder för lyckade projekt.

Wunderkraut är inte precis några nybörjare på Agila kontrakt. De började experimentera med Agila kontrakt så tidigt som 2010 och till dags dato har man levererat runt 100 projekt med hjälp av Agila kontrakt.

Vi träffade webbstrategen Tomas Persson och affärsutvecklaren Fabian von Tiedemann på Wunderkraut för att lära oss av deras erfarenheter..
Läs hela intervjun på agilakontrakt.se >

Mer goda exempel på lyckade upphandlingar med Agila kontrakt kommer att komma, håll dig uppdaterad på agilakontrakt.se.

Kontakta mig eller Mattias skarin om du är intresserad av att få veta mer, vill ha en föreläsning på företag eller myndighet, eller vill gå utbildningen.

One property of legacy code is inflation by irrelevant logging statements. Not only does this increase the size of a bulging code base, I’d also argue that it’s dead wrong.

Quite recently I’ve had the honor of making acquaintance with a piece of code that looked roughly like this:

if (LOGGER.isLoggable(Level.FINEST)) {
    LOGGER.log(Level.FINEST, "foo is now", foo.getValue());
}
boolean result = doSomeActualWork(foo);
if (LOGGER.isLoggable(Level.FINER)) {
    LOGGER.exiting(this.getClass().getName(), "bar", result);
}

This was the end of a method. The beginning looked quite similar, and so did thousands of other methods in that code base. It was most definitively not my first encounter with this “pattern”, and it certainly won’t be the last, but this time I decided to spend some time explaining why I think this is a bad thing to do.

The issue

Why is this problematic? Logging things should indicate a considerate programmer who tries to be defensive and friendly by helping you to get a bunch of randomly selected values in your face, should you decide to turn on/up the logging.

The issue has to do with noise, relevance, and cyclomatic complexity. Look at the seven lines of code above. Out of seven lines, only one is important. That’s the line you’ll read when changing the code. That’s the line you’ll need to understand … And that’s the line you’ll need to filter out from six totally irrelevant lines. The illustration at the beginning of this post shows what the code looks like if you squint when reading it. Legacy code bases already suffer from misused and overused design patterns, superfluous comments, and learning on the job code, so you don’t need to add more lines of code. Your predecessors have already done it for you.

Then there’s the increase in cyclomatic complexity. See the two if statements? They turn a harmless piece of code into something that has two conditional statements that your brain needs to process.

–Is the log level set to finest? Jolly good! Let’s log the value of foo just in case somebody will need it.

–Are we logging at the finer level now? Exciting! Let’s tell everybody that we’re leaving the method.

Now you have introduced conditional accidental complexity.

The reasons

Why is code like this created? I’m just guessing, but here are my theories:

A genuine will to help – People want to help. The programmer who wrote this code wanted to help future readers by logging things that were important to him.

Lack of unit tests – The inability to verify assumptions about the code during development often translates to the second best thing–verification at runtime.

Poor controllability and observability – Some systems are so (accidently) complex to set up and monitor that even debugging won’t help. This is yet another reason for sprinkling log statements throughout the code.

Ignorance – Then there’s the issue of actually understanding how a logging framework actually works. It so happens that logging frameworks check the log level themselves in the output methods, so you don’t have to duplicate the effort. The if statements in the example above are only necessary if the cost of printing the object is so high that it would impact performance.

Groupthink – It’s really safe to repeat patterns seen frequently enough throughout the code base.

The exceptions

At this point, I wish I could just say: “Don’t ever use logging. Write your unit tests and start trusting your code!” But there are actual reasons in favor of logging. I can think of two, and I invite people to comment on this post and give me some more!

1. Logging used with a purpose – This kind of logging is part of someone’s requirements. Either the customer or another stakeholder wants certain kind of information, which is conveniently available through logging. It may be some kind of transaction history used for auditing or performance figures for further analysis. In such cases, the logged information should be part of the requirements, and the developers should write tests to verify that it works.
2. Logging required by operations – This is actually a variant of the reason above. If you’ve worked in operations you know that there are cases in which you want something logged. You may want to get a feeling for how often something’s used, or you may suspect that something’s broken, but you can’t reproduce it. In such cases, having things logged is quite helpful. The difference from the first case is that the logging may be temporary and won’t require its own tests.

Summary

Don’t fly on auto pilot and add tons of log statements to your applications because everyone else does. It just makes the code unreadable and harder to maintain. If you want to be certain about your code, write tests! Save the logging for when it matters: If it’s an actual requirement or if it will help operations.

There was a debate about this and Scrum Alliance created the Scrum Master Manifesto in 2011.

Even though this has been debated by many minds before, I still get asked what my views are on this topic.

I’ve done all kinds of variations on this role. I’ve been a dedicated Scrum Master for a single team. I have done the SM role and a developer role at the same time. I’ve been a Scrum Master for several teams at the same time. These alternatives have their own advantages and challenges. In this post I intend to describe my view and recommendations.

Primary and secondary roles

First of all, I believe that the Scrum Master role is important enough to be the primary role when you have several roles. So, if you are a SM/Developer, any SM-related work should take precedence over developer work. What implications does this have? It means that you must be able to drop whatever else you are working on, when the team needs you to wear the SM hat. Imagine you are coding on a feature and another team member can’t continue working because there are conflicting requirements or another impediment. Enter the Scrum Master. You now need to drop what you are working on to resolve these conflicting requirements, probably together with the Product Owner. This means you should probably rarely take lead on the top feature. Why? Beacuse you may need to stop working on it at any time, and since it is the top feature, it should be the top priority of at least someone in the team, preferrably several people in the team. In the SM/Developer role, I think it works well to see yourself as a supportive programmer. You work together with others, do pair programming, help someone nail down a bug and fix the broken pipeline someone is struggling with.

Working in several teams

Which team is your team? Can a person be a member of several teams? Sure, but it is unlikely you will be a full member, comparable to the other, full-time members of the team. If you are a Scrum Master for several teams, then it is quite likely you have a role in some management group, and then that group is probably your primary team. The Scrum teams will then become your secondary teams.

Working in several teams will also stretch you and it will become hard to keep track of everything that is going on in each team. Keeping informed will require disturbing team members and you may become a impediment yourself… When you are in a single team, you are constantly in on all conversations and happenings, and you get a feeling for what the team needs to advance forward.

Also, if you are a SM in several teams and both teams need your help, how do you prioritise? I’ve had this role and done it with some success, but it is stressful and sometimes you need to choose which team needs your help the most.

Regardless if you are a Scrum Master or if you have some other role, I prefer to be in a single team. It’s easier and much better for the team.

Not enough work for a full-time Scrum Master

Let’s say we have a team that needs a Scrum Master, but we don’t think it needs to be a full time role. We acknowledge that the SM role needs to be the primary one, but we cannot find a suitable secondary role for the intended Scrum Master. Is it wasteful to have a SM who probably won’t have enough to do?

In my experience, this is often the line of thought that leads to problematic situations like a SM for several teams. I don’t really have a perfect solution for this that can be applied in any situation. Like argued, I prefer to have people working full time in a single team. If there is not enough work to do as a SM in a single team, I try to find a good secondary role for this person in this team and encourage them to improve their Scrum Master skills. Perhaps learn some new facilitation techniques, agile games or visualisation. Perhaps the person is interested in learning a new craft, such as programming. I do prefer a person doing several roles in a single team than a person working for several teams.

In summary

I don’t really care about doing Scrum by the book or not. I care about what works. In my experience, being in a single team is more likely to work well. Working for several teams is quite hard and will force you to make difficult choices, sometimes leaving other teams disappointed. Having several roles in a single team can work well, but it is ofcourse harder and also requires more skills of the individual.

I en uppföljande open space samlade vi också ihop olika praktiker som stödjer samarbetets tekniker.

Samarbetets mekanik

Samarbetets praktiker

I’ve spent a few years working with Spotify and published a few things that have gained a surprizing amount of attention – especially the scaling agile article and spotify engineering culture video. This has come to be known as the “Spotify Model” in the agile world, although it wasn’t actually intended to be a generic framework or “model” at all. it’s just an example of how one company works. The reason why I shared this material is because my Spotify colleagues encouraged me to, and because, well, that’s what I do – help companies improve, by learning stuff and spreading knowledge.

Since then, many companies have been “copying” the Spotify model, which I found rather scary at first. But now I’ve met quite a number of those companies (and heard back from even more), and so far I have yet to see a case where a company ended up in a worse position than where they were. In fact, some have seen some huge improvements! Pretty surprising actually. So apparently, yes, companies can copy models from each other, and it can sometimes be helpful – mainly because it’s almost always valuable to look at your own organization and process with a critical eye, and take inspiration from others. As long as you adapt to your local context (which most do, eventually).

So, back to the messenger thing.

I’ve noticed, via various blogs and articles and presentations, that people sometimes seem to make the assumption that I invented the Spotify model. Well, I most certainly didn’t! I’m just the messenger. Everything I do at Spotify (and other clients) is collaborative. As coach and mentor I have no formal authority, so I have to work with and through other people. The Spotify model is the result of a lot of people collaborating and experimenting over time, and many aspects of the model were invented without my involvement at all. I certainly wouldn’t want to take credit from the people involved.

So, if you see or hear anyone making the claim that I invented the model, please point out that I didn’t, and refer them to this blog if there are any doubts.

Thanks!

/Henrik

It was interesting to see other speakers (for example the Google guy) share similar experiences on product development (keep up speed, prototype and fail fast). I couldn’t agree more on the quote: “If it isn’t tested, it is broken”.

The coolest demo of the day was a JavaScript live code demo of JS interacting with HW devices for example pulse meters . (Thanks @wouter).

Thanks Maarten for bringing together so many interesting people.
Here are my slides – Introducing Concepts.

För det är ju just det det handlar om. Först vände programmerarna upp och ner på mjukvarubranschen genom att börja ge bort sitt arbete som fri källkod. Nu vänder de upp och ner på företagen genom att göra den gamla sortens chefer överflödiga.

Programmering handlar om att generera kunskap. Och det sker bäst när man får arbeta direkt mot användarna och när man själv får styra sitt arbete. När man får makt över sitt liv på jobbet, kort sagt. Och eftersom allt mer i samhället kräver programmerare får programmerarna makt. De kan forma sina arbetsliv så bra som det är möjligt.

Denna förändring är så spännande att följa och i Tillsammans skildrar jag mitt arbete som chef i en produktorganisation och hur vi förvandlade den till en utvecklingsorganisation i världsklass, med hjälp av agile och lean och en hel del gnutta sunt förnuft, och framförallt: extremt experimenterande.

Jag påbörjade och en märklig resa där min roll som chef drastiskt förändrades: den som behöver praktiska tips om hur man gör med utvecklingssamtal, karriärvägar, lönesättning, kompetensutveckling och rekrytering i en organisation som domineras av självorganiserande team hittar gott om tips i Tillsammans hoppas jag.

Läs mer om Tillsammans här eller köp direkt från:
adlibris och bokus.

What happens when Kanban is used in real projects? Kanban has few rules, but an infinite number of strategies. What seems easy in theory can become tangled in practice. So there’s nothing like learning from real world cases. Learn how we:

• Improved the full value chain by using Enterprise Kanban.
  (Find out how we improved time to market and shifted focus from Sprints to Flow to deliver customer value in a traditional company.)
• Boosted engagement, teamwork, and flow in change management and operations.
• Saved a derailing project with Kanban.
• Helped an office team outside IT keep up with growth using Kanban.

Inside each case story, you’ll find guerilla techniques on how we made improvements happen (including cases where we #failed). I also walk through why focusing on “improving IT” can make you miss your biggest improvement opportunity (the front end part of your value stream) as well as the 5 system “enablers” that guided our long term improvements.

Sounds interesting?  You can get “Real World Kanban” from:

• Pragmatic   https://pragprog.com/book/mskanban/real-world-kanban (eBook for Kindle/PDF, physical version due July 8th)
• Amazon (coming soon!)

Cheers

Mattias

In an agile or lean project, discovering these requirements is the work of agile product ownership. Product ownership intersects with the disciplines of product management, project management, and business analysis/requirements engineering. Agile and lean teams use different titles for the person in charge of this work, including product owner, product champion, associate product manager, or technical product manager.

Whatever the title, agile product ownership is no small task. Product owners are the champions of the product—and have ultimate accountability for the health and well being of that product. They “own” the jointly derived product vision, must deeply and emphatically understand customer needs, keep a finger on the pulse of changing stakeholder values, and continuously make decisions on what to build (or not), and when. This is true whether the product is sold commercially or is used to operate the business.

This is a tall order. Product owners cannot do this work alone, especially if they also have strategic, customer-facing product management responsibilities. Instead, in many organizations, business analysts, requirements engineers, or testers (or some combination of them) work closely with the product owner, sometimes even taking on tactical or technical product ownership responsibilities (the day-to-day interaction with the delivery team).

Product owners—and the business analysts, requirements engineers, and testers who work with them—who handle the challenge successfully all seem to understand 9 essential practices, which are explained below.

1. Put the Ends before the Means.

Agile focuses on value, and delivering the highest value features as soon as possible. To do that effectively, all involved — from the c-suite to the delivery team — need to have their eyes fixed on value. One of the many responsibilities of agile product ownership, and perhaps the most important, is to share, over and over, the vision, goals, and objectives for the product. The best product owners ensure a compelling, clear and cohesive product vision emerges from collaborating cross-functional disciplines.

2. Build Empathy for Your Customer.

Great agile product owners share with their delivery teams what they (and their product organization) are learning from competitive intelligence, product and market research, and customer visits. When possible, they invite engineers, testers, user experience experts, and any other members of the delivery team to participate in contextual inquiry by observing actual product users interacting with the product. They may also invite the team to read customer service and complaint emails or sit in as operations or customer service personnel addresses customers’ needs. The idea is to have the team fully experience walking in the customers’ shoes.

3. Stand Up.

The best product owners, or those explicitly designated as the tactical “product owners,” attend daily team standups. They don’t consider standups as status meetings, but as daily planning sessions that require facilitative leadership.

4. Cozy Up.

Successful product owners make themselves available every day to answer questions about work in progress. They know they are responsible for clarifying acceptance criteria and reviewing prototypes, completed stories, or other evidence of acceptance before the demo. These product owners never wait until the demo to see what the team has accomplished — otherwise they lose opportunities for real-time refinement and suffer potentially embarrassing demo-day surprises.

Great product owners always, always, always attend the team’s demos. Better yet, they facilitate the demo so that customers or proxy customers “test” the completed work. The best take it one step further and invite the world to the demo. In other words, they persuade colleagues from other product areas, technology, operations, support, and so on to attend. They also encourage their delivery teams to invite their colleagues. A standing-room only demo not only showcases the team’s work (and that of the product owner as well) but also demonstrates accountability and invites powerful feedback.

5. Fess Up.

Successful product owners are part of their teams, and that includes being part of team retrospectives. They are always ready to give and receive open, honest feedback. They are integral to their teams’ — and their own — learning about the process and product. They are present and they expect retrospectives to be well facilitated, engaging, transparent, and to conclude with one or two specific actions or experiments for improvement or learning.

Some people might argue that retrospectives are only for the delivery team. I disagree. Agile product owners are part of the team — and have a right and an obligation to be there. And remember: retrospectives need to be facilitated by a skilled, neutral facilitator, who can be an agile project facilitator, a coach, or a ScrumMaster from another team.

6. Decide How to Decide.

Great product owners never relegate decisions about what features to build and when to the delivery team. They accept that this is their responsibility. They proactively encourage and expect the delivery team to share and express their opinions (hopefully backed by data). Ultimately, however, they know that the decision about what to pull from the product backlog (the living, prioritized list of product requirements) lies with the product owner.

Some product owners choose to explicitly and transparently delegate tactical decision-making to a business analyst, requirements engineer, tester, technical leader, or ScrumMaster (whomever has the right skills and product expertise) when, like many typical product owners, they are overloaded with strategic product management responsibilities. In this case, the delegate is now a tactical product owner. Typically, this is done for near-term product planning: deciding which backlog items to pull into each iteration. At the same time, the best product owners understand that once that responsibility is delegated, they cannot overrule or second-guess the delegate’s decisions; otherwise, the delivery team will quickly lose faith.

7. Develop Telescoping Vision

Agile projects don’t attempt to understand or predict all product requirements up front. However, agile product owners still need to sketch out the long view of the product to establish a common focus and marshal organizational resources (people, money, space, governance). From that vantage point, product owners define what to build in each release, and then in each iteration. For large products, they collaborate and rely on product management to do this work.

These three levels — product (and portfolio), release, and iteration — correspond to three views (the Big-View, the Pre-View, and the Now-View) of the product.
The Big-View includes the overall understanding of what the product will be and the sequence of delivery. The Pre-View outlines what product functionality to deliver in a given release, and obtains agreement on the backlog items to deliver in the first few iterations in the release. This is articulated in the release plan. The Now-View (iteration or sprint plan) defines the items the team will deliver in an iteration, or if using Kanban, the work-in-progress.

Successful product owners are able to keep the Big-View in mind, even as they progress through the Pre-View and the Now-View.

8. Move in Measurable Inches.

At the Now-View, great product owners think about small, cohesive, high-value product slices. They know they need to create the product inch by inch. They realize that delivery teams need clear, measurable conditions of satisfaction so that they can create the user acceptance tests necessary to ensure that what they deliver is what the customer needs.

9. Use Roadmaps as a Guide, but Don’t Pave Them.

At the Big-View, agile product owners use a product management planning and analysis tool called the product roadmap. It is an evolving plan of product releases, with brief descriptions of their themes, features, primary customers (market segment or personas), and anticipated outcomes.

“Evolving” and “over time” are two key points that successful product owners keep in mind. As the product is developed, the roadmap must be revised to include new technologies, emerging opportunities, response to market conditions and customer feedback, team cycle time (or velocity), and new learning. If product owners were to create one roadmap at the beginning of a product’s lifecycle, freeze it, and never stray from the original path, they would miss the chance to continually discover and deliver a product that truly delights their customers.

Agile Product Ownership

Successfully delivering high value products depends on knowledgeable, engaged product owners. At its core, the work of agile product ownership entails one clear and essential mission: steer a team toward a vision, in small steps, with regular stops along the way to check in, learn, adjust, and move forward.

IMAGE SOURCE: Discover to Deliver: Agile Product Planning and Analysis by Gottesdiener and Gorman.

References

Gottesdiener, Ellen and Mary Gorman. “It’s the Goal Not the Role: The Value of Business Analysis in Scrum. Available at: http://www.agileconnection.com/article/its-goal-not-role-value-business-analysis-scrum.

Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. 2012. EBG Consulting.

Gottesdiener, Ellen. “5 Ways to Recognize a Great Product Manager”. Success with Requirements blog, available at http://ebgconsulting.com/blog/5-ways-to-recognize-a-great-product-manager/

Gottesdiener, Ellen. “Decide How to Decide” Available at: https://www.ebgconsulting.com/Pubs/Articles/DecideHowToDecide-Gottesdiener.pdf

Additional Resources

Cagan, Marty. Inspired: How To Create Products Customers Love. 2008. SVPG Press.

Cohn, Greg. Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams. 2010. Super Star Press.

Larman, Craig and Bas Vodde. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. 2010. Addison-Wesley.

Pichler, Roman. Agile Product Management with Scrum: Creating Products That Customers Love. 2010. Addison-Wesley.

Candy Crush Saga started out successfully as a Facebook game, a year later it was released on mobile and it became a runaway success. In the cut-throat casual gaming industry you can’t rest on your laurels. King was already developing several other games, but with the success of Candy Crush, it made sense to start working on what would become a sister title to the game.

In the Spring of 2013 a team of about 16 developers, artists, producers and  level designers was assembled. The only directive was to build the next big thing. The sky was the limit. This was a really big team to start developing a game with no prototype. So while half the team worked on prototyping the game the other half started working on a 3D framework in ActionScript for Facebook that could share graphical assets and set up with the C++ code for mobile. This was the first architectural decision. We would develop the game client in both C++ and ActionScript, but we would do it simultaneously and reduce duplication by using the same assets.

A few months into the project we were facing our biggest challenge: an internally set hard launch date that was fast approaching when we didn’t have a releasable game. We had a lot of game elements, and new features, and game modes, and cool experiments, but they were all more or less in prototype form. The initial backlog that we were working off of had grown, and there was no end in sight to finishing all the features that were half done.

We needed to get out of the groan zone, and focus on a common concept that would make a successful game. We set a playtest launch date (an unofficial limited launch in one or two small countries) so we could start gathering quantitative data on the game and we started converging. We defined an achievable minimum feature set for the playtest launch, by reducing the scope to what we really needed to do to meet the launch date. This included removing incomplete features, and clearly defining the features that stayed in the game. We used the results from user testing to get feedback about the game elements, logic and fun factor.

Within a couple of sprints we achieved our biggest milestone to date: a releasable game! We playtest launched on Facebook, and we were finally getting quantitative data. We expanded our targeted user testing as well, capturing players on camera and asking them for their feedback about the game, observing how they interacted with the game. We also started A/B testing different game modes and game progressions trying to find the best way to introduce players to the game.

We had the data we needed to plan what to work on next, but we were at a cross roads. The original planned release date was just a couple of months away. However, in the time it had taken us to come this far, the Saga feature set had grown tremendously. Also, even though we originally decided to develop mobile and Facebook simultaneously, mobile was lagging behind and we needed to reach feature parity.

Our final constraint was the marketing/branding campaigns. We needed to set a hard launch date that wouldn’t slip. Celebrities, TV ad spots, event locations, none of these are amenable to a Just-In-Time development style ;). We had reliable statistics for how long it took us to implement features, we also had a concrete list of all the features that we wanted in the game. We set a new, realistic release date, and started getting the game ready. We nailed down the theme and the name of the game, and the story started taking it’s final shape. We already had enough game mechanics to fill the first 75 levels, but we needed to make a final decision about how to introduce them into the game.

Officially, King soft launches titles once they are feature complete, but that wouldn’t give us time to analyze the data and react ahead of the planned hard launch so we decided to soft launch soon after our playtest launch. We officially launched on Android and Facebook, and expanded the number of countries so we could start getting statistically significant data on both the mobile and Facebook platforms.

This was the last major piece of the puzzle needed to get the game ready for launch. We were finally getting reliable numbers on whether or not players liked the game. We didn’t have enough content live to reliably judge if players would keep coming back indefinitely, but we could see that players kept coming back as long as they had new levels to play. We also achieved true feature parity on mobile and Facebook, and from then on developed both platforms simultaneously. The last couple of months were a flurry of content creation and implementing key saga features. A couple of sprints before the hard launch date we were feature complete, and we were greenlighted for release.

In November 2014, Stritz hard launched worldwide as Candy Crush Soda Saga. We had successfully taken a vague idea, “build the next big thing”, and made it a reality! Our team had grown from 16 people to 28. We went from two large sub-teams to 4 smaller ones, 1 producer to 4, complete freedom to do anything to having all eyes on us, and now we were going from a team developing a brand new game to a team growing a game. This is when our story really starts. It turns out, releasing a game is the easy part. Keeping the game interesting and dynamically growing? That’s the challenge!

I’ll be writing more about how we work at King, specifically in the Soda team, so stay tuned.

You can download a PDF with all the hand signals here.
Once downloaded you can, if you want to, print them on A4 or A3 papers and use them yourself.

Here you can read a previous blog post from Peter Antman about Crisps concesus model (v2.1).

And here you can read about How we make decisions on dna.crisp.se, our open-source site that describing how Crisp works and why. On the same site you can also read about the Hand signals shown below.

The hand signals are…

Shared the stage with teacher Frida Monsén who talked about how to get this kind of stuff into schools. Thanks Helena Hjertén for organizing this, and Spotify for hosting & sponsoring. Here’s an article in Computer Sweden about this event and our little “mod club”.

Here are the slides! They are in Swedish though. Might do an English version of this talk some day

PS – here’s a short video about LearnToMod that I created earlier to show what it is all about.

Curious about A3 problem solving? See the FAQ.

Here’s a direct link to the template.

Enjoy!

The book can be found here.

I’ve made it public, thanks to persuasion from my colleague Hans Brattberg. I decided to try out Google Slides to make it easily accessible and to provide a simple way to give feedback. That turned out to be a great decision. The response has been overwhelming. There are at any given point 5-15 people reading the book, many of which provide great feedback, point out spelling correction and provides generous suggestion for more examples.

I’ve written 45 examples to this date. I have a total of 94 ideas so I’m almost halfway done. But the ideas keep on increasing so I don’t know the total number of examples yet. The goal is to have it ready for print in a few months.

The book is filled with visualization examples for teams to improve collaboration and communication, as well as shaping behaviours. These are only examples. Nothing else. No deep theoretical explanations. No references to Gamification. No discussion on how the brain interprets visual input or how our behaviours are influenced by visual information. There are other books written on those topics.

You are most welcome to join the fun! Many who have read it have found plenty of useful ideas that they already are trying out. Hopefully there are some ideas that trigger your inspiration in here as well

This article will help you write effective and useful documentation for those situations where documentation is the only available source of knowledge.

Read the full article at InfoQ

It’s very simply. Grab the top Post-it with a firm grip, and pull it straight down.
Not to the side. Not up.
Straight down.

With practice comes mastery – someone probably said.

Side note: Some colleagues argue that it is easier to place the left-hand thumb in the middle of the pack (on the second Post-it) instead of on the side of the deck. I guess you need to try to see what works best for you

But don’t despair; let me introduce you to Confidence Smileys. Confidence Smileys provide a simple, honest, transparent and overview-friendly tool for the team to visualize how confident a team is that they will be able to finish each User Story by the end of the sprint. The can replace the need for a Sprint Brundown (or Sprint Burnup), or function as a complement.

The idea first presented itself when working with a team at Spotify. It immediately became appreciated and popular, both by the team and by the Product Owner. Since then I’ve pitched the idea to many more teams, both directly and indirectly through friends and colleagues, many are still using it today.

It’s very simple. At the end of every daily meeting the team asks themselves how confident they are that they will be able to finish each User Story by the end of the sprint. The answer is represented by a Confidence Smiley.

The team quickly goes through each lane/User Story and updates the color of the Confidence Smiley. When in disagreement, you could let the most pessimistic vote wins.

	Happy/Green smiley = We are confident that we will be able to finish this story by the end of this sprint
	Nervous/Orange smiley = We will probably not be able to finish this story
	Sad/Red smiley = No way we will be able to finish this story
	Green checkbox = User story is DONE.

When a smiley shifts (from green to orange, or from orange to red) the team grabs the opportunity to discuss what they need to do, how they can help out, and if they need to alert Product Owners and Stakeholders on changes in the forecast.

A few examples of discussions that a change of a Confidence Smiley could trigger:

• What needs to happen for the Nervous (or Sad) smiley to become Confident? Can we make that happen?
• If we removed a User Story from the Sprint would that enable us to focus and finish the remaining?
• Can we slice the User Story and deliver a smaller increment?
• Which stakeholders do we need to alert on the change in the forecast?

Confidence Smileys offer an instant and simple overview of the sprint progress. Not only for the team but for anyone. It’s super easy to start using them and quicker and more informative than a Sprint Burndown.

Let go of the Sprint Burndown. Let it die.

Try something else.

Run an experiment with Confidence Smileys

Den bärande tanken i Lean Startup är att i en snabb föränderlig värld kan vi inte planera fram en ny tjänst, utan måste via experiment och feedback från verkliga användare verifiera att den är värd att ta fram.

Metoden har följande steg:

De olika stegen brukar illustreras med denna bild:

Bild1: Cykeln Bygg-Mät-Lär

Trots ordet “startup” i namnet är detta en metod som lämpar sig så fort du har en idé som du är osäker på ifall marknaden och användarna vill ha eller ej. Det vill säga tämligen ofta. Det kan vara för en ny produkt, eller för en ny Epic.

*I sammanhanget brukar man prata om MVP:er = Minimal Viable Product = Det minsta man kan bygga för att validera sin hypotes.

Here it is, A Scrum Product Owner Checklist as a pdf updated 2015-03-27.

Maybe you’ve just been assigned the role Scrum Product Owner, and you are thinking “what is required of me”?

or

Use this as a basis for discussion within your team, maybe as a part of a retrospective.

or

Please let me know how you use it!

I’ve compiled it from various sources, some that I have lost track of. But one I’m sure of is The Official Scrum Rule Book.

I’ve also got excellent feedback from the Agile Sweden mail list, http://www.agilesweden.com/ .

/Hans

With a vocabulary for small things daily Scrum becomes a lot easier as the team have working agreements on how to deal with each one of them.

Bugs

Bugs are of one kind only: bug. There is no high priority bugs, all have the highest priority, higher than user stories. Bugs have a swim lane on the board above the ones meant for user stories.

With that said, it is of paramount importance to have a very strict definition of what is a bug. It is only a bug if any of these applies:

• Information is corrupted or destroyed by logic errors in the software.
• Usability is so bad that it tricks the user into entering wrong information, thus making information corrupt.
• It is a security breach which threatens to corrupt information

The common denominator is the corruption of information. After all, that’s is what we do, information technology.

Once you have identified a bug, put it on the top of your planning board. How fast you react on such a change in the priority is up to you but if your process is working, the next day would be the latest.

The first thing about bugs is to write a test that exposes them. I’m not saying that because I do TDD, you would like to have a test anyway so that you feel confident that the bug is fixed. The only thing worse than a bug, is a bug that comes back!

If bugs stops you from delivering new features, first stop producing bugs. A sprint filled with bug fixes delivers zero business value, unless you consider getting a kidnapped person back as a kind of value delivery.

If you love bugs a lot, collect them in a bug tracker. But in either case, do count them to see if there something you need to follow up.

Fixes

Fixes are small things like bad grammar or spelling in a user interface. No information is corrupted but it certainly does not make you look good. Annoying, is a word that comes to mind. Meanwhile, you can’t reasonably write a story that takes care of it. “As a teacher of mathematics, I want the question dialog be spelled correctly so that I don’t get a heart condition”.

Fixes go to the board as well, to their own spot. I suggest you grab fixes when you’re done with a story, before moving on to the next. They are often cheap and gives you a quick fix of satisfaction.

You should count fixes too. If you have a lot of them, consider tuning your process. Is there a sloppy attitude somewhere or is there a lack of communication between people? Is there a common root cause to many of our fixes?

Support

Support issues are when the system works as designed but there is still a need for something. E.g. database reports available only by writing custom SQL or explaining an integration point to an external party.

Support takes a delicate touch when prioritizing.  Usually the user need is imminent and the value obvious, thus requiring high attention. Still, there are user stories to handle. Of course, PO must be in the loop.

If you have too many support issues, you need to analyze them and find ways to bring the number down.  Again, count and visualize.

Summary

Little things like these can be frustrating and sometimes take a long time to deal with. By classifying them, visualize and keeping statistics, it gets a bit easier to live with them.