I write this part because it’s always debatable about how to run a project and cooperate with other departments within the company. This is supposed to be seen as a template that can be used together with a team to agree on the way you are working together to minimize misunderstandings and unnessecery work. My notes are based on information I got during my own experience, Scrum workshops, books like “Lean Management” (ISBN:978-91-47-09449-3) and “Praktisk projektledning” (ISBN:978-91-631-9605-8).

Define the problem

We need to agree on how to work together that encurage members to take initiative, explore possiblilities and still thive towards the same goal. To acheve this goal, we just follow the rule of plan-do-check-act for both iterating over the project to constantly update the goals. But we also need to update our way of working. To do this we need written processes that describes our current way of working. We continously challange the processes to find ways to make the work easier with better outcome.

Overview

We want to create an organisation based on responsibility where everyone feel the urge to fix things to the better. Most organisations have a top-down management with responsibilities which often leads to debates about who is responsible and pie thowing. We need to agree on how to work together that encurage members to take initiative, explore possiblilities and still thive towards the same goal. To acheve this, we just follow the rule of plan-do-check-act/adjust for both iterating over the project to constantly update the goals. But we also need to update our way of working.

Two loops

You can say there are two loops running this iteration while running your project. One is to reach the project goal and the other is how to improve the way of working.

Example Project goal iteration:

  • plan: find out our current situation and identify desired state and try to find a way to reach it.
  • do: we work in a “sprint” to close the gap between our two states.
  • check: after eg 3weeks, we stop and check where we are right now.
  • act/adjust: did it go according to plan? did anything become better? keep the good things and throw away the bad things. then do another iteration.

Example way of working iteration:

  • plan: identify how we are working today and how we would like to work. (identify flaws/improvements in our process, and select solutions)
  • do: try out the solutions
  • check: measure if there was an actual improvement in our work
  • act/adjust: update the process if the change was good.

Processes:

Every company has processes to follow, some with success. How do we think here? A process shall ideally contain how to work, which goals we would like to acheve (explaines the “5 x why”) and how to check if we are doing correct. One way to remember is that our processes shall be seen as a “baseline” that makes it possible to compare our changes against. This makes it possible to constantly improve. It shall not be seen as a statue that only shall be seen and never touched. That’s why it’s important to be able to measure the outcome to know if we made an improvement. The goals is important to know if the change we did affects all previous goals and not only the one that is important for the moment. One common mistake is to not explain the “why” which makes it open for speculations and no-one dares to change the document.

Exploration, exploatation:

This is an important part of both itteration loops. We both need to be efficient and harvest the fruits of our hard earned learnings (exploration) but also need to continue to grow our knowlage (exploatation). Sometimes we get stuck in either of these states and could use this expression to communicate to the group to focus more on the one or another. For example, if we would like the team to work more efficiently, one way is to tell them they need to work faster with maintained quality (does not often give good resluts). Or we could tell them/ give them the opertunity to explore new ways of working and update the processes.

Roles

Anyway, we still need responsibilities. To make it easier to work together, the following roles are defined as follows:

  • Project Owner: The person who pays for the project. Need to get deeply involved into the project to be able to ask intelligent leading questions about how the project is progressing. Never tells directly what to do since then you remove the responsibility. Leads and coaches the team and wants to know what the plan looks like. Assumes there will be problems and that nothig goes as planned.
  • Scrum Master: A person from the team who are responsible for modderating meetings. He/she shall be part of the team, as any other team member but might have the final call in some mattes.
  • Team members: 1-8ih people who perfrom the actual work. They are responsible for planning the project together, breaking down the goals into smaller tasks, time-estimations of all tasks and tries to keep their estimations. Some teams have dedicated tasks which makes the team very fast but sensitive to member-losses. Other teams have a more general approach where each team-member should be able to take any task in the project, wich makes the team more robust but a bit slower. Another advantage of the more general approach is that all team-members have the insight to all parts of the project wich often leads to better products and less confusion.

Phases

These are execution phases in the project:

  1. Project start: One of the most common mistakes is to throw yourself over a solution before actually understanding the problem (looking at data, talking to people, finding the root cause summorized into one sentence). .The following define_the_problem template can be used to understand the problem a bit better. Also determine how the feedback loop will look-like. Some useful links: 7-step problem solving, A3 Gemba

