Friday, December 02, 2016

Outsourcing technical competence?

I have written about technical competence before in the context of Agile Engineering Practices and Three must have Technical Competencies for Scrum Teams. This article will shed some light on a different aspect of technical competency. Outsourcing it.

A number of companies I have worked for have started a large project based on a technology they are not competent in, or even completely unfamiliar with. This fits very nicely in the outsourcing strategy most of them have regarding IT. But does this makes sense?

In my opinion having technical competence (and excellence) in your organization has never been as crucial as it is today. Creating a technology strategy that allows you to not only deal with, but take advantage of the increasingly rapid pace of change separates the successful organisations from the obsolete ones.

Some observations I have made when your organization is not competent in a technology that is used for a big initiative:

- your IT architecture team is dependent on external consultants for creating an architecture. You can have luck with your external consultants (honest, competent, independent), but I have seen the opposite more often (not competent, driven by sales, vendor lockin). Unfortunately when you have no competence in your organization you have no way of judging before it is to late.

- the cost of implementing new features (your business requirements) are determined by external consultants and/or vendors, and you have no way of judging if these are reasonable or not.

- the decision if certain new features are possible or not are made by external consultants and/or vendors, and you have no way of knowing if these decisions are justified or not.

- you have no healthy team atmosphere during the project. Internal employees always have to ask external ones for their opinion and input. This gives a very strange team dynamic where externals are making all the decisions one way or another (direct or indirect).

- you are not able to support the implemented solution after go-live without help from external consultants and/or vendors. This makes you very dependent, even after the project is finished

- it makes it very hard to switch vendor or implementation partner, because all of the knowledge of the solution is with them, so when you want to switch because you are not happy you have to work a while in parallel with two different companies. Besides the costs, this will give an even worse team dynamic.

- your best external people can leave the project on a whimp because you have no influence on keeping them there. Supplier priorities may not be you, or they just leave your supplier.

In general I am the opinion that when a company is deciding on a certain technology for a big initiative the first thing they should do is hire two or three of the best people they can get, make them internal employees and give them key positions in your project setup (architect, QA, technical project lead). Leverage their experience by not making beginner mistakes, get second opinions on cost and feasability estimations and get a judgement of skills of external consultants. This will put your organisation in the driver seat instead of being driven by others.

Yes your headcount goes up, and yes they do not work for free, but trust me on this one, this is money well invested and far much cheaper as not doing it.

PS: Allthough this was written based on a new technology decision, all the above is true for starting an agile project with a technology you know. When your internal employees are not familiar with Unit Testing, Test Automation and  Continuous Integration, get people on board that do. You will never make a lasting change in your organisation by outsourcing these.

Read more…

Friday, September 30, 2016

Swisscom CX Day: Agile. One day. Four sprints.

So next month (October 27) I am speaking at the Swisscom Customer eXperience Day. I am really looking forward to this event. Katja Leu and Christina Taylor have put together a fresh and interesting format on the topic "Agile".

"Agile" has long been the buzz word in software development for a new people-centred and efficient innovation culture that cuts across all methods. In four sprints we highlight "agile" insights as they relate to organisation, leadership and culture, environment and collaboration, and measuring success. We will discover together how an agile corporate culture can contribute to lasting success. 

The event is invite only, but you will find the presentations from previous CY Day events in their archive. There are some really interesting talks lined up for this event.

"Work? Question. Think. Learn." by Bastiaan van Roden, Founder @ Nothing Interactive

The way we think about work is stuck in the age of the industrial revolution. Linear, recurring routines have become less suited to producing adequate answers to the challenges of today when we need them. Bastiaan prefers open, authentic participation when it comes to people creating meaningful experiences for other people. It's not about work any more; it's about curiosity: only constantly asking questions, providing new answers and learning from them will ensure success.

Culture has a stronger impact than strategy." by Franziska Stebler and Rudolf Gysi, Agile Coaches @ SBB

The people in a company shape its culture. The culture is the shadow of the system and carries more influence than any strategy. For a company to change, it needs to start with the people. So the Agile Coaches train SBB IT employees in agile practices, empowering entire teams to develop new solutions faster. Using the "Iteration Zero" example, Franziska and Rudolf show how they boost the groundwork for product development with their people-centred approach.

"Goodbye boss. Hello trainer." by Heinz Herren, Head of IT, Network & Innovation @ Swisscom

