Zsolt Fabók

Spring-Boot Configuration Properties

2017-04-09T00:00:00+02:00

I wanted to switch in my spring-boot microservices project from hard coded values to configurable ones:

// ...
JsonNode json = restTemplate.postForObject("http://localhost:8081/login",
  payload, ObjectNode.class);
// ...

The easiest way to configure anything in spring-boot is through application.properties. By default, spring-boot looks for the application.properties in the /config folder first, so I placed one there with the desired value in it:

~/microservices/webservice % cat src/main/resources/config/application.properties 

services.authservice.url=http://localhost:8081/

~/microservices/webservice %

There are two ways to access configuration values in spring-boot: using the @Value annontation or with structured objects. I’m going to use the structured objects, because the @Value annotation can be cubersome to use when it comes to types (and it is also a bit hard to mock it in testing):

package com.zsoltfabok.webservice.config;

import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;

@Component
@ConfigurationProperties(prefix="services")
public class ServicesProperties {

    private Authservice authservice = new Authservice();

    public static class Authservice {
        private String url;

        public String getUrl() { return url; }
        public void setUrl(String url) { this.url = url; }
    }

    public Authservice getAuthservice() { return authservice; }
    public void setAuthservice(Authservice authservice)
      { this.authservice = authservice; }
}

The ServiceProperties is bounded to all the variables that start with the word services. The authservice is a sub level property and as such spring-boot reaches it with a static sub class. Mind that the getters and setters must much the configuration name. For example, in my case the getAuthService() and setAuthService() methods did nothing, and when I asked for the value, the system returned null.

In order to use the class above I had to do two things. First, tell spring-boot to load it with the @EnableConfigurationProperties annotation:

@SpringBootApplication
@EnableConfigurationProperties(ServicesProperties.class)
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

Second, inject it into my contoller (that’s why the properties file is annotated with @Component):

@RequestMapping("/login")
@Controller
public class LoginController {

    @Autowired
    private ServicesProperties servicesProperties;

    // ...
 }

Using the property:

// ...
String authserviceUrl = servicesProperties.getAuthservice().getUrl();
JsonNode json = restTemplate.postForObject(authserviceUrl,
  payload, ObjectNode.class);
// ...

Since it is autowired, mocking it in testing is also easy:

@RunWith(SpringRunner.class)
@WebMvcTest(LoginController.class)
public class LoginControllerTest {
	// ...

    @MockBean(answer=Answers.RETURNS_DEEP_STUBS)
    private ServicesProperties servicesProperties;

    @Before
    public void setup() {
        authserviceUrl = "url";
        when(servicesProperties.getAuthService().getUrl())
          .thenReturn(authserviceUrl);
    }

    // ...
}

The answer=Answers.RETURNS_DEEP_STUBS tells mockito to allow to mock chain of methods. Otherwise, I had to create a mock for ServicesProperties and another one for the ServicesProperties.Authservice.

Spring-Boot Configuration Properties was originally published by Zsolt Fabók at Zsolt Fabók on April 09, 2017.

Rsync for Windows

2017-03-21T00:00:00+01:00

I really needed rsync for Windows, but I didn’t want to bother with installing cygwin, because it is cubersome to use and I’m already using cmder. I found wdRsync which seemed a good option:

~/Downloads $ curl -O https://www.itefix.net/dl/cwRsync_5.5.0_x86_Free.zip
   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
 100 3404k  100 3404k    0     0  2036k      0  0:00:01  0:00:01 --:--:-- 2095k
~/Downloads/ $ ls
cwRsync_5.5.0_x86_Free.zip
~/Downloads $

The setup was not that hard (I’m using the /c/Applications folder instead of the /c/Program Files):

~/Downloads $ unzip cwRsync_5.5.0_x86_Free.zip -d /c/Applications/cwRsync_5.5.0

It does work locally:

~/Downloads/rsync_test $ rsync -av from/ to/
sending incremental file list
created directory to
./
a/
a/first.txt
a/b/
a/b/second.txt
                                                   
sent 261 bytes  received 94 bytes  710.00 bytes/sec
total size is 0  speedup is 0.00

Remote over ssh works, too:

~/Downloads/rsync_test $ rsync -av -e ssh from/ "zsolt@192.168.1.2:/tmp/to/"
sending incremental file list
created directory to
./
a/
a/first.txt
a/b/
a/b/second.txt
                                                   
sent 261 bytes  received 94 bytes  1010.00 bytes/sec
total size is 0  speedup is 0.00

There are cases when it does not work:

~/Downloads/rsync_test $ rsync -av -e ssh from/ "zsolt@192.168.1.2:/tmp/to/"
dup() in/out/err failed
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.2]

This happens because of an ssh incompatibility. cwRsync comes with an ssh version (see cwRsync/bin), and rsync works just fine with it. If you have issue above, use it instead of the ssh that comes with your shell or OS. Instead of -e ssh use -e /c/Applications/cwRsync_5.5.0/bin/ssh:

~/Downloads/rsync_test $ rsync -av -e /c/Applications/cwRsync_5.5.0/bin/ssh
from/ "zsolt@192.168.1.2:/tmp/to/"

sending incremental file list

