There’s no doubt that 2020 was a tumultuous year for everyone and it’s widely acknowledged that government assistance has been a big part of keeping people safe and supporting businesses and individuals financially. At Pragmateam, we’re super proud to have been part of several support initiatives provided by the NSW Government.

We were recently discussing ways to show how we have a successful offshore model with Brazil and I thought there was no better way than the actual people involved talking about their experience: I happen to be originally from Brazil, where I started working for Pragmateam through the partnership with DB and that's where this story 'from the trenches' begins.

I’ve grown a bit tired of strategies for ‘digital transformation’ that focus on agile, team structure, customer research, architecture, continuous delivery and ways of working (lots of them quite good advice, btw) but don’t say one word about the strategies to motivate and get people to change. Agile, lean, software engineering and product development practices are the easiest parts to solve but the people aspect, buy-in and ‘stickiness’ of those changes are not as straightforward.

There is a common trend for teams to push ahead with partially completed work, irrespective if it no longer aligns to our goals. It feels counter intuitive to halt this work, but if done in a conscious and informed manner, I encourage teams to have the brave and open conversation about whether they are still aligned to their goals.

Too often teams feel disconnected from their leaders and the company's strategy and vision.

We need to put a focus back on connecting the dancefloor with the balcony.

Think about your Agile environment. Have you implemented your version of Agile and stopped there, content that you're done? Have you focused on what Agile is actually about? In this blog post I'll share my views on what Agile is, and more importantly, what Agile is not.

For the recent second PragmaBirthday, the whole team was asked for their favourite quote on "change". Now, that's fairly broad ask and it's hard to pick out one. Here I explain why I chose this one.

Taking on the role of Product Owner is no small feat, ensuring a balanced view of commercial needs, user needs and technical feasibility.

Ensuring the organisation is setup to allow the Product Owner to excel, giving them the responsibility and autonomy, yet support they need is crucial.

On October 27th, Digital Transformation Agency hosted Market Ready panel, in conjunction with the Spark Festival, a festival held throughout startup hubs across Sydney.

Hey You features in the Financial Review, a write up by Hey You co-founder Rebekah Campbell on the positive impacts of the improvements introduced through partnership with Pragmateam.

I recently found myself working with Sarah on a mini-production line with the goal to laminate a new sets of flashcards which we use during workshops. The setup was pretty simple…

In the spirit of continuous improvement, we should always be actively seeking feedback, opportunities to do better next time.

At Pragmateam we believe in learning and improving so much so that we have captured a number of OKRs around learning culture, one specifically regarding meetings, workshops and sessions.

Sprint Planning is one of the well-known “ceremonies” within the Scrum framework. While at Pragmateam we absolutely see the value in planning, we typically approach Sprint Planning from a perspective of flow. The question we want to answer during sprint planning: How do we use the weekly/fortnightly conversation to continue the momentum of the previous sprint?

There are many interpretations of “Agile”, varying processes and methodologies, such as Scrum or Kanban. However, the implementation of Agile techniques and practices needs to be contextual to the environment and constraints. A purist implementation will be at the detriment of the organisation. As such, teams are encouraged to consider Agile a toolkit and apply relative to the problem they are looking to solve.

Instead of a reason not to run a retro, a slow sprint can be a tremendous opportunity: How often does your team take the time to reflect on topics outside of the regular sprint activities?

Few in the Agile world would disagree that Retrospectives make up an essential part of Agile. It is anchored in the Agile Principles as “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

Every workshop we do to kick off a project has some aspect of team building in it. The main reasons of course are to allow people to get to know each other, to feel comfortable working with each other, and to break the mould of the day-to-day. Sarah has previously written about the ROI of icebreakers.

The understatement of the year: Meetings are often not quite as effective as they should be.

As facilitators we have many tips and tricks in our toolkit. But of them all, “icebreakers” tend to get the most apprehensive reaction (myself included). Typical perceptions of icebreakers may be that they are a waste of time, too abstract, too fluffy. Also, given the creative nature of icebreakers, people can feel uncomfortable in putting themselves out there through whatever the chosen activity is.

In part 1 of this blog post, we explained that coaching is a 4-stage process which reflects the team's agile maturity. The stages are Educate, Show, Mentor and Support. Let's now focus on why delivery-oriented coaching is more valuable than coaching teams from the sidelines. Delivery-orientated coaching means showing things rather than talking about them.