You can see the full force of the butterfly effect in the networked world. When something happens in one corner of the world it is transmitted in the shortest of times to other areas and can trigger huge movements. Agile, people-centred collaboration is the answer to the shortcomings of hierarchical organisations in reacting quickly, flexibly, and diversely to changes. When it comes to management that means moving from rigid control to vibrant, learning organisations. Top and bottom was yesterday. Today it's about being a trainer and making others successful.

"The setting is crucial." by Thomas Bickel (Head of Sport) and Uli Forte (Manager) @ FC Zürich

What do agile forms of collaboration and top football have in common? What is the secret of a top-performing team that works in perfect harmony? What can influence a team positively and negatively in terms of its success? We find out from the perspective of the Head of Sport and the Manager of FC Zürich how important environment and communication are for perfect teamwork.

"Getting a little better every day." by me

Delivery is more important than all processes, frameworks, methods and tools. But it's not more important than the people involved in the project. Only the team knows what really works. So the team determines the success, not a book, a consultant or a manager. For every race, the team decides which activities from the backlog bring the greatest added value if they are pursued further. Too much guidance restricts any eagerness to experiment and stops you making mistakes, reducing your ability to learn. Quality is important from the first iteration. But it's not possible without technical excellence. Agility means small steps: getting a little better every day.

"Less is almost always more." by Head of Business Development @ Digitec Galaxus

Agility only works then the entire ecosystems works agilely together – not just some parts of the value chain. It's only when the entire system is operating agilely that its full power is released. It is important that everyone actively participates and can play their part. Focus is vital for this: it is only when we are prepared to give up some things willingly and leave them to the side that we can make everything faster and better. So less is almost always more.

CX-Day Panel 

How does agile collaboration change management? Is management even necessary in an agile environment? If so, what type of management? How is the new management role defined and what values is it based on? Moderator Carsten Roetz will put these and other questions to the following panel of experts.

Read more…

Wednesday, June 08, 2016

Antifragile at the Global Scrum Gathering Munich 2016

October 17 till 19 I will be at the Global Scrum Gathering in Munich. The theme of this gathering is

Business Agility: How to Thrive in a Constantly Changing Environment 

Questions that will be addressed are:

- How can executives of large- and mid-sized organizations set up their businesses to adapt and react faster to technological changes and challenges?
- How can they not only enable their teams to build things the right way but, even more importantly, ensure that they build the right things?
- What kind of structures are needed to involve and enable “smart creatives” to develop innovative and valuable products?
- To what extent do classic organizational structures support or contradict business agility?

The idea is to explore the different perspectives on what’s needed by whom.

- What are the needs of the executives?
- What are the needs of middle management?
- What are the needs of those who build the products in the end?
- Where are the gaps and how to bridge them?

The gathering is divided in four different tracks:

1) Dealing with Uncertainty: How to Build “Anti-fragile” Businesses in a Constantly Changing World

2) Effectiveness over Efficiency: Focus on Building the Right Thing Rather than Building Things Right

3) Empowering People: The Right Organizational Structure to Nurture and Foster “Smart Creatives”

4) Amplify Learning: How Do We Create the Right Experiments to Get the Right Learning Experience in Order to Reach the Next Level of Maturity — as a Product, as a Team, as a Corporation?

I will give a talk at the gathering titled "Dealing with Uncertainty: From Agile to Antifragile". The purpose of my talk will be:

- Gain a better understanding of what uncertainty is
- Understand Black Swan theory
- Understand what antifragile means
- Gain insight in some strategies that can be applied to deal with uncertainty

I am really looking forward to the event. Many smart and experienced people, cool conversations and new ideas will be guaranteed. When you want to meet up at the gathering and have one of those amazing German beers just contact me.

Read more…

Friday, April 29, 2016

Scaling Agile at LEGO

I have written articles before about scaling Scrum and scaling Agile because this is a challenge I am confronted with a lot. One way of approaching scaling Agile is the Scaled Agile Framework (SAFe). To put it mildly, SAFe is controversial in the Agile community. At first glance SAFe looks a bit like a big scary heavy-weight top-down RUP-zombie. But what about in real life?

Based on what I know about SAFe so far, I am not convinced it is something I would advice in most situations. Personally I am more of a LeSS guy myself. But that does not prevent me from learning more about it. So I decided to spend some time reviewing use cases of SAFe. One of the best documented use cases of SAFe is the use of it at LEGO. Henrik Kniberg is working as a coach at LEGO and he and the LEGO team are presenting about their learnings frequently.

