The online whiteboard of Kristofer Palmvik
Discovery is about the collaboration between the Product Manager, the Product Designer, and the Tech Lead to discover the right solution to build before writing any scalable code. Typically, this involves talking to end-users, customers, and stakeholders to gauge their needs and then ideating, prototyping, and validating solutions—quickly. The last word is key here.
How do OKRs stack up against the alternatives when it comes to alignment frameworks? And what are the potential undesirable behaviors that come with them?
Running a Working Agreement workshop as early as possible is crucial for setting the team up for success.
The requirements document is now called backlog and the requirements are called user stories. Then you think you are agile.
Efter den lyckade lanseringen av Pust Java togs ett strategiskt beslut att övergå till s.k. standardsystem. Avsikterna var goda, att minska förvaltningskostnaderna. Tyvärr gjordes ett dåligt teknikval – Siebel.
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?
So they decided to do an experiment for a few months. They moved one of the testers from India to Stockholm and dropped the other two testers (re-allocating the other two to other teams) to see how that would work.
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?
The important thing is not your process. The important thing is your process for improving your process.
Most organizations are riddled with policy-driven waste, i.e. wasteful practices, rules, and routines. Just keep your eyes open. Look at it positively - these are high-leverage opportunities for improvement.
One day in Kanban land - Henrik Kniberg’s blog
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?
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.
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).
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.