The online whiteboard of Kristofer Palmvik
What will happen when we blindly apply Big Agile + premature AI tooling to core health services and patient data? Financial services? Social media and the spread of misinformation? Government infrastructure? Military infrastructure? It’s 2025 and software engineering is the backbone of pretty much everything. But for all its prevalence and influence, most people don’t have the technical literacy to even grasp the basics.
In this episode of the Distributed podcast, host Jack Hannah chats with Tim Ottinger, aka the Agile Otter, about how to manage and organize the work. Among other things, Tim is a Senior Consultant at Industrial Logic, contributor to the book Clean Code, and active presence online. Jack and Tim explore various ways to work in teams instead of solo and the various benefits they offer.
As Agile consulting sunsets, many are naturally shifting focus toward “Product” as the next growth area. While the language is evolving, the underlying tactics often stays the same.
The main takeaway is this: be ready for change. I don't know exactly how things will change (this article is just some of my guesses), but I'm pretty confident that Agile in the Age of AI looks different from before. So take a step back, look carefully at how you work today, and start questioning everything.
These are the three most common signs I see that strip team decision ownership: Teams get solutions to build, not problems to solve. Smart, centralized groups decide, teams follow the recipe. Effort and dates are set for the team upfront at the moment of highest uncertainty.
Measuring team morale puts a focus on the task at hand, and how the team feels about it’s capabilities to deal with it.
The most common characteristic I see behind truly productive tech work is that the people involved prioritize building the right product above everything else. They build it in small cycles and validate it, which follows the agile philosophy, but they don’t limit themselves to a strict agile recipe.
You can execute agile processes perfectly by the book and still have a product that sucks. Don’t think that being agile is going to give you answers, because not even internally you will have agreement on what it means. The goal is not to ship something into production. The goal is to build something that allows us to test our hypothesis. The best way forward may be to not ship anything at all.
In our work with agile teams and organizations, we’ve seen that teams follow a typical progression in their understanding of agile approaches and the benefits their organization receives. We’ve grouped this progression into four zones of fluency.
Fluid teams organize themselves based on the work at hand. Every time new topics need to be addressed, the people of the fluid teams organize themselves to optimize the chances to succeed with their challenges.
Using our exclusive Maturity Framework, you can become a DevOps organization in less than 6 months with no disruption to your organizational structure and minimal training investment.
We value all of these things, and strive to balance or combine them for each situation.
The fastest growing pathology I see, especially outside the US, is people confusing a product owner (the role on an Agile delivery team) with a product manager (one of the three critical competencies on a true product team).
A foundation of organizational stability is what provides people with a sense of confidence, security, and optimism during times of disruptive change in the workplace, which, in turn, allows them to keep calm, act rationally, and adapt effectively as the situation evolves.
When you take this humble approach — instead of "installing" a bunch of artifacts, tools, roles, and rituals AKA doing Agile — I think you’re embracing the true spirit of Agile.
Running a Working Agreement workshop as early as possible is crucial for setting the team up for success.
If you are treating your user stories as miniature specification documents, stop. Start instead thinking about each as a promise to have a conversation.
We regularly work with teams that see the daily scrum as irrelevant, disruptive, and boring. They are often right.
An "agile" team isn’t going to get very far if management doesn’t protect their time. And if they don’t have flexibility to change requirements as they learn, late nights and late delivery are guaranteed.
The iterative cycle of behavior modification is that you can NOT change a belief system, until you first have some positive behavioral evidence, which only happens after you create a safe and stable operational environment.
Forget about Agile and Scrum on the team level. Start with the org. Visualize the work as it is really happening ... with all the gnarly dependencies. Have 150 person stand ups if that is the true size of the team.
How can we as a team complete the most important user story before the next meeting?
If your software developers are able to accurately estimate how long something will take, you should fire them
We who wrote the Manifesto for Agile Software Development did our part – the arm now moves. We are not the people to write the next part.
How can you take the Agile Mindset serious where continuous improvement is important if you live in the society that is trapped in their past and do not improve because they believe it is already great?!
Agility is still like an accessory in the majority of Asian companies, people don’t really do it for the value behind it but for the sake of staying cool amongst the world.
An autonomous collective of courageous and fearless geeks gathered along in a freshly created duchy of perpetually hoarded meeting rooms, and joined forces into an unstoppable mob of programming, leaving behind everything, and starting completely fresh.
The requirements document is now called backlog and the requirements are called user stories. Then you think you are agile.
These teams say they’re Agile, but they’re just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It’s the reward, not the method.
But please, don’t go as far as having a Kanmaster, Kanban-host, The Khan (yes I have seen this role) or the Kanban lord.
I expect team performance to improve with agile methods. But if you really want high-performance you need to improve the entire system–and that is management work.
Often when stand ups resemble a status meeting each person is working on their own piece of work and as it is isolated from everyone else, they don’t really need to know what others are doing.
I’ve noticed that Agile is frequently creatively misinterpreted as: * "move fast and break things" or * "testing is the end user’s job" or * "what we were doing before, except with morning meetings where nobody is allowed to sit" I expect some of the backlash is, ironically, against that.
In a world of agile development and super-tablet-multi-magic-laptop-phones, the best layouts can’t be contained in a single framework or technique. CSS Libraries are a bloated mess of opinions about how to do your job. Why let the table-saw tell you where to put the kitchen?
the biggest sin of Agile consultants was to over-simplify the software development process and underestimate the real complexity of building software systems.
In the Web era of development, Waterfalls are finally out. Agile is in.
One of my great joys in software development is relishing the feeling of raw productivity. The competing and converse feeling, for me at least, is pain. It’s painful when I’m not productive and it’s pain that robs me of potential productivity, the so-called "good days at work." There are many sources of pain in software development, but none more obvious than a rigid and chaotic codebase. This psychological effect takes a toll on team morale which, in turn, causes productivity to lag.
What organizations need to learn is not how to follow some "agile recipe". Organizations need to learn how to learn. That is, how to come up with experiments and how to evaluate if those experiments improved things or not.
Agile @ Spotify – bakom kulisserna - Agila Sverige 2014 - Space 4 juni
If you’re into agile and lean this is of course not new, in fact you could say that it’s common sense to, but in fact the longer you wait the more work you create. Waiting creates extra work, if you like that better.
While the other browsers are heavily leveraging their auto-update capabilities by making frequent releases with new features, bug fixes and security patches, the IE team has yet to embrace an agile iterative strategy.
"If current approaches actually worked well, then by now, thousands of organizations would have reached a state of self-sustaining, "freestanding" agility. Clearly, that is not the case." Pondering the question, several possible reasons for this result (or lack of) occurred to me. These are speculative and based on my own experience and observations.
Now look at the consultants and vendors who say they’ll get you started with "Agile." Ask yourself where they are positioned on the left-right axis. My guess is that you’ll find them process and tool heavy, with many suggested work products (consultant-speak for documents to keep managers happy) and considerably more planning than the contents of a whiteboard and some sticky notes. If you see this too, then it’s more evidence of the corruption and devaluation of the word "agile."
How do we achieve success in the business context of programming? Agile is a good start. Small changes are good. Pair programming is a bit of a pipe dream for most organizations, but if you have gregarious developers who talk to one another, they will at least understand what is going on in each other’s development trees.
I die a little bit inside when people say "should we do Agile or not". The assumptions behind this question are all wrong
Planning your next retrospective? Get started with a random plan, tweak it, print it and share the URL. Or just browse around for new ideas!
I once observed what was probably the worst daily scrum ever. Just when I thought it was over, something interesting happened.
Are you in a software development team, trying to be agile? Next time the team gets together, ask: How do we feel about the quality of our code?
Bring the team back to one or two userstories to be worked upon. Teammembers might argue that they sometime cannot work on the same story. It is then a good idea to let them pair, test or write documentation. They have to work together to get the stories done and not just the tasks. Allowing everybody working on individual task is not effective and does not help the team and therefore the end product.
Face-to-face communication is the most effective means for sharing knowledge within a project team, and even teams separated by only an elevator ride or stair climb will have less face-to-face interaction. Get all of the project team in the same room if at all possible.
Scaling Agile Meetup 20130311
Scrumy is a project management tool loosely based off of Scrum.
You’ll hear about these myths most of the time on management level, but some of them can be found on the development level, too. IMHO it’s important to be aware of these myths to be prepared for possible discussions.
One of the most impressive examples I’ve seen so far is Spotify. I’ve had the pleasure of working with Spotify on and off ever since the company was founded, and it’s one of the few companies I’ve seen with a truly agile culture. Spotify has grown a lot lately and now has hundreds of developers divided into 30 agile teams spread over 4 cities in 3 timezones. So how is this managed?
Om några veckor avslutar jag min tjänst som utvecklingschef. Normalt sett brukar ju en avgående chef ersättas med en ny. Jag är emellertid inte så säker på att det är en bra idé, åtminstone inte med någon som förväntar sig att få bestämma över så mycket. Jag har nämligen, kan jag så här i efterhand se, delvis ägnat mig åt att dekonstruera den traditionella utvecklingschefsrollen – ett slags un-management i praktiken. Så vad finns det egentligen kvar att chefa över?
The Improvement Kata guides us in a very focused way from our Current Condition towards our vision. The path goes through a number of intermediate Target Conditions in an iterative manner. (via Agile LEGO – Toyota Kata an alternative to...
Our company is almost 6 years old now. It was founded on agile principles and grew up on them. We’ve used Extreme Programming from day 1, immixed some Scrum ideas later on and switched to Kanban in the end. Here below I’ve tried to review our process changes for the last 4 years.
Here is the simple way in which you can mount box.net as an additional network folder or drive in Windows XP ( I have not tested in any other environment but it should work )
Ten years ago, we tried to use UML diagrams and CASE tools to develop software. Ten years ago waterfall was all the rage. Ten years ago, we thought that ten years in the future we would have programs that would allow us to build software in the same way that CAD tools allow for building machine parts. Not only did it not happen. It went completely the other way. Now we are all talking about Agile. Now people don’t even remember what CASE tools are. Now we are building software without trying to define the whole system in UML diagrams.
Done and done! 1,5 years of hard work at National Land Survey is over. What a great project! This post will be on my personal findings about Scrum team transition to Kanban. What worked and what not? Moreover, I will try to analyze the failures we made and to come up with some solutions. Let’s get started!
One of the goals of a good UI is to not require the user to learn a new language. The UI should allow them to express themselves in terms they already understand, presenting them with easily recognisable concepts which map closely to their own mental models of the application domain. In the Agile Design workshop, pairs/threes work as a single team to establish a UI design for a community DVD library. I very deliberately ask them to design and implement the internal application logic first before considering the user interface. Many will tell you this is wrong, wrong, wrong, but I’m here to tell you that they are wrong, wrong, wrong and double-wrong.
Agile teams also tend to become insulated from each other (Kähkönen, 2004), and there is a chance that teams will start to reinvent tools and approaches as well as reject outside ideas. Communication and knowledge-sharing is especially important to avoid these problems. I will now describe four ways of facilitating inter-team knowledge-sharing.
Mattias Hällström såg modellerna för projektledning som fyrkantiga. Folk sa: "Man får det projekt man planerar." Han såg inte projekt som att man först planerar, sedan verkställer, utan som en ständig dialog. Han jämför med synen på system utveckling, där agil systemutveckling och Scrum vuxit fram som en reaktion på vattenfallsmetoden och andra arbetssätt där man strävar efter att planera allt i detalj innan man börjar skriva kod.
As I release more frequently, I start to focus on automating the actual process of deploying a release. One of the most powerful steps of automating deployment is to automatically upgrade the database schema.
A simple Windows XP tool which allows the user to browse to Mozilla.com and download Firefox, a web browser.
Hitler goes crazy when he learns his team has not been following the tenets of the agile manifesto.
Why do people complaining that they can’t do agile development with 50 crap developers not see that the problem is in the second part of that statement, not the first?
Tänk tanken att hela skolväsendet jobbar efter en scrum eller agile variant i framtiden samt utnyttjar alla medier...
One of the teams I have recently coached quickly got a grasp of how to phrase user stories but found it hard to relate to the concept of acceptance criteria. I wrote this short FAQ as an attempt to make it easier for my team to work with acceptance criteria and hope that other teams might find this useful too:
Scrum, when done well, is a responsible way to develop software and if positioned maturly is a benefit to management. With permission from Jeff, here is the ScrumBut test. Take the test, add up your scores and divide the result by 9.
Managing Risk on Agile Projects with the Risk Burndown Chart Risk management is a central part of traditional project management and is included as one of the knowledge areas in the Project Management Institute’s (PMI) body of knowledge. In many of my classes, participants ask how Scrum and agile address risk management. Some are concerned that agile or Scrum ignore risk management completely. Let’s see why this is the case.
Utan ordentliga tester blir mjukvaran sämre och projekten dyrare. Men den starka trenden med korta utvecklingsfaser ökar kraven. "Scrum föder behovet av en ny typ av testare", säger Petter Salomonsson, vd på konsultföretaget Addq.
– Det går bra för många företag i början när de kör Scrum. Men när metoden sprider sig till hela företaget visar det sig att den inte passar överallt, säger Henrik Kniberg, konsult och agileexpert på Crisp.
This can shed a new light at why e.g. sprint planning meetings and retrospectives in SCRUM might be counter-productive if the group is not properly "tuned up"
Neo4j is a graph database. It is an embedded, disk-based, fully transactional Java persistence engine that stores data structured in graphs rather than in tables. A graph (mathematical lingo for a network) is a flexible data structure that allows a more agile and rapid style of development.
Mingle, the Agile project management and team collaboration tool, provides a shared workspace for your entire team. It adapts to the way agile project teams think and work, while supporting various flavours of Agile like XP, Scrum, Agile Hybrid.
Banana Scrum is a web based, online tool for teams practicing agile development, primarly Scrum. It was developed as a result of Codesprinters team’s experience in creating high quality web applications . It is meant to replace project walls, index cards and other paraphernalia of the paper age long gone.
There’s a lot of buzz on Kanban right now in the agile software development community. Since Scrum has become quite mainstream now, a common question is "so what is Kanban, and how does it compare to Scrum?" Where do they complement each other? Are there any potential conflicts?
"På en utvecklarkonferens i Göteborg förra veckan talade Kent Beck om att i USA börjar agil utveckling redan bli gammalt. Programmerare är trötta på de dagliga mötena där de måste vara sociala. De vill koda - inte prata. Detta sagt av pappan till XP och den som triggade igång hela agilrörelsen - en fantastisk prestation som har min största respekt." Den fantastiske Ivar Jacobson är igång igen...
Vi utvecklare följer hela tiden det senaste modet. För några år sedan sprang vi efter Rup, nu springer vi efter Scrum och snart blir det något annat. Vi kastar ut det vi lärt oss och börjar om från början med det vi tycker är nytt och sexigt.
Här kan man jämföra och betygsätta agila verktyg för backlog management och sånt.
Scrumy is a project management tool loosely based off of Scrum. We were attempting to use Scrum to manage our projects, but the generic post-its we bought kept falling off the wall. We looked for online solutions to scrum, but all of them were too complicated and expensive. All we really wanted was an online version of our wall post-its. So we made one.
I en artikel i Computer Sweden den 3 feb står det "siffror visar att nio av tio Scrumprojekt misslyckas". Men de angivna siffrorna handlar i själva verket om något helt annat - att 9 av 10 personer som säger att de kör Scrum inte implementerar Scrum fullt ut. Detta säger ingenting om huruvida själva projektet lyckades eller inte (eftersom Scrum inte är ett självandamål). Denna typ av sensationsjournalistik gynnar ingen - utom möjligen tidningen som vill öka sina tittarsiffror, men på bekostnad av trovärdighet.
Ett amerikanskt konsultbolag har tagit fram en rekryteringsmetod för att hitta utvecklare som verkligen vill och kan jobba enligt Agile-principerna. Något för Sverige?
Tar du hänsyn till dessa råd är det mindre sannolikt att Scrumprojektet blir ett misslyckande.
Lättrörlig utveckling har lanserats som en mirakelmedicin, men siffror visar att nio av tio Scrumprojekt misslyckas - något många förespråkare gärna tystar ner.
But what has daily home life with Agile to do? A lot I would say but this time I will concentrate on the technical debt or debt in general and having releasable as part of definition of done. Let’s say you choose the easy way out all the time. When your child wants food you cook and when your child likes to play you leave everything to go playing. What you leave behind is dishes and a messy home. The next time it’s time to cook it will take longer time since you first need to dish some pots and you have less free space left to use while cooking (because of the dirty pots).
We are developing an online Scrum tool called Scrum’d that will go into private beta within a month or so. We are looking for active Scrum practitioners to provide feedback during our beta.
Varje morgon kl 09:00 samlas Sveriges alla (nåja majoriteten känns det som i alla fall) systemutvecklare i små grupper om 5 - 15 pers, berättar vad de gjort den senaste dagen och vad de tänker göra idag. Nej, det är inte improviserade AA-möten som utspelar sig på landets alla IT-arbetsplatser. Det är såklart Scrum.
I often hear from Scrum teams they don’t understand why estimating in story points are better than estimating in ideal man days. Here comes three reasons.
"Agile - konsten att slutföra projekt" av Tomas Gustavsson på TUK Kompetensutveckling har utsetts till Årets Projektledarbok av Svenskt Projektforum som är det största projektledarnätverket i Sverige.
"Om du är intresserad av systemutveckling har du säkert sett att det debatteras flitigt om olika utvecklingsmetoder, som till exempel Scrum. Eller metoder förresten, ska det inte heta processer?" Det här har vi brottats lite med i vårt exjobb: Vad är Scrum egentligen? Method, methodology, praxis, framework, process...