1 – WHY THIS BOOK
MINN and TMIBERIA have been (or are being) a long learning process, based on a defined methodology that we are experimenting. But what is important on both is the content, not the process; so the process is always secondary, and “we don’t talk about that”.
But in my case, I’m thinking about how this methodology could be applied to create intrapeneurial teams in a software development company (init services); and knowing and understanding it, in this case, is a must.
I was willing to grab the book to understand the whole and make a plan and proposal for iScrum, the methodology for creating not only good software development teams, but creating intrapeneurial teams.
2 – FELLINGS ABOUT THIS BOOK
The book is a book for having as a “manual”; it’s very straight and simple. That’s also the key of the methodology of Team Academy, and the book is a reflection of that.
The book is the typical book you will have always over your desktop or in a visible shelf of your library, to be able to check it frequently when you have questions, doubts or some theory that you want to grab and put in a team.
Reading the book clarified me lots of thoughts, and gave me good insights about how iScrum should be. What comes next are lots of reflections on iScrum based on the book.
The book is divided in three clear chapters: the Rocket Model, the Applyting Theory to Practice Model (ATP) and some Practical Tools.
3 – ROCKET MODEL
Before reading the book, and while being at TMIBERIA, I complained a lot how superfitially we went through the Rocket Model: I knew that for each process we were going through, there were some indicators that we weren’t. We tried to during MINNTEAM, but I couldn’t find the ones we used to evaluate ourselves.
All of this is explained in the book, in deep detail.
It goes well with my way of being to have such an structured model, I like that idea and the way to be able to visualize, phisically, the progress of the team. One of the problems these days is that we, people, THINK we are one way, but the true is that our results are going other way.
It is important to have indicators from one point of side (“the way we are behaving”) and from the other one (“the results we are getting”). TA has indicators to grab both of them. Rocket Model is, mostly, of the second ones.
So my main insights when I read this RM chapter were about how it could be translated to iScrum: how could an IT company have its own rocket model, to be able to visualize, and what it meant for the team and company. Also, while reading this book, I had the chance to be able to participate in the development of the project of “LEINN digitalization” (although it’s more that just that), and that gave me the ability to explain the RM, with Jose Mari, to people who didn’t have any contact with it. Doing that brings you back to the WHY of the RM, to the roots of the model of TA.
3.1 The methodology of TA is “learner centered”, although focused on team development.
As you get results in a TEAM (in your company), the development of the team is followed up and measured. There are indicators for the TEAM, and they are very important, as results are what drive the company.
But the methodology is LEARNER CENTERED. Based on learning, and based on the learner. It means that the learner is the one who drives his own personal career. “What do I want to do and how?” Is the main question that the learner has to answer, while the RM is a visualization of how good / bad they are doing in the process that will help them answer the question.
So in iScrum, the employee (let’s call him “intrepeneur”), the intrepeneur is the one who has to drive his own personal career, and choose and LEARN if the company is the tool that is going to help him develop it.
This makes me recall “Let my people go surfing” book, in which Yvon defines himself as a climber, and his company is a tool to develop himself and a way of living, but not the goal itself.
Related to this, is the teams creation. In iScrum in INIT we just created the teams, and now, all intrepeneurs are in FORJA or SUA teams. They had to decide, as in MATRIX, which team to choose. How will it affect to their personal career is clear (as both teams have different mean of existence), but they personally and individually chose the team.
How will it affect to the company their decisions? Is one of the most important things I have to work on.
Something I’m very worried on is about to mantain the Leading Thoughts of the INIT Brand (INIT SERVICES company) and the Leading Thoughts of each team. How can we keep the Mission, Vission and Values of INIT, while at the same time, individuals in both teams are defining, by themselves, the Mission, Vission and Values of their teams? Is it fair to tell them just “they have to be aligned with the ones in INIT SERVICES”? Or they shouldn’t be aware of that? Where to put the line? Is there a line to be put?
3.2 WE ARE STILL (slow) LEARNERS
For me, one of the main ideas of iScrum is to bind again to the idea that we are still learners. When students finish university and we start working in a company, we forget that we learn, and we just work. We don’t stop and think. We work. Nobody reminds us to stop and think sometimes. When was the last time I read a book about “entrepeneuring” before MINN? I can’t remember it.
Using TA tools remember us that our personal development goes through learning. We are still learners, as we master new skills and new goals in our lives.
As we work with others, this learning can be improved through team learning. As we are in an (open) ecosystem, this learning can be speed up through interacting with it.
iScrum, then, wil work to give more power to the idea of learning these days. To the idea of reflecting about what we do and learn from all the team’s mistakes. In that case, for example, training sessions are a perfect space to stop working and reflect all together.
3.3 IT ROCKET MODEL
As already done with LEINN or MINN in the case of MTA, the Rocket Model should be adapted to an IT Software Development company.
“Scrum” (or in general, Agile) concept is not far from TA methodology, and that’s why I see clear that both of them can fit so good. Agile is about developing, TA is about creating intrepeneurs. Both mix perfectly.
The 12 processes of the Rocket Model are like the main core of the learning development of a company. All team learners, independently of where they are, have to go through this main development cycle. The Rocket Model will help us learners to be aware of how slow / fast / deep / etc. are going through our learning process.
3.4 ADAPTING CURRENT PROCESSES
RM has 12 processes in the core of it. 12 processes that are common to every team-company; but it’s clear that they should be different depending on the context in which they are applied, and the metrics we have to use to measure them. Here are some examples I was thinking of while reading the book:
- Individual Learning process: the idea of adding a new cathegory “IT” in the reading plan, while selecting books about IT, TDD, etc.
- Branding intrapeneuring a company: how to effectively use INIT brand in the different new brands that we will create “FORJA” and “SUA”? How independent or bound to INIT should they be? How would it affect to the team?
- Leading Thoughts: as I was stating before, transmiting and linking leading thoughts (without controlling them) we think it’s very important in the case of intrapeneuring in a company.
- TC team: To solve that, we created a third team in INIT (A-TEAM), whose mission is to effectively link both teams to the company, giving support to both teams as they develop business. That would be like the team of coaches, in which Jordi, Borja and myself are working. How our team should have (or not) an IT Rocket model and what are the results we should deliver, is something unclear for me now. We have our own mission and vision, but we are not “producers”, just supporters. How will work this approach in the near future? Will it be sustainable?
- Leveling processes: Another question that goes through my mind while reading the progress of the RM is: would it be possible to create different leves inside INIT depending on the evolution of the teams? Would it be “fair” for these teams to be compared to others? That would lead us to an interesting concept, like creating a university of IT intrapeneurship.
3.5 CREATING NEW PROCESSES
But at the same time, we have to think on the learning of IT methodologies or IT skills. For that, I’m developing IT processes. Some of them will be individual and some of them will be in team.
So I’m thinking in the processes that should be introduced specifically in an IT company, something like:
- The process of learning how to develop good software: testing and quality (TDD / BDD / etc.), master different programming languages, being involved in different projects (small and big ones), etc.
- The process of learning how to design good software and services: design thinking, analyzing requirements, creating different business models, etc.
4 – APPLYING THEORY TO PRACTICE MODEL
This chapter of the book for me was more pointless than the RM one, as I think we, in INIT, are currently working and applyting theory to practice. Although I found some keypoints interesting that maybe I wasn’t reflecting on before. They are: (1) the importance of the premotorola for the postmotorola effectiveness, (2) the importance of the book of books and a reading plan based on the learning contract and (3) the importance of the Birthgivings.
Defining the individual learning contract is one of the first things we tried with FORJA. It worked very well and is one of the main driving motor force when learners doubt: “remember what you put in your LC? Is this helping you to get through it?”.
One challenge for me related to the ATP model is to be able to make the first Birthgiving. When will the teams be able to create a Birthgiving? How will it be perceived from the team’s point of view? When do I know that we are ready and the perception will be the one intended? And how will it be perceived from the company’s point of view? I think the first one it can be for solving problems inside the teams, problems that they actually have, and the BG can be a tool for them to talk about it and put a solution. But in this case, the BG misses the customer (or the customer might be INIT). Is this a good point of view?
Actually, I don’t see at all creating BG for real customers at this point of time 🙂
Another struggling thing for me is the Team Coach’s support. How deep should we go into the development of he teams? And the operative of the teams? It is very difficult to create a good balance between the learning-by-mistakes of the teamcompanies and the survival of the company. Where to put the line? Some examples about what’s happening to me these days:
- When I go into a TS, I find teams worried about specific things. Things that my job before was to clarify, help and support in an operative manner: “Ok, we will call the customer together and explain this and help you to do it better”. Now, I’m overwhelmed about “worries” that are going through during the TS, and those worries get bigger as the ones before are not getting properly solved (becaue the rythm in the company is fast and doesn’t let you solve those problems “in the TA way”). So I find myself operatively working to solve those problems WITH them. The difference (with before) is that I make special focus on letting THEM lead the solution. But to me, at the end, it means to be overwelmed with all the operative problems of the company, and it personally affects me.
- Another factor to have into account is the communication with internal people: all the time I find myself justifying the behaviour of the teams, knowing that maybe they did wrong, but that now they learnt how to do it better. Those justifications are also affecting to me.
5 – TOOLS
The book brings some tools for the coaches so we can put in practice with our teams. The ones that I found interesting:
- 21 Skills: for me was really useful, as I was looking for a way to help intrapeneurs to visualize their skills. I was thinking on which skills should have an iScrum intrapeneur, while I was reading the book, and suddenly I found the 21 Skills that TA intrapeneurs should have. I clearly understood that an iScrum intrapeneur should, then, have the 21 IT skills AND the 21 TA skills.
- We should use them to be able to reflect about the development of the skills of the individuals; and, thus, the development of the skills in the teams. We should use them in the 360 evaluation: not a evaluation itself, but a reflection; that affects to the learning contract of each.
- You can find my proposal of the 21 IT skills in this post.
- Different passes and points that you get from different programs, as leadership trainings, masters, etc.
- I liked the idea of creating a “fake management position”, or at least to create different positions not related to customers, but related to internal positions that people could use to develop their leading skills.
- The importance of cross fertilization: between LEINN teams for example, and INIT ones (easier in BBF building). But how can we do it without interfering the daily work?
- The rest of the tools (Johaness laws, white papers, Q47, …), may be I already knew them, or I didn’t find anything related to our day by day that I already said.
6 – CONCLUSSIONS
A book to know and understand the theory of TA. Maybe to understand how simple the theory behind is, as, the importance is not the process itself, but the content. The process only helps learners to learn faster and focus on their individual development, using the team as a tool to get to it. With iScrum, the challenge is to create a company as a tool for self-development in teams, while boosting the development of the company itself.