Prioritisation is a necessary evil of every product development lifecycle. Deciding what to build, where to focus limited resources and what customers segments to target are questions that face every organisation on a day to day basis. So with this being the case, why is it that companies do it so badly?
You can’t really call it a cross-functional team if there isn’t UX and Design in it to deliver your product. But we see so many times we get a request to take out UXD from our team structure. Sound reasonable to you? Let me explain why they are not.
If I said to you I know about less safe dad, the place where your brain would go probably isn’t toward project management. Technically, if I was being completely correct I would say LeSS SAFe DAD. Sort of looks more like a cry for help created from newspaper cuttings than ways of working.
As we work with larger and more complex companies, we become the people to introduce Agile ways of working into an organisation. However, when you’ve worked using Agile for a decade or more, as many of us have, you often assume some knowledge that people don’t have. With that in mind, we decided to put together a glossary of Agile terms, so you know why we randomly ask you to stand up every day at the same time!
The other day, the following tweet was shared by a friend of mine:It put into words something that I’ve been struggling with for a while. As a Project Manager, I am always focused on the practical elements of the work I am doing. However, because Red Badger is a full-service agency, I also act as something more approaching an Agile coach.
In Kanban, behaviour changing data is key. We will visualise absolutely everything we do, and track it diligently. We do this so that we can use real-world examples to enable us to give accurate, tangible forecasts for our projects, and identify bottlenecks and inefficiencies so we can continuously improve.
Typically on most Agile projects, the success (or failure) of a project can heavily depend on how good (or bad) the product owner is and how committed they are. Good Agile teams that consistently deliver the right thing at the right time, and with quality in mind.
More often than not, software projects end up with pretty arbitrary deadlines.
Once upon a time, six blind men went to find out what an elephant is.The first man touched the legs of the elephant and thought, an elephant is like a big pillar or a tree with strong skin. The second man touched the tail and came to the conclusion that an elephant is like a rope with a brush at the end and it can move right and left very easily in air. Well, I won’t bore you with what the rest thought as I’m sure you can sort of imagine.
When working on any large project, 3rd parties are inevitable. We have worked with companies of all shapes and sizes, from two-man startups to internationally recognised names.
This week I’m in Antwerp, Belgium for a 2 day Lean Change Agent workshop with Jason Little. Day 1 just ended and I’m exhausted. But in that great my-brain-is-buzzing-with-new-ideas-and-information kind of way. Since my brain is way too excited to let me fall asleep, I thought I’d share just a few interesting bits from the workshop today that got me thinking.
Why doing it differently produced an innovative minimum viable product and enabled a better supplier selection process for Fortnum & Mason
For many businesses the principal barriers to customer driven business agility are speed and risk. Speed – because change happens so fast these days its hard to keep up. And risk – because of the concern that the costs associated with getting something wrong could outweigh the benefits of getting it right.
The term “lean” is thrown around a lot in the software world these days. It's the new agile. In reality, most people don't really understand what is meant by lean, or at least what was meant by the those who pioneered the movement.