Leadership

Philosophy – One Step Ahead

If you are one step ahead of things, life is so much easier. Its like in chess, where you have the next move already sorted out. If a problem occur, you already have a solution, or at least a strategy on how to solve it. One step ahead means that you are in the driver seat of the car, and not pinned down in the back.

One step ahead

”One step ahead” – Slightly better prepared or more successful than someone else (taken from TheFreeDictionary)

Being alert and looking forward is also more fun than looking backward. Therefore one step ahead is the philosophy that I vouch for! It’s also very easy to remember and visualise in your head, three simple words:

  • One
  • Step
  • Ahead

Ok, maybe this is enough of ”selling my theory”, let’s get a little more concrete.

You can visualise my philosophy like traveling along a road. Your road can be straight or with a lot of curves. But on that road there will be a number of obstacles, impediments that needs to be dealt with. If your sight is narrow (close to blindfolded), you will bump into EVERY obstacle and need to deal with them reactively. But if you are one step ahead of everything, your sight is longer (aiming for the horizon) and you can see the obstacles ahead, and can be able to turn for them (i.e., do something actively about them). It is always easier to deal with problems you can see coming (when they are ”small” and further away), than when they have happened (and have become ”large”).

”One

Figure 1 – One step ahead philosophy. The project is like a truck with cargo (tasks) traveling along a road with obstacles.

The truck in previous picture symbolises your project or other larger work at hand. The truck is loaded with a lot of stuff, that is your tasks or work items.

To be one step ahead you need to keep your eyes open (talk to your project team members, find out what they are worried about), and to have your view on the horizon (with that I mean a time perspective of weeks or months ahead, rather than days or hours).

If you sense a problem or challenge (picking it up when you discussed the project with Ed, the lead programmer, in front of the coffee machine in the morning) you should not give up before you can sort the it into one of the following categories:

  • Immediate action needed – You need to understand the problem in detail (in so much detail that you understand it, and can make a decision about it). If you don’t understand the problem, you simply need to keep digging until you do (book meetings with key persons, read the specification once more, etc.). When you understand and can see the impact, you need to take the proper actions to solve the problem.
  • Needs to be dealt with later – You have done your homework and understand the problem and its impact, but it doesn’t need your immediate action. You still need to ”own” the problem and follow-up on it, i.e., by adding it to the AP-list and the time plan (if it is affected), more about that later.
  • Harmless / no action required  – Your investigation shows that the problem is harmless to you (i.e., it will not affect your project or task at hand, you can pass it on in the organisation) or ”it will solve itself” (i.e., the problem can be fixed without your involvement, or even simpler, there was no problem).

Next section will tell you a little more about how to face problems or challenges.

Reactive management

In reactive management (a.k.a. ”fire fighting”) you act on things that HAS happened. Your data storage has run out of free space, your largest customer has found a fatal bug in your software that is already in production, or your best programmer has left you for your competitor. That’s why it is also called ”fire fighting”, your are dealing with the symptoms, and can do nothing about the cause of the problem (at this point of time).

”One

Figure 2 – Reactive management. You are running behind the truck to pick up the stuff that has fallen out, i.e., fixing problems that have already happened.

You as a leader are running after the truck to pick up the stuff that has fallen off because hitting the bumps in the road. Most of the things that falls out is possible to fix (like adding more disk to the data storage), but it slows you down. Some things are broke and lost forever (like the lost of your best programmer). The truck must stop while you fix things, i.e., your project moves slower or is even stopped from time to time. This will lead to delays, that in turn makes frustration among all the projects’ stakeholders.

In reactive management you are one step behind, lying in the backseat of the car. Interested to hear how you can grab the steering wheel?

Active management

In active management you have a preparation for things that can happen.

”One

Figure 3 – Active management. You are running in front of the truck to remove impediments as they come along.

Visualise this by you running ahead of the truck to push the stone away or to fill the hole in the road, or to tell the driver to steer away from the hurdle. The more problems or challenges you can fix, the faster you truck (project) can move. In theory you can clear the road all the way to the finish line (the project goal), but in practice its about ”clearing” a reasonable distance in front of the truck (after all, it can be very hard to look into the future). It’s all about removing of impediments before the truck (project) hits them.

