“Big 5” dangers for your software company

The definition of “big 5” is traditionally the 5 most dangerous african animals to hunt on foot. For software development I have defined it as the 5 greatest dangers of running your software company. Technical Debt A lot of legacy code and not aggressively reducing technical debt is a sure way to keep your IT organization on a low level of productivity and high level of frustration. With technical debt I mean for example spaghetti code and poor architecture, lack of or bad APIs, lack of tests, no modularization and no continuous refactoring. If you are building a new system letting the above happen is a good way of making sure you will have potentially fatal problems later. An example is not refactoring the quick prototype you hacked together for your first demo or letting your test and deploy infrastructure become a mess. Weak technical leadership Relying on cowboy developers, whole development teams or disconnected managers to lead in important technology and architectural decisions will likely result in fragmented architecture and endless discussions. Worst case examples can be taken from public examples in Sweden where bad technical decisions wasted tens of million euros of tax payers money. Even if  bad decisions does not topple your business you will likely end up with sub-standard development tools and practices and lack of Continuous Delivery, DevOps and Lean Startup thinking. This will in turn reduce your company agility and the best tech people find a cooler place to work. Waterfall project model Although Agile development has become a de facto standard for software development many companies still employ traditional project management and...
How to produce successful change

How to produce successful change

A couple of people have asked me recently what the silver bullet is for succeeding with change. My gut feeling response is that it depends so much on the particular situation. An answer was needed however and stepping up one level in abstraction I observed how I typically approach it. The model below is my answer. Some context is suitable. Personally I like to create an environment where everyone is involved and feels ownership of the situation. I believe such an environment is the perfect ground for successful change and improvement. I practice catalytic leadership which means that I do not only make change happen but also build an environment where everyone creates change for the best of the whole. Often the latter is the main task. The base As stated at the top of the picture the basis of this model is that we as leaders want to align all the forces involved in the model. We want the solutions to have synergy between all parts (circles) which means that the change is a positive evolution that will benefit the whole. Not everyone needs to agree on the solution but in the whole there is agreement. We want to do this collectively, co-creating. This means that we want to create a movement and feeling that we are all in this together and that the result will be a consequence of everyone’s actions. This is in stark contrast to one leader seing him/herself as the central point of controlling the forces involved. Presence A leader, especially on higher levels in a traditional pyramidal organization, the “strategic levels”, need to have a strong capacity for presence. Presence means here...

Guest blog: Stepping Stones into the Future through Leadership Agility at Ericsson

This is a guest post by my dear friend Anna Sandström; Agile Coach and Organizational developer at the telecom giant Ericsson. Anna is an excellent coach who help people with deep changes that translates into everyday high-performance, both at Ericsson and in her own company. The original post can be found here. /Emil By Anna Sandström Within Ericsson we have gained lots of experience from Agile Way of working! But what about our leadership? Have we become increasingly adoptable at responding to the degree of change and complexity that pervades today’s workplace? Trigger for my curiosity and inspiration My curiosity started in my work in leadership teams, and reading about adult learning and growing into new stages of awareness and leading. I had the opportunity to meet with a very inspirational leader in a different branch than where I’m working, and through understanding more about the work she has been doing from a co-creator way of leading, I got inspired to dare to start using some of my skills in the leadership teams I am active coaching in. I created WS material for the Leadership Agility model I created together with a colleague (Per) from a different part of Ericsson, four blocks of material around the Leadership Agility model, using some techniques from Training from the Back of the Room thinking. Each block in itself is self contained, and the theory is broken up with short presentations in the big group, self-reflections and “pair share” with a colleague and sharing with the rest of the group. What we tried to achieve was… Communicating an understanding of the Leadership agility concept. Understanding of the...

Continuous Delivery anti-pattern: We are unaware of the waste in our process

A big part of the waste we have in our development processes is there simply because we are not aware of it and the thinking that creates it. We lack transparency and a thinking of the whole flow from requirements to production. Some common causes of this are: We do not measure lead-times, queue-sizes and bottlenecks We don’t have tools and methods which supports that we as people gather and create awareness of the whole We organize, use steering models and architecture and employ a management philosophy which optimizes on so called resource efficiency. Unfortunately focusing on resource efficiency often leads to that we do not focus on delivering value to the customers. We tend to forget that we also need to optimize on lead-time and so called flow efficiency. We also tend to not see the waste we create by optimizing on resource usage. Depending on how you steer the organization and what basic assumptions you use the balance between resource efficiency and flow efficiency can end up in any of the four quadrants described in the following picture. Note: this picture is based on the model from the popular book This is Lean. Unfortunately we have seen that many organizations that have been using a traditional development methodology (resource efficiency) have over time slipped further and further down into Dead End. For the organization this usually means near deadlock in information flows, zero productivity and people burnout. On the other hand, successful organizations we are working with have managed to create a synergy between delivering quickly to the customer and using the resources...

Continuous Delivery Anti-Pattern: Long lead-times from requirements to production

Ok you may ask “how is this an anti-pattern? it sounds more like a symptom”. I would argue that it is both a symptom and a cause and that it really doesn’t matter. It is a symptom because we get long lead-times from of the practices and processes we use. It is a cause because today we have the knowledge, technology and experience to greatly reduce the lead-times. In other words the length of lead-time is a matter of choice. Traditional development processes, steering-models and organization is by definition working against short lead-times. Much of the delay is created in the handovers between requirements, development, test and production. Some consequences we almost always see in traditional organizations which are related to long lead-times are: Difficulty in planning Highly risky deliveries Poor quality Very large cost to make sure quality is good Cleanup months after delivery Unhappy customers High employee costs Employee burnout Naturally we may have more or less “debt” in the organization which are preventing us from instantly reducing the lead-times. There are on the other hand many examples of organizations which have reduced lead-time greatly (and also reduced the mentioned consequences) by just working in another way. So what is a good first step? Having the management team look into DevOps and Continuous Delivery is great. You don’t need to understand every technical detail about it but getting a basic understanding and then focus the whole organization on reducing lead-times can be very effective. As I mentioned short lead-times is a choice, for some perhaps a long term goal. We have learnt that in traditional organizations this choice must be made...