Concentration cone

In this blog post I will introduce you to the concentration cone. It’s something that I’ve had as a mental model during the most part of my career. The text uses a project, the project manager role and a team to explain the concentration cone, but this is applicable in many other contexts as well.


If you are a project manager and responsible for a project, you need to handle many tasks in parallel. At the same time, you need to be able to juggle around more than one ball in the air if you like. Can’t you handle more than one task at the time? Well, there are other roles that may suit your personality better.

I like the juggling metaphor. At a company conference I attended, all employees got three juggling balls and an hour of practice. Most people were able to get all the balls in the air and catch (some) of them. With a little more practice anyone can learn to juggle three balls. To juggle for a while is also a good way to take a break, it requires total focus and ”clears your brain”.

In juggling, you can’t hold on to a single ball for too long, you need to toss it up in the air to be able to catch the ball that is falling down. There is a ”rhythm” or ”flow” you need to be able to master, the same thing you need to be a good project manager. I believe this to be very important! Below you see my mental model to explain it more deeply.

Concentration cone


At the top of the concentration cone you are handling many tasks at the same time (colourful circles in the picture above). You need to have a constant flow of things happening, you can’t spend too much time diving into details for each task. You need to have the correct amount of information about the task, so you can make a proper decision and act. Wether it be doing the task yourself or pass it along to another person. Picture yourself swimming at the top of the concentration cone, dip your head into the water for each task to find out what to do about them, but then get your head up above the water surface again to catch the newt task. As a project manager, its at the surface you need to be, and let others ”dive deep”.

On the bottom of the concentration cone, you are in deep concentration and are working focused on only one thing (black circle in the picture above). Here you need to be, to be able to solve complex problems and do deep thinking. When you are here you shouldn’t be disturbed, then you will be forced up to the surface. Maybe if possible, its best if you can focus totally. But since you need to be available to your team to be ”in control” you can’t be deep down in the concentration cone too long. Your team members needs to be deep down in the concentration cone a lot, if your project shall be successful!

It’s very hard to find balance if you are trying to go ”up and down” in the concentration cone. My recommendation is obvious, stay at the surface to be a good project manager. I once experienced a fellow project manager that struggled to get the grip of a project. To get things going, he dove down into the details of every single task trying to do them himself. By doing this, the overall ”helicopter view” of the project was lost, and the customer was deeply unhappy about ”nothing happening”. It can surely itch in your fingers to dig into the details yourself (for example being an old programmer like me, that wants to ”hack code” again), but don’t do it. When you are deep down in the concentration cone, you can get stuck, and it’s a long way back to the surface. Your project will not benefit from you losing the overall control.


Did you like the mental model of the concentration cone? If you are more into soccer, you can say that a project manager should be like a midfielder and not like a goal keeper. The midfielder has to be involved in the game all the time, whether it being offence or defence. The goal keeper on the other hand, just have to focus on one thing only, stop the opponents from making goals. Until next time, enjoy!

All the best,
Tomas from TheAgileist

Planning with multiple timelines

You should all know by now that I’m very fond of visualisations, to say the least. 🙂 Recently I’ve told you about how we did a ”retrospective with timeline”. That thought stayed in my mind when we needed to do some more detailed planning for multiple projects spanning multiple products. This blog post describes what we came up with. Here we go!


The idea is simple, the timelines highest up on the whiteboard are projects (or larger initiatives, whatever you like to call them). The other bottom half (or whatever suits your needs) are products or components within a product (depending on the level of details you want to plan for). Usage:

  1. The project timelines shows major activities and milestones. I.e. ”hard facts” that we need to consider. For example a promised customer delivery.
  2. The product (or component) timelines shall show activities (work that needs to be done) and is used to find, and sort out, dependencies (”To deliver project X on time, we need to do activity 1 in product A, before we can do activity 2 in product B” and so on).
  3. Color coding. The activities needed in products (components) have the same color as the project that need them to create traceability.


Before the actual planning meeting, you need to find a suitable whiteboard. The larger, the better. Preferably the largest one in the office! But think carefully, you may want to spend some time doing your plan, and therefore keep it up on the whiteboard for some time after the meeting to be able to make adjustments. At least I did, so I found one in a meeting room that is seldom used and started drawing.

Planning with multiple timelines