You must also have an awareness of the problems you can’t see, they might be too far away for the moment or they are hidden. Like when it’s around Zero degrees Celsius and a spot of ice appear in a steep curve (that can make your truck run off the road). To have that humble insight that it can be even more problems is a good start.

”Why do you need to spend time on problems thats has not happened?”, someone might ask. Because you then have a chance to call for meetings, find the proper solution or minimise the impact. You don’t want to end up under time pressure, because that will force you into bad decisions. With bad decisions you will end up in reactive management and you are stuck in a catch-22 (i.e., going round in circles).

Summary

  • Management is like traveling along a road with a number of obstacles.
  • Active management – You try to do something about your problems before they occur, or if not possible to solve, to minimise the impact.
  • Reactive management – You bump into problems and act on them after they have happened.
  • Active management is to prefer over reactive, to be ”one step ahead”.
  • Go from reactive to active management A.S.A.P!
Advertisements

Top Ten List – Books

Today I visited Stockholm Lean Coffee. It was my first visit in a long time, and the discussions were very giving as usual! The question that I brought to the table was the one of tips of (new) Agile books to read. I got a few suggestions that I can come back to later, when I’ve read them. For now, I will share with you my top ten list of the most inspiring Agile/Lean/Management-books that I have read. Here it goes, in reversed order for most excitement, of course! 🙂

”Top

Top Ten List – Books

10. #Workout (Managing for Happiness)

I start off with the one and only book that yours truly have contributed to. 🙂 It’s the “#Workout”- book that Jurgen Appelo self-published. See my short review here. It has now been withdrawn from the market, and replaced by “Managing for Happiness: Games, Tools, and Practices to Motivate Any Team”. Most of the chapters from the first book was transfered over to the new one that is available for purchase.

9. Scrum and XP from the trenches, 2nd edition

My Agile journey really kicked-off by reading this book back in 2008 (it was then the 1st edition, released 2007). It gave me the understanding that it was possible to build software without using the waterfall model! The 2nd edition is annotated by Henrik Kniberg, sharing eight more years of his experience. Here is my review of the 2nd edition.

8. Creativity, Inc.

Ed Catmull is an astonishing leader! This book is his biography, but also tells you the story on how to build an innovative and creative company, like Pixar (nowadays a subsidiary of The Walt Disney Company). In his career he made art and technology come together. Here is my review of the book.

7. Soft Skills

Before I started this blog I had a strong desire of writing a book myself. But I had no idea on how to do it. Via Manning I got involved in a MEAP (Manning Early Access Program) providing feedback to this book “Soft Skills”, to get me “into the world of book writing”. It turned out that John Sonmez are a quite nice fellow! 🙂 “Soft Skills” clarifies personal kaizen.

6. This is Lean

This is my Lean-bible! It taught me the “secret sauce” of flow efficiency (work moves fast through the process) over resource efficiency (people to be busy at all times). I read this book long before I started blogging, therefore I don’t have any formal review, instead you can read this blog post that sums up my thoughts regarding this.

5. Moments of Truth

This book I first read in Swedish (then it is called “Riv pyramiderna!”). The author Jan Carlzon states that a leader of a company can’t be an isolated and autocratic decision maker. Instead, he or she must be a visionary, a strategist, an informer, a teacher, and an inspirer.The values presented in this book are well inline with the agile thinking, talking about empowered teams that are cross-functional and customer focused. Here is the review.

4. Agile Project Management with Kanban

I immediately bought this book after I heard about it, since I’m both into project management and Kanban! And yes, the book fit me like a glove! It’s a true gem, a perfect Agile book in 160 pages. Read more about it here.

Ok, we are approaching top three now…

3. The Innovators

”The Innovators” is Walter Isaacson’s followup book to the ”Steve Jobs”-biography that I think many of you have read. The book holds 500 pages plus, that covers the whole history of the digital revolution from the 19th century to present time. The main takeaway from this book is that creativity is a collaborative process. That innovations comes from smart people working together as a team, rather than from a lone genius. Here is my review.

2. Kanban in Action

