The background to 3Labs is the purpose to create an environment where we have innovation being a part of our daily work – 3Labs is one way of doing just that.
So, the idea with 3Labs is to give all our awesome colleagues at 3 one day every month to do whatever they want (as long as it has something to do with 3’s business), work with whoever they want, work wherever they want – and work on it how much or little they want within the given 24 hours.
All the great ideas are then shared with everyone by having a “mingle demo” – where each lab gets a station and where the persons involved in the idea is presenting what they have achieved. Kind of a market place.
During the demo every visitor is given three pieces of LEGO, and those are then used to vote. Simply, one piece of LEGO equals one vote. The votes are piled up in a tower, and at the end of the demo all towers are put next to each other – and the highest tower wins.. a “wandering trophy” (handed over to the winner each time), and last but not least – wins the glory! 🙂
Everyone can participate as long as one has a good, crazy, small or big idea they want to experiment with and try out. It started off as an initiative within the IT department but has been growing ever since to evolve to other departments – and in some cases even external partners.
Last but not least; the ideas coming out from 3Labs are, in short, simply amazing! They vary from trying out a new tool, system or platform to delivering new apps, test-automation suits, one-click deployments, visualizing architecture and changes, and much more! As of today we have had 140+ ideas and concepts that have been demonstrated and shared within the company – which is awesome!
Release planning is simply the act of determining what functionality you’re going to be able to deliver in a certain time frame. Obviously you want this data to be as accurate as possible. The greatest accuracy is gained by basing the Velocity on actual historical data.
Change will happen. Change will affect everyone – including you. Change is constant happening. The way to manage change is to manage the “dip” in performance that occurs every time a new change is introduced. Managing it means that you will have to try to make the dip in performance as small as possible! If it is not managed and the dip gets too profound – you might be certain that you will have a very hard time implementing your change and making it happen!
Kanban (看板) is pronounced /’kan’ban/ and means ”visual board” – where kan means “visual,” and ban means “card” or “board”. Kanban is a concept developed at and used by Toyota. It is related to lean and just-in-time (JIT) production.
On the surface, there isn’t much difference between an average task board and a kanban board. Each of these boards has various columns that represent the stages that a card needs to go through before it is considered done. The real difference in a kanban board, is not the board itself. The board is just a visual indicator, the same as any task board, and the intention is still to get the cards to the “DONE”-state – that is, delivered to the customer so that they can use the features from that card.
One of the biggest challenges when starting up a project is to create a team. What usually happens is that a certain amount of resources (or I would prefer calling them what they really are; persons) are given to the project. Then it is the project managers task to create a team out of the group of individuals given. This is a tremendous, complex and very time consuming effort that simply just has to be done. All this effort is not even giving you any guarantee what-so-ever of succeeding. Failure in the beginning of a project can be devastating for the whole product and/or project. Hence, why do we keep struggling with this problem every single time we start up a project? My ideas is to keep the team(s) intact and then assign a product and/or project to the team! This way we get rid of all the tremendous, complex and very time consuming effort(s) that has to be done in order to create a high-performing team!
When developing software it is a fact that we spend way to much time and effort on implementing things that will only be used sometimes, rarley or NEVER! There are several studies covering this. One such example is the famous survey by The Standish Group in 2004.
The Agile community are trying to solve this in SCRUM by an approach of really focusing what is important for the customer right now, instead of the approach of focusing on everything-at-once. One examplary example of a product that focused only on the features used always and/or often is the.. iPod!
In order to have a better understanding of the total cycel time one also have to understand the concept of batching, and how it affects the total cycel time. Finding out your cycel time tend to seem easy:
Total Cycel Time = Number of things in Process / Average Completion Rate
The picture tries to illustrate on how the delivery is affected by driving parallel projects (all-at-once) comparing to one at the time (focused). Also, it tried to illustrate what happens when the average completion rate increases and decreases.
More and more companies are struggling to transform their organization into a more lean and agile form. While doing this many companies fail to realize and recognize some fundamental aspects. One of the fundamental aspects is the purpose of the organization (refer to the purpose of why Toyota exists), yet another important aspect is the company’s view of their customer(s).
Those two aspects together (the purpose of the organization and customer focus) is laying the foundation of how a company chooses to organize its organization in order to meet the customers . With the illustration below in mind, I think we would need to consider and ask ourselves a couple of things:
How well does your company truly understand what really matters to your customer(s)?
What level of customer focus does your organization (really) have?
Are the workers working for management, or is management working for the workers in the company?
Is management using the organization to reach the company’s goals, or is management supporting the organization (and it’s workers) in achieving its goals?