Fun at Workplace

It is Spring in Switzerland. We often have time for small talk because it is cold or rainy outside. Quite a few of the discussions are about job opportunities and how interesting and motivating the current activities are. I selected two articles to help everybody to decide if your software development job is worth the effort. 

Just go through the questions and ask yourself if the current project provides the current settings.

List of Agile and Lean Books for Software Engineers or Students

Purpose

I am regularly asked by practitioners and technical universities which books I shall recommend to learn more about agile developers, agile projects, and agile companies.

Below a selection of books I read and found really interesting. The selection is certainly not exhaustive. The criteria are

• I read the book and learnt something
• I have bought the book to have it as reference, I mean a real reference opened at least monthly
• The book is available as ebook - I only read ebooks and save trees -

Agile Trends Switzerland 2016

What are the main hurdles to introduce agile approaches in Swiss companies. The last five years learn us that

• Introducing agile company-wide is a cultural change process. Such a change takes time and sometimes hurts,
• Without commitment of senior management, the initiative will fail,
• You must teach, coach, support your collaborators through the transition. You need to believe in them and provide an environment where they can safely learn and experiment,
• At the end what matters is collaborator purpose, customer satisfaction,  business value.

Seven Pitfalls with Agile or Scrum Methods

The post describes a presentation I gave at a company internal technical day.  It reflects situations we have seen in a lot of agile projects over the last years.
I assume that the Scrum approach is well introduced in your company. You are already proficient with Scrum, eXtreme Programming, Clean Code, Code Refactoring, how to write stories and story maps, and techniques such as TDD, ATDD.
You are using Scrum well and can laugh about all these posts about Scrum-But(t). Still misunderstandings about Scrum abound.
We will present common pitfalls seen in teams already applying Scrum; meaning teams using Scrum as an empirical process, holding the meetings as described in the Scrum guide, and producing all expected artefacts. We want to increase your awareness and reflect how you can become better Scrum experts. We exhort you to eliminate these misunderstandings in your projects.

What you do NOT need to do in Scrum!

I often hear discussions who is doing the "traditional" project leader tasks in Scrum. This is in general an excuse to state that Scrum alone cannot work and classical project leaders are still needed. 

Below a list of tasks you do NOT need anymore to do in Scrum.

• Make commitments on behalf of the team about how much they can get done by a certain date or estimate effort for the team,
• Coerce the team that the commitments made on their behalf are attainable,
• Coerce the team to change their estimates,
• Give direction to the team on how to implement the work,
• Monitor the team's progress to make sure they stay on schedule,
• Step in and determine the solution,
• Conduct weekly status update and face to face meetings with the team to surface issues and provide direction,
• Provide motivation and push the team to work harder than they might want to using carrots and sticks,

Found a Limited Liability Company in Switzerland

I left the company I founded 20 years ago and needed a new home to work and have access to social insurances. Therefore I had to found a limited liability company with a capital of CHF 20'000.

Here the steps for the impatient.

What is an Agile Company?

Lately people often ask me what is an agile company. They have an understanding of agile software development techniques such as Scrum, Lean, Kanban, eXtreme Programming but no clue how a company could be agile. 

One way to approach this theme is to implement concepts of the above mentioned agile approaches. These are the pillars for iterative incremental improvements.

• Transparency you trust all collaborators to provide their best when working on the product. Therefore they need full access to all relevant information: quality, progress, budget, people and financial data. They use the data to select the best alternatives to reach the company’s goals
• Inspection you cherish a failure culture because inspections will find weak points. You need a culture where people are never blamed. One consequence is that you eliminate management by objectives, and bonuses in your company
• Adaptation you are ready to learn better approaches and truly believe there is a better solution. Therefore processes change regularly bottom-up, company’s budget can only be a rolling indicative budget, and planning has to be continuously updated