This is my personal favourite amongst the books about Kanban! I’ve read it several times. It sort of changed how I see things, and even how people anticipate me, as you can read in the review that I end with: ”I can truly recommend ’Kanban in Action’ to anyone that wants to know just the slightest bit about managing knowledge work. From the first moment I started reading it, this has been my holy bible of Kanban!”.

And the winner is…

1. The Nature of Software Development

This book is written by Ron Jeffries, one of the original Agile Manifesto signatories. It was published 2015 and is a truly agile book with 150 pages full of wisdom! And questions. That can raise wisdom. If you ask me, I think this book is fantastic! Since the chapters are so short and to the point, it’s almost like reading poetry. Agile poetry. This is the ”true north” or ”guiding star” in Agile we all should aim for! Read my full review here.

Summary

I hope you liked this top ten list of books! If you did and tell me, I can make more of this type of lists in the future. It was quite fun compiling it. 🙂 Until next time!

All the best,
 Tomas from TheAgileist

Doing It

I first learned about Ralph van Roosmalen and his work when I participated in a video chat about ”Exploration Days”, hosted by Jurgen Appelo. Ralph is passionate about Management 3.0, and now he has written a book about his learnings called ”Doing It – Management 3.0 Experiences”. The book has 157 pages, with foreword by Jurgen Appelo, and was released in 2017.

”Doing

Content

The book consists of 13 chapters, and I thought that I should give you a short description to each and one of them.

1. Management 3.0? Huh, what?

Ralph starts out with setting the arena and tells what Management 3.0 is. In short: ”Management 3.0 is about engaging people, improving everything, and delighting the customers.” This short and to the point introduction also have references for more information.

2. What is the role of a Manager?

Management 3.0 highlights six areas for you as a manager to focus on:

  1. Energizing people
  2. Empowering teams
  3. Aligning constraints
  4. Developing competence
  5. Growing structure
  6. Improving everything

3. Move your Motivators

This chapter introduces The Moving Motivators game. This is connected to the first management area: energizing people. It has ten motivators (the CHAMPFROGS model):

  1. Curiosity
  2. Honor
  3. Acceptance
  4. Mastery
  5. Power
  6. Freedom
  7. Relatedness
  8. Order
  9. Goal
  10. Status

4. Surprise your team during their next review?

When it’s time for the review meeting, the first question you ask your team member is, “How are you doing?” They respond, “Er … good…” Then you say, “Okay, why good?” “Just good, you know … good.” Does this sound familiar?

Do you recognise yourself in the quote above? Then this chapter can help you make the review meeting fun again.

5. Traditional HR combined with Management 3.0

Here you will learn more about Delegation Boards. ”In short, just think of them as a spreadsheet that vertically lists the decision areas that you want to delegate to others, while the horizontal axis sets the amount of independence a team lead has.”

6. Implementing Cudo Cards

Next up is an introduction to Cudo Cards, a peer-to-peer rewarding system.

7. Visualise values and name your team

To get a team together you need to find the team values and then visualise them. Here you find concrete tips on how to do that.

8. Team 1 and Team 2, boring

Let the team themselves decide on their team name. Even better let them find a symbol that they can associate with the team! For example Yoda from Star Wars to symbolise mastery.

9. Getting your guilds going

Don’t feel guilty if you haven’t tried it out yet, but guilds are the thing! 🙂 Guilds to nurse craftsmanship is a common practice within Agile.

10. Things I learned about Exploration Days

You want learning and innovation to take place within your company, right? In this chapter the concept of Exploration Days are described.

11. Giving feedback without fear

Are you upset with a colleague? Don’t give them a slap, instead prepare for them a delicate feedback wrap! 🙂

12. I don’t want to implement the Spotify model!

Don’t imitate, innovate! This chapter tells you not to just copy a successful model without tailoring it to your context and unique needs.

13. To finish up

Time to wrap up! 🙂 Some last words from Ralph on where to go next.

Recommendation

If you are new to Management 3.0, ”Doing It” is the perfect starting point! Read the well-written introduction texts, and then use the references to go further. Do you want to try Management 3.0 out? Perfect, use this book to guide you. I can truly recommend ”Doing It – Management 3.0 Experiences”! Best of all? You can download the book right here. Happy reading, and see you next time!

