Skip to content

Companies

WorldCup 2014 Retrospective: The Magic about Mindset and Leadership

Xebia Blog - Sun, 07/13/2014 - 14:56

This weekend preparing this bjohan-cruijff-hollande-1974logpost, I ran into a brilliant quote from Johan Cruijff. At a conference a few years ago for the Dutch local government, he told a great story about a talented blind golfer, Ronald Boef he played golf with.  Despite his handicap, Ronald Boef played his best golf in difficult mental circumstances like playing balls over a big pond or consistent putting. The conclusion of Johan Cruijff: "Ronald doesn’t “see" the problems, he is only focussing on the next target. He thinks from a positive mindset".   I couldn’t agree more.  In my opinion, this is one of the fundamentals behind eXtreme Manufacturing (XM) and the reason why the Dutch team didn’t made it through the WorldCup finals.

Like many consultants, topsport is an inspiring source for me.  Almost every day I show or tell stories from great sport coaches like Marc Lammers or Johan Cruijjff.   Like every major sports event, also this WorldCup in Brasil contained some interesting lessons for me I wanted to share with you.

The Big Question: You can have the best individual team members but still not be able to perform.  Why?

 3rd Place Playoff - 2014 FIFA World Cup Brazil

Top Team Ingredient #1: Mindset

The defeat of Spain against the Netherlands, the glorious win of Germany over Brazil showed having fun, faith and determination pay off and a lack of these ingredients will bring you in a lot of trouble.   Until the penalty series of the semi-finals, the right side of this recipe also worked for the Dutch squad. Now, penalty series are for no one a fun exercise, which only leaves faith and determination.   Unlike the previous penalty series against Costa Rica, the Dutch team had no faith in their keeper as a penalty-killer which directly effected the teams determination. They became more hesitant and aware of what could happen when missing a penalty.  Yes, Ronald Boef probably would have taken the penalties better than the Dutch team did against Argentina.. ;-)

Top Team Ingredient #2: Leadership

Like Johan Cruijjf stated in the same video, the leader on the pitch should be 100% concentrated on every detail and also (in my words) be the natural leader of the team, coaching them in keeping the spirit up and giving them enough room “to grow".  Despite his great qualities as a football-player, as a captain Robin van Persie was obviously not the natural leader of the team. Arjan Robben was. The natural leadership of Arjan Robben in combination with his determination was an important reason why The Netherlands were able to regain their motivation and pull off a highly respected 3rd place in this WorldCup.

In my opinion, a high performing team should always have a natural leader.  The options:

  1. A formal leader with natural leadership qualities is the perfect combination.
  2. A formal leader without natural leadership qualities but able to delegate this to another team member is also okay.
  3. A formal leader without natural leadership qualities and ignoring don’t having this competence, is bad news for the team, the team’s environment but above all, for the formal leader himself.

For the new coach van the Dutch team, Guus Hiddink, it will be a challenge convincing Robin van Persie to step back as the 1st captain after nominating Arjan Robben.  Robin van Persie should keep one thing in mind here:  no one is doubting his qualities as a top world class striker.  As a natural leader however, he is not that world class.  Trying to be one is effecting his performance as a world class striker and that would in the end be a disappointment for his supporters but above all, for Robin van Persie himself.

What does this imply for Leadership within organizations?

Leadership, especially natural leadership, is crucial for having highly motivated and productive teams.  The team stays motivated and focussed on their goal.

How ever, a lot of employees are still instrumentally “nominated” to become a coach or manager without having any leadership skills.  In my opinion, natural leadership is something you can’t gain by nomination or just by learning it.  You can improve it, but there should be some basis of natural leadership.  Ignoring this can be even counter-productive: conflicts will arise, the spirit and productivity will go down.

Categories: Companies

[Webinar] "Fast IT": Concepts and Examples from Assembla and Attivio

Assembla Blog - Fri, 07/11/2014 - 17:41

Join us on July 23, 2014 from 11:00 AM - 11:45 AM EDT for a webinar “Fast IT”: Concepts and Examples from Assembla and Attivio.

describe the image

When we at Assembla heard about the 2-2-2 project structure used by Attivio, we knew we had a fun story and a big idea to share.  The fun story is the way that Attivio can spin-up major Business Intelligence apps with 2-day, 2-person prototyping sessions. The big idea is “Fast IT”: a way of managing fast and Agile projects, while working smoothly with your slower, more reliable core systems: "Core IT".

In this Webinar, Sid Probstein, CTO of Attivio, and Andy Singleton, founder of Assembla, will share their discoveries about ways that “Core” and “Fast” can work smoothly together.  We will show tools that help you wrap and index your Core IT so that you can easily use it in Fast IT projects.  And, we’ll show how to professionally launch and manage an expanding portfolio of Fast IT projects for analytics, Web, mobile and marketing applications and SaaS integration. 

This Webinar is designed to help IT professionals or project managers who are handling analytics, Web, mobile, cloud and marketing applications.

describe the image

Presented By:

assembla logo rectangle    Attivio logo

Categories: Companies

Why Little's Law Works...Always

Xebia Blog - Fri, 07/11/2014 - 13:00

On the internet there is much information on Little's Law. It is described an explained in many places [Vac]. Recently, the conditions under which it is true got  attention [Ram11]. As will be explained in this blog the conditions under which the law is true are very mild. It will be shown that for teams working on backlog items virtually there are no conditions.

Why does it work? Under what conditions does it hold?

Airplane Folding

