Professional coaching is one of the four stances of an Agile Coach, and the reason for the word “Coach” in Agile Coach. But yet we see so many misconceptions of what professional coaching is and when to use it. I was recently involved in a couple of discussions about this on LinkedIn, and was surprised that apparently many Agile Coaches still don’t really know what professional coaching is. Here’s why it matters to an Agile Coach.Continue reading
Individuals and interactions or processes and tools?
As the developer cheerfully runs over to work with Sue in the deployment team, with an extra cup of coffee, he is stopped by Charlie, the manager of the deployment team.
-Hey, where are you going?
-To see Sue about the deployment, the developer answered.
-Have you written a ticket?
-What? No, I’m gonna talk to Sue and we’ll do the deployment together as usual.
-Sorry, Charlie said, we have implemented a ticketing system last week, and you need a ticket. We can’t have developers running all over the place disturbing our team all the time!
True story.Continue reading
If the acronym VUCA hasn’t made sense so far, then in these pandemic Covid-19 times it surely must. The acronym stands for Volatile, Uncertain, Complex and Ambiguous. So when people refer to a VUCA world, they refer to a world where you cannot possibly foresee everything ahead of time (if anything, really). This is true to the whole world – the planet Earth, but also to the world, or context if you like, in which you and your organization operate.Continue reading
The Agile Manifesto has been around since 2001, and agile ways of working have existed long before that. So what is this thing called Modern Agile? Is the manifesto outdated and needs to be replaced? All good questions, but let’s start with taking a look on what Modern Agile is.
In 2014 Gartner introduced bimodal IT. Since then quite a lot has been written and said about it. And just recently it popped up at two different clients almost simultaneously. After reading articles, watching webinars and listening to what people say about it, I’m a bit worried that organizations think Bimodal IT is the goal. I don’t think so, and I’ll explain why.
For more than a year now, I’ve been working with clients that have agile scaling problems. But not the kind of scaling problem everybody is talking about – one product and lots of teams. No, I’ve been busy trying to sort out what to do when you have one team supporting a multitude of products with different architectures, stakeholders, technology stacks and whatnot. This is what I’ve learnt, so far.
Otroligt kul att se hur många som fick plats i ett konceptrum i Aula Magna under våra presentationer under SAST Q20! Vi pratade först om kontinuerlig förbättring och sedan om working agreements. Slides hittar du nedan. Kontinuerlig förbättring Working Agreements På Crisp har vi en hel del gratis material och guider, bland annat en ToyotaContinue reading
Låt oss säga det direkt: att kombinera pm³ och någon agil metod, som t ex Scrum, är en dålig idé. Varför?
Därför att du kommer inte kunna dra nytta av det agila arbetssättet. pm³ är baserat på en helt annan världsbild. pm³ bygger på årsplaner och att verksamheten beställer från en leverantör, typiskt den egna IT-avdelningen. Agilt har som en grundläggande värdering att reagera på förändringar i stället för att följa en plan. Det agila arbetssättet drivs proaktivt genom utforskande i motsats till att vara en mottagare av beställningar.
Vi har sett flera försök att implementera pm³ och de har ofta misslyckats på grund av att pm³ bygger på tankar om att verkligheten kan förutsägas 18 månader i förväg, att användarna vet vad de vill ha och att det är viktigt att ha en skarp linje mellan verksamhet och IT. Vi hävdar (och flera med oss törs vi lova) att inget av detta är varken sant eller bra.
Traditionally IT-systems and products are developed in a project. Once developed, it is deployed and handed off to the maintenance organisation. But the new companies that start out with an agile way of working does not have these maintenance organisations. How do they do it? Is there no Maintenance in Agile?
One of the most common questions we get is whether to estimate in time or points. It seems like points are used only “to avoid thinking about time” and they are essentially the same. Wrong.
Let us give you the travel metaphor to give you an idea about how we are thinking.
Å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
Last friday, I had the day off. Again.
This was just one of several days that I have had off, not counting weekends and vacations. So am I just a slacker that don’t work 5 five days a week? No, on the contrary! This makes me a better programmer. How? Read on.
The other day I read a blog by Uncle Bob. It more or less stated that no matter what situation you are in, writing automated tests will make you go faster. Ok, this is old news I thought, until I checked Uncle Bob’s tweets. A fair amount of people argued against this statement, and that surprised me!
So I started thinking about why there still are fellow software developers that doesn’t believe in automated testing? Have they not seen them in action and understood what they are for? Please, gather around the campfire, and I will tell you one, just one, of my war stories, and then I will tell you why also you should write automated tests!
You know, every system has a software architecture and a software design. Whether you think about your system’s architecture or not, it will have one. Here is an example of two methods in a class I recently saw. It is not architecture, it is good old OOD, but it exemplifies what can happen if youContinue reading
I am first and foremost an agile guy. I try to be as agile as possible at my assignments, and I coach and teach agile ways. But I know that there still are several companies that use RUP, and this is written for them.
As I argued in my previous blog post, you can do RUP and be agile. In this blog post, I will give you my top 3 RUP anti-patterns that I have experienced at various projects, and often enough the solution to them is to work in a more iterative way as the creators of RUP intended (more agile if you like). If you want to know what you can do about them, read on. If you can top them, please share your experiences with me 🙂
Having mentioned the acronym “RUP” at Crisp a couple of times, I am starting to get a better understanding of how Harry Potter felt when he mentioned the name “Voldemort” (if you don’t know who Harry Potter is, just borrow the book from the nearest 13-year old and read it). What is it about RUP that has made agilistas scream in terror whenever mentioned? Is RUP a hideous beast that no one can work with, or is it actually a trainable pet that can be useful when treated right?
This is actually a true story that I am about to tell you. I heard it from a friend talking about his childhood a couple of weeks ago. When I listened to him, I could immediately compare it to many of the software projects I have seen.