This is how the “planning with multiple timelines”-meeting was performed.

  1. Some 15-30 minutes before the meeting started, I went to the meeting room and draw the timelines for the projects that we needed to plan (with major activities and milestones). In our case two projects (larger initiatives) and two other activities that were more like dependent on the outcome of the planning. This acts as the starting point for the planning, i.e. things that we intend to deliver.
  2. The meeting started with me explaining the procedure (described above). Then the actual planning started. An example: ”We have promised to do this in that project, for that to work we need to add this in product A and that in B. Wait isn’t this needed in product C as well? Hmm, it is, maybe we should do that first then.” and so on. In this step you can spend as much time as you like, depending on the level of details you want to discuss, and the complexity in what needs to be done. The more dependencies you have the longer time to solve them out. Actually we had one first meeting to get an overview of everything, saving the details for later sessions.
  3. After the planning meeting I always take a picture of the whiteboard using my mobile phone for documentation and the possibility to communicate the plan outside of the room.
  4. As mentioned in a previous point you may want to revise your plan. Preferably you may want do it regularly as long as the projects are running, or you do it in the beginning in a couple of sessions to ”set out the course”.


This is an example of a whiteboard with multiple timelines for planning.



Ok, that was some thoughts and examples on how you can use multiple timelines for planning. If you don’t have several projects (or initiatives) running simultaneously, or you don’t have a complex flora of products you don’t need this. One possible enhancement I can think of is to use a digital whiteboard tool, to be able to keep the plan stored and also to distribute it easier. But for our needs a good old whiteboard suited us just fine. Don’t make things more complex than what they have to be, remember that!

If you don’t like this at all, it feels to much like “MS Project all over again” (however I don’t agree, the key is in the interaction between people to find out dependencies in front of the whiteboard) you can use my other idea for ”visual planning”.

All the best,
Tomas from TheAgileist

Google Docs, Sheets & Slides in remote meetings

Earlier this year I wrote a blog post about how we use Trello as a “whiteboard simulator” for remote meetings. The interest in that has been phenomenal! We have also started experimenting with using Google Docs, Sheets & Slides in remote meetings. We have people in three different locations that needs to attend our meetings. You can see Google Docs, Sheets & Slides as the equivalents of Microsoft Office (Word, Excel and Powerpoint). This blog post is a tutorial how you can start to use these tools in remote meetings.

Initial setup

For sound we use Skype or an ordinary conference phone. If you want to go all in on Google you can use their Hangouts service (chat, phone and video- conference). All documents are stored in Google Drive that is an online file storage and synchronization service, tightly integrated with Google Docs, Sheets & Slides to enable collaboration over the Internet. All meeting participants needs Google (Gmail) accounts.

Then on the meetings, we basically talk to each other and look in the documents online, without using any form of web conference or shared screen! How is this possible?

Automatic update function

Before going any further, I must explain the one thing that makes it possible to use Google Docs, Sheets & Slides in remote meetings. That is the automatic update function. If I write something in a document on my laptop, that update is very shortly after visible on the screens of the others looking at the document online. This happens without any form of reload. There is also a very neat auto save function so you don’t have to care about that either! The latest and most updated version of your documents is always present online. No more bothering of keeping track of different versions of documents!

We have tried with two different setups for remote meetings: workshops & project meetings.  


This first setup is the one we use for workshops. In this example we are discussing a document (Google Docs) on the remote meeting.


The meeting facilitator talks and navigates around in the document. In the picture above the meeting facilitator is represented by his avatar seen up in the right corner (as a facial photo with a red line beneath). The cool trick now is that the other meeting participants can click on the avatar of the meeting facilitator and now starts to see where his cursor is in the document (as seen in the picture above as a ”red vertical line” currently placed between the words ”Lorem” and ”ipsum” under the ”Introduction” paragraph). When the meeting facilitator moves the cursor that change in location in the document is seen on the screen of all others that are ”viewing” the document.  


So what you you need to prepare before the meeting? Apart from creating the document on Google Drive we do the following two things.

  1. Share the document with the meeting participants

For convenience (to save valuable meeting time) we share the document to all participants before the meeting. This is done by using the blue Share button in the top right corner.


Now you will see a dialogue where you enter the Google (Gmail) credentials for the meeting participants. You can chose three different levels: Edit, Comment & View.


To make things smoother we also perform the following step (despite the fact that invitation emails are sent separately to all persons that a document is shared to).

  1. Get link to document for inclusion in meeting invitation

It is neat to include the link to the document in the meeting invitation. Then the participants just clicks the link, comes straight into the document and the action can begin (without spending time looking in email inboxes to find the invitation email). One way of getting hold of the link is to look under Google Drive.


Right click on the document you want to share and chose the ”Get link” option from the menu. From here you can copy the full url to the document and then include it in the meeting invitation.