In the previous post (Applying Little's Law in Agile Games) I described how to calculate the quantities in Little's Law. As an example this was applied to the Agile game of folding airplanes consisting of 3 rounds of folding.

airplane-1

Let's look in more detail in which round an airplane was picked up and in which round it was completed. This is depicted in the following figure.

The horizontal axis shows the number of rounds. The vertical axis describes each airplane to fold. The picture is then interpreted as follows. Airplane no. 2 is picked up in round 1 and competed in the same round. It has a waiting time of 1 round. This is indicated at the right of the lowest shaded rectangle.
Airplane no. 8 was picked up in round 1 and finished in round 3. A waiting time of 3 rounds. Airplane no 12 (top most shaded area) was picked up in round 3 and unfinished. Up to round 3 a waiting time of 1 round.

The number 3, 5, and 10 denote the number of completed airplanes at the end of round 1, 2, and 3 respectively.

Waiting Times

The waiting times are determined by counting the number of 'cells' in a row.

The pictures show that we have 12 airplanes (12 'rows'), 3 completed in the first round, 2 more completed in the second round and 5 additionally  folded airplanes in the third and last round giving a total of 10 finished paper airplanes.

All twelve airplanes have waiting times of 1, 1, 1, 2, 2, 3, 3, 3, 3, 3, 3, and 1 respectively.

Work in Progress

In the figure below the number of airplanes picked up by the team in each round are indicated with red numbers above the round. new doc 6_2
In round 1 the team has taken up the folding of 11 airplanes (of which 3 are completed). In round 2 the team was folding 8 airplanes (of which 2 were competed) and in round 3 the team was folding 7 airplanes (of which it completed 5).

Work in progress is determined by counting the number of 'cells' in a column.

Little's Law.....Again

Now that we have determined the waiting times and amount of work in progress, let's calculate the average waiting time and average work in progress.

Average Waiting Time. This quantity we get by adding all waiting times and dividing by the number of items. This gives 26/12.

Average Work in Progress. This quantity is equal to (11+8+7)/3 = 26/3.

Average input rate. This is equal to 12 (the height of the third column) divided by 3 which gives 4.

Again we find that: Average Waiting Time = Average Work in Progress / Average input rate.

Why It Works

new doc 6_3 Little's Law works....always....because the average waiting times is got by adding the lengths of all the rows dividing by the number of rows, so it is proportional to the size of the shaded area in the picture to the right.

The average work in progress is got by adding the heights of the columns in the shaded area which is also proportional to the size of the shaded area.

Both the waiting time and work in progress relate to the size of the shaded area: one by adding the heights and the other by adding the rows. The proportionality corresponds to the average input rate.

Conditions

What assumptions did we make? None...well this is not exactly true. The only assumptions we make in this calculation:

  • We count discrete items
  • There are a finite number of rounds (or sprints)
  • Items enter and possibly leave the system.

That's it. It doesn't need to be stable, ageing (items having increasingly larger waiting times) is not a problem, prioritisation/scheduling of items (also known as queueing discipline), etc. Only the above assumptions need to be true.

Note: Especially the second condition is important, i.e. Little's Law is measured over a finite time interval. For infinite time interval additional conditions need to be fulfilled.

Note: When applying this to agile teams we always consider finite time intervals, e.g. 6 months, 1 year, 8 sprints, etc.

Conclusion

Little's Law is true because the average waiting time is proportional to the size of the shaded area (see figure) and the average work in progress is also proportional to the size of the same shaded area.

Only 3 basic conditions need to be met for Little's Law to be true.

References

[Vac] Little’s Law Part I, Dan Vacanti, http://corporatekanban.com/littles-law-part-i/

[Ram11] Little’s Law – It’s not about the numbers, Agile Ramblings, http://agileramblings.com/2012/12/11/littles-law-its-not-about-the-numbers/

Categories: Companies

UX: Why Lists Save Time

TargetProcess - Edge of Chaos Blog - Fri, 07/11/2014 - 02:44

Any information in the world falls into one of the 2 categories: it requires some action on our part, or it wants to be consumed (or browsed). The job of a UX designer or an infoviz/dataviz specialist, then, is to create UIs or pages with one of these goals in mind. If we want to subtly nudge users to browsing more pages in a passive mode, the design logic needs to be built just for that. If we want to help users act and save their time, rather than make them hang out on a web page,  then the page layout or user interface has to take that into account. I will show the difference between these two kinds of logic based on the  list and grid infoviz patterns from a news hub and from a project management tool.

It’s quite common nowadays to display news as a grid of tagline+image sets, maybe with a mouseover text. Here’s one such grid:

news grid

If we think about it, this image+headline+mouseover layout is used with one major goal: engage users. Make them spend more time browsing the news, move mouse over images, check a few headlines, click on an image. Once a mouseover text is displayed, it’s an easy-lazy thing to get to the full view of the news, with advertisements, videos and social comments. The grid layout, thus, appears to eat more of users’s time, luring them with this ease to click and to browse. In general, if we lay this whole “engagement” thing aside, reading news is a passive online activity, and it can be completed rather quickly. So, if someone wants to scan the news, rather than get stuck in them, they wouldn’t want to hover mouse over those pieces, checking for the clues. The grid layout in the news appears to be more “engaging”, as they call it, but it loses in terms of time spent vs. value gained. I mean, what if I don’t have time to move mouse over those snapshots to find out what’s behind a headline? Busy readers will likely want to just scan the news and headlines. They don’t even need those large image thumbnails. That’s why a list layout scores higher on the time spent/value gained scale. Check this out:

news list

This layout allows  to scan many headlines+summaries in one look. Readers are able to decide faster, if they want to click on some news or not, without mouseovers. Apparently, I would want to read more about the cleanup from storms, which left three dead, and I don’t have to hover mouse over an image, as in a kid’s game, to find out what the cleanup from storms entails. That’s why I like the list layout better: it is more respectful of my time. I must give credit to the UX designers of this news portal, though. They have provided users with an option to choose between a list and a grid.

That was the case with passive browsing. A few “active” things available to users on a news web-site would be clicking on an ad (the more time they spent there, the more likely they are to do that), posting a comment and/or sharing news in social networks. That’s the logic behind the grid design in case you were wondering why such a draining layout — that’s how it looks to me — should ever be used in the news. Another handy example of grid slowing us down is… our desktop. Often I just save stuff to my desktop, files, snips or images, and when I want to find something, it takes more time and effort to move eyes between thumbs, as compared to using a list or search.

Let’s now consider the logic behind the list and grid/board layouts in a project management tool. The UI of such a tool must encourage users to spend time productively. It might seem a stretched parallel, but in some ways board/grid is less efficient for project management as well. Lists will work better when it gets to managing bugs, for example:

list view inline edit 1

If someone in charge, a QA manager, or anyone else, will want to create a living display of bugs, tailored for hands-on work, it would be such a list. Apart from the compact layout, the list has inline edit for most of the fields, and it’s like with processing fish: bug details can be updated faster than in a grid view. Besides, the very columns in this list are customizable; one can choose which column they want to see and which not. Now, what if this person in charge were to work with bugs displayed as a grid? Check this out:

board view mouse over

As with the news portal grid, one has to move mouse over bugs for more details, e.g. to check on a bug’s severity. This grid layout would be a plus if I had time to leisurely contemplate which card might mean what, but if I want to change a bug’s status, assign people, or update tags, I need to dive further in *sigh*, click on the bug card and work there. The grid layout does not allow for quick scanning of the bugs and quick editing/updating. But it would be optimal for changing states as they do on a Kanban board. Thankfully, this project management tool allows users to switch between views when they want to do whatever they want :)

I hope these examples helped reveal some logic behind designing information layouts for various purposes.

Related articles:

How Visualize: Board, List or Timeline?

Visual Management Software

How Timelines Help Project Managers Track Progress

Categories: Companies

Bootstrapping and monitoring multiple processes in Docker using monit

Xebia Blog - Fri, 07/11/2014 - 00:01

If you have every tried to start a docker container and keep it running, you must have encountered the problem that this is no easy task. Most stuff I like to start in container are things like http servers, application servers and various other middleware components which tend to have start scripts that daemonize the program. Starting a single process is a pain, starting multiple processes becomes nasty. My advise is to use monit to start all but the most simple Docker application containers! When I found monit while delving through the inner works Cloud Foundry, I was ecstatic about it! It was so elegant, small, fast, with a beautiful DSL that I thought it was the hottest thing since sliced bread! I was determined to blog it off the roof tops. Until.... I discovered that the first release dated from somewhere in 2002. So it was not hot and new; Clearly I had been lying under a UNIX rock for quite a while. This time, the time was right to write about it! Most of the middleware components I want to start in a docker container, have a habit to start the process, daemonize it and exit immediately, with the docker container on its tail. My first attempt to circumvent this while starting a tomcat server in Docker looked something like this:

/bin/bash -c "service tomcat7 start;while service tomcat7 status;do sleep 1;done

Quite horrific. Imaging the ugliness when you have to start multiple processes. A better solution is needed:  With the zabbix docker container  the problem was solved using simplevisor. As you can read in this post that was not a pleasant experience either. As I knew little about simplevisor and could not solve the problem, I put in an issue and  resorted to a plain installation. But a voice in my head started nagging: "Why don't you fix it and send a pull request?"  (actually, it was the voice of my colleague Arjan Molenaar). Then, I remembered from my earlier explorations to the inner workings of Cloud Foundry, a tool that would be really suitable for the job: monit. Why? It will:

  1. Give you a beautiful,readable specification file stating which processes to start
  2. Make sure that your processes will keep on running
  3. Deliver you a clean and crisp monitoring application
  4. Reduce all your Docker starts to a single command!

In the case of the Zabbix server there were seven processes to start: the zabbix server, agent, java agent, apache, mysql and sshd. In monit this looks as follows:

check process mysqld with pidfile /var/run/mysqld/mysqld.pid
        start program = "/sbin/service mysqld start"
        stop program = "/sbin/service mysqld stop"

check process zabbix-server with pidfile /var/run/zabbix/zabbix_server.pid
        start program = "/sbin/service zabbix-server start"
        stop program = "/sbin/service zabbix-server stop"
        depends on mysqld

check process zabbix-agent with pidfile /var/run/zabbix/zabbix_agentd.pid
        start program = "/sbin/service zabbix-agent start"
        stop program = "/sbin/service zabbix-agent stop"

check process zabbix-java-gateway with pidfile /var/run/zabbix/zabbix_java.pid
        start program = "/sbin/service zabbix-java-gateway start"
        stop program = "/sbin/service zabbix-java-gateway stop"

check process httpd with pidfile /var/run/httpd/httpd.pid
        start program = "/sbin/service httpd start"
        stop program = "/sbin/service httpd stop"
        depends on zabbix-server

check process sshd with pidfile /var/run/sshd.pid
        start program = "/sbin/service sshd start"
        stop program = "/sbin/service sshd stop"

Normally when you start monit it will start as a daemon. But fortunately, you can prevent this with the following configuration.

set init

Your Dockerfile CMD can now always look the same:

    monit -d 10 -Ic /etc/monitrc

Finally, by adding the following statement to the configuration you get an application to view the status of your container processes,

set httpd
     port 2812
     allow myuser:mypassword

After starting the container, surf to port 2812 and you will get a beautiful page showing the state of your processes and the ability to stop and restart them.

monit overview monit process control

Just delve into the documentation of monit and you will find much more features that will allow you to monitor network ports and files, start corrective actions and send out alerts.

Monit is true to its UNIX heritage: it is elegant and promotes an autonomous monitoring system. Monit is cool!

Categories: Companies

Breaking Gantt – Project Reporting in Agile Transition – A BigVisible Webinar

BigVisible Solutions :: An Agile Company - Thu, 07/10/2014 - 20:47

Breaking Gantt – Project Reporting in Agile Transition – A BigVisible Webinar by Dave Prior

When an organization makes the decision to move from a traditional (waterfall) approach to Agile, coming to grips with the new way of tracking projects can be one of the biggest challenges. Dave Prior presents on some of the tips and tools he has found to have a positive impact when helping an organization let go of their dependence on traditional project tracking in favor of Agile reporting.

Webinar Topics Include:
• Core differences between traditional and Agile project tracking
• How Agile reporting can impact a traditional organization
• Communication Modeling and Agile Transition
• Understanding the needs of an organization in transition
• Tracking Agile projects
• Hybrid reporting approaches

download

The post Breaking Gantt – Project Reporting in Agile Transition – A BigVisible Webinar appeared first on BigVisible Solutions.

Categories: Companies

More Agile Testing: Book Review

Growing Agile - Thu, 07/10/2014 - 11:00

We were lucky enough to receive a pre-release copy of Janet Gregory and Lisa Crispin’s new book: More Agile Testing. The book is available for pre-order and the published version is coming soon. I highly recommend the book, even if you haven’t read the previous one. Here’s my review.

 Book ReviewMore Agile Testing is a great collection of stories and ideas that can help you improve, not just how you test, but the products you build and the way you work. What I love most about the book is how easy many of the ideas are to try. If one message is clear, it is that regardless of your context and challenges there are things you can try to improve. Get started today with something small, and nothing will be impossible.

I wanted to pick three things that I found most useful to share with potential readers to help you get a flavour for the book. Trust me it was hard to pick just three, but here they are.

The chapter on Technical Awareness is excellent. For a long time I have heard people debate whether testers need to be able to code. In this chapterJanet and Lisa answer this eloquently and confirm my personal views that even if you don’t write code, testing requires specific and deep technical skills.

Secondly I love the approach to both Session Based and Thread Based Exploratory Testing with test charters. In particular the idea of using this with the whole team for pre-release manual regression. I have been struggling to find a good approach for teams not ready or able to give up manual regression and I think this approach is exactly what I have been searching for.

The third (and hardest to pick because the more I read, the more good ideas there were) is the approach of using page objects to simply automated UI testing. I often encounter teams stalled in the maintenance nightmare of GUI automation and I have not had practical advice except move the tests down the pyramid. This books offers some great ideas to help refactor and structure UI tests.

Lisa and Janet mention this book starts where the last one left off, but in someways I think it’s a great prequel. If you read agile testing and haven’t managed to adopt the ideas in it, then I think this book will help you get started. The stories in the book will help you see that even seemingly impossible obstacles can be overcome. Probably the greatest praise I can give this book is to say that it made me want to become a tester again. It is an exciting time with fantastic tools and approaches available and this book will help you uncover them.

Categories: Companies

New ScrumMaster Tips

Agile Management Blog - VersionOne - Wed, 07/09/2014 - 18:47

Team

I recently completed a blog on PMs transitioning to a ScrumMaster role.  I was inspired to put together a quick blog post for new ScrumMasters after reading a question that was posted to social media.  The poster basically wanted to know how to drive the team without them reporting to him/her or having “control” over them.  When I first read this I was perturbed but quickly thought to myself this person could be new to Agile and Scrum.  I’ll refer back to my definition of a ScrumMaster, a servant leader who is an Agile champion for your team.  I didn’t say management leader or controller or mother of dragons.

The ScrumMaster role is very challenging role and it takes some self control for people coming from a different role such as a PM or a lead from the team.  I am not a fan of “working” ScrumMasters, meaning they are also coders or leads.  They need to resist the urge to roll up their sleeves and dive in.  A good example of this, I was working on a Legos4Scrum (By Alexey Krivitsky) exercise acting as ScrumMaster.  Legos4Scrum is a cool way to introduce Scrum during an Agile bootcamp. You basically have teams working with sprints building items for a city while working with a product owner for vision of the city.  All the other teams had working ScrumMasters meaning they were diving in helping to build items such as schools and hotels for the city.  I was not building anything, instead I was separating the bricks, breaking bricks apart, sorting into colors etcetera making it easier for the team to build. Can you guess which team achieved a higher velocity? The team with a ScrumMaster who was constantly making the team’s job easier.  I was also working with product owner with any questions the team had as they were building. I tracked down the product owner if need be, not the team member working.  Do whatever you can to keep impediments down and efficiency high!

The servant leader side of the role is rewarding but being an Agile champion is crucial.  If you are new to the role start to soak up as much knowledge as you can.  At the end of the day you serve as the Agile coach for the team.  You should know the ceremonies and fun ways to facilitate them.  I highly recommend joining groups out there in internet land.  If you have a local Agile group join it, attend the meetings and share your experiences.  You will never stop learning.  Your knowledge and ways to handle situations builds trust with the team.

Another piece of advice I have is to provide a fun environment for your team.  Anything you can do to achieve this whether it is adding some cool posters or getting that energy drink fridge installed.  Try coming up with fun ways to do the standups and retrospectives.  If your team has the personality for it a prank doesn’t hurt from time to time.  Now remember don’t rewire the power switch on a PC to a remote power switch unless they can take a joke.  That was one of my favorite pranks I’ve ever been apart of.  Soft dart guns can also be very interesting on Friday afternoon.

I have only scratched the surface, this is a topic I could type for days on since I am very passionate about it.  That being said if you are a ScumMaster and have some tips please comment for those new ScrumMasters out there!

Categories: Companies

Recent Enhancements to LeanKit

Enhancements have been rolling in over the past few months. Here’s a rundown of some of the latest features, including: Mass card updates Auto-subscribe settings Quick card adds Mobile app improvements Update Multiple Cards at Once The new multi-select option (Ctrl/Cmd + click) allows you to update multiple cards on a board at once. Remove cards that are […]

The post Recent Enhancements to LeanKit appeared first on Blog | LeanKit.

Categories: Companies

Random Issues in the Agile Transformation Bridge

BigVisible Solutions :: An Agile Company - Wed, 07/09/2014 - 17:25

The other day I was thinking about the problems I have been seeing with clients. My thoughts expanded from the current team and organization concerns to more general scope of experiences with other transformations. Below is the resulting list of ideas, in no particular order and without fanfare. Let’s talk about it if you’d like to go deeper on your favorite!

Random Issues in the Agile Transformation Bridge

Tacoma-narrows-bridge-collapse

  • Managing by email doesn’t work well. Leading a transformation by email doesn’t work at all.
  • Documents are important. Leading by example is vastly more important.
  • Before you can scale Agile (or anything else) you have to have Agile (or that anything) to scale.
  • If the business around the teams does not change, the teams will work they way they always have and just use the new labels for what they do. And have more frustration.
  • Policies, procedures and processes send messages. These messages define your culture. To ignore the messages is to ignore culture.
  • Culture eats strategy for lunch. And dinner. And steals your lunch money. Unless culture is aligned with your strategy. Then it gives you lunch. And Dinner. And more lunch money in beautiful greeting cards.
  • Ownership of improvements is better handled by those who need to improve. That means improvements mandated by others rarely create the desired result.
  • If a team doesn’t have what they need to get the work done, asking them to work harder will not help much.
  • For every decision maker or specialized skill that is not dedicated to a team add two days to every request. For example, if the stakeholder needs to approve a feature change it will take at least two days to get an answer. If a meeting is needed, add four days.
  • 99% or more of the time everyone is doing the best they can under the circumstances. Check your system and environment for the root causes of failure, not your people.

