– Having rules for communication is stupid!
– What was your intention with calling the rules stupid?
– Well, I’m sorry, I didn’t mean anything negative towards you, of course. I just don’t find such rules necessary at all. We have been communicating with each other since we were small.
– Okay, I understand what you are saying. But, hear me out…
There will always be a productivity dip for the team when a new member joins. The question is not if it is going to happen, but how much will productivity dip and for how long. Imagine if you could onboard new team members with a minimum of productivity loss.
A common pitfall for large and medium size organizations who are adopting Agile is to organize teams based on software component boundaries instead of feature teams. Some of the aspects of long term code ownership are more straightforward this way, but the negative consequences in terms of business agility and costs of coordination are huge. A few years back I designed a simulation exercise that I call Team Shapes which illustrates some of the issues and now I would like to share this simulation with the community.Continue reading
In my team, we are working on improving real-time performance for our main service. The goal is to have response times below 100 ms in the 95th percentile and below 200 ms in the 99th percentile for certain database volumes and request frequencies.
We don’t know what will be needed to reach this goal. We have some ideas, but we don’t know which one, or which ones will do the trick. We call these ideas “experiments”.
We can estimate each experiment, but we don’t know how many we will need to do to reach the goal.
This is the story of how we apply the scientific method to working with performance improvements.
In my experience, when it comes to programming productivity, mob programming beats the rest. Of course the definition of productivity in this context is debatable and these are just my observations. Thus, it is not a proper scientific study but bear with me anyway.
I wish to compare one aspect of productivity, how we work together. I look at single programming, pull requests, pair programming and mob programming.
Here is my slide (yes, it’s just one slide) from my keynote at AgileByExample in Warsaw. And a video of the talk. Scroll down for a written summary.
We have translated our blog on team size and proximity to english. If you prefer to read it in Swedish it’s called Storlek och närhet har betydelse. The english version you’ll find at Nomad8 site, because Jimmy Janlén is currently in New Zealand. 🙂
Continue reading
Process är dyrt. Större team, distansarbete, deltidsarbete samt många specialister leder till mer uppstyrd process. Kanske är detta självklart, men ju fler företag vi lär känna, desto mer upplever vi detta vara något som ignoreras.
Jobbar vi i någon form av agil process såsom Scrum, Kanban, eller Lean UX värderar vi högt samarbetet mellan olika kompetenser. Ett team av olika kompetenser som kan ta en idé från start till mål brukar kallas tvärfunktionellt.
Enklast möjliga agila process för hur dessa personer kan samarbeta ser ut så här:
Continue reading
Help your team improve by visualizing their way working with the fluent@agile game. With the game you can help a team find out where it is on its agile journey and help it find new ways of both fine tuning and make leaps in their daily agile practices.
Me and Christian Vikström made the game together at Spotify during the spring 2014 when we were coaching and helping team to improve their agile skill sets and processes.
At Spotify the teams owns their own way of working. A team is basically only accountable to itself. We therefore needed an coaching tool that could help team take ownership of their self image and improvement strategy.
We also wanted the tool to be opinionated. It should be normative, tell what’s good and not, what kind of practices and behaviour that’s expected and not. But at the same time it should be open to new ideas, new practices and the teams local conditions.
Having trouble with curled Post-its that won’t stick to the wall? Well, it could be due to bad glue or that you peel them off wrong. I would guess it’s the latter. Might feel like a silly blog post to write, but I found myself teaching people the technique of peeling Post-its quite frequently. It’s
Continue reading
A decade of agile boils down to theses simple fundamentals and steps for me. A. Ask: do you need to improve as an organization? Only go forward if your sincere answer is yes. Ask everyone: Do you want to improve? Same procedure. Make sure you will fail (and win) regularly by commitment (plan/hypotheses) and checkpoints.
Continue reading
A while ago I was asked to help out create a checklist for a team, a checklist that could tell something about whether or not a user story was “good enough”. I opened PowerPoint and starting to ponder over how I could help. I immediately realized that a presentation would be boring, shown once and then forgotten, and not invite to curiosity. I put my laptop away and created a cube instead.
A couple of days later I showed it to a friend and colleague (Viktor Sessan, Agile Coach at Spotify), who were also very intrigued by the concept, and we started to talk about how to take this further.
This is the result 🙂 We believe that if you let an idea loose, and it is a good idea, great things will happen.
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?
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.
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.
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.
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: