Using Jira for Project Management & Agile Collaboration on scale

Using Jira for Project Management & Agile Collaboration on scale

Using Jira for project management and agile collaboration is widespread and popular, especially for teams. With the following configurations and enhancements a standard Jira installation can be transformed into a scaled agile project management and collaboration platform.

Jira software is designed for Scrum, but with its Kanban board functionalities, it has been used as a task management solution for project teams and other working parties.

The main reason for Jira’s success story in the past was that it was very inexpensive for small teams, and this combined well with the many offered benefits:

  1. Everyone is using it.
    Atlassian, the vendor of Jira, has more than 200.000 customers with 25 or more users. Why using another platform for project management, when you can use a de-facto-standard solution like Jira?
  2. Jira is optimised for Scrum and Kanban.
    With these methods it is easy to keep on top of managing the progress of a team.
  3. Value for money.
    Why should we spend more money on other solutions?

These are strong arguments for utilising Jira.

But there are two aspects that we must not ignore. Our world is not purely agile and what works for a small team, doesn’t necessarily work on scale.

  • Communicating quickly becomes chaotic and nervous on a large scale.
    Kanban, Backlog and Sprints are methods to stabilise the organisational context of a team. Well, vanilla Jira should be additionally configured for a non-Scrum-Team-Backlog planning. However, not everything can be fixed with configuration: It is not possible to work with many – let’s say 30 or more – people on the same Kanban board. Kanban just doesn’t work on scale. Alignment between teams or projects need to be ensured otherwise.
    Especially in remote, cross-time-zone, cross-location or program initiatives there is a specific need to ensure frequent alignment between the teams in terms of planning, progress and review of the results in order to manage interdependencies on a regular basis.

For cross team alignments plug-in Alignment Meeting Board needs to be installed and configured for Jira.

  • Jira is missing a timeline view and tasks are not part of a plan
    Sequential process organisation through workflow control is increasingly unsuitable for agile collaboration. But without a timeline every card in Jira is a standalone topic, not meant to be part of a task sequence flow. Complex projects or programs cannot be managed with deadlines across different teams when no one sees a timeline or roadmap. Kanban boards are great for in-team co-ordination – and they are terrible for planning projects on scale. On scale you need the supporting structure of a plan.

For project planning a plug-in like BigPicture for Jira needs to be installed and configured.

Templatizing of plans can be enhanced with Visual Issue Card for Jira by displaying generic task descriptions.

Now, that you have fixed Jira for alignment and planning on scale, it’s worth to think about configuring and enhancing Jira to a fully-fledged collaboration platform.

  • In a big Jira installation it is impossible to find attachments in Jira
    Finding working documents and files in a big Jira installation can be a nightmare, because the build-in JQL-search doesn‘t include attachments. In addition to that, if you need some structure for your documents in progress – what is the case in projects where we normally produce documentation – vanilla Jira has nothing built-in but refers to Confluence-Wiki as a separate software solution.

Attachments can be found with a small plug-in like Attached Quick Finder for Jira

Provide an Explorer-like folder structure for a project and install MiniWiki for Jira

  • Every ordinary chat system always misses the point
    Jira is great in organising communication around cards. But why is it sending notifications to Email-addresses? This seems like harnessing a horse to a car. What is really needed on a scaled Jira platform is to link people-chats to Jira cards where asynchronous communication is needed. If you now believe this is what you can do with a channel in Slack or MS Teams as well, then I would wonder if you could work with countless channels like you can with countless Jira cards.

People’s chats can keep topic focus with the plug-in SharePlus for Jira. Chats can be copied by the user with a click into the comment thread of the Jira card.

  • Individual task management is still a waste of paper
    People bring ring binder, paper sheets or old school notebooks to meetings to take away their to-do‘s or take notes for their own better understanding. That‘s how people keep focus and optimise their own work. Unfortunately, taking notes on paper counteracts the agile principle of transparency and valuable information on paper can get lost for the solution thread of a Jira card. An individual notebook need to be digitized and integrated in Jira.

Users can decide by their own what information they maintain in the plug-in MyToDo Board and when they want to share this by a click on a Jira card

If you want to transform a standard Jira installation into a scaled agile project management and collaboration platform, the first two points – planning and alignment – are compulsory, the others are optional. Using all these Jira plug-ins would definitely support increased and faster acceptance to work with Jira from your users and would lead to better team collaboration on all levels.

The required agility of an organisation

The required agility of an organisation

It is tempting to transfer successes in applying agile software development methods in small teams to an overall organisation. The buzzword is Scaling Agile. SAFe in particular is booming – a framework for scaling agility in an organisation. Accordingly, the number of training courses and experts is increasing steadily.

The market for scaling agility still appears to be dynamic and not saturated. But there are already providers of certification programs and frameworks like SAFe or LeSS at this early stage.

Agile experts like to talk about the new normal. There seems to be common sense that scaled agility provides a good answer to an increasing complexity that many organisations face today. But what scaling agility is all about, experts don’t seem to agree on yet.

Inspired by an article on agility by Benjamin P. Taylor, University of Oxford, published on LinkedIn, four types of experts can be distinguished:

  1. The Agile Behaviorist.
    He says everything is just a matter of designing necessary structures. In his belief, there is only one structure of agility on a large scale that fits all organisations.
  2. The Agile Paradogmatist.
    He is convinced the measure of quality of a transformation can be reduced to the unconditional fulfilment of the agile dogma. The inescapable truth of the paradigm shift must be acknowledged and accepted once and for all.
  3. The Agile Trend-Junkie.
    He demonises everything old and inappropriate and puts it down just because it is not new and modern. Agile Labs, trips to the Californian Silicon Valley and other hip agile references provide the desired orientation here.
  4. The Agile Housemaster.
    For him, everything is just a question of Agile Mindset: the agility of an entire organisation depends exclusively on the interaction of agile cultural patterns of individuals. Scaled agility can easily become a purpose in itself here, serving a new morality.

But rather than opting for one expert’s mantra now, agility on a large scale can also be understood as the evolution of collaboration that comes with increasing complexity in product innovation. Thus, if agility is understood as the result of an evolution pressure, then an organiation evolves toward agility to the extent and at the speed required by its own business model.

Of course, as described above, the right structures, methods, practical relevance and mindset are just as important here. However, this is from a different perspective than that provided by the four types of agile experts described above: the focus is not on the mantra of experts, but on the need for their own agility.

  1. What exactly should we become agile for?
    Here, the Agile Behaviorist’s one-fits-all approach gives way to the approach of developing required structures of scaled agility for an organization’s specific context and needs.
  2. What does agile mean to us?
    The dogmatic agile approach of the Agile Paradogmatist gives way here to the approach of reflective and participatory team mobilisation based on a shared understanding.
  3. How do we make the transition to scaled agile ways of working?
    An Agile trend-junkie‘s denouncing-the-old approach gives way here to the learning organisation and exploratory iteration approach.
  4. How do we create an optimal environment for a coaching leadership culture?
    Here, the blaming mindset problem approach of the Agile Housemaster gives way to the enabling and empowering approach across different levels of the organisation.

A joint discussion of these issues of scaled agile collaboration by all employees involved is critical to success. From our experience, experts can even have a counterproductive effect if they engage the employees involved to such an extent that, in the worst case, they have an inhibiting effect on them. Agility can literally be understood better by asking the right questions than it can be understood by the teachings of an expert.

If you are already familiar with agile working, you may have already experienced benefits at the team level. Scaling these benefits with kyona methods and extended toolset, we guide you to a collaborative, digital and agile business structure and culture.