The post Random Issues in the Agile Transformation Bridge appeared first on BigVisible Solutions.

Categories: Companies

How Workspace Improves Productivity

TargetProcess - Edge of Chaos Blog - Tue, 07/08/2014 - 22:57

Success in software development business depends on an intricate fusion of optimized individual performances, be it for a C-level executive, or for a junior software developer, QA engineer or UX designer. Naturally, stakeholders want to drive business results to the optimum, using the leverages they can control, as they are looking for the ways to foster productivity of teams and individuals. In the end, it’s people who take decisions, come up with creative ideas and make working software. That’s why it’s so important to design a harmonious workspace that helps people feel good and deliver their best work. Enough has been said on how stressful environments strangle performance. A stressful environment, the way I see it, covers not only work, but lifestyle-related stresses, such as tedious commutes, being a parent to a newborn or overspending energy on a pursuit unrelated to work. Employers pretty much have no control over such things. A sensible employer will surely be aware of the impact they make on productivity, but these are life choices that people make, when it goes about babies and hobbies; it’s a matter of personal responsibility. Commutes can be controlled, partially, either by setting up an office in a favorable location with decent standards of living and reasonable population density, or by allowing remote work. What stakeholders can control completely is workspace. Rather than brooding over utopian surroundings, it makes sense to focus on the things that can be improved in your office.

That’s exactly what we do in our company, Targetprocess. We are in product development, and this implies that enhanced creativity and optimized individual performance are essential for the company’s success. In this business the price is too high if people are coming up with faulty solutions, on all levels. We simply cannot afford being downtrodden by a dull office environment.

A well-thought-out workspace can help a lot with these 4 things (or activities):

#1. Informal exchanges

Very often, if not always, discussions on work-related issues occur anywhere but at a scheduled meeting. Such conversations can bring along some good ideas, from our experience. That’s why Targetprocess office has been specifically designed to encourage these informal exchanges. The office is made up of 3 round towers, and we have a lounge dining area in one of the towers, the Green one, where we carry free buffet lunches. There’s also an espresso machine with a counter, and this lunch space has snacks and supplies. This environment encourages people to talk and share ideas. Here’s a map view of our Green tower (we also have the Blue tower, and the Orange tower, the space takes about 11,000 sq feet in total):

green tower

The other two towers have coffee counters in the center, with bar stools and a cooler/heater nearby. Everyone is welcome to stop by, sit down and discuss something.

Another thing that we have in place to facilitate informal exchanges is a no-cubicle setup. Some of us had previously worked at companies with huge open spaces, which would be another extreme. Of course, people can talk freely when they sit in one large room, but the noise and distractions are horrible. So, we’ve arranged something in the middle and remodeled the original space in the towers as “slices of a pie”. Check the snapshot of the Blue tower:

the blue tower

These pie-slice rooms hold comfortable workspace for our feature teams. Each feature team is cross-functional, and includes software developers as well as QA engineers. They usually develop one piece of our product’s functionality. This workspace arrangement is more favorable for our development process than a maze of 50 cubicles in one open-space, looks like. And, of course, it fosters informal exchanges in feature teams.

#2. Focused solo work

This kind of work can also be facilitated by office space. We have silent rooms, with a lounge chair or a couch, available to anyone who needs some time alone. One of these rooms is located in our office library. A UX designer, or a software developer, or a company stakeholder, or anybody else can walk in to the library (we have 300+ books and counting), pick a book from a shelf, flip through the pages, sit down in an armchair nearby and get some insight. Actually, a library is not only a part of an office space. It is a part of our continuous learning culture, which is mega-important to us as a software product company. Here’s a picture of some bookshelves in the library:

TauLibrary

#3. Visual aids

We believe in the power of all things visual. Nothing facilitates creative thinking and problem-solving more than having a problem sketched, visualized, diagrammed and dissected. Also, nothing can give a work status report faster than a crisp visual dashboard. That’s why our office sometimes reminds a school with many classrooms. We have whiteboards in every pie-slice room, and we’ve also used IdeaPaint to turn some of the walls into the renewable sheets for jotting down ideas, software architecture maps and what not. That’s how we visualized our production roadmap on an IdeaPaint wall a few years ago:

roadmap for 2 dev teams Targetprocess

A large digital screen is another tool that helps a lot with visualizations. Just one example, that’s how we feed the status of our production builds to a screen:

a screen with production builds in Targetprocess office

 

This whole visualization philosophy is very strong with us, and since our product is a visual management tool, we have many screens with boards in the office.

#4. The sweet things and “feel good” stuff

These are the small things that do not directly contribute to productivity, but help brighten up the environment and make it happiness-oriented. Imagine, after a dull commute in a rainy day, or after a night of bad sleep you walk in to your office… and this charming cat greets you  :)

a cat with the deer horns

This cat is a very influential guy, by the way. We use it as a token to identify who is in charge of automated test runs. The cat obviously feels some affinity with deer (this picture was taken at Christmas time).

It somehow happens that our employees care about the space around them. Such small things do not appear in the office by an executive rule. People use their own creativity to make their workspace vibrant. Take a look at this custom artistic installation at a QA engineer’s desk:

inspiring wooden clips

I believe each and every office can come up with things like that. Such DIY craftworks create a cozy environment at work, helping people feel relaxed rather than stressed out. When everyone is focused and still relaxed, that’s when the real good work happens.

There’s yet another dimension to office environments. Workspace can be improved not only with furniture, or artefacts, but emotionally. Harmonious emotional spaces facilitate improved individual and group performance as much as harmonious room spaces, if not more. But this would be a subject for another article.

Related articles:

5 Things We Need for Sustainable Performance at Work

Cognitive Endurance Basics for Software Development

Continuous Problem-Solving Is No Accident

Top 5 Non-Office Brain Killers

The Perils of Facebook-ization

Do You Need an Open Office?

Our Library

Categories: Companies

Tuning your Scrum Standups

Rally Agile Blog - Tue, 07/08/2014 - 16:00

I recently taught my first Scrum workshop in a while, after a number of years of doing other work. The team was excited and ready to go. The next day, they held a daily standup in the traditional style. Each person answered the three questions:

“What did I do yesterday?”  

“What will I do today?”  

“What’s slowing me down?”

But since they were sitting together, it really felt forced. They had all worked together they day before, and so the readouts of “what I did yesterday” were pretty useless. At the same time, “what am I committing to do today” was something they needed to collaborate on -- not something they could each read out independently.

At the time, I reminded them that this wasn’t meant to be a status meeting -- it was a time for them to coordinate, and they discussed a little bit more amongst themselves. The three questions, meant to be a starting point, were a distraction from what they actually needed to talk about.

Not too long ago, I was at an event where Jim Benson talked about his mission to end the question, “What are you doing?” in the workplace. If work is being made visible through some kind of system or board, the answer should be obvious. You don’t need people to read out on this.

At Rally, most of our teams do daily standups, but I don’t see any of them following the traditional three-questions format. Most of these teams stand around a kanban board and then talk, right to left, about what needs to be done to move items forward. It doesn’t take long; the meeting is focused on the work, not the people, and the teams walk out the door with a clear plan every day.  

photo via Flickr, Creative Commons

This approach doesn’t ensure everybody talks. But over time, it’s obvious who’s involved … and who’s not.

Is it time for your team to stop going through the motions of the three questions in your daily standup, and start focusing on the work again?

Learn more about Standups, Scrum, and other Agile fundamentals with the Chalk Talk video series.

Alex Pukinskis
Categories: Companies

7 tips to improve your standup

Growing Agile - Tue, 07/08/2014 - 10:03
standup2 300x201 7 tips to improve your standup 1. Check your time.

Five minutes is too little, this means people are rattling off tasks but not really communicating. More than 15 minutes is too long, usually this indicates that some people are going into deep discussions which can be parked until after the standup.

2. Who is there?

Only people working on tasks with the team and the team should be there. Personally I think the Product Owner should be there as often as possible. IF you have more than 10 people in your standup its too big. Indicators are that most people don’t know what others are working on and so lose interest.