Sometimes the team has a lot of new members and have not yet developed their rols and how to work together. One efficient way is to make a tight deadline for the team in the beginning of the project to force the team-members to work together. This shall be done with care and the acual goal is develop a tight team, not reach the project goal in a short time.

  1. Planning (team): The team breaks down the prioritized list of objectives and distrubutes the tasks. A prioritized list is prepeared for the Demo which will be re-prioritized by the project owner. There are alternatives to move this part to after the demo to do a more detailed planning after feedback from the demo.

  2. Demo (team + owner): The team tries to show tasks and goals that are ready to be shown for the project owner. They also updates the project-plan/goals together with the project owner since more knowlage has been gathered to solve the problem. Finaly they go thru the prioritzed list and let the product owner re-organize about what need to be done. I’ts always a good idea to have a small chat with the team after the meeting to discuss things that could be improved for the next meeting and summorize key insights and information.

  3. Sprint Retrospect (team): The team improves itself(way of working) by eg creating a time-line about good/bad things, discussing how to improve them selves, eg get better tools, fix missing documents etc. Select the top most importand tasks and set an owner and time estimate for each task to fix and try to squeeze it in the upcomming sprint. There are different ways to do a retrospective. One way that is not listed is to create a timeline together with the team to refresh the memory and put postits on what’s good and bad. Use the postits to create a row for improvements and another for things to continue with. If too many things aprear in the “fixed” column, it might be a good idea to try to find if they relate to eachother to find the root cause. Then assign a person or team to fix the problem.

  4. Execution (team): The team executes the tasks in the prioritized list.

  5. Closing the project: The project is often in a hurry the last couple of weeks to finish the work for a deadline. This part takes care of the aftermath of the project wich culd be:

    • retrospect: update processes and way of working
    • Break out parts of the project that can be used in the future like software tools, documentation etc.
    • Write down the learnings.

Questions:

  • How often skall we have the meetings? Decide a date for meetings.
  • Members, shall they have single competence seen separate goals for each one man team. Or shall we share our work?
  • Does the project owner atted to the retrospects or shall feedback be given during the meetings?

Templates

Startup:

Fill in the project plan define_the_problem template One of the most common mistakes is to throw yourself over a solution before actually understanding the problem (looking at data, talking to people etc). Here are some useful links for understanding when you have understood the problem.

7-step problem solving A3 Gemba

project basic consepts

Sprint Meeting

Things we want to discuss.

  • Demo: Show finished tasks (show current state):
    • Show how the feature/thing is working
    • Share learnings.
    • Share important decisions that was made during this phase and the background for that decision.
    • Raise risks that was found to be able to prioritize upcomming sprint.
    • show where we are and workload for reaching current goal (burndown chart?)
  • Update the project plan (dicuss desired state):
  • Present a prioritized list of tasks/questions/problems to be solved for the upcomming sprint(broken down to eg 1-2weeks of work).
  • Let the Project owner re-arrange the list and give feedback to the group.

Fail Fast:

This is a common expression and does not actually say much. One could interpreat it as developing a small working prototype and the iterate to constantly improve it. Or it could also be interpreated as trying to identify larger risks and try them out early in the project. There are a lot to say about this topic but the best way is to ask exactly what person means by that expression when it’s brought up as a goal for the project.

Questions:

  • Which topics can be removed, or shall something be added?
  • How accurat shall the timing estimates be?
  • Shall the team commit for the prioritized (must be finished untill next sprint) or shall the team just try to finnish as many as possible?

** Startup phase Most project can be divided into diefferent parts.

  • Selection phase: where it’s decided that the project will be resourced and executed
  • Startup phase: The team sets up goals, milestones and metrics
  • execution phase: The team runs the project
  • Evaluation: Initial release of the project
  • Support: The product usually needs to be updated to fix minor errors etc.

Team dynamics:

  • Make an excercice with the team where the memebers are put under stress and need to trust and help eachother.
  • kreativitet skall belönas.
  • eget initiativ skall belönas.

Bra ledare: -sätter andra före sig själv

  • alla är olika, hantera dem olika beroende på kvalifikationer. styrkor/svagheter
  • tydlig

  • tar snabba beslut

  • Elon Musk:
    • hård, ställer de svåra frågorna.
    • Vad gör Elon möjligheten att vara hård?
    • Hård för att nå målet, inte hård för att hävda sig själv.
    • lägger mycket tid på att “sova på fabriksgolvet”, förstå detaljerna.
    • Om det dyker upp ett problem, förstå alla detaljerna för att lösa problemet.
    • vet inte hur man vet allt, men vill förstå problemet för att hjälpa till.
    • fastnar inte i att “micro manage” alla.
    • Han hanterar bara att släcka bränder.
    • få till descentraliserad hjälp som han tränat själv och som han litar på.
    • skapa en stark kultur.
    • startup, tittar på sitt eget företag och lyckas inte lyfta blicken och förhålla sig till andra företag. -

      Framgång gör människor mjuka

  • ständigt försöka förbättra och ifrågasätta och inte låta egot komma ivägen.