This article is a follow-up to my post on lean documentation that I published some time ago. In summary, lean documentation is characterized by being easy to consume and simple to keep updated. The purpose of lean documentation is to help you, as the reader, find answers to your questions, not to hold the detailed answersContinue reading
To understand this article, first read Managing in Mayberry by Don Gray & Dan Starr: https://www.donaldegray.com/managing-in-mayberry-an-examination-of-three-distinct-leadership-styles/ In short, it is about three different styles of leadership, depending on their view of the problem. The situation is that, in heavy traffic, left-turners may cause a queue of cars that leads to a dangerous situation. Officer Barney’s micromanaging leadershipContinue reading
I guess you, like the most of us, have a problem breaking work down to small but still valuable pieces and that your MVP (minimal viable product) is more or less the same as the project scope. If you recognize yourself in this than keep reading.
Our article about Scaled Scrum has been published on InfoQ. In the article we describe the basics of LeSS, SAFe, and Scrum@Scale and show the similarities and differences between them You find the article about Scaled Scrum at InfoQ. Enjoy!Continue reading
Att organisera flera Scrum team görs på en hel del olika sätt. Här beskriver vi likheter och skillnader mellan några av de ramverk som vi har stött på hos våra kunder och utbildare, LeSS, SAFe och Scrum@Scale.
Gemensamt för LeSS, SAFe och Scrum@Scale
I alla tre ramverken utgår man från att man i botten har vanliga Scrum-team som är tvärfunktionella och självorganiserande.
Man utgår också från att vi alltid försöker bryta ner kraven vertikalt, så att varje inkrement blir så litet som möjligt men ändå kan driftsättas separat.
Underförstått är även att man kör kontinuerlig integration och automatiserad regressionstestning, och att man efter varje sprint har en produkt som går att driftsätta ifall man så väljer.
Designed as a 30-day action plan, this book will help you understand and implement Kanban – and start seeing results – in a month.
Analyze your current situation and define your goals and wider strategic aims, and begin developing a plan to help you and your team confidently work towards achieving them. Involve your team into driving cultural change, learn how to prioritize, and organize tasks and projects to efficiently use your time and resources.
Create your own value stream map to better understand your processes and identify improvement areas, and adapt and use the features, tips, and examples to overcome challenges you may face when implementing Kanban. Pick up this book and experience the full results of this vital Agile methodology-fast.
Who this book is written for
If you want to simplify your processes, improve collaboration, and manage projects successfully, this guide to Kanban is an essential companion. Continue reading
My amateur research has given me the insight that the three most important things for greater effectiveness and good quality are knowledge, knowledge and knowledge. Knowledge is best acquired through a dialog but a dialog is only efficient if it includes someone with knowledge. Unfortunately, there are situations when such a person is not around.Continue reading
What is Agile, actually?
Have you ever asked yourself the question, ”what is Agile”? Ever been asked the question and found yourself looking for the easy answer? The true answer is of course that Agile is the Agile manifesto but do you know anybody who can recite the manifesto just out of his or her head? When asking what is Agle, it’s more likely you will get the answer that Agile is about being flexible or about high efficiency. Some will say Agile is about having a Scrum Master, daily stand-up meetings and notes on a white board. I think Agile is much more than that and in this post I will tell you the answer, the short answer, I have found after many years looking.
Is it important to know what Agile actually is? Yes, of course. If you don’t know, how can you know in which direction to change your way of working when you decide to go Agile. By the way, Agile is a direction how to improve your way of working, not a place or a fixed description of how to work.
To make Agile easy to understand I will borrow a symbol from Lean, the house
I guess you have heard about T-shaped people, that is, people with deep skills within one or a few areas combined with some knowledge in many areas.
Now it’s time to introduce U-shaped teams. That is, teams that are balanced and where teammates are helping each other. It’s a team where you might have a bad day and are allowed to fail without causing consequences. It’s where the teammates help you get back to normal and what’s more make you feel comfortably included in the team. Your team becomes your safety net and it’s the place where you can dare to be vulnerable. U-shaped teams are also good for productivity since safety means productivity. *
A couple of months have passed since I wrote the post “Responsibility the Agile way” and I have refined it since then. Here is the new and more slim version:
1) I promise to look for improvements, both opportunities and problems.
2) I promise to participate in implementing the improvements. I will at least communicate the improvement possibilities I have found.
I am a teacher of Agile methodologies which means that I teach collective responsibility. I often get the response that ”everybody’s responsibility is no one’s responsibility”. To make everyone really take responsibility we need to define what we mean with responsibility the Agile way. Here is at least my version:
We are all responsible for contributing with our intelligence and senses for the best of the product and the process. We are also responsible doing what we have said we will do and being transparent with our progress.
If you think that is too fluffy, here comes more details about what I think Agile responsibility means:
While reading a blog post by my Crisp colleague Anders Laestadius I remembered a meeting type I tried a few years ago. We called it “Pomodoro meeting” since it was timeboxed to 25 minutes, just as the time management technique Pomodoro.
This is how it was conducted:
Do you do Scrum? I would guess that 90% of Swedish programmers would answer yes.
Do you have retrospectives? Again most developers’ answer is, yes.
Will you empty the impediment backlog before the next retrospective? Silence.
This post is for those of you who remain silent after the last question.
Kanban kick-start has been updated. What’s new? Not much but I met David J Anderson and after that meeting I felt I wanted to make some changes to be more compliant with the content of his course “Kanban for Managers”. Please enjoy. http://www.crisp.se/wp-content/uploads/2012/07/Kanban-kick-start-v2.pdf If you like to have a version with the changes visualized, please letContinue reading