Last edit: Aug 2015
Introduction
I've a technical background in programming for more than 10 years and practicing & coaching agile software development in different environments for 20 years. I started my first Scrum and XP project in 2001. Since that I've been learning and sharing knowledge about agile software development in various industries. I started my work with LeSS in Nokia Networks with Craig and Bas in 2005.
To me, LeSS is primarily an approach to reduce organizational and systemic complexity, as well as descale product development. Even though the word LeSS refers to large scale scrum, I'm happy to work with LeSS without Scrum.
I encourage always to start your improvement journey by studying the system and trying to find out ways on how not to scale in the first place. All organizations are unique and thus there's no generic process or solution that could be applied to make an organization agile. Organizational change and agility requires that the leaders study and understand their whole system first, and agree required changes on the system level. When the organizational structure that favours agility in it's own context is agreed, we move on working with the teams and technical disciplines.
"How do we scale our organization to agile?" or "How do we transform our ways of working to agile?" are wrong questions. We in the LeSS community have seen that some agility and improvements can be achieved also in bigger organizations and beyond development teams. Especially in bigger organizations, we must start with these questions:
- What is the purpose of our organization in the future?
- How our organization and ways of working meet that purpose at the moment?
- How we should change our system and organize people to better meet that purpose?
- Which constraints we should remove in our system to reach better flow?
Once the leaders truly understand their systems, and how the work works, the organizational structure for their specific system is agreed mentally. LeSS recommends to start your journey towards agility with Scrum on the team level. However, if you're already practicing Scrum or some other agile method that the teams are happy with, Scrum is not mandatory.
LeSS is not a process or methodology to follow, or a codified method for scaling agile, that you can buy and implement. LeSS encourages organizations, teams and people to own their process, and not to copy or rent some "best practises". LeSS is built on the idea that you build your own method up, step-by-step, and don't tailor down some other's process. The whole idea of agile and agility is that you improve by inspecting and adapting systematically, and make changes in your ways of working when you've learned what works for you and what not. There's no agile process or framework that would "make you agile".
For me, LeSS is primarily a group of professionals helping bigger organizations in agility whose experiences and knowledge has resulted in a number of experiments, books and principles that you can find at LeSS.works site.
I recommend to start learning about LeSS by reading first Why LeSS?, LeSS structure, LeSS principles, and LeSS technical excellence chapters. After these I recommend to read a couple of LeSS case studies and join some of the LeSS communities.
I do LeSS consulting and coaching only in Europe. I don't give LeSS trainings.
A brief story of my experience
Born in 1970, living with my family in Helsinki. Currently I'm working in a startup called Kuha Mobile Network and a Finnish company called Reaktor.
I wrote my first commercial software in 1991 with Turbo Pascal. This was a book-keeping application for a housing association. The product was ready in 2 months. I did a demo to the PO every Monday (I coded mostly during the weekends while I was studying). In current money, I earned about 300 Euros for this, and gave the maintenance for free. Well, I wasn't a good salesman at that time :)
After that, I played with AWK, Fortran and C in the university and in my part-time job in a library. I fell in love with C and wrote some desktop apps and tools with C.
My first full-time job started 1995 at Teamware. We developed a “collaborative application suite” called Teamware Office (e-mail, calendar, etc) with C and C++. I worked on the IMAP stack. We even won the best office collaboration software award in the Byte Magazine around 1996. Everyone in the company worked in the same building and floor, except for one small development team in England. In Helsinki we had 3 real development teams in addition to the dev team in London. We had daily builds, prioritised list of features, PO, and bi-weekly releases. Teamware was sold to Fujitsu in 2011. The Teamware software seems to be still alive and in use in, although it's 20 years old! I'm pretty proud of this.
After that, in 1996, I started developing digital switching platform DX200 with C, PL/M, Assembler and TNSDL at Nokia Telecommunications. Note that Nokia Telecommunications (now Nokia Networks) is a Telecom infrastructure company, while Nokia is known from the mobile phones. These 2 different companies didn't have anything else in common than that they belonged to the same Nokia Group. The development style at Nokia Telecommunications was very old-fashioned, slow and sucked in many other ways. The tools and environments were just horrible - mainly VAX/VMS, proprietary HW, OS, tools, etc such as DMX, SPM, Pronto, LinSee, DMXSee, ChorusOS. So this was a huge step backwards technologically and methodwise from Teamware. During this engagement, I also got my first contact with CMM accessors, Quality managers, process documentation, etc, when Nokia wanted to step from CMM level 2 to 3. I recall the biggest result from that was that the amount of processes, single-specialists, documents and waste increased significantly. So I know what it is to work in a real waterfall environment!
In the beginning of 2000 I went to a startup called SmartTrust to develop technology for wireless Public Key Infrastructure in GSM networks and phones. We used mainly C and C++. The company merged quickly with 2 Swedish startups, and was sold a couple of years after to Carlyle.
Between 2002-2004 I worked for Zed developing mobile phone and internet entertainment, film animation and video game production as well as content delivery and billing technology for operators, so that they could sell ringtones, wallpapers and other content for mobile phone users at that time. This was the golden era of SMS and WAP. They had chosen Java, which was disgusting to me, and at this time I stopped programming production code. I worked on test automation tools while working with the R&D management and business people. In Zed we also first tried Scrum and XP in 2001. The work - or actually the business people - at Zed were really “dynamic”. We had around 20 big telco operators around the world (from US, UK, Holland, Italy, Germany to Philippines) as our customers, and the business people & senior mgmt couldn’t just manage the chaos and complexity. The priorities changed many times during the week, and the R&D was feeling sick. I recall searching the web (using Altavista) for “software development in chaotic environment”, and the first result was controlchaos.com. We tried to seek for Scrum and Agile coaches, but couldn’t find a single one in Europe, so we started with just based on Ken’s ideas and writings. However, we got many benefits from Scrum, the biggest being clarity on priorities and focus. Then, at 2004, a Spanish company called LaNetro bought whole Zed, the R&D centre in Finland was shut down, and I went back to Nokia Networks.
After Zed, at 2004 I went to Nokia Networks to help with flexible R&D initiative that studied different ways to improve Nokia Networks' ability to better respond to changes. Here I first met with Bas and Craig. We also worked occasionally with Ken Schwaber, Michael Feathers, Diana Larsen, Esther Derby, Rachel Davies, Jutta Eckstein, (big) Dave Thomas, Ralph Stacey, Dave Snowden, Mike Cohn, Roman Pichler and many other consultants. Craig was however the lead consultant working there full-time, while the others mainly did workshops and trainings. In the beginning, I worked in the Nokia Network OSS systems, but quickly moved to the legendary "Flexible Company" team where Bas and Craig was already. This was located within centralized organization of Nokia Networks, so we served all different product lines. At this time, I also started to go to agile, XP and Scrum conferences regularly. So often, that I stopped going to agile conferences at 2008.
At Nokia I also got to know Reaktor, and hired their people. I had Lasse Koskela from Reaktor developing the very first release of Robot Framework, that I started in 2005 together with Pekka Klärck and Juha Rantanen. Later I also hired Jukka Lindström and other coaches from Reaktor, to help us with agile software development.
I quit Nokia Networks when it merged with Siemens AG. I started my own company called LeanTek at 2007 to do consulting and coaching. Soon after, Reaktor founders approached me, and I decided to move there in the beginning of 2008. At Reaktor, I started the coaching and training business while still consulting Nokia Networks, and some other big companies mainly in Finland with LeSS, agile and lean. I didn't have the time and patience to become a Scrum Trainer though, but we educated 3 great trainers (Lasse, Jukka, and Arto Eskelinen) who worked with Bas, Nigel Baker and Geoff Watts to become Certified Scrum Trainers. One of my best engagements at Reaktor was Ericsson's LeSS adoption, where I worked with the M-MGW's leadership team. We had 5 coaches from Reaktor there in different parts of the organization, altogether for 1,5 years, and were able to do a quite successful LeSS experiment.