3. The 3 questions

The three questions: What did you do yesterday? What will you do today? Do you have any impediments? Each person should be answering these everyday. It helps if each person spends a few minutes before the standup thinking about what they will share and comes to the meeting prepared. It’s also important to listen to each person. When someone has been working on the same task for a few days, they should be offered assistance, and encouraged to break the task down.

4. Impediments

Most people answer that they have no impediments and yet the words they use indicate there are many. Take a look at our impediments video to learn how to listen for these words. We also have a great fourth question you can ask that will help uncover impediments.  Video & Workbook

5. Updating the board and burndown

The people doing the work need to control the board. It is their board. So if the ScrumMaster is doing this, get them to stop. Ask the team to update the board to reflect what they have just said during the standup. At the end of the standup, ask someone to update the burndown chart – which should be visible at all times, preferably next to the board and not in some online tool.

6. Checking the commitment expectations

Often teams have a great sprint except for the last 2 days when they realise they are not going to finish all their commitments. As soon as the burndown chart has been updated (by someone in the team)  ask the team if they are on track to meet their sprint commitment. If not, ask them what they can do to get back on track. Often a quick conversation with a Product Owner can result in simplification of a story in order to have it completed within the sprint. This is also an indication that the team could and should break down their stories smaller.

7. Start on time, same time everyday

Its much easier to attend a meeting if it is same time and same place everyday. Always start on time, even if there is only one person there. As the others arrive, don’t catch them up. Soon the team will learn to arrive on time and respect each others time and commitment to the meeting.

 

Categories: Companies

Applying Little's Law in Agile Games

Xebia Blog - Mon, 07/07/2014 - 22:20

Have you ever used Little's Law to explain that lower WiP (work in progress) limits lead to shorter cycle times? Ever tried to illustrate Little's Law in an Agile game and found it doesn't hold? Then read this blog to discover that it is exactly true in Agile games and how it really works.

Some time ago I gave a kanban workshop. Part of the workshop was a game of folding paper airplanes to illustrate flow. To illustrate Little's Law we determined the throughput, cycle time and work in progress. To my surprise the law didn't hold. Not even close. In this blog I want to share the insight into why it does work!

Introduction

It is well known that the average number of items in progress is proportional to the average cycle time of completed work items. The proportionality is the average input rate (or throughput rate) of work items. This relation is known as Little's Law. It was discovered by Little in the 1960s and has found many applications.

In kanban teams this relationship is often used to qualitatively argue that it is favourable for flow to have not too much work in parallel. To this end WiP (work in progress) limits are introduced. The smaller the WiP the smaller the average cycle time which means better flow.

A surprise to me was that it is exactly true and it remains true under very relaxed conditions.

Little's Law

In mathematical form the law is often stated as:

(1)

 \bar{N} = \lambda \bar{W} \bar{N} = \lambda \bar{W}

Here  \bar{N} \bar{N} is the average number of work items in progress at a certain time, and  \bar{W} \bar{W} is the average cycle time.  \lambda \lambda is the average input rate (new work items per unit of time). In stable systems this also equals the average throughput. In this case Little's Law is often (re)stated as

(2)

 \frac{\mathrm{Work\, in\, progress}}{\mathrm{Throughput}} = \mathrm{Cycle Time} \frac{\mathrm{Work\, in\, progress}}{\mathrm{Throughput}} = \mathrm{Cycle Time}

Conditions

In practise one considers Little's Law over a finite period of time, e.g. 6 months, 5 sprints, 3 rounds in an Agile game. Also in practise, teams work on backlog items which are discrete items. After the work is done this results in a new product increment.

Under the following conditions (1) is exact:

  • The system is observed over a finite period of time,
  • The system is a queueing system.

A queuing system is a system that consists of discrete items which arrive at a certain rate, receive service after which they depart.

Examples of a queueing system. An agile team works on backlog items. A kanban team that works on production incidents. A scrum team.

Agile Game

An often used game for explaining the importance of flow to team is the game of folding paper airplanes. Many forms of this games exist. See e.g. [Heintz11].

For this blog's purpose consider a team that folds air planes. The backlog is a stack of white paper. 3 Rounds of folding are done. Airplanes that are folded and fly at least 2 meters are considered done.

new doc 5_1-1

At the end of each round we will collect the following metrics:

  • number of completed airplanes
  • number of airplanes in progress and not yet finished.

The result of the the 3 rounds are shown at the right. At the end of round 1 Team A completed 3 airplanes and having 8 unfinished airplanes. Likewise, Team B finished 4 airplanes in round 3 giving a total of 12 finished airplanes and having 6 unfinished airplanes in progress.

The cycle time are got by writing the round number of the sheet of paper when starting to fold the airplane. When done, write the round number of the paper. The cycle time for one airplanes is got by subtracting the two and adding 1.

Calculating Little's Law

The way I was always calculating the number for work in progress, throughput and cycle time has been

  1. averaging cycle time for all completed airplanes,
  2. averaging the throughput over all rounds,
  3. averaging the work in progress over all rounds.

When calculated at the end of round 3, for Team A this amounts to:

  • Average work in progress = (8+6+2)/3 = 16/3,
  • Average throughput = 10 (completed airplanes)/3 = 10/3,
  • Average cycle time = 22/10 = 11/5

Using (2) above we get: 16/3 / (10/3) = 8/5. This is not equal to the average cycle time of 11/5. Not even close. How come?

The Truth

The interpretation of work in progress, throughput and cycle time I got from working with cumulative flow diagrams. There are many resources explaining these, see e.g. [Vega2011].

The key to the correct interpretation is choosing the time interval for which to measure the quantities  \bar{W} \bar{W} ,  \lambda \lambda , and  \bar{W} \bar{W} . Second, using the input rate instead of the throughput. Third, at the end of the time period include the unfinished items. Last, in calculating  \bar{N} \bar{N} consider all items that went through the system.

When we reinterpret the results for teams A and B we get

Team A

  • Average work in progress
    In round 1 3 airplanes were completed and left 8 unfinished; a total of 11 for work in progress (11 airplanes picked up as work)
    In round 2 the team completed 2 airplanes and have 6 unfinished; a total of 8
    In round 3 the team finished an additional 5 airplanes and left 2 uncompleted; a total of 7
    When measured over 3 rounds an average of (11+8+7)/3 = 26/3
  • Average input rate
    Using the input rate:
    In round 1 the team picked up 11 new airplanes
    In round 2 the team picked up no additional airplanes
    In round 3 one new airplanes was picked up.
    An average input rate of (11+0+1)/3 = 4 airplanes per round
  • Average cycle time
    At the end of the third round 2 airplanes are left in progress; one taken up in the third round having a waiting time of 1 and one left from the first round having waiting time of 3 rounds. A total waiting time of 22 + 3 + 1 = 26 rounds.
    Averaging over 12 airplanes we have an average cycle time of 26/12 = 13/6 rounds per airplane.

Dividing the average work in progress by the average input rate we get 26/3 divided by 4 = 26/12(!). This is exactly equal to the calculated average cycle time!

Team B

In a similar manner the reinterpreted results for team B are:

  • Average work in progress = (13+14+10)/3 = 37/3 airplanes,
  • Average input rate = (13+2+3)/3 = 6 airplanes per round,
  • Average cycle time = (27 (completed) + 10 (unfinished))/18 (airplanes) = 37/18 rounds per airplane

Again, dividing the average work in progress by the average input rate we get 37/18 rounds per airplane, which again is exactly equal to the average cycle time or waiting time!

Note: the cycle time of 10 days is built up by (a) 1 airplane from round 1 (cycle time of 3), 2 airplanes picked up in round 2 (total of 4 rounds), 3 airplanes picked up in round 3 (total of 3 rounds).

What About Cumulative Flow Diagrams?

Now that we understand how to calculate the quantities in Little's Law, we go back to cumulative flow diagrams. How come Little's Law works in this case.

In the case of teams that have collected data on cycle time, work in progress and throughput Little's Law work when done as explained in the section 'Calculating Little's Law' because:

  1. the teams are kept stable by having WiP limits on the left most column ("To Do"); then the throughput is more or less equal to the input rate,
  2. the team has completed a fairly large amount of work items in which case the waiting time of unfinished work items can be neglected,
  3. when measured over the (large part of the) value creation process, the completed items per time period can often be neglected in the calculation of the average work in progress.