Are there more things to use for collaboration in the document? In fact there are! Continue reading and you will find out more about them.



If your have many participants in your meeting, maybe you want to use the online chat function to pass in questions to the meeting facilitator. If you are fewer participants, it’s often more convenient to interrupt and handle questions using the voice channel. Anyway, in the picture above you can see an ongoing chat. It is started by pressing the icon to the left of the ”Comments”-button in the upper right corner of the picture above.

Let the participants ”send in” questions via the chat function and have a section of the meeting to handle them. The chat function can also be used if you are a smaller group of people and don’t use any sound. Maybe to check some information, or discuss smaller adjustments to the document.



Comments can also be used as an alternative to the chat function during the remote meeting. You can see an example of a comment in the picture above. Use the cursor to mark some text you want to make a comment on and click on the ”Comments”-button. The comments function is maybe even more useful for evaluation. An example: You have finished making updates to a document and now wants feedback from a colleague. You share the document and your colleague can either make changes directly in the text (if you have given him or her edit permission) or use the comments function to share thoughts and feedback with you.

Post workshop-work


Post workshop work? If you have done all the updates during the meeting there is not much work to do after the meeting! No protocol is needed. If someone for some reason missed the meeting they can go back themselves in the document to view all changes (as seen in the picture above). The discussions is of course lost, if you not recorded them, which is also a possibility. 🙂

Project meetings

This second setup for remote meetings is the one we use for project meetings. In this example we use a presentation (Google Slides) to run the meeting.


As you hopefully can see in the picture above the presentations holds an agenda for the meeting and separate slides for things to discuss. The thing we use here is the linking function. Have a bullet point with text that links directly to, for example, a to-do list (Google Sheets). The participants clicks the link and jumps straight into the correct document!


You can follow the cursor of the meeting facilitator in Google Sheets as well. However when he or she is updating a cell, that becomes gray, and the text is not visible to others before Enter is hit (as showed in the picture above).

On other thing that we haven’t figured out yet is how to ”follow” in a presentation. You can’t press the ”Play”-button to show the presentation to remote participants (of course, if you connect your laptop to a projector, the others in the room can see it). Right now we use the good old way of speaking ”we are on page two” to navigate in the presentation.


The same preparations as for remote workshops applies here as well (see paragraph above). To minimize the number of links to keep track of (yes they can get lost too, just like emails) we reuse the same presentation for every recurring project meeting (that are run weekly, biweekly on monthly depending on the project). By having the same presentation you only have to share it once, and have one and the same link to include in your recurring meeting invitation.

Of course you need to prepare new slides inside the presentation. I use copy & paste from previous meeting and place those slides first in the presentation.

Post ”project meeting”-work

If you document decisions that are taken during the meeting, afterwards no protocol is needed! For example by adding them as bullet points on the same slides that initiates the discussion. Storing slides from previous meetings inside the same presentation also gives you a neat ”decision log”, to go back to later, if needed.

Benefits & disadvantages

So what are the benefits of using Google Docs, Sheets & Slides in remote meetings? I think they are:

  • First of all, no valuable meeting time is spent on making sure that the participants have the same and correct version of the document. The link to the document is included in the meeting invitation. Since it is online, everybody have the same and most recent version. What a relief this is!
  • A presentation can include links to other things that needs to be discussed. For example other Google documents. No need for the participants to keep track of those individual links, just the one for the starting presentation.
  • Discussions and decisions can be captured and documented in the moment. Some caution though, you need a skilled meeting facilitator to pull of both speaking and writing at the same time. You don’t want your meetings to turn into multiple persons waiting for one guy to type on the keyboard. If that happens, split into two roles. One meeting facilitator that ”does the talking” and another person that ”does the writing”. You can even have multiple persons edit the same document all in once! However, maybe not recommendable, to keep some order in the meeting. 🙂
  • You don’t have to use Google Docs, Sheets & Slides in your remote meetings. The collaboration benefits of using them anyhow is enormous!

What are the disadvantages? Company policies may not allow you to use online solutions that stores ”in the cloud”. I know for a fact that some larger companies block access to Google Drive for their employees.


The biggest benefit of doing like this, is that everything feels so easy! No time is wasted on solving meaningless problems (do we have the same version of the document? Is this the latest version? Etc.) No more “extra steps” for the meeting facilitator to store documents (in intranet, file servers or Sharepoint) and endlessly keeping track of different versions. I think this is the future way of working!

All the best,
 Tomas from TheAgileist

