*This post is part of the series ‘SAFe Practice Tips’, which aims to offer helpful advice to anyone using SAFe.

As a SAFe® Program Consultant Trainer (SPCT) I can’t remember how many PI Planning events I facilitated and attended last year. However, what I do know is that this is a seminal event in SAFe, which aims  to create alignment with the Teams, the Product Management, the Architects and Business Owners.

“Program Increment (PI) Planning is a cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared mission and Vision.”

PI Planning is essential to SAFe - If you are not doing PI Planning, you are not doing SAFe.

Over the last 2 years, I have been experimenting with different techniques and practices which I thought I would share with you. The first one is regarding Business Context and Team Space

As a SAFe® Program Consultant Trainer, I have launched many Agile Release Trains (ARTs) over the last two years in a variety of industries and countries. Every time, I look to try something new (an experiment) to see whether there is a better way of doing things.

So, through a series of blogs I am going to share some of those experiments that I have found really useful. Perhaps try them out for yourself and let me know how you get on.

This is a guest post by Samantha Webb. Samantha is an experienced Scrum Master and Agile coach working in the computer games and eSports industry. She spends a lot of time both inside and outside work mentoring professionals new to the Scrum Master role as well as coaching teams in Agile. 

Whether or not you are familiar with the world of MMOs or RPGs (that’s massively multiplayer online games and role-playing games), there are a lot of lessons that can be learned from the virtual world and applied in the real one. This is certainly true of my experience working in Agile environments as well, and this article aims to look at some of the practices introduced in online games that can help Scrum Masters improve their own practices.

One of the most common questions I hear from new Scrum Masters – and also often those with more experience under their belt – is how they can better themselves. Inspection and adaptation are two of the three pillars of Scrum, so it is no surprise that the best practitioners I know apply these pillars to their own practice. Lately I’ve found myself offering up similar advice to many Scrum Masters in different circumstances, so I thought the time had come to put quill to parchment and record my advice for other Scrum Master adventurers.

Are you struggling to plan your Christmas in an efficient way? We have provided a solution for you to overcome this with a Kanban board. A Kanban board is a workflow visualisation tool that enables you to optimise and manage the flow of your work. If you are a beginner in using a Kanban board or have never used one yourself check out our previous blog on ‘How to use a Kanban board’.  There are many benefits to using a Kanban Board such as:

- Providing visibility across the team

- Reduces overburdening

- Helps with communicating better

- Encourages better quality of work

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.

What is Kanban?

Let us start with what Kanban is not:

• Kanban is not a project management methodology.
• Kanban is not a product development lifecycle process.

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.

1. Organisational Culture and Agile Frameworks: How to Create an Alignment

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?

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.

What are Agile Requirements?

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.

In the Beginning.

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>’.