sent 166 bytes  received 14 bytes  360.00 bytes/sec
total size is 0  speedup is 0.00

Rsync for Windows was originally published by Zsolt Fabók at Zsolt Fabók on March 21, 2017.

Agicon - One Does Not Simply Improves without Visualisation

2016-03-30T00:00:00+02:00

I gave a talk at the Agicon 2016 conference about Kanban, focusing mostly on visualisation and how it can help to improve different kind of organisations from startups to large enterprises. You can find the slides here:

Kanban visualisation from Zsolt Fabok

and some references you may find interesting:

Agicon - One Does Not Simply Improves without Visualisation was originally published by Zsolt Fabók at Zsolt Fabók on March 30, 2016.

Ericsson Hungary MMGW - Devops and AWS Introduction

2016-02-26T00:00:00+01:00

I gave an introductional and motivational talk about devops and AWS to folks at Ericsson Hungary MMGW divison.

Ericsson Hungary MMGW - Devops and AWS Introduction was originally published by Zsolt Fabók at Zsolt Fabók on February 26, 2016.

Debrecen Tech and Startup Meetup - What Scrum, Kanban, and Lean Have Ever Done for Us?

2015-12-14T00:00:00+01:00

I gave my last talk at the Debrecen Tech and Startup Meetup for a local community about how Scrum, Kanban, and Lean can help small or startup companies achieve their success. Scrum, Kanban, and Lean are very good at improving processes, which we need for fast delivery, and Agile/Lean UX to find the right product to deliver, so I put emphasis on these parts.

What Scrum Kanban Lean Ever Done for Us from Zsolt Fabok

and some references you may find interesting:

Thank you very much for coming, I really appreciate it, and Merry Christmas!

Debrecen Tech and Startup Meetup - What Scrum, Kanban, and Lean Have Ever Done for Us? was originally published by Zsolt Fabók at Zsolt Fabók on December 14, 2015.

Agilia Conference 2016

2015-12-01T00:00:00+01:00

The next Agilia Conference is around the corner with exceptional speakers such as Tom Gilb, Scott W. Ambler, Łukasz Węgrzyn, and Pierre E. Neis.

Aguarra - the organizer of the conference - is keen on bringing great variety of speakers to its events. For example, last year they had Mario Almondo who is a COO and the Technical Directory of the Ferrari Formula-1 team. He talked about how they collaborate at Ferrari to deliver an excellent performance from race to race. How cool is that? Moreover, “Mr. Beyond Budgeting” Bjarte Bogsnes was there as well, and gave his brilliant talk about how to run a big company without the burden of yearly budgets.

It seems Aguarra keeps its good habit and invited Łukasz Węgrzyn, who is a laywer, and will talk about a very important topic: the legal point of view of projects and how to do contracts for agile projects. This talk alone might be worth you time and money, because several companies struggle to find the right way of writing a good contract.

Last but not least, Scott W. Ambler will deliver a keynote on Disciplined Agile Delivery - DAD - which is an IT process decision framework for delivering sophisticated agile solutions in the enterprise (I hope it is the complete opposite of SAFE).

Agilia Conference seems to be a good event to attend to. The main conference is on the 5th and 6th of April, and there will be workshops on the 4th, 7th, and 8th of April 2016. See you there!

Magyar verzió

Már nem kell sokat várni a következő Agilia Konferenciára, ami olyan kivételes előadókat vonultat fel, mint Tom Gilb, Scott W. Ambler, Łukasz Węgrzyn, és Pierre E. Neis.

Aguarra - a konferencia szervezője - híres arról, hogy nagyon különböző előadókat hív meg a rendezvényeire. Például, tavaly Mario Almondot, aki COO és technikai igazgató a Ferrari Forma 1-es csapatánál. Előadásában arról beszélt, hogy hogyan dolgoznak együtt a Ferrarinál, hogy versenyről versenyre tudják szállítani az eredményeket. Ez azért nem semmi. Többek között ott volt még Bjarte Bogsnes, aki a “Beyond Budgeting” mozgatórugója, és előadta, hogy hogyan lehet nagy cégeket éves költségvetés nélkül működtetni.

Úgy tűnik Aguarra folytatja jó szokását, és meghívta Łukasz Węgrzynt, aki egy ügyvéd, és fontos témáról fog előadni: hogyan kell jogilag jó szerződéseket kötni agilis projektekre. Lehet csak ez az előadás megéri a pénzt s időt, mert sok cég küzd azzal, hogy jó szerződést írjon.

Végül, de nem utolsó sorban, Scott W. Ambler a DAD-ről (Disciplined Agile Delivery) fog beszélni, ami egy a nagyvállalatok számára kifejlesztett döntéshozó keretrendszer (remélem nem olyan lesz mint a SAFE).

Ezek alapján, jó kis esemény lesz ez a konferencia. Az előadások április 5-én és 6-án, a workshopok 4-én, 7-én, és 8-án lesznek. Ott találkozunk!

Agilia Conference 2016 was originally published by Zsolt Fabók at Zsolt Fabók on December 01, 2015.

Agile, Lean and UX is Coming

2015-11-04T00:00:00+01:00

This time I was talking about the basics of Agile and Lean methodologies and how to apply the UX principles in them. Here are the slides:

Agile, Lean UX is Coming from Zsolt Fabok

and some references you may find interesting:

Taiichi Ohno and the Toyota Production System (book reference)
Waste (blog post)
Flow Efficiency, work of Niklas Modig (book reference) and slides from Hakan Forss (blog post). More about flow efficiency: how to measure it and when it is not so useful
The agile way of working (blog post)
Scrum (don’t do Scrum if possible. If you want to, here are some good posts about it.)
Kanban by David Anderson (slides)
Value stream mapping (blog post about how to do it)
Cynefin by Dave Snowden (blog post and further reading)

Thank you very much for coming, I really appreciate it!

Agile, Lean and UX is Coming was originally published by Zsolt Fabók at Zsolt Fabók on November 04, 2015.

Philosophies of Building the Workplace

2015-04-24T00:00:00+02:00

I gave my second talk at the Budapest University of Technology and Economics to psychology students about the philosophies we use to build and improve a workplace. I covered a wide range of topics (Taylor, Kanban, staff liquidity, cynefin, etc.) and promised the students to share some references and further reading materials. Here you go, and thank you very much for coming I really appreciate it!

Philosophies of Building the Workplace from Zsolt Fabok

Intro

What the goal of the organisation or workplace
Empowerment (book reference)
Tribal leadership (book reference)

Processes

Frederick Taylor, Henri Fayol and Max Weber
Taiichi Ohno and the Toyota Production System (book reference)
Waste (blog post)
Flow Efficiency, work of Niklas Modig (book reference) and slides from Hakan Forss (blog post). More about flow efficiency: how to measure it and when it is not so useful
The agile way of working (blog post)
Scrum (don’t do Scrum if possible. If you want to, here are some good posts about it.)
Kanban by David Anderson (slides)
Value stream mapping (blog post about how to do it)
Staff liquidity by Chris Matts (blog post)
Cynefin by Dave Snowden (blog post and further reading)
Beyond Budgeting by Bjarte Bogsnes (metion in a blog post and further reading)

People

Social sciences make a difference (slides)

Philosophies of Building the Workplace was originally published by Zsolt Fabók at Zsolt Fabók on April 24, 2015.

Teaser Talk about Development at the University

2015-03-02T00:00:00+01:00

I’ve recently given a teaser talk about software development at the Budapest University of Technology and Economics. The audience was great and thank you for coming folks, I really appreciate it!

I wasn’t talking much about programming, because nowadays a programmer or software developer is expected to know and do testing, and keep in mind two things: quality and user satisfaction.

Here are the slides:

Introduction to Software Development from Zsolt Fabok

I also presented this older material from XP2013:

[xp2013] Narrow Down What to Test from Zsolt Fabok

There are some more useful links below.

Teaser Talk about Development at the University was originally published by Zsolt Fabók at Zsolt Fabók on March 02, 2015.

Visualize Information Flow in Value Stream Mapping

2014-05-23T00:00:00+02:00

When I met Mary and Tom Poppendieck we not only talked about flow efficiency but about the entity that actually flows through the system. According to Mary it can only be a deriverable: a customer request, a feature or a product, but not a patch or a bug fix. The more I think about it and the more I look at my current and previous projects, the more certain I am that she is wrong. My point is that we cannot focus only on deliverables in case of a flow: if we do, we won’t be able to see the big picture. I still believe that a value stream mapping should contain all kinds of things that appear in the flow, and therefore I’d say that the entity that flows and shall be mapped in value stream mapping exercises is the information.

I added information flow to the value stream mapping exercises because a long time ago we tried to improve the flow of a certain organisation but none of our efforts was successful. The reason was that the flow of customer requests and features covered only the 30% of the whole flow. The other 70% was communication, office politics, site politics, bug fixes etc. If you think about it, these work with information - even the features and bug fixes can be seen as some kind of information -, so it make sense to add them to the value stream map. With this approach we were able to see the whole, and finally it made sense why our efforts on feature flow improvement were unsuccessful: there was insufficient communication, therefore decisions were based on assumptions.

After we did the usual value stream mapping we added the information flow. It turned out that delivery management was out of the loop: no information went in and no information went out (no feedback loops). This means that they assumed certain important details just by looking at the package, and never gave feedback on it (practically, if there was an error they fixed it, but never pushed upstream). This was not visible on the usual value stream map but was immediately visible on an information stream map.

And this is something you can try. Do a usual value stream mapping and then add the information flow and see if the information flow follows the value (eg. features) flow. If not, or in a worst case there are information flow without feature flows you found a good place for improvements.

Visualize Information Flow in Value Stream Mapping was originally published by Zsolt Fabók at Zsolt Fabók on May 23, 2014.

Flow Efficiency Based Improvements Aren't Always Useful

2014-05-21T00:00:00+02:00

Yesterday, I met Mary and Tom Poppendieck and over a nice beer we were talking about various topics but we spent most of our time talking about flow efficiency (ratio of the value added activities to waiting). When I was riding my bicycle home I was still thinking about our conversation and presented examples. Despite the fact that I think the current right move is to favour flow efficiency over resource efficiency, I think it only works in the simple domain of Dave Snowden’s cynefin framework, where the connection between cause and effect is obvious to all. Here, simple means that the process is clear to everybody who is involved even if it is a long process. If you think about car manufacturing from where the concept of flow efficiency originates, you can see that it’s in the simple domain: every detail of the process is well known to all workers involved. However, in knowledge work and in software development, that is not necessarily true.