No project managers in Agile?

Recently I visited another Lean Coffee in Stockholm. I really like these meetings, they give me new insights and more to think of. This time was no exception. The question that caught on to me was:

”What is the role of the project manager in the Agile world?”

This blog post is a summary of the discussion and my thoughts afterwards.


The role of project managers in software development

The person who wrote the question started to describe that his experience was that a project manager is someone who works ”från ax till limpa”. That is a Swedish expression roughly translated to ”from seed to bread”. It is used to say that you take part in the whole process of something, from the very start until it’s finished.

Now in Agile where the teams are empowered, the role of the traditional project manager becomes more vague. In Scrum for example, no project manager role is specified. You have the team, Scrum Master and Product Owner roles that all share management duties between them. In Kanban, no roles at all are stated, merely ”Respect the current process, roles, responsibilities and titles”. The writer of the question continued to say that the project managers he sees at his company now works with ”packaging”. They ”take the bread from the oven, and put in bags for delivery”.

As I have written earlier, the executives of the company sets the vision. The teams starts to seek and find solutions to the problems that are in line with the company vision. The knowledge and power are now more evenly spread. Teams are autonomous and self-organizing. Management is there to remove impediments and reminding of the overall vision (to prevent sub optimization).

What now?

But what about the ”middle managers” (between the executives and the teams)? What shall they do now? I think that solving this question will remove a huge obstacle that now stands in the way for a wider agile adoption throughout companies worldwide.

First question, shall we have projects at all in software development? We have stable teams that continuously work iteratively with the same product over a longer period of time, so the need of time boxed projects seems to be vanishing. There is a #noprojects movement within the Agile world (lead by Allan Kelly).

In Kanban 2.0 there are actually two roles specified (David J Anderson states this in his upcoming book that will be released in 2016)! From the ”Essential Kanban Condensed Guide” I take the following:

The two roles are:

Service Request Manager: responsible for understanding the needs and expectations of customers, and for selecting and ordering work items accordingly (alternative names for the role: Product Manager, Product Owner, Service Manager)

Service Delivery Manager: responsible for the flow of work in delivering selecting items to customers (alternative names for the role: Flow Manager, Delivery Manager or even Flow Master)

The second one there sounds to me a bit like the one that keep track of all the pieces and put the puzzle together. Or to ”take the bread from the oven and put in bags for delivery”, to put it another way.

Right now I think that many former project managers in agile companies are working as agile coaches or have the role of a release/delivery manager.


So what about project managers? My take is that the role of a project manager, as we have thought of it, will slowly disappear and in some years there will be no project managers in traditional sense left within software development.

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”.


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


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


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


The Product Backlog is an essential artifact in Scrum. The description of the Product Backlog on currently says: ”The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value.” Many organizations have taken these words literally, and have hundreds of items in their product backlogs. Time is spent ”backlog grooming”, where items are re-estimated and re-ordered. To me it’s pointless to keep track of such a long list of things to do. You only need a shorter list, with what you should do next. I think it’s time for this to be changed.

Sources of inspiration

I have been thinking about this for some time and the following sources of information have inspired me:

  • ”Backlogs Are Not Waste” – Jurgen Appelo made a great blog post that really made me think. In it he separates wish lists (”A wish list is a list of Could-Haves”) from checklists (”A checklist is a list of Must-Haves”). Even if you don’t buy everything from your children’s wish list you can still make them happy at Christmas (if you buy the things that delivers most value to them). If you forget something from your checklist while shopping food for a dinner, you can end up with a Chili con carne without beef (making it a Chili sin carne). On a wish list you need to dome some things, while for a checklist you need to complete all of them. I think that many people think of a product backlog more like a checklist, not a wish list.
  • #NoEstimates semantic discussion  – I have been following the vivid #NoEstimates debate on Twitter for some time. A few months ago the focus was on semantics. The term #NoEstimates was attacked because is says ”no estimates”, while the founders of the movement more are meaning ”to seek alternative ways to reduce the need of estimation”. The debate was that it should be called #LessEstimates, #BeyondEstimates or #EstimateFree. My conclusion is that you should call things for what they really are. Backlog sounds to me something that goes ”back in time”, meaning things that you should have done already, giving a feeling that you are late from the start.
  • ”The backlog” – Ron Jeffries recently published a very thoughtful blog post about backlogs. Here he presents other ways ”around” using a backlog with Index Cards, Product Vision, Product Increment and Regular Live Product Review. He thinks that the backlog notion should be eliminated, but leaves it up to other persons to actually do so.

