from the Crisp Consultants
The www.crisp.se website is based on WordPress, with a custom Crisp theme.
This is the story about how we’ve developed our custom WordPress theme, how we’ve made it easy for any Crisper and external consultants to work on the theme, how we’ve setup version control, continuous delivery, staging and production environments on Amazon Web Services (AWS). And how all of this is setup with absolutely no automated tests whatsoever.
Elephants are not giraffes and user stories are not requirements. They share some traits and you may find them in the same context, but that does not make them the same. Despite that, many believe that user stories are the new requirements because there has to be requirements for a project, right? I give that a double “no”, they are not requirements and that is not anything we really need. User stories are about being able to explore options and seize opportunities. Requirements are about deciding up front and sticking with that.
Daniel and Martin have been in the same team since the beginning of summer and they’ve been collaborating in an unconventional way. Yassal interviews them to understand what’s been going on.
You’ve been successfully using mob programming with your team at Expressen for the past 6 months. How did you get started?
Daniel: The project started without any tech solutions in mind. We decided as a team that mob programming was a good way to figure out what tech stack to use. We had no backlog, but we sort of knew what we needed to do
Martin: I remember proposing this as the best way to do discovery work from a tech perspective. We didn’t know what language or tech platform we were aiming for, and this way we would learn more quickly as a team and could come to a decision.
So, what is mob programming anyway?
Daniel: I don’t really care about the formal definition, to me it’s group programming rather than pair programming. One person is at the keyboard and the others act as support, coming up with suggestions, or researching potential solutions. This helps the whole team stay on the same page, and makes sure that we’re all learning at the same pace.
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
I recently recorded a webinar where I walk through 5 ways to find slack (to invest in critical improvements), when a team is under high pressure. Enjoy! http://leankit.com/blog/2015/11/real-world-kanban/
Continue reading
Hej kära läsare! Mitt namn är Martin och jag är en “process-aholic”. Jag har sett processer (eller avsaknaden av dem) överallt sedan jag var barn. Jag har sett en del människor som gör saker på “fel” sätt och en del människor som gör saker på “rätt” sätt. På universitetet lärde jag mig dock att inte ens när det kommer till processer är livet svart eller vitt, men jag förstod aldrig hur jag skulle kunna särskilja en “bättre” processen från en “sämre”. 11 år senare när jag fann Scrum blev jag glad över att hitta en process med inbyggd processförbättring. Jag kunde äntligen experimentera och sedan utvärdera om det hela blev bättre eller sämre. När jag insåg att de flesta team körde Scrum utan denna del, bestämde jag mig för att försöka lära världen ämnet kontinuerlig förbättring. Detta är ett sådant försök, men det var nog uppenbart…
Vad jag har saknat när jag predikat om tillbakablickar/retrospektiv är tydliga och konsekventa mål. Att nyttja de fantastiska grundvärden som agila metoder vilar på, såsom Extreme Programmings kommunikation, återkoppling, enkelhet och mod (inklusive respekt från version 2) och Scrums öppenhet, engagemang, fokus, etc, har hjälpt mig att sikta bättre på kort sikt. Men det var inte förrän jag lärde mig om två specifika (och överlappande) mognadsmodeller, en via Torbjörn Gyllebring och en via min kollega Fredrik Lingren (tack så mycket till er båda!) som jag förstod hur jag skulle kunna tillämpa en mer fokuserad strategi för ständiga förbättringar. Detta är min strategi:
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.
I’m happy to announce that Toolbox for the Agile Coach – Visualization Examples is now available on LeanPub! It’s a 124 page book cramped with visualization examples for teams on how to improve collaboration and communication, as well as shaping behaviours.
It’s been great fun to write. It’s been great fun to get feedback from early readers. It’s been great fun to show it to colleagues and friends. And now, finally, it feels awesome to be able to share it with you!
I planned to release the book in physical and digital form at the same time… but getting it printed have sadly taken forever, and I still don’t know when it will be available on Amazon.
So, I’ve decided to go ahead and release the digital version first. Might be a stupid thing to do from a marketing perspective, but I don’t care about that. I want the book out and available 🙂
Hi! Here’s the video me and Eik’s presentation – “Learnings from SAFe @LEGO” (presentation at LKCE – Lean Kanban Central Europe, Nov 2015). Best quote: “..this looks exacly like what my 6 year son does in kindergarden” 🙂 Cheers Mattias
Continue reading
We have just released our short comic as a poster, free to download and print! Jennie Discovers is a comic that tells a story about working Agile and Lean. It’s a story of product discovery, the journey from first idea to continuously releasing and updating a product or service. This book is written for product
Continue reading
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.
The Pirate Ship is a workshop format that will help you grow amazing teams. It is “speed boat” on steroids. I have now been using it for a couple of years, and the time have come to share this useful and productive format.
I do a lot of workshops with teams. Very often the workshops are about the teams themselves. It can be anything from getting a newly started team up and running to helping a mature and stable team find new inspiration and challenges.
Here are the slides from my keynote “Real-life agile scaling” at Agile Tour Bangkok. Enjoyed hanging out with everyone!
Key points:
Here is an InfoQ article with a nice summary of the keynote.
Sample slides:
Just back from Lean Kanban Central Europe 2015. A great conference that keeps pushing the limits. At the conference I gave a talk together with Eik aka “Captain Agile” from LEGO. We walked through how they introduced SAFe, how they involved other departments and most important, how they experimented their way forward. (Me and Henrik iterated as coaches
Continue reading
InfoQ has just released an interview regarding my latest book Real World Kanban. In this we walk through the reasons behind writing the book plus why Kanban needs to be matched by long term thinking to improve over time (aka behaviours like “don’t pass bad quality forward” matters) Check it out: http://www.infoq.com/articles/book-review-real-world-kanban ps: For anyone interested in the book, I have
Continue reading
(translations: Russian, Turkish)
Agile product development has become the norm in many industries (especially software). That means products are developed by small, self-organizing, cross-functional teams, and delivered in small increments and continuously improved based on real customer feedback. Pretty much as described in the Agile Manifesto – but replace the word “software” with “product” (because it really isn’t software-specific).
That’s all fine and dandy. However when things get bigger, with dozens of teams collaborating over organizational boundaries, things obviously get more complex and painful. Even if the entire organization is neatly organized into scrum teams, you can still end up with an unaligned mess! Here’s a picture that might feel familiar:
(translations: Turkish)
I wrote this article because of two observations:
I don’t claim to have “the answer”, but I’ve thought about this a lot and also experimented on my clients (don’t tell them… sshhhh). So, here is my take on project leadership in an agile context.
Oh, and by the way, this article is a Bait & Switch. I’m trying to get you to read What is an Agile Leader. You might save time by just skipping this and going there right away 🙂
The word “project” is controversial in agile circles. Some companies use the “project model” as some kind of universal approach to organizing work, even for product development. However, a surprising number of projects fail, some dramatically. I see more and more people (especially within the software industry) conclude that the project model itself is the culprit, that it’s kind of like rigging the game for failure.
A “project” is traditionally defined as a temporary effort with a temporary group of people and a fixed budget. Product development, on the contrary, is usually a long term effort that doesn’t “end” with the first release – successful products start iterating way before the first release, and keep iterating and releasing long after. And teams work best if kept together over the long term, not formed and disbanded with each new project. Also, the traditional approach to planning and funding projects often leads us to big-bang waterfall-style execution, and hence a huge risk of failure because of the long and slow feedback loop. The project model just doesn’t seem to fit for product development.
Just back from Lean Kanban France where I gave a presentation on “Learnings across Kanban case studies, and what happened next” and introduced Skarin’s law: ”The number of improvement initiatives in a kanban system is proportional to the trust members have in that systems purpose” (.. it’s never too late to introduce your own law 🙂
Continue reading
Do you, a developer, have a feeling that the user stories your product owner is but a list of ideas prioritized on gut feeling only? That the relationship between them and their purpose are vague? Impact Mapping is an agile conversational tool by Gojko Adzic that may be primarily for product owners but hey, a developer needs a purpose too!
When refactoring legacy code, two problems seems to repeatedly occur. One is that the code is all tangled up with interdependencies and the other is that there is no specification of what the system is supposed to do.
Still we are asked to add features or fix problems without breaking anything. Everything in there should stay there.
Edgeware is a cool hardware and software company helping operators to build efficient video content delivery networks. Read their blog about what we have been up to since August this year: Lean and Agile at Edgeware
Continue reading
UPDATE Dec 2016: Wrote an article about LEGO’s agile journey, see here. Includes all of the material below, plus explanations and updates.
Here are the slides for my Lean Tribe keynote Scaling Agile @ Lego – our journey so far.
Here’s also a more detailed version from a talk that Lars Roost and I did at GOTO conference in Copenhagen: is SAFe Evil (that talk was also recorded).
This is just a brief snapshot of a journey in progress, not a journey completed 🙂
Sample slides below.
Our goal at the Crisp hack summit last weekend was to migrate our 2 year old shopping app written in Meteor to the latest version and to learn about Google’s material design. Our old app was built as a way for us to learn Meteor. The structure is less than ideal, and as we learn new things we add them to the app, but don’t revisit old parts. So we followed Dan North’s experiment rewriting the app from scratch. We also decided to use Materialize for the UI. We wanted to rewrite the app in 2 days, keeping all the functionality we currently have, but at the same time adding the UI and usability improvements that we really need.
We ended up completing the rewrite in 9 days: 2 hack days and then a couple of hours each day for the next week. Not too bad for a brand new app, but surprisingly longer than we would have guessed. Both Meteor and Materialize are pretty simple to get started with, but adding Materialize to Meteor proved to be challenging. Here are some highlights!
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 Toyota
Continue reading
Are you thinking about electronic Kanban tools? Do you need transparency to end-to-end flow? Do you work across multiple sites? Tired of managing work states in Jira? Here’s a short video demonstrating visualisation, analytics and key features in Swift-Kanban & Leankit. Both combine “simple and flexible” with “enterprise ready”. I also mention an interesting runner up – Obeya. Some things I
Continue reading
How do you decide what to build next? Who comes up with the ideas? How do you decide in what order to implement them? How do you keep track of what you’re working on, and what you want to work on?
Here’s a behind the scenes look at how the Candy Crush Soda team comes up with ideas and decides what to build next!
The other week I got the idea to create simple conversation cards. Each card represents an agile practice, a conversation topic or an abstract theory. Now I’ve drawn 96 cards. I simply couldn’t stop 🙂
Last night our Lego Mindstorms robot “Robit” somehow managed to win the Robot Sumo competition at the GOTO conference in Copenhagen! (here’s also an article in Mälarö Tidning)
Pretty frickin’ amazing considering that this was a big software development conference with lots of super-experienced developers competing, and our robot was mostly built by two kids – David and Jenny Kniberg (11yrs and 10yrs old) – the only kids at the conference. Their robot didn’t just win once – it outmaneuvered and outwrestled the competing robots in every match!
Here’s the final, Robit to the left:
So how could a newbie team win the competition so decisively?
For this year’s Stop Starting conference, we asked ourselves three questions: How do you develop awesome products? How do you bootstrap a successful mega project using Agile contracts? How do you use Agile and Lean thinking to turn a stagnant company around? We then picked the brains of people from real companies who have been
Continue reading
Can you develop new products from scratch in one day?
This challenge was taken on by the Medical HW manufacturer Optinova in August. Over the course of two days, we pushed the limits of “what is possible” by applying Agile in a HW environment.
Our hypothesis was that Agile would be a good fit in product development and innovation scenarios. And the result so far from the work that we have been doing with Optinova is promising.
Cross-functional teams, focus, rapid prototyping, close customer feedback and visual overview work just as well in hardware as in software. The training setup we used was as follows:
The result: All three participating teams managed to take an idea to working prototype in a day. One team went so far as submitting a bid to a real customer the following day based on their prototype. That’s high speed, even in software terms. But the most important thing wasn’t the result, it was the lessons learned. When we asked the participants if they wanted to continue to build products this way, the votes were unanimously in favor. If we can get it to work, this would help build a competitive and innovative company.Continue reading