In 2014, LEGO Digital Solutions turned to SAFe to improve their collaboration model. Much like creating something from LEGO bricks, they built their transformation one piece at a time, starting with inviting 20 managers to a 2-day Leading SAFe class. From there, they began training the teams; first one, then another until they had 20 teams trained in SAFe.

They approached every step as a learning journey, allowing for creativity along the way. When something didn’t seem like a good fit, they weren’t afraid to experiment. Taking results from Inspect and Adapt, they tweaked SAFe to their needs with a simple guiding principle, “Keep the stuff that generates energy.” Currently they work with 150 people in 20 teams using Scrum, Kanban and XP to deliver.

It is a fascinating use case, and no matter what you think about SAFe, you can learn from it. Below you will find the material I have reviewed.

Learnings from SAFe @ LEGO – Mattias Skarin & Eik Thyrsted Brandsgård at LKCE15

Is SAFe Evil? - Lars Roost & Henrik Kniberg at GOTO Copenhagen 2015

The slides for the talk Agile @ LEGO at at Passion for Projects in Uppsala.

Read more…

Tuesday, April 12, 2016

Agile Engineering Practices

Just finished reading the 10th State of Agile Report from VersionOne. I have written before about data from this report. See "Top six reasons for failure of Agile projects".
This time one question caught my attention. Respondents were asked to state which agile techniques they use. They were able to give multiple answers. Because of a project I am currently involved in I was very curious about the answers regarding used Agile Engineering Practices.

Response was as follows:

- Unit Testing (63%)
- Continuous Integration (50%)
- Single Team (integrated dev and testing) (45%)
- Refactoring (37%)
- Test Driven Development (33%)
- Automated Acceptance Testing (28%)
- Continuous Deployment (27%)
- Collective Code Ownership (25%)
- Pair Programming (24%)

What can I say... This is a sad state of affairs. Or looking from the positive side. There is a lot of potential for many agile development teams to step up their game and improve. Scrum is the most used agile process method according to the survey, and Scrum itself says nothing about Engineering Practices. Scrum is not limited to be used for software development only. But as soon as you use Scrum in software development, solid Agile Engineering Practices are essential to do Scrum right. I have written before on this in my article "Three must have Technical Competencies for Scrum Teams". Some additional thoughts...

Unit Testing
The purpose of unit testing is not for finding bugs. It is a specification for the expected behaviors of the code under test. The code under test is the implementation for those expected behaviors. So unit test and the code under test are used to check the correctness of each other, and protect each other. Later when someone changed the code under test, and it changed the behavior that is expected by the original author, the test will fail. If you code is covered by reasonable unit test, you can maintain the code without breaking the existing feature. That’s why Michael Feathers define legacy code in his book as code without unit tests. Without Unit Tests your refactoring efforts will be a major risk every time you do it.

Continuous Integration
Martin Fowler defines Continuous Integration (CI) in his key article as follows: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly." You see, without Unit Tests and Test Automation it is impossible to do CI right. And only when you do CI right you might be able to succeed at Continuous Deployment.

Single Team (integrated development and testing)
It is hard to grasp that this is still not implemented by so many agile teams. In order to deliver high quality software every iteration, your development and testing should be done by a single team. Not just that, your team should be a Feature Team.

Code should be written to solve the known problem at the time. Often, teams become wiser about the problem they are solving, and continuously refactoring and changing code ensures the code base is forever meeting the most current needs of the business in the most efficient way. In order to guarantee that changes do not break existing functionality your regression tests should be automated. I.e. Unit tests are essential.

Test Driven Development
Test-driven development is a development style that drives the design by tests developed in short cycles of:

1. Write one test,
2. Implement just enough code to make it pass,
3. Refactor the code so it is clean.

Ward Cunningham argues that test-first coding is not testing. Test-first coding is not new. It is nearly as old as programming. It is an analysis technique. We decide what we are programming and what we are not programming, and we decide what answers we expect. Test-first is also a design technique.

Automated Acceptance Testing
Also known as Specification by Example. Specification by Example or Acceptance test-driven development (A-TDD) is a collaborative requirements discovery approach where examples and automatable tests are used for specifying requirements—creating executable specifications. These are created with the team, Product Owner, and other stakeholders in requirements workshops. I have written about a successful implementation of this technique within Actuarial Modeling.

Continuous Deployment
Continuous delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing. Since every change is delivered to a staging environment using complete automation, you can have confidence the application can be deployed to production with a push of a button when the business is ready. Continuous deployment is the next step of continuous delivery: Every change that passes the automated tests is deployed to production automatically. Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements.