Ron Jeffries is a ”big fish” and I assume he can’t come up with new definitions without the risk of annoying a large number of people. Since I don’t have that problem, I hereby introduce the futurelog!




”A futurelog contains items that may or may not be included in your product in the future. A futurelog is best kept short and visualized.”

Some more explanation may be in place:

  • A futurelog is per definition a wish list.
  • A futurelog focus on value.
  • A futurelog is best kept short only showing the items that are ”next in line” with some reasonable buffer.
  • A futurelog should be visualized (see next section for some ideas on that).
  • The futurelog needs to be revised on regular basis.
  • A futurelog is never ”complete” or ”done”, it shall live as long as your product live.

Other than that you can think of and use the futurelog just as a regular product backlog.

How to visualize the futurelog

Since I’m a big fan of visualization I have some ideas on how it could be done:

  1. ”Priority pyramid” – The simplest way to visualize your futurelog is to use the ”Priority pyramid”. You need to replace priority with value.
  2. ”The Arrow” – If you have one product and one team working on it, I recommend that you visualize your futurelog using ”The Arrow”. As for the ”Priority pyramid” you need to replace priority with value.
  3. ”Product radar” – One other elegant way to visualize this is to use the ”Product radar”. Things closest to the center have highest value.


I hope you like the idea of a futurelog to replace the product backlog. As usual, if you have feedback and comments let me know! Finally, you can now say ”I see into the future” whenever you look inside your futurelog :).

All the best,
 Tomas from TheAgileist

The Shrinkage Factor (TSF)

”We are running late”, ”we need to delay” or ”we are over budget”. If you have worked in projects you have probably heard these phrases many, many times before. But what is the cost of delay? I read a very interesting article about that. In the article a way to calculate the cost of delay is described. I’m working in a product development company so cost is pretty much already set for us, ”this is the team and number of people assigned to work with the product”. Time is also to a very large extent also set, since we have time plans to follow for the releases of the product. The only thing left to be variable from the Iron Triangle is scope.

”The shrinkage factor” from Seinfeld


(Picture captured from the YouTube clip)

I think many of you remember the sitcom Seinfeld that ran on NBC during the 90’s starring Jerry Seinfeld, George Costanza, Elaine Bennes and Cosmo Kramer. In the 85th episode called ”The Hamptons”, the following happens (information taken from Wikipedia):

The four principal characters travel to the Hamptons to see a baby; they find that the baby is altogether ugly. While on the beach, Kramer finds a filled lobster trap and thinks the catch is his, unaware that it’s a commercial lobster trap. George’s girlfriend goes sun tanning topless while he goes out to get tomatoes, and George is seen naked by Jerry’s girlfriend Rachel, to whom he tries in vain to explain that, having just gotten out of the cold water, he is a victim of penile ”shrinkage” by yelling “I was in the pool!”

More according Wikipedia – The episode has been credited with giving “new meaning to the word ‘shrinkage'”. Seinfeld writer Peter Mehlman took credit for introducing the word, with apparently enthusiastic approval from Larry David (co-creator of Seinfeld together with Jerry Seinfeld).

The Shrinkage Factor (TSF)

Have you watched the hilarious YouTube clip yet? If not, please go ahead and do so before continue reading. Finished? Now I’ shall try to give the shrinkage factor a new meaning in the context of agile.

The Shrinkage Factor (TSF) represent the scope decrease in percentage for every time unit of project delay.

This definition resonates well with the one that I found here. Let me provide a simple formula together with an example. The simple formula:

The Shrinkage Factor (TSF) = Capacity per Time Unit (CTU) / Total Scope of Project (TSP)


  • Capacity per Time Unit (CTU) – How many tasks the project team completes per time unit. This needs to be measured. Example: 10 tasks/week.
  • Total Scope of Project (TSP) – The total number of tasks that are planned for the project. Example: 200. Giving an implicit project length of twenty weeks to complete all tasks.
  • The Shrinkage Factor (TSF) – The decrease in scope, in percentage.

An example, using the mentioned values from above:

TSF(1) = CTU / TSP = 10 / 200 = 5% per week

Meaning for each week of delay the scope of the project has to be reduced with 5%.


TSF is now something I have in my toolbox to be able to communicate to my project stakeholders the impact of delay. Everybody logically understands that given a shorter time you can complete less work, but to have a hard value on it is of course even more pervasive! I hope you find this blog post amusing and that you put TSF in your toolbox.

All the best,
 Tomas from TheAgileist