Summary

Little's Law (1) holds under the conditions that (a) the system considered is a queueing system and (b) the observation or measurements are done over a finite time interval. It then holds independently of the stationaryness of the probability distributions, queuing discipline, emptiness of the system at the start and end of the time interval.

Calculate the quantities  \bar{N} \bar{N} ,  \lambda \lambda , and  \bar{W} \bar{W} as follows:

  • Average work in progress  \bar{N} \bar{N}
    For each time interval considered count the total amount of work in the system and add any items completed in that time interval.
  • Average cycle time  \bar{W} \bar{W}
    Sum the cycle times for all completed items and include the waiting time for unfinished items and divide by the total number of items.
  • Average input rate  \lambda \lambda
    Add the total number of items that entered the system and divide by the total number of time intervals.
References

[Little61] Little, J. D. C. 1961. A proof for the queuing formula: L = ãW . Oper. Res. 9(3) 383–387.

[Heintz11] John Heintz, June 2011, Agile Airplane Game, GistLabs, http://gistlabs.com/2011/06/agile-airplane-game/

[Vega11] Vega Information System Services, Inc., September 2011, Basics of Reading Cumulative Flow Diagrams, http://www.vissinc.com/2011/09/29/basics-of-reading-cumulative-flow-diagrams/

 

Categories: Companies

What does it really mean to be an Agile Tester?

Agile Management Blog - VersionOne - Mon, 07/07/2014 - 18:46

I was a QA Lead back in the mid 90’s for a couple of years, before any of this fancy Agile stuff really started taking off. Waterfall all the way back then; mostly manual testing, with full regression cycle at the end. Hurry up and wait, then go like hell given some ridiculously small window of time remaining before we had to release to Production. We started to dabble with automated testing tools, but they were difficult to use at the time; you almost needed to be a programmer. But a lot has changed since then.

What I learned more recently, in making the move to Agile testing methods and away from these more traditional QA functions, is that it’s a really big undertaking.

For those Testers out there who have yet to really dive into the deep end of the pool with Agile testing, let me just tell you this… you have never been so important in this new Agile world.

I think it’s this ‘whole team’ approach that’s probably the biggest difference between Agile and Traditional Waterfall development.

All for one

As an Agile Tester, you’re a full-fledged, first class member of the Agile Team. All for one and one for all!

You may be saying to yourself… “That sounds nice. And I don’t disagree on the Three Musketeers cheerleading you’re doing here, but I’ve heard that before. Be a bit more specific; What does it ‘really’ mean to be an Agile Tester?”

OK, allow me to elaborate…

For starters, it means that as an Agile Tester, you actively participate in planning, estimation, scheduling, retrospectives and any other activities of the team. You’re no longer in a QA silo where you only come out to play near the end of a project or release.

It also means you’re not the only one on the team who can test, anybody can. But no need for concern; you’re still the best equipped to do so. In other words, you’re job isn’t going anywhere. And more good news; you have help when you need it.

It means that you embrace change; you collaborate well with your team members as well as those outside the team.

It means you know how to help other folks on the team automate tests and help drive exploratory testing.

It means you put yourself in the customer’s shoes, and understand where they’re coming from, what their needs are. You’re empathetic, and can see the big picture.

It means you possess a unique perspective in the way things should work, and can help identify any potential roadblocks and dependencies sooner rather than later.

It means you guide other folks on the team, helping them improve upon their testing knowledge.

It means you work closely with the developers, sharing your skills and knowledge with each other; developers helping testers with some of the more technical aspects of creating automated tests, for example.

It means you work closely with the Product Owner, guiding and helping them understand the acceptance criteria, and final verification of what it means for a user story to be ‘done’.

It means you’re involved heavily in the design of the user story’s test cases prior to Sprint Planning. This helps your Sprint Planning Meetings go more smoothly. You groom your test cases in much the same way a Product Owner grooms their product backlog.

It means you’re an explorer. You’re systematic in the way you work, you pursue anomalies, and you think about what folks on both ends of the spectrum would do.

It means you radiate information. You open the doors and provide visibility into all testing activity. Things like ‘Testboards’ that display test status and progress, defects reports, impediments, trends, etc.

It means you’re heavily involved in the estimation process, helping folks understand the acceptance criteria for the user stories, and helping to refine them along the way.

It means you actively participate in Sprint Planning, identifying individual testing tasks. Things like preparing the testing data, executing the tests, exploratory testing, test automation, etc.

It means you help the Team decide what it means for a story to be ‘done’. Things like… code complete, unit tests written and executed, integration tested, performance tested, documentation completed, etc.

It means you understand and can articulate the difference between an ‘issue’ (a problem that occurs ‘during’ the Sprint and it coupled to a user story that hasn’t yet met its definition of done) and a ‘bug’ (identified ‘after’ a user story has been completed and accepted by the Product Owner). Bugs are included in and prioritized in the Product Backlog Item. Issues are not.

In particular, it means you understand the 2nd line item in the Agile Manifesto very well (working software over comprehensive documentation). Meaning you get the importance of face-to-face communication over formal documentation of all bugs. Be lean.

It means you address issues head on. We all know the sooner an issue is found, the cheaper it is to fix it. Make sure you practice this, and the folks on the team do too, and put it into practice.

It means you understand the importance of automation, and help the team put into practice stuff like automated testing, continuous integration, build-deploy automation, and continuous delivery.

And yes, it means you actually run tests too, whether they’re automated or manual.

Yea, I know; this is a lot to take on. Start small. Make progress in chunks. Be empirical. Inspect and adapt.

If you’ve made the move to Agile practices, what have you found to be the biggest difference when it comes to testing? What are some of your biggest struggles?

Categories: Companies

Create the smallest possible Docker container

Xebia Blog - Fri, 07/04/2014 - 22:59

When you are playing around with Docker, you quickly notice that you are downloading large numbers of megabytes as you use preconfigured containers. A simple Ubuntu container easily exceeds 200MB and as software is installed on top of it, the size increases. In some use cases, you do not need everything that comes with Ubuntu. For example, if you want to run a simple web server, written in Go, there is no need for any tool around that at all.

I have been searching for the smallest possible container to start with and found this one:

docker pull scratch

The scratch image is perfect. Literally perfect! It is elegant, small and fast. It does not contain any bugs, security leaks, slow code or technical debt. And that is because it is basically empty. Except for a bit of metadata added by Docker. In fact, you could have created this scratch image yourself with this command as described in the Docker documentation:

tar cv --files-from /dev/null | docker import - scratch

 

So that is it, the smallest possible Docker image. End of blog post!

... or is there something more we can say about this? For example, how do you use the scratch base image? It turns out this brings some challenges of its own.

Creating content for the scratch image

What can we run on an empty base image? An executable without dependencies. Do you have executables without dependencies?

I used to write code in Python, Java and JavaScript. Each of these languages/platforms require a runtime installed. Recently, I started looking into the Go (or GoLang if you prefer) platform. And it seems (spoiler alert) like Go is statically  linked. So I tried compiling a simple web server saying Hello World and running it within the scratch container. Here is the code for the Hello World web server:

package main

import (
	"fmt"
	"net/http"
)

func helloHandler(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintln(w, "Hello World from Go in minimal Docker container")
}

func main() {
	http.HandleFunc("/", helloHandler)

	fmt.Println("Started, serving at 8080")
	err := http.ListenAndServe(":8080", nil)
	if err != nil {
		panic("ListenAndServe: " + err.Error())
	}
}

 

Obviously, I cannot compile my webserver inside the scratch container as there is no Go compiler in it. And as I am working on a Mac, I also cannot compile a Linux binary just like that. (Actually, it is possible to cross-compile GoLang sources to different platforms, but that is material for another blog post)

So I first need a Docker container with a Go compiler. Let's start simple:

docker run -ti google/golang /bin/bash

 

Inside this container, I can build the Go web server, which I have committed in a GitHub repository:

go get github.com/adriaandejonge/helloworld

 

