Out of the various Agile frameworks and methods out there, today’s blog post focuses on Kanban. More specifically, on how to use one of the most popular techniques for the visual management of your workflow: the Kanban Board.
Let us start with what Kanban is not:
So, what is Kanban?
What makes consumers decide to buy your product or service? How important is adopting a user-centric approach when planning new features? Why does solving real-life problems matter for your customers? Read this blog to find out.
On my commute into the office today I was struck by the vast array of exciting new products that seemed to flaunt themselves from every angle. The adverts that flash up on my phone whilst nosing around on Social Media, the mesmerising new gadgets that brandish themselves from the centre of the free ad paper, and the cutting edge fashion that lines the high street. I would be lying if I said I wasn’t a little tempted by these goods, but would it be enough to lure me into parting with my well-earned cash?
Just in case you missed any of them, or would like to refresh your learnings reading them again, here are our top six blog posts of 2016 from the Radtac Blog.
Can you map a certain type of organisational culture against an Agile framework? Is a certain Agile approach better suited to a certain culture? How can various culture types affect the success of your chosen Agile approach?
I love mince pies. FACT.
It was a day in late November, and I was catching the late train home after a long day in the office. I needed a drink, so I went to the food and drink place in St Pancras International. I asked for my coffee, and was offered a Mince Pie for an extra £1. Ooh that’s a good offer, I thought, so I said ‘Okay’.
Whilst sitting on the train I sipped my drink and devoured my Mince Pie. The coffee was good, but the mince pie was average at best. Especially for a £1, I thought. Perhaps it wasn't such a good deal!
So I posted a picture of my pie to our Slack channel, and jokingly gave it a score of 6 out of 10. Our Slack channel went berserk with ‘You’ve had a mince pie - why have you scored it?’ ‘OMG you scored it’ etc. And I thought, well yes, I have had a mince pie, and yes I have scored it... I wonder how others compare, and I wonder which one is best!
And that is where it all started.
It’s 1989 in San Dimas, California, and strange things are afoot at the Circle K. Bill and Ted have been spending all their time trying to create a metal band - “Wyld Stallyns” - all at the expense of their education.
Somewhere in the future the year is 2688 A.D., and the world exists in an utopian society due to the inspirational “Wyld Stallyns”.
Little did Bill and Ted know the consequences of failing their final year at high school. A bogus outcome could have a devastating impact not just on their future, but also the whole of humanity. Ted’s dad would send him to military school if he failed his final history oral report, ending the chance of “Wyld Stallyns” being successful.
This blog post will explain what Agile Requirements are, and guide you through writing and using User Stories.
As we cannot possibly know all requirements of our products at their inception, it is futile to spend time creating a detailed Requirements Specification Document upfront. Instead, we should use Agile Requirements.
Agile Requirements are requirements that are allowed to, in fact encouraged, to evolve over the lifetime of a product. We are learning more and more about our product during its development through feedback from Customers, Users, Stakeholders and Developers. Using this feedback, we can regularly choose to add requirements, remove requirements, add more details to requirements, change their priority, and so on, to make sure our Agile requirements will deliver the most value to the business as soon as possible.
This blog is a case study of an Agile implementation which started off as a classic Scrum implementation, and then evolved to use Scrumban and Kanban techniques.
It is day 1 of sprint 1 for a team.
To set some context, a Business Analyst had spent several months preparing a product backlog of nicely written user stories. They were conveniently written in the user story format:
‘As a <who>’
‘I want <what>’.
Imagine this scenario: you’ve created your initial product backlog. The requirements on your backlog have been broken down just enough, not too much, but just enough to be able to prioritise delivery of features to the customer. How do you prioritise, who does it and what options do you have?
Firstly, it is important to have a vision. In fact, the product backlog should have been created with this vision in mind. The vision helps communicate to everyone involved what the outcome of the product should be.
This post is the first one in a 'How To' series of posts by Peter Measey. The posts in this series will explain different concepts, terms and practices within Agile, as well as how to run these practices.
Agile teams need the capability to monitor and track progress, and also the ability to be open and transparent about that progress. Many Agile teams use ‘Burn-Up’ and ‘Burn-Down’ charts to achieve this, especially within Scrum. This blog provides some practical advice on how to use these charts effectively, and what they can provide for your team.