According to Dave Snowden, most of the knowledge workers are in the complex (connection between cause and effect is clear only in retrospect) and complicated (connection between cause and effect requires expert knowledge) domains, and in these domains the flow is not as visible and controllable as in the simple domain. Without having the proper - and not expert - view on the flow it is extremely difficult to improve the flow efficiency. This is a minor thing compared to the fact that in the complex and complicated domains we don’t even know for sure the connection between cause and effect (that’s why Snowden suggests to probe and analyze) and we add flow efficiency changes on top of that.

For example, we see that there is a buffer between two teams (buffer means waiting time). One way to improve flow efficiency is to merge the two teams or at least make them interact more frequently. This looks like a good idea, however there is no guarantee that it is going to work. What if the teams simply cannot communicate more or they cannot work together which slows them down and the waiting time increases?

Nevertheless, improving the flow efficiency is a good idea but knowing in which domain of the cynefin framework we are in is crucial. I had improved the flow efficiency of various teams in the past but in retrospect they were in the simple domain. I failed with my last team because we were in the complex domain and despite the huge effort we put into flow efficiency improvement nothing has changed. We should have moved to the complicated domain first where the connection between cause and effect are clearer and do the flow efficiency improvement as an experiment that we can analyse. My point is: don’t start with the flow efficiency improvement until you understand your flow and you have control over it (having a value stream map is a good start but knowing is different from understanding).

Flow Efficiency Based Improvements Aren't Always Useful was originally published by Zsolt Fabók at Zsolt Fabók on May 21, 2014.

London Lean Kanban Day 2014 - The Road to a Fairly Predictable System

2014-04-28T00:00:00+02:00

I see agile software development methodologies (Scrum and XP) and modern management methods (Kanban) as tools for predictability. The development organisation would like to know what is coming and whether it will be the right thing to do. On the other side, the management would like to know when the new features can hit the market. Both want predictability but in a different way. We are on the road to a fairly predictable system that can accurately tell us what the next right thing to do will be and also when it is going to be ready. In my talk, I’ll share my experiences with you, focusing on practices - from portfolio Kanban to risk management - we do to be more predictable.

Here are the slides:

[Agile Adria Croatia 2014] The Road to a Fairly Predictable System from Zsolt Fabok

London Lean Kanban Day 2014 - The Road to a Fairly Predictable System was originally published by Zsolt Fabók at Zsolt Fabók on April 28, 2014.

Schedule Portfolio Kanban

2014-04-07T00:00:00+02:00

As a project manager one of my current tasks is risk management, and I have to focus especially on schedule risk. Therefore I was looking for something that can show me quickly the current status of the project and this kind of risk. I started to use a portfolio Kanban board that covers the whole project, but my board is different from Pawel Brodzinski’s resource oriented board:

I’m using an old idea from Chris Matts - a work item is put into a column that tells us when the it is supposed to be ready -, and the idea of organisational level Kanban boards. If this is week 13, team yellow is doing fine, whereas teams red and blue are in trouble.

Besides the nice overview the board points to the most problematic parts of the project regarding schedule risk: the oldest item (team red’s work item in week 11) and the team with the highest number of delayed work items (team blue).

The completeness attribute tells me something else: a work item with a 3/5 completeness (number of done items / number of planned items) won’t be finished this week if today is Friday, however a 2/3 might be finished. Moreover, team red has started to work on something that is supposed to be ready by week 15, but they haven’t finished their week 12 commitment. Team yellow might be delayed later: so far - in 3 weeks - they finished 6 of their work items (1/1+2/2 from done, 2/3 from week 13) and they committed to deliver 8 by week 14. That is very unlikely to happen.

These numbers are not accurate enough but they are a good basis of a discussion. Looking at the assigned team’s lead time and throughput can tell us more about the situation (more about this in a later post). Information about the completeness should automatically come from the assigned team’s board:

It is still early to say much more about this approach. I have two urgent things to solve. First, I cannot see dependencies between teams which would be important. Second, somehow I need to gather more data from teams and show it to them on the portfolio level, such as lead time, takt time and throughput, which would provide a good basis for predictions.

Schedule Portfolio Kanban was originally published by Zsolt Fabók at Zsolt Fabók on April 07, 2014.

Agile Adria Croatia 2014 - The Road to a Fairly Predictable System

2014-04-06T00:00:00+02:00

I see agile software development methodologies (Scrum and XP) and modern management methods (Kanban) as tools for predictability. The development organisation would like to know what is coming and whether it will be the right thing to do. On the other side, the management would like to know when the new features can hit the market. Both want predictability but in a different way. At Prezi, we are on the road to a fairly predictable system that can accurately tell us what the next right thing to do will be and also when it is going to be ready. We are far from a perfect system, we had our ups and downs, but after every down we are more up than before.

[Agile Adria Croatia 2014] The Road to a Fairly Predictable System from Zsolt Fabok