Collective Code Ownership
Collective Ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve designs or refactor. No one person becomes a bottle neck for changes. This is easy to do when you have all your code covered with unit tests and automated acceptance tests.

Pair Programming

Having 2 developers work on one piece of code, using one keyboard and one monitor. Pairing results in higher quality output because it greatly reduces wasted time and defects, and results in high collaboration. It is noting else as continuous code reviews. Hence, when implemented you do not need code reviews before merging your branches, hence continuous integration can be done faster.

Those who are familiar with Extreme Programming (XP) will notice that many of these techniques originate from it. Ron Jeffries in his (highly recommendable) book "The Nature of Software Development" goes even that far that he says that Scrum combined with Agile Engineering Practices is nothing else as XP. I see his point. It is about wording and labeling. The ideas and principles are the same.

I am a very strong believer that without successfully implementing Agile Engineering Practices it is impossible to be agile in software development.

Read more…

Wednesday, April 06, 2016

Questions to ask before developing your new product

A while ago I wrote an article titled "Why are we actually doing this project" where I discussed a number of questions to ask about your project. It helps determing if it is actually worthwhile doing/continueing a project.  

Peter Thiel, in his book "Zero to One", goes a step further and laid out seven questions that a startup must answer in order to be successful. But when you think about it, you can use the same questions for developing a new product in an existing company. His seven questions are:

1. The Engineering Question: Can you create breakthrough technology instead of incremental improvements?

2. The Timing Question: Is now the right time to start your particular business?

3. The Monopoly Question: Are you starting with a big share of a small market?

4. The People Question: Do you have the right team?

5. The Distribution Question: Do you have a way to not just create but deliver your product?

6. The Durability Question: Will your market position be defensible 10 and 20 years into the future?

7. The Secret Question: Have you identified a unique opportunity that others don't see?

As Thiel puts it, if you don't have good answers to these questions, you will most likely have "bad luck", ie fail. "If you nail all seven, you'll master fortune and succeed. Even getting five or six correct might work."

Read more…

Monday, April 04, 2016

Liquid Scrum

I just have finished reading "The People’s Scrum" from Tobias Mayer, and I have to admit that big parts of it resonate very strong with me. After some searching on the net related to the book I found the website of Olaf Lewitz, who calls himself the Trust Artist.

Olaf is a Certified Enterprise Coach that approaches Scrum a little different as most. He has written a guide to Scrum in a way that is capturing the essence of Scrum and I think he did this very well. He calls it Liquid Scrum.


Everyone involved takes shared responsibility for success. Focused interests (see below) never imply that something is not within your responsibility.


Assume everyone is contributing the best they can. Focus your conversations on options you have right now, not on what should be or should have been. Choose wisely: decide using consent or better.

Constrain Your System With a Timebox

Set a timebox of two weeks. This will give you rhythm and enable you to see what emerges, and give you options to focus:


1. Deliver.

2. Visualise what you do in a way that supports your understanding of how you do it.

3. Reflect daily on what you see, decide on choices you have. Adapt the rhythm if that makes reflecting more effective. Only execute these three options until you can reliably deliver every two weeks. Everything else may confuse you.

4. Experiment within the bi-weekly timeboxes. Detail the options you discovered to set clear goals up front and indicators for success and failure. Decide what to invest and how to limit risk. Never run an experiment without making explicit what you want to achieve or learn.

5. Focus on what to deliver.

6. Reflect on what you did, and how you did it, and discover options to get better.

Focused Interests

Your system may get better faster at making a difference if you focus on these three interests:

1. Do the right thing.

2. Do things right.

3. Get better and better every day.
- Better at delivering faster.
- Better at doing the right things faster.
- Better at doing things right faster.
- Better at deciding which of these is important, right now.(some people call this effectiveness, and it’s blurry)

In many or most systems having people take explicit responsibility for one of these works well. By-the-book Scrum prescribes one voice for 1. (Product Owner) and 3. (Scrum Master). In mosts contexts, that’s good advice and a good choice to start with.

Are We Doing Scrum?

Olaf is the opinion you can call what you do Scrum, if you:

- deliver consumable value at least once every two weeks,
- regularly and continually improve, and
- have established the focused interests.

Framed differently, if you achieve

- Focus,
- Alignment,
- Artful Making,
- Self-Organisation, and
- Rhythm,

you’ve got the Soul of Scrum...

Read more…