The go get command is a variant of the go build command that allows fetching and building remote dependencies. You can start the resulting executable with:

$GOPATH/bin/helloworld

 

This works. But it is not what we want. We need the hello world container to run inside the scratch container. So, in fact, we need a Dockerfile saying:

FROM scratch
ADD bin/helloworld /helloworld
CMD ["/helloworld"]

 

and then start that. Unfortunately, the way we started the google/golang container, there is no way to build this Dockerfile. So first, we need a way to access Docker from within the container.

Calling Docker from within Docker

When you use Docker, sooner or later you run into the need to control Docker from within Docker. There are multiple ways to accomplish this. You could use recursion and run Docker inside Docker. However, that seems overly complex and again leads to large containers. You can also provide access to the Docker server outside the instance with a few additional command line options:

docker run -v /var/run/docker.sock:/var/run/docker.sock -v $(which docker):$(which docker) -ti google/golang /bin/bash

 

Before you continue, please rerun the Go compiler, as Docker forgot our previous compilation during the restart:

go get github.com/adriaandejonge/helloworld

 

When starting the container, the -v flag creates a volume inside the Docker container and allows you to provide a file from the Docker machine as input. The /var/run/docker.sock is the Unix socket that allows access to the Docker server. The $(which docker) part is a clever way to provide the path for the docker executable inside the container without hardcoding it. However, be careful when you use this command on an Apple when using boot2docker. If the docker executable is installed in a different location than it is installed in boot2docker's virtual machine, this results in a mismatch. It will be the executable inside the boot2docker virtual server that gets inserted into the container. So you may want to replace $(which docker) with /usr/local/bin/docker which is hardcoded. Similarly, if you run a different system, there is a chance that the /var/run/docker.sock has a different location and you need to adjust it accordingly.

Now you can use the Dockerfile inside the google/golang container in the $GOPATH directory, which points to /gopath in this example. Actually, I already checked this Dockerfile into GitHub. So you can copy it from the Go build directory to the desired location like this:

cp $GOPATH/src/github.com/adriaandejonge/helloworld/Dockerfile $GOPATH

 

You need to copy this as the compiled binary is now located in $GOPATH/bin and it is not possible to include files from parent directories when building a Dockerfile. So after copying, the next step is:

docker build -t adejonge/helloworld $GOPATH

 

And if all goes, well, Docker responds with something like:

Successfully built 6ff3fd5a381d

 

Which allows you to run the container:

docker run -ti --name hellobroken adejonge/helloworld

 

But unfortunately, now Docker responds with:

2014/07/02 17:06:48 no such file or directory

 

So what is going on? We have a statically linked executable inside a scratch container. Did we make a mistake?

As it turns out, Go does not statically link libraries. Or at least not all libraries. Under Linux, we can see the dynamically linked libraries for an executable with the ldd command:

ldd $GOPATH/bin/helloworld 

 

Which responds with:

linux-vdso.so.1 => (0x00007fff039fe000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f61df30f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f61def84000)
/lib64/ld-linux-x86-64.so.2 (0x00007f61df530000)

 

So before we can run the Hello World webserver, we need to tell the Go compiler to actually do static linking.

Creating statically linked executables in Go

In order to create statically linked executables, we need to tell Go to use the cgo compiler rather than the go compiler. The command to do so is:

CGO_ENABLED=0 go get -a -ldflags '-s' github.com/adriaandejonge/helloworld

 

The CGO_ENABLED environment variable tells Go to use the cgo compiler rather than the go compiler. The -a flag tells Go to rebuild all dependencies. Otherwise you still end up with dynamically linked dependencies. And finally the -ldflags '-s' flag is a nice extra. It reduces the file size of the resulting executable by roughly 50%. You can also do this without the cgo compiler. The size reduction is a result from removing debug information.

Just to be sure, rerun the ldd command.

ldd $GOPATH/bin/helloworld 

 

It should now respond with:

not a dynamic executable

 

You can also rerun the steps for creating the Docker container around the executable from scratch:

docker build -t adejonge/helloworld $GOPATH

 

And if all goes well, Docker responds with something like:

Successfully built 6ff3fd5a381d

 

Which allows you to run the container:

docker run -ti --name helloworld adejonge/helloworld

 

And this time it should respond with:

Started, serving at 8080

 

Until so far, there were many manual steps and there is a lot of room for error. Let's exit from the google/golang container and continue from the surrounding machine:

<Press Ctrl-C>
exit

 

You can check the existence or absence of containers and images with:

docker ps -a
docker images -a

 

And you can do some cleaning of Docker with:

docker rm -f helloworld
docker rmi -f adejonge/helloworld

 

Creating a Docker container that creates a Docker container

The steps we took so far, we can also record in a Dockerfile and have Docker do the work for us:

FROM google/golang
RUN CGO_ENABLED=0 go get -a -ldflags '-s' github.com/adriaandejonge/helloworld
RUN cp /gopath/src/github.com/adriaandejonge/helloworld/Dockerfile /gopath
CMD docker build -t adejonge/helloworld gopath

 

I checked this Dockerfile into a separate GitHub repository called adriaandejonge/hellobuild. It can be built with this command:

docker build -t adejonge/hellobuild github.com/adriaandejonge/hellobuild

 

Providing the  -t flag names the image as adejonge/hellobuild and implicitly tags it as latest. These names make it easier for you to remove the image later on. Next,  you can create a container from this image while providing the flags that you have seen earlier in this post:

docker run -v /var/run/docker.sock:/var/run/docker.sock -v $(which docker):$(which docker) -ti --name hellobuild adejonge/hellobuild

 

Providing the --name hellobuild flag makes it easier to remove the container after running. In fact, you can do so right away, because after running this command, you already created the adejonge/helloworld image:

docker rm -f hellobuild
docker rmi -f adejonge/hellobuild

 

And now you can start a new container named helloworld based on the adejonge/helloworld image as you have done before:

docker run -ti --name helloworld adejonge/helloworld

 

Because all these steps are run from the same command line, without opening a bash shell inside a Docker container, you can add these steps to a bash script and run it automatically. For your convenience, I have added these bash scripts to the hellobuild GitHub repository.

Also, if you want to try the smallest possible Docker container running a Hello World web server without following all the steps described in this blog post, you can also use the pre-built image that I checked into the Docker Hub repository:

docker pull adejonge/helloworld

 

With docker images -a you can see that the size is 3.6MB. Of course, you can make it even smaller if you manage to create an executable that is smaller than the web server in Go that I wrote. In C or Assembly you may be able to do so. However, you can never make it smaller than the scratch image.

Categories: Companies

8 Techniques to Visualize Policies in LeanKit

One of the core practices of the Kanban Method is to make process policies explicit. This helps team members and stakeholders understand what’s expected, thereby reducing confusion and enabling greater process consistency. Until the mechanism of a process is made explicit, it can be difficult to engage in meaningful discussion about how to improve it. Without […]

The post 8 Techniques to Visualize Policies in LeanKit appeared first on Blog | LeanKit.

Categories: Companies

Dockerfiles as automated installation scripts

Xebia Blog - Thu, 07/03/2014 - 20:16

Dockerfiles are great and easily readable specifications for the installation and configuration of an application. It is terse, can be understood by anyone who understands UNIX commands, results in a testable product and can easily be turned into an automated installation script using a little awk'ward magic. Just in case you want to install the application in question on the good old fashioned way, without the Docker hassle :-)

In this case, we needed to experiment with the Codahale Metrics library and Zabbix. Instead of installing a complete Zabbix server, I googled for a docker container and was pleased to find a ready to run Zabbix server configuration created by Bernardo Gomez Palacio. . Unfortunately, the server stopped repeatedly after about 5 minutes due the simplevisor's impression that it was requested to stop. I could not figure out where this request was coming from, and as it was pretty persistent, I decided to install zabbix on a virtual box.

So I checked out the  docker-zabbix github project and found a ready to run Vagrant configuration to build the zabbix docker container itself (Cool!). The Dockerfile contained easily and readable instructions on how to install and configure Zabbix. But,  instead of copy-and-pasting the instructions to the command prompt, I cloned the project on the vagrant box and created the following awk script in order to execute the instructions in the Dockerfile directly on the running system.