Agile Adria Croatia 2014 - The Road to a Fairly Predictable System was originally published by Zsolt Fabók at Zsolt Fabók on April 06, 2014.

No Attributes in Objects

2014-03-31T00:00:00+02:00

I just realised that I rarely define attributes in my classes (the dependency injection references are exceptions) and I’m passing everything as a parameter. So instead of this:

class Foo
  attr_accessor :list

  def do_something
    @list = []
    action_1
    action_2
  end

  private
  def action1
    @list[2] = "a"
  end

  def action_2
    @list[1] = "b"
  end
end

I have this:

class Foo
  def do_something
    list = []
    action_1(list)
    action_2(list)
  end

  private
  #   self. means that this is a class level method (static in Java)
  def self.action_1(list)
    list[2] = "a"
  end

  def self.action_2(list)
    list[1] = "b"
  end
end

Similarly to my spike workflow I realised what I’m unintentionally doing after actually having done it. I switched to this method because of the Unix philosophy: “The Unix philosophy emphasizes building short, simple, clear, modular, and extendable code that can be easily maintained and repurposed by developers other than its creators.”

More precisely: I switched to this method because I was struggling with the Unix philosophy. When I’m writing code I don’t know what the shortest and simplest entity in my code is so I put everything into a class and when it is done, I may refactor it into smaller classes. This refactoring work is very hard when I have tightly coupled methods, but when I have methods that are not coupled by attributes (except dependency injection references) then it is easy. In the code above I can simply move action_1 and action_2 anywhere I want:

class Foo

  # I have an attribute here: @actions

  def initialize(actions)
    @actions = actions
  end

  def do_something
    list = []
    @actions.action_1(list)
    @actions.action_2(list)
  end
end

# ----

class Actions
  def action_1(list)
    list[2] = "a"
  end

  def action_2(list)
    list[1] = "b"
  end
end

The action_1 and action_2 methods are no longer class level methods (no .self) because it is easier to code dependency injection with object level methods.

I do this even if my class has an actual “state”:

class Foo
  attr_accessor :last_element
  attr_accessor :list

  def do_iterate
    last_element = action_1(@last_element, @list)
  end

  private
  def self.action_1(last_element, list)
    list[2] = "a"
    last_element = 2
    return last_element
  end

end

Anyway, this is the first time a large refactoring is no longer a difficult and long process. Furthermore, there are no more surprises in my methods: I know what is going to happen just by looking at the method definition.

No Attributes in Objects was originally published by Zsolt Fabók at Zsolt Fabók on March 31, 2014.

Risk Kanban Board

2014-03-25T00:00:00+01:00

A couple of days ago I was talking with a friend about the talk I gave last year during the Lean Kanban Europe tour and I realised that my unusual Kanban board may be able to solve my recent problem: I want to visualize and easily manage risks. The board is a horizontally sliced board with four horizontal lanes and was originally designed for an operations team (note: for risk management I won’t need WIP limits):

Each lane represents a certain severity using the visualization idea from Jeff Anderson. The severity (risk) comes from the correlation between time and impact: the later the team handles an issue the higher the impact is. Moreover, the cost or effort to “handle” a certain level is proportional to the area under the curve:

Level 1 category has an “infinite impact” and an unknown cost of delay. The problem of this level is that it is completely unpredictable. The costs can be extremely low or extremely high and this high uncertainty forces us to take care of it immediately. For example, the lead developer of the project cannot come to work any more. We can gamble and say that we’ll survive without him or we try to promote somebody else and train very-very fast. Level 1 doesn’t allow us to do proper risk management and mitigation, it forces us to do something. So it is better to take actions before a risk turns into level 1, but when it is on level 1, we have to take care of it immediately.

Level 2 category means that at the moment we know something is going to happen and we are aware of the consequences of a late action. For example, we know that the lead developer is leaving the company and we have 30 days to find a new lead. The more we wait with the promotion or the hire, the higher the cost of delay will be; it will be inversely proportional to the insufficient domain knowledge of the new lead developer. In other words: the more we wait the higher the risk reduced quality and delays in the project because of the domain knowledge of the new lead.

As you can see, if a level 2 item is not taken care of in time, it will turn into a level 1 item:

Level 3 is similar to level 2, but it has a free delay before turning into level 2:

Which means that there is a period of time when we can ignore the risk, but we cannot do it forever. Following our example, we know that the lead developer will leave the country later this year, so finding a replacement is not an immediate issue, but will be eventually.

Level 4 is a collection for nice to have issues or low risk level items. As I used to say: “this is the place where all the refactoring and code improvement tasks come to die”.

Like the other boards, this one also needs daily updates (the previously mentioned operations team did it twice a day). The risks (work items) have to be reviewed from top-right to bottom-left so that the team talks about the most “painful” risk first. The rest of the risks should be revisited and checked whether they have got closer to a level transformation or need to change level:

And finally, when a risk is sorted out - or a work item is done -, it gets into the done column. Similarly to other Kanban systems this approach provides measures such as lead time (time needed to mitigate a risk on a certain level) and throughput (number of risks mitigated) and needs to be continuously improved in order to be an effective system.

Risk Kanban Board was originally published by Zsolt Fabók at Zsolt Fabók on March 25, 2014.