All the best,
 Tomas from TheAgileist

The Power of Project Leadership

According to the list of blog posts in my WP-Admin this is my 25th book review! I guess you know by now that I like to read books. Hopefully you like my reviews and find them useful. This time I’ve read a book that is called ”The Power of Project Leadership” by Susanne Madsen. It was published in 2015, and the subtitle is ”7 keys to help you transform from project manager to project leader”.

””The

”In other words, managers are concerned with doing things right, leaders with doing the right things.” – Susanne Madsen

Content

The book has four chapters and they are:

  1. The world is changing and so must you
  2. Your hidden drivers
  3. The 7 keys to project leadership
  4. Making the transition happen

Throughout the book many questions are raised for the reader to think of and reflect upon. Are there more questions than answers? It’s a fine balance, and it is up to the reader to put effort in to get the most out of this book (by doing the exercises for example).

In the first chapter Susanne introduces the three common mistakes that project managers make:

  • Mistake #1: Managing tasks and events at the expense of leading people
  • Mistake #2: Being reactive and focusing on the urgent rather than the important
  • Mistake #3: Believing that we have to know all the answers

These three reflects very well with my own experiences. So how to avoid these mistakes? The key to good project leadership is to be proactive and to keep a good balance between task focus and people focus. As a help to this, the 7 keys to project leadership are introduced:

  1. Be authentic
  2. Lead with vision
  3. Improve and innovate
  4. Empower the team
  5. Get close to stakeholders
  6. Establish a solid foundation
  7. Work with intent

As you see, this resonates with the agile values. To be able to lead people you need to know what motivates them. Personal development experts lists six human needs: Certainty, Variety, Significance, Connection, Growth and Contribution.

People comes together in teams to perform the work. Energy, engagement and explorations are keys for team communication.

”Organizations are no longer built on force but on trust. The existence of trust between people does not necessarily mean that they like each other. It means they understand one another. Taking responsibility for relationships is therefore an absolute necessity. It is a duty.” – Peter Drucker

Recommendation

Basically the book is about the transition from a project manager to a project leader, and the 7 keys that helps you to get there.  The book is solid with nice layout, good structure, informative stories, many exercises and pictures and a pleasant length (250 pages). If you are into agile and are working with projects, you should check this book out!

All the best,
 Tomas from TheAgileist

To team, or not to team – That is the question

Teams are the holy fundament that agile resides on. Teams should be autonomous and cross functional. Teams should be kept together over longer periods of time to become good at what they are doing, to be high performing. This is sort of ”common sense” in the agile world today, we all know this. But what if the team model doesn’t fit your needs?

To team, or not to team?

It happened during one of our biweekly meetings that discuss continuous improvements to the process. The question ”Why can’t we split the team?” was raised. The discussion started and soon the more general question ”Why do we work in teams at all?” was brought up. I was sort of defending it, teams are the way to go and we should not change that, but afterwards I started to think. This blog post holds those thoughts.

Questioning teams

Some background first. We have a relatively small development department. It is currently divided into three teams. Each team has their own set of responsibilities. Personnel has stayed fairly intact over time so everybody knows each other in the department. Each developer has a broad competence, meaning that most of them can do all types of work. Some of the developers have ”special competence” regarding certain areas.

Back to the question about teams. It was raised because only two persons is allocated to work with one of our responsibility areas. Two persons are not a team. Why not have a kanban board for that responsibility area, and have a daily meeting where people that has an interest in this responsibility area can participate? The kanban board then don’t belong to a team, but rather to a responsibility area (this could be one of your products for example).

This thought is not new. I recall that I have read in a David J Anderson book that they had a kanban board and a daily meeting with 50 participants (yet the meeting took less than 10 minutes). I hardly think those 50 persons thought they belonged to the same team, more that they shared interest and participated in a work flow (depicted on the kanban board). I also know that Spotify makes many small organizational changes. On a regular basis (quarterly?) they form the teams (they call them squads) needed. Afterwards they evaluate and re-forms the teams if needed.

”Temporary groups”