/^ADD/ {
sub(/ADD/, "")
    cmd = "mkdir -p $(dirname " $2 ")"
    system(cmd)
    cmd = "cp " $0
    system(cmd)
}

/^RUN/ {
    sub(/RUN/, "")
    cmd = $0
    system(cmd)
}

After a few minutes, the image was properly configured. I just needed to run the database initialisation script (/start.sh) and ensured that all the services were started on reboot.

 cd /etc/init.d
for i in zabbix* httpd mysqld snmp* ; do
     chkconfig $i on
     service $i start
done

Even if you do not use Docker in production, Dockerfiles are a great improvement in the specifications of installation instructions!

Categories: Companies

The Perils of Facebook-ization

TargetProcess - Edge of Chaos Blog - Thu, 07/03/2014 - 18:16

Software development companies have been using real-time online communication tools for about 10-15 years by now, and it’s hard to imagine how they could possibly do without such tools at all. Online collaboration started out first as instant messaging, back in the late 90′s – early 2000′s. With distributed teams and with work outsourced to other parts of the world, instant messaging became indispensable. Be it a development team located thousands miles away from an executive team, or from a customer support team, or whether an organization needs an online hub where the remote workers can get together, no one questions the need for such tools and the value they bring to the workflow. However, online messaging has always been a subject to productivity-related concerns, and for a reason. I want to look into how the real-time online communications at work evolved over the last 15 years, how it was early on, what has changed now, and what we need to do about those changes, as stakeholders, or as employees if we want to be productive and feel good about our work.

Instant messaging at work in the early-mid 2000′s: Block and Spy

In early 2000′s workplace culture was more restrictive and prohibitive, in general, than nowadays. Some companies used the punish-and-fear practices with regard of instant messaging at work: they would log ICQ chats, banning any chatter unrelated to work altogether, or they would go as far as to totally block instant messengers.  A point to note: there was no Facebook in the early-mid 2000′s. Instant messaging just started out, and I’m old enough to remember how it seemed to be one of those technological miracles. People were soo eager to chat online with their friends when at work. The employers, naturally, wanted to keep their employees working and working. The practices of material production were implanted to software development back then. They assumed, mostly, that knowledge workers should work by the same token as machines in the manufacturing: 9-5 and non-stop. Back at those times, the issue of productivity with instant messaging at work was about not letting people get distracted. To get an idea of how it was back then (or to refresh the memories), we can refer to this 10-year old article in Wall Street Journal. Someone would probably smile, as they read this, quoting from the article:  “Being overly casual with colleagues and superiors is one of the biggest pitfalls of using instant messaging.”

The rise and decline of Facebook in the mid 2000′s – early 2010′s

By mid 2000′s this dynamics was replaced by a new one. Enter Facebook, going mainstream in about ’07-08. No doubt, Facebook has influenced the way we live our lives, let alone our communications with friends and co-workers. Some employers sensed trouble as early as then and blocked access to Facebook in their companies. But these attempts were futile, because the general public opinion tended to regard such actions as the Draconian culture-of-fear measures. 5-7 years later, one can observe yet another change. Now numerous studies and research prove that Facebook makes people unhappy, and they give a detailed account of how exactly this happens. I reckon the recent notorious psychological experiment conducted by Facebook is a clear proof that they sense trouble and look for the clues on how to keep people hanging out there. Otherwise, the Facebook’s game might be over. Anyway, back to to my story.

The Facebook-ization of workspace

Facebook, as outstanding a phenomenon in public life as it is, has certainly influenced the way companies arrange their online communications. Before Facebook, it was about instant messaging. In the age of Facebook, real-time communication at work has got more and more Facebook-ized. Now these tools are not “instant messengers”, they are referred to as the tools for “team collaboration, file sharing, document sharing, social sharing”. Can you feel the difference? Now, let’s think logically: if research proves that Facebook makes people unhappy, and given that real-time collaboration tools have acquired many Facebook-ish traits, it is safe to assume that teams might be subjected to this same unhappiness and feeling low as they use such tools, similarly to how it happens with Facebook users! So, which Facebook-like peculiarities of online team collaboration tools do we need to keep an eye on?  Where’s the potential danger of unhappiness and unproductiveness?

Miserable observer vs. energetic doer

As the research has it, one of the most insidious traps associated with Facebook, on a psychological level,  is spending more time in passive than in active mode. The more time we spend browsing photos and passively checking updates, the worse it feels. Same with the real-time team collaboration tools. Once we spend a lot of time passively checking status updates of our co-workers, on how something worked great or sucked in an area of work which is beyond our control, a certain cognitive bias of being let out of the real action is slowly formed. It might feel that our work doesn’t matter at all. There’s a nagging voice that says: “All my efforts are in vain, no one needs them.”  In a bounceback fashion, these people will want to stand out and make a difference. But their work is not related to any major achievements. They just do their job, as a tech support engineer, or as a QA engineer, or as a software developer. Still, they feel alienated, under the influence of this bias, and they will act Facebook-ishly to remind the rest of the world that their work matters. They’d post an update that — in their mind influenced by the bias — would make their work appear meaningful. But this update wouldn’t add value to the work of others in the team. Or, they might tend to be overcritical as to how things work, or how something is eternally wrong. I do not mean the exchanges where the team collaborate online to resolve an urgent issue real-time. My point is that these channels of communication have to be arranged thoughtfully, and engage those employees that can be the doers in such situations, rather than passive observers.  I’ve given just some examples of the distortions produced by those biases. Let alone that this vicious “feeling low+the need to compensate” circle creates a swirl of alienation, its contribution to the team’s productivity is zero. If an employee is preoccupied with this unhealthy virtual environment, and tends to act in a Facebook-ish fashion, they do not do the work. They blow their productive focus and their mental energy on coping with such psychological biases.

What to do about Facebook-ish biases?

If something like that happens in your team, fingerpointing and spotting individual point of failures will not help. People are people, we have emotions and visceral reactions. The only way to go forward and to keep us productive, energetic and healthy at work is to sit down, think and come up with the strategic setup for internal communications. Who in the team needs to collaborate real-time to do their job? For whom online collaboration is more of a waste, loaded with potential biases? If someone needs some information, could there be such a setup, where they’d get this info async? If this info is available, how do we make sure that everyone knows where to get it? These are just some questions that one needs to answer. If you’re a a stakeholder, or a person in charge of the mechanics by which your company runs, there’s a compelling evidence that calls to de-Facebook-ize work-related communications. If we think more about it, the real-time messaging is usually required for customer-related issues.  It could be, a tech support team urgently needs help from developers or from the dev ops.  But do they need to include other people from QA and dev to these firefighter talks? Gee, if the production team see that customers always come complaining, they might get a bad cognitive bias that no matter how hard they work, customers still have issues. The rule of a thumb is: think who needs which information to do their work, rather than “why don’t we keep everyone informed real-time?” Biases developed from spending time in passive-observer mode come with a price tag: dissatisfaction with work, loss of productivity, and a whole array of other such bad things, which no sensible person, be it an employee or a business owner, would want to have in their organization.  If you are an employee, think if you want to stay on top of all the updates real-time. Beware passive browsing. It’s the most dangerous thing ever about anything online. If your management has no policy for real-time collab tools, invent it for yourself.  When you start feeling bad being a passive observer, and catch yourself posting notes with negative or sarcastic messages, run away. Shut down those channels, and focus on your own work.

Slack, an online team collaboration tool, displays some cheerful messages for its users. One of these messages is particularly wise and well-intentioned. Here’s how it goes: “Enjoy Slack responsibly“.  Also, Slack has a slogan on their web-site: “Be less busy”, which I would like to extend: “Be less busy. Be more focused instead“.

Related articles:

Getting Closer with Remote

Skype Is (not) The Limit

Categories: Companies

Product Tip: Tracking work in your Calendar app

Pulling LeanKit work items into your Personal Calendar app Need to keep track of work that has due dates?  You can set up a feed so that your LeanKit tasks with start and/or end dates appear in a personal calendar like your mobile phone calendar app.  Subscribing to an iCal feed is equivalent to adding a mailbox […]

The post Product Tip: Tracking work in your Calendar app appeared first on Blog | LeanKit.

Categories: Companies