Fast or Accurate Applications?

2014-03-24T00:00:00+01:00

It is a common topic between software developers whether an application should be fast or accurate. I’ve always chosen accuracy over speed until now, like when I was solving problem 7 on project euler, which sounded very simple: find the 10001st prime number. My algorithm for finding prime numbers used Wilson’s theorem:

def is_prime?(number)
  (Math::Factorial.get(number-1)+1) % number == 0
end

And it was just fine for problem 3, where I had to find the prime factors of a certain number. There, the highest prime number I had to deal with was 6857 which is the 882nd prime number. Then I started to look for the 10001st prime, and my algorithm managed to find the 3000th after 2 hours.

I’ve observed before that my algorithm is not really fast, but why change something until it is not necessary, right? Wilson’s theorem is slow, because of the factorisation. Here is the factorial of 100 (100!):

>> (1..100).to_a.inject(:*)
=> -10384284350875615835879868794784780563948700682078952346418475
948982003462663882896989074486814358339575949818878047438776630877
0729164800000000000000000000
>>

It takes quite a long time and you can imagine how long it takes to calculate the factorial of 1000, or the factorial of the 10001st prime. So I needed something faster, and I found Fermat’s little theorem (setting a = 2):

def is_prime?(number)
   a = 2
   (a ** (number - 1) - 1) % number == 0
end

And it was faster, way faster (~86 seconds with IO operations, because I’m storing the primes in a file cache). But, Project Euler didn’t accept my solution. I thought I had screwed up the indexes and had submitted the 10000th prime instead of 10001st. So, I submitted primes in the range of +/-2, but none of them was good.

Since it would take ages to guess the right number, I took a different approach. I downloaded the first 1000 primes from the internet and compared them to my primes and there were differences. The first was 341. As it turned out, it is a pseudoprime. A pseudoprime looks like a prime according to Fermat’s little theorem, but actually it’s not: 11 * 31 = 341. The application became faster but less accurate. I didn’t go back to Wilson’s theorem, but changed the code quite a bit:

def is_prime?(number)
  a = 2
  if (a ** (number - 1) - 1) % number == 0
    if is_pseudoprime?(number)
      return false
    end
    return true
  end
  return  false
end

protected
def is_pseudoprime?(number)
  number_sqrt = Math.sqrt(number).to_i
  divisors = (1..number_sqrt).to_a.delete_if do |n|
    is_composite_of?(n, [2, 3, 5, 7, 11])
  end

  divisors.each do |n|
    # n > 1 makes sure that it works for actual primes in the recursion
    if number % n == 0 && n > 1
      return true
    end
  end
  return false
end

def is_composite_of?(n, base_primes)
  base_primes.each do |d|
    if (n % d == 0) && ((n / d) > 1)
      return true
    end
  end
  false
end

It is a bit slower, but more accurate (~89 seconds with IO). I think, it can be made faster (and cleaner), but for the moment I have enough primes and therefore I don’t need a different solution. Nevertheless, I learned a couple of things. First of all, playing safe and going for accuracy wasn’t a good choice because I didn’t improve and learn new things. Second, faster algorithms mea faster turnover times and faster development. And third, things like pseudoprimes finally make sense after 10 years I finished the University. Nevertheless, it was fun, solving Project Euler puzzles is fun, too. Give it a try, you’ll like it.

Fast or Accurate Applications? was originally published by Zsolt Fabók at Zsolt Fabók on March 24, 2014.

Spike and a New Workflow

2014-03-19T00:00:00+01:00

The other day I found myself writing a single test case the whole day without making a significant progress in the production code. It wasn’t efficient at all and I wasted the whole day on stupid test cases - so it was time to ditch TDD for the rest of the weekend and try something different. After calming down I asked myself why I was writing test cases when I didn’t have a clue about the next step. So, instead of writing tests I wrote a spike. It wasn’t nice at all, but showed me which direction I should go. I wrote a test case which tested the spike and was green, and I deleted the spike afterwards. And at this very moment, the Spike Solution from XP finally made perfect sense to me.

According to extremeprogramming.org a spike is a proof of concept: “Create spike solutions to figure out answers to tough technical or design problems”. Sounds great; it resonates well with my conclusions above (the next time it would be fantastic to find the science first and then the practice and not vise versa ;-)). And from now on - until I find something better - I’m going to follow this workflow in my projects:

If I know what I should do I’ll use TDD, if I don’t, I’ll write a spike. When I’m satisfied with the results, I write a test case (acceptance or unit). Next I delete the spike, and inject the new test case into the TDD cycle which will be red in that context (there is no matching code, remember: the spike is gone, so it should be red).

Here is an example. I have a nice algorithm that does certain things to numbers. I know the inputs and outputs of the algorithm, so it is TDD, no questions. However, an algorithm alone is worthless. Either I need an app, a command line interface, or an API. There are too many options and possibilities, so I’d make more progress by just writing spikes until I find the right solution. When I have it, I’ll write a test, delete the spike and let TDD do its magic.

As you can see the “spike turn” takes more time, and you should be prepared for that. If you aren’t prepared enough, you’ll do the same mistakes I did. I was writing spikes for days. From a certain point of view, there is no difference in writing spike code for a day and writing test code for a day. So my agreement with myself was that I have to sweat out at least one acceptance test in a day when I’m doing a spike.

After making progress with the new workflow in my project, I realised that I ended up with a nice test pyramid:

The “spike turn” produces one acceptance test case, but the TDD produces more, because the acceptance test case kind of covers the more likely scenario, whilst the unit tests cover all the possible scenarios and outcomes.

This workflow is very similar to a BDD workflow, but there are two important differences. First, BDD is a conversation tool between product and development. Second, the two parties (product and development) have an idea about how the application should behave. I’m using my main success scenario because I don’t have a clue how it should behave. Anyway, I’m happy with it, and if you give it a try, don’t forget to comment and share your experiences.

Spike and a New Workflow was originally published by Zsolt Fabók at Zsolt Fabók on March 19, 2014.

Constant WIP - CONWIP

2014-03-10T00:00:00+01:00

CONWIP stands for constant work in progress which means that the overall number of work items in the system is limited, not just a single phase or column. For example, with a CONWIP of 6 we can have at most 6 work items between ‘todo’ and ‘done’. Like throughtput, takt time, and flow efficiency CONWIP comes from the car manufacturing world and it was designed for a system that produces the same kind of work item over and over. The idea is the following: it is hard to control throughtput (it is a lag measure: it provides a value that applies to a period in the past) while it is relative easy to control the overall number work items (real kanban cards and pulls) in the whole system. For example, our factory produces two kinds of product ‘A’ and ‘B’. At the moment the market needs more of ‘A’ and less of ‘B’, we simply reduce the CONWIP of ‘B’ and increase the CONWIP of ‘A’ (we do product leveling). This will change the throughput. When the demand changes we change the CONWIP values accordingly. Like the previously mentioned metrics, CONWIP cannot be used as such in software development, but after putting it into context it is very helpful.

First, it is obvious but I have to mention that a very high CONWIP won’t cause very high throughput. There is an upper limitation of every system and if you go above this limit the overall lead time will increase and the throughput will decrease because the high CONWIP will allow aging work items in the system. Second, CONWIP has really nothing to do with the WIP that is applies to the columns (or phases) on a Kanban board, except that the CONWIP cannot be lower than the highest WIP. For example, if you have a WIP limit of 5 for testing and your CONWIP is 4, you’ll never have more than 4 items in testing, so why have a WIP of 5 and/or a CONWIP of 4? And third, the sum of WIPs won’t provide the ideal CONWIP. CONWIP is in connection with a desired throughput or capability.