I have an example of this that I would like to share with you. We needed to make a new release of one of our old products (that is not in our main focus anymore). Before when that have happened, we have spread out the work on the individual teams, to be fair to the persons that holds the ”special competence” needed to make the release. Work has then not become prioritized and have been dragging for months before it got completed.

This time we thought to try something different. Why not setup a ”temporary group” (I call it so in lack of a better name) and take out those ”specialists” needed from their current teams. We prepared a kanban board and set a time for a daily meeting. Work started and the focus was really good, the ”temporary group” completed the release work in 13,5 working days! The same type of release took two to three months in lead time to perform when working the old way. After the release was done, the persons in the ”temporary group” re-joined their former teams.

Summary

What I am trying to describe is to have ”temporary groups” that forms some sort of task force to come together to solve a particular mission, then they are scattered to be able to join in on something else. Do you have experience in working in this manner when it comes to software development? I would really like it if you can share your stories!

All the best,
 Tomas from TheAgileist

Smells like team spirit

During my vacation I had a great talk with two of my wife’s relatives. They are both into team sports; one is a youth soccer coach and the other is a professional ice hockey player. My main question to them was: How do you get good team spirit?

””Sweden

(Picture taken from http://www.fotbollskanalen.se)

UEFA U21 2015

Earlier this summer Sweden won the European championships in soccer for players under 21 years (UEFA U21). How could that happen? Sweden is a small country with only nine million inhabitants. Large parts of Sweden are covered with snow during parts of the year, not making ideal conditions for practicing and playing soccer. During the tournament Sweden competed against more respected ”soccer countries” like England, Italy and Portugal. They had teams packed will already well established players with ”star status” in their respective clubs.

Not having the best players on the individual level, there most be something else that made this possible. My take is that it was the team spirit. A strong force that is created when a team comes together as one. Like the following quote:

”The whole of the ant colony is greater than the sum of the ants.” – Andrew Stellman & Jennifer Greene, taken from the book ”Learning Agile”

Factors for team spirit and thereby success

Back to my question about team spirit, here are the answers I received:

  • Trust – A team can’t function if the individuals don’t trust each other. Without trust you don’t have a team, what you have then is individuals grouped together. Trust is the fundamental base for a team.
  • ”Högt i tak” – A Swedish phrase that roughly translates to ”height up to the ceiling”. This means that there is a climate in the group that allows different opinions to be expressed without fear of them being turned against you. This may sound a bit fuzzy, so let’s break it down a bit:
    Questioning – If only one or a few voices are to be heard in a team there is no questioning. Without questioning not all brains are used to make the best decisions possible. Utilizing all brains in the groups is better then just using one! The climate in the team must be that everyone has the possibility to discuss and influence important decisions before they are taken.
    Dare to fail – Without trying out new things and thereby risking failure, no learning takes place. Without learning there is no moving forward. Barely holding up status quo is not an option anymore, your competitors will destroy you!
    Dreaming – Months before the UEFA U21 tournament started no one thought it was possible for Sweden to win! All except one person, John Guidetti, one of the key players in the Swedish team. He thought it was possible, he even said it in media. By formulating the dream, the others in the team bought into it, and made it happen! John Sonmez has a great saying for this: ”Act as if, them become!”.
  • Humble – For the team to be truly successful each individual needs to put the goals of the team first, before any individual and more ”egoistic” goals. The team players needs to be humble to the greater course of the team. This comes very natural for Swedish people, it’s part of of DNA to be part of a group/team and to put the goals of the team first. You can even say that is part of of our social democratic legacy (however now the society is being more and more focused on the individual, like in many other countries). There is another Swedish phrase for this, ”laget före jaget” (translates to ”the team before my own needs”).
  • Acceptance of roles – In a team, different roles and competences are needed. When you are assigned to a role, you need to accept that and not complain that you want to do something else. In a soccer tournament this is especially true for the players that are substitutes and get very little time to play in the matches. They need to hold their head high, not whining, and still contribute to a good team spirit.
  • Time limit – For a team to come together the ”extra effort” needed has to be time limited, like during a tournament. A ”bubble” can only exist a certain time before it pops.
  • Underdog – Swedes like to be the underdog, with no initial pressure, building up confidence for each match and then finally winning it all. It seems to be very suitable for our mentality. Other countries may need the pressure of being favorites from the beginning to be able to ”get that little extra” to win.

How this translates into the world of software development

Some great answers above, but I guess you wonder how they can be translated to our world of software development? Here is my take:

  • Trust – This is a basic foundation for any team!
  • ”Högt i tak” (Everyone is free to express their opinions without repercussions)
    Questioning – As stated, the right level of questioning needs to be present to reach the best decisions in a team. If not, we a back in an old ”command & control”-manner where only one or a few persons make all the decisions.
    Dare to fail – Without the courage to fail sometimes we have no experiments that in turn leads to continuous improvements (kaizen).
    Dreaming – Any team needs a visionary person. Might it be a person in the team or someone ”external” that can influence and ”sell” the bigger picture. However, the ”dream” must be seen as reachable, otherwise the ”dreamer” will just be neglected.
  • Humble – The goals of the team must be treated over the personal interests of the individuals.
  • Acceptance of roles – If you are a developer that is your primary focus. But if testing skills are needed at a certain time, the same person shall not turn those tasks down. Even if you are a striker in soccer, you have to participate in both offense and defense.
  • Time limit – In an organization that works day out and day in, it’s harder to find natural time limits. However, a project is naturally time limited and the time boxing aspect also exist in Scrum with the sprints. These can be used as time limits to create focus.
  • Underdog – What we can take away from this is to set the right expectations for the team. The right motivation will make the team perform better. If the expectations are unrealistic, they will be neglected as stated earlier.

Summary

I hope you have got some more ideas on how to create team spirit. It all starts with trust, then humble team players will come together and reach the challenging goals set for the team!

All the best,
 Tomas from TheAgileist

Agile captains

This blog post will tell you about how we define the role of agile captain, something that I know stands out a bit after discussing with others in the agile community.

In Scrum, three roles are defined:

  • Scrum Master – Leads the team and work with removing impediments to get the work forward.
  • Product OwnerReceives, handles and prioritize the requirements for a product.
  • Team members – Persons that are part of the team that shall be cross-functional and self-organizing.

We are in a transition phase from Scrum into Kanban and what roles shall you have then? Looking in the Kanban literature, it only states:

Respect the current process, roles, responsibilities and titles” (taken from Wikipedia)

It feels awkward to call the team leaders for Scrum Masters when we are not using Scrum. We looked to the world of sports for inspiration.

””Mats

In most team sports, the concept of captains are present. Like in ice hockey for example. The captains are players with extra leadership qualities that leads the others on the ice. They interact with other ”stakeholders”, like the coaches (to discuss game strategies) and the referees (to discuss decisions that are being made). The coaches are not playing the game themselves, they supervise and make adjustments (enforcing different game tactics, shifting players, etc.) trying to win the game.

Agile captains

For me, an agile coach it not necessarily part of the team. This is how we define agile captains:

  • ”C” – The head captain. A servant team leader with some extra responsibilities.
  • ”A” – The assistant captain. Also a servant team leader with a few extra responsibilities. However we don’t really make any difference in status between ”C” and ”A”, they are equal.

One of them lead the daily standup meeting. Why have two? Maybe the captain is sick or working from home one day, then it is more convenient to have the assistant stepping in. It’s also good to be two persons, to have a natural part to discuss with before making a decision. The captains also work as a interface from the team to other stakeholders. Comparing to Scrum the role of captain has similarities to the ”Scrum Master”-role.

Pros:

  • Redundancy – If one captain is not present, the other one can step in and for example conduct the daily standup meeting.
  • Sharing work load – An example, each team needs to be represented on a high-level planning meeting. Then the captains can decide between each other, given the tasks they have at the moment, who shall participate.
  • Better decisions – Not one single person being responsible for a decision. There is always another person (the other captain) to discuss with, before making any type of decision. Two brains are better than one!

Cons:

  • No one solely responsible for the team. Since we are not giving the ”C” captain more status, we don’t have one single person responsible for the team. It could be a problem, leading to a ”blame game” between the captains, but we have not experienced this.

Summary

The role of agile captain is working really well for us, what do you call your team leaders in Kanban?

All the best,
 Tomas from TheAgileist