In this episode of our YouTube channel Crisp Agile Academy I talk about Sprint Burndowns. I discuss the value of having one and that it is a tool for the team, not anyone else. I also give examples of different kind of burndowns: Remaining Hours, Remaining Story Points, Remaining Tasks, Things in progress, and Confidence level. I wrap up the episode with a little quiz.
Det är inte bara din ScrumMaster som behöver förstå vad “agile” är!
Återigen har ni diskussionen om “working software over comprehensive documentation” verkligen betyder att man inte behöver dokumentera någonting alls. Eller diskussionen om det är ok att förlänga sprinten med några dagar för att hinna klart den sista fixen på den där storyn. Eller diskussionen om vad det egentligen innebär att vara “lean”. Känner du igen dig? Kan det vara så att alla har nytta av att ha samma grundförståelse av centrala begrepp i och runt “agile”? Läs vidare för ett enkelt sätt att skaffa den kunskapen!Continue reading
The Future of Software Development
What will software development be like in the future? “Agile” as we know it, will not be around, nor will test-driven development, continuous delivery, or BDD-like methodologies. I’ve been pondering this for a while, and based on some observations and a dose of wishful thinking, I’ve arrived at the conclusion above. Do you agree?
What questions does your Working Agreement answer?
All teams have some sense of what is regarded as acceptable or good behavior within the team. Most people know that colleagues don’t appreciate it when you’re late. Perhaps you have a silent agreement regarding how you vote and make decisions. Some teams write down their behavior and collaborative “protocol” in a Working Agreement.
You might think that common sense covers it and writing it down seems silly, but surprise – common sense is subjective and you will have different opinions about things. Great! Let’s discuss and find our common ground.
The act of discussing it and writing it down is also a strong team building activity and forges relationships between team members. Any new team, or any team for that matter, could benefit greatly from a one-hour workshop. It could be part of a retrospective or a stand-alone meeting.
Team LiftOff with Market of Skills and Competence Matrix
Introduction
I got into agile development during the late 90s when I read Kent Beck’s book about extreme programming (XP). It was mostly the technical aspects of XP that attracted me; I liked test driven development and continuous integration and I understood the benefit of continuously reviewing the code by doing pair programming. It took some time for me to turn my attention to what I mainly focus on today, and what I see is a cornerstone of agile, teamwork. Product development is in most cases a complex endeavor where you need a high level of collaboration and teamwork to reach required outcome. To succeed you have to make sure the participants build on each others strength and knowledge, and where they see differences as something valuable and important. But it is not certain that all working groups ends up as a true team. As a team coach you need to pay attention to building the team at the beginning. This post will describe a few tools that I have used in order to form teams.
Agile Product Ownership in a nutshell
This is basically a 1 day product ownership course compressed into a 15 minute animated presentation.
Over a million views! Some call it “The best 15 minutes on the Internet” 🙂
There’s obviously more to product ownership than this, so see this is a high level summary.
- Here’s the complete drawing (.png format)
- Here’s a downloadable version of the video, in case you don’t want to stream (.mov format, 90 Mb)
Special thanks to Alistair Cockburn, Tom & Mary Poppendieck, Jeff Patton, Ron Jeffries, Jeff Sutherland, and Michael Dubakov for providing many of the models, metaphors, and ideas that I use in this presentation.
Translations: (see also the translation guide by Cédric Chevalerias)
- Chinese – simplified (subtitles)
- Chinese – traditional (subtitles)
- French(subtitles)
- French (voice)
- German (subtitles)
- German(voice)
- Italian (voice)
- Japanese (subtitles)
- Polish (voice)
- Portuguese – Portugal (voice)
- Portuguese – Brazil (voice)
- Russian (voice)
- Spanish (subtitles)
Below is a full transcript in english. But I recommend watching the video instead of reading the transcript. The video is 100% visual, the transcript is 0% visual…
Five team principles
Building a well-functioning software delivery team is complicated. There are many factors to consider. Current team (if any), needed skills, available people, company politics etc.
There are some fundamentals that often (but not always) seem to work.
My fundamental principles for teams
- Static
- Cross-functional
- 5-9 people
- Co-located
- Dedicated team members (belong to only one team)
I find these principles to be a useful basis for discussion, when helping managers configure their teams.
The principles are goals, and one must realize that all cannot be achieved all of the time, nor instantly.
Programmerarna visar vägen
Lite i skymundan pågår något av en revolution inifrån i IT-branschen, och då särskilt i företag med många programmerare. På gräsrotskonferenser, i nätfora och i management-litteratur äger vår tids kanske mest avancerade och levande diskussion om hur man bäst organiserar arbete rum. Om det skriver jag i en längre essä om hur programmerarna visar vägen
Continue readingLean from the Trenches keynote @ AgileEE, Kiev
Here are the slides for my keynote “Lean from the Trenches” at Agile Eastern Europe, Kiev. And here is the book/ebook, in case you want more details. Thanks for attending!
Continue readingR3 – den agila formeln
För ett halvt decennium sedan när jag skulle börja som utvecklingschef på Polopoly kände jag att jag behövde ett verktyg som hjälpte mig att sammanfatta andemeningen och de praktiska konsekvenserna av Agile, Scrum, XP och Lean. Var och en av dessa innehåller en rad – i viss mån överlappande – begrep, som är tydliga och om man kan dem inte så svåra att förklara – om man har många timmar på sig. Men hur minns man hela denna komplexa väv? Hur kan man uttrycka den enkelt, snabbt och koncist?
Responsibility the Agile way
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:
Remote seminar – result of first experiment
I was invited by Agilenetið to come to Iceland and do a talk. That didn’t fit my travel schedule, so we instead decided to do an experimental “remote seminar”. That is, with me on a video link instead of physically in Iceland. I’ve done webinars before, and usually miss the interactivity. I wanted it to “feel” like I was there, discussing and interacting with the participants.
Here’s what we learned:
Improve the improvement process
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.
Case Study of Mobile Team at Projectplace
I am currently working as a Scrum Master for multiple teams at Projectplace in Stockholm, Sweden. One of those teams is the Mobile Team. They are developing Action Boards for both iOS (iPad) and Android platforms. These Action Boards are also available in the Customer Preview of the Projectplace web service. Both Web Team and Mobile Team share the same API’s. The iPad app is planned to be released in 2-3 Sprints from now.
This case study can be written from many perspectives, but in this article I am going to focus on how we are working with the challenges of having a distributed Scrum team.
Lean from the Trenches – Managing Large-Scale Projects with Kanban
I’ve published another book! This one’s called “Lean from the Trenches“. It is about how we scaled a 60-person project by combing techniques from Kanban, Scrum, and XP. I chose this title because it really it illustrates how to put Lean principles into practice in a software project, especially the notion of an end-to-end Kanban
Continue readingImproving the Daily Scrum
Doing the same thing every day for a long time can get boring. You might even forget why you started doing it in the first place; you just keep doing the same thing, and don’t reflect on what you are getting out of it. The scrum meeting at my current client had gotten into this rut, it had devolved into a status meeting. The participants routinely answered the three questions; what I did yesterday, what I’m going to do today and what impediments I have, but they didn’t really tell each other much about what they had actually done, or what they were planning to do today. They almost never reported any impediments either.
This team has been using Scrum for almost two years. It is a very well working team from a technical perspective; they produced an even amount of user stories each sprint with a high level of quality. But they had lost the energy in the scrum implementation. They felt that they could do more; that they could perform even better if they just could just somehow improve their scrum implementation.
We started working on the daily scrum meeting. Our goal was to use the meeting to give the team a good start to the day with energy and desire to start working on the tasks discussed during the meeting. In order to do this we made a few changes, both large and small in how we perform the meeting.
- The structure of the scrum board
- The process of how we perform the scrum meeting
- The location of the scrum board and the meeting
- The metric that we uses to monitor how we are improving the meeting
Teaching the first CSM course in Iran – and getting lost in the mountains
In April Reza and I traveled to Teheran to teach the first CSM course in Iran. It was my first time in Iran, we had a great time! We had 30 participants in the class and they were absolutely amazing! They spent at least 30 minutes after class discussing, taking pictures, and joking around.
Tokyo Scrum Gathering keynote: Everybody wants Change, but nobody likes to Be Changed
Here are the slides for my Tokyo Scrum Gathering keynote “Everybody wants Change, but nobody likes to be changed“. Thanks for attending! Sample slides:
Continue readingProperties of a good daily stand-up
I had a conversation with some of my colleagues about what makes a good daily stand-up, here are some properties: Time-boxed (15 minutes) Everyone is engaged Synchronization is taking place Attention to problems People ask for help The conversation is about stuff that matters to most people, individual issues are postponed Anyone can lead the
Continue readingScaling Scrum in the Enterprise with Kanban
I have had the pleasure to hold a lightning talk for the Agila Sverige conference in Stockholm about “Scaling Scrum in the Enterprise with Kanban”.The talk went well but the format (10 minutes) made it more like an elevator pitch. You can find an enhanced – somewhat longer – version of the slides used during
Continue readingWhat to do when Scrum doesn’t work
Here are the slides from my keynote at the Scrum Gathering in Cape Town. What to do when Scrum doesn’t work – PDF What to do when Scrum doesn’t work – Powerpoint What to do when Scrum doesn’t work – Article Positive atmosphere and lots of laughs, really enjoyed the audience! The whole topic felt
Continue readingScaling Scrum in the Enterprise with Kanban
Working at different clients, I often see the need to have many Scrum teams working together towards a common goal – be it a large project or initiative.The issue with having many Scrum teams quickly becomes a question of how do you keep the coherence – the actual control over the project. So many issues,
Continue reading