Let’s say you have 5 developers, you have one ‘ongoing’ and one ‘review column’, and in order to move things forward you have a WIP limit of 2 for ‘review’ and 5 for ‘ongoing’. The sum of these WIPs is 7 but the actual capacity is 5. If you set the CONWIP to 6 or 7 you’ll have at least one developer who is working on multiple things. Moreover, the team slows down because ‘review’ will be emptied when ‘ongoing’ reaches its WIP limit. If you go below 5 you’ll have a developer who is idle. So the best CONWIP for this team under the given circumstances is 5. If you change the WIP limits to 4 and 1 ((for ‘ongoing’ and ‘review’ respectively) because you want your lead developer to do only review you can do it without changing the CONWIP. Unfortunately, it will be the same as the sum of WIPs but as I showed you before it is not a working use case.

As I mentioned in the first chapter the CONWIP serves as a controlling function in car manufacturing and it can be used in the same way in software development. The team which owns the board below can do more and more week by week (increase in throughput), but never enough to match the demand:

So, it decides to maximize the amount of work items it can have at the same time. With this approach the team can have some time and stabilize they are in. So the team takes control over the demand (input) and throughput (output) by using CONWIP.

Constant WIP - CONWIP was originally published by Zsolt Fabók at Zsolt Fabók on March 10, 2014.

Improve your Estimations and be More Predictable

2014-02-28T00:00:00+01:00

Planning in general - not just in software development - is not an easy thing. We have to know what to do next and have an idea when it will be ready. Although the former is harder the latter seems to be more problematic. We also struggled with it with my old team at Digital Natives. We had frequent and long planning meetings, and had rarely finished everything we had planned. So, we decided it was enough, and it was time to try something new. After about two months, we were able to give very accurate hour based predictions on spent time and delivery (lead time) with a quarter of the effort of our previous planning meetings.

We started a new board - not a Kanban board - where we collected the already finished work items:

As you can see this board had three different columns. Each column represented a T-shirt size: ‘S’, ‘M’, and ‘L’. When we set up this board we put all the work items we had into these columns based on difficulty. Our smart questions were: “was this work item hard to do?” and “was it harder than these work items in this column?”. With this approach we ended up with three columns and since we weren’t able to find right titles for the them we named them T-shirt sizes. We calculated the lead time and spent time using distribution diagrams for each, and wrote them on the board (you can see them on the next picture). At the end of each week, we recalculated and put them on the board in order to use always the latest data for our predictions. When a work item was finished we put it into its proper column.

When we got a new work item, we gathered around the board, and we tried to estimate the right difficulty for the new work. Then we wrote ‘S’, ‘M’, or ‘L’ on the card and put it on our Kanban board. During the daily meeting our product owner checked the new work items on the board. When he thought that an item would take too long - its predicted spent time based on its size was too much - he asked us to cut the work item into pieces or he reduced the scope just to let something hit the market sooner. Our weekly inflow was around 7 work items, we spent around 5 minutes on finding the right place for the card, so our planning effort was a bit more than half an hour. Before that we have never finished our planning meeting in under two hours. The other big gain was that we could get rid of Scrum sprints and could work continuously: the planning meeting wasn’t an obstacle any more.

After several weeks, we observed that our predictions were not as good as before. There were ‘M’ sized items that were finished sooner, and vice versa. After a retrospective meeting we concluded that some of our data had expired. We were getting better at what we were doing, learned a lot about the product, and did several minor improvements in the meantime, therefore our old data was no longer useful. So we introduced lines on our board. Each line represented a week, and the latest was on the top (it took about 5 minutes to shift the whole board down each week, so it wasn’t a big effort). When we were doing the planning we considered only the last three weeks.

Of course we were wrong several times. The note on the right shows a transformation from ‘S’ -> ‘M’. After a work item was finished we took it from our Kanban board and move it to the other board. When a work item took more time than we had originally predicted, we tried to find the right place for it. The work item above was predicted as ‘S’ but actually was an ‘M’, so we put it into the ‘M’ column. With this technique we kept our board up to date. Of course, if it was an ‘S’ but we predicted an ‘M’ we did the same routine. This ‘S’ -> ‘M’ marker became very helpful later. There is an inner voice that tells us “next time you’ll do better”, but this marker kept us from listening to it. If the new work item was similar to a card with ‘S’ -> ‘M’, we wouldn’t mark it as ‘S’ because we knew that we had problems with predicting similar work items before, so it became an ‘M’. Most of time we were right, and I’m still very happy about it, because we were making decisions based on data and not gut feeling. Moreover, we were also looking for certain keywords. For example, if a work item had the word ‘wizard’ in its description it couldn’t get into the ‘S’ column, ever. Even if it was a text change on the UI. We tried several times to finish a ‘wizard’ related work within ‘S’ scope, and we never succeeded. So, the minimum an ‘wizard’ work item could get was an ‘M’. And our product owner was okay with this (I guess he valued predictability and quality over speed).

You may wonder about a couple of things. First, why were we tracking both the lead and spent time? We were kind of working in a TTM (time to market) fashion so it mattered how much time we spent on this project during a week or a month, so the spent time was important. On the other hand we needed the lead time to predict when a work item could be delivered. We weren’t doing continuous delivery - we did continuous deployment - so it was good to know when we can deploy.

Second, what has happened to the architectural decision part of a planning meeting? During a typical Scrum planning meeting, the teams kind of make architectural decisions as well. We didn’t stop doing this. We changed our process so that we did this planning for each new work item when it could get into the ‘analyse’ phase (before implementation). So in general the time we spent on planning didn’t change much. What changed is the time we spent on a regular planning meeting, and we reduced some mura waste: we planned when it was necessary, and therefore we had fewer re-planning sessions than before.

And third, the environment. When we started to do this kind of planning we knew the domain, knew each other and our technical knowledge was kind of the same. The size of the team changed over time, but this affected only the lead time because we rarely worked on work items in pairs.

I really enjoyed working like this. It was stressless: no hassle around deadlines and estimations, because everything we did was predicable most of the time. Of course, when we had some performance issues we had some stress, but not because of planning and execution of plans. The pictures above were taken after four weeks of usage but we used this technique for three months until the end of the project. I can only recommend this technique, and if you are interested in the #noEstimates movement, this is a good start. You don’t need a physical board either. You can have a bit wider Done column, or a different kind of Archive board. Here is an example from Leankit:

Improve your Estimations and be More Predictable was originally published by Zsolt Fabók at Zsolt Fabók on February 28, 2014.

Zsolt Fabók

Spring-Boot Configuration Properties

Rsync for Windows

Agicon - One Does Not Simply Improves without Visualisation

Ericsson Hungary MMGW - Devops and AWS Introduction

Debrecen Tech and Startup Meetup - What Scrum, Kanban, and Lean Have Ever Done for Us?

Agilia Conference 2016

Magyar verzió

Agile, Lean and UX is Coming

Philosophies of Building the Workplace

Intro

Processes

People

Teaser Talk about Development at the University

You may also find interesting:(View all posts)

Visualize Information Flow in Value Stream Mapping

You may also find interesting:(View all posts)

Flow Efficiency Based Improvements Aren't Always Useful

You may also find interesting:(View all posts)

London Lean Kanban Day 2014 - The Road to a Fairly Predictable System

Schedule Portfolio Kanban

You may also find interesting:(View all posts)

Agile Adria Croatia 2014 - The Road to a Fairly Predictable System

No Attributes in Objects

You may also find interesting:(View all posts)

Risk Kanban Board

You may also find interesting:(View all posts)

Fast or Accurate Applications?

You may also find interesting:(View all posts)

Spike and a New Workflow

You may also find interesting:(View all posts)

Constant WIP - CONWIP

You may also find interesting:(View all posts)

Improve your Estimations and be More Predictable

You may also find interesting:(View all posts)