Mid 2016 we found that people were regularly bringing this objective to life, whether it be experimenting with new techniques, organising a learning lunch, presenting at meetups, all with a positive impact on the rest of the team. But we were lacking a way to naturally yet formally thank, reward and recognise each other.
The “team” in Pragmateam is critical to us and our culture. We are a collective of like-minded practitioners who are all inquisitive, continually looking to experiment and learn. And we acknowledge that working together as a team will get better results for us personally, our clients and their customers.
Learning and sharing is a key ingredient within Pragmateam’s culture. While we have a very healthy internal shareback rhythm (more about this later) we also actively seek ways to give back to the community, sharing our techniques, experiments and learnings.
On Monday at our Start of Week, Juliano and I were reflecting on the team's recent achievements. As we went through the list, we were struck by how many events the team had participated in at the tail end of 2016; we led, facilitated, presented or mentored.
September marked the 2 year anniversary of Pragmateam. It felt timely to reflect.
While I wouldn’t say every day over the last 2 years has been smooth sailing (we would be bored, unhappy and missing a lot of great lessons for life if it were), as company directors there are a few key principles Juliano and I have subconsciously adopted which I believe have assisted us to stay on course.
Hey You partnered with Pragmateam, stripping Agile back to it’s basics, introduced a regular heart beat to their Product Visioning and Inception, increased delivery discipline, re-energised their way of working and constructed a invaluable wall, visualising the end to end flow of work across the company.
One year on, 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.
Every 8 weeks we spend quality time with the whole team, typically a half day offsite. Each offsite we seek to experiment in some way, shape or form. Here we share some of these experiments and what we learned from them.
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?
Delivery-orientated coaching means showing things rather than talking about them. Coaching a team in 'advisory mode' (ie. not being hands-on in delivery) is a difficult and long path to proper agile delivery. If the team hasn’t seen what ‘good agile’ looks like, how would they know where they are heading? Hands-off advice from a coach doesn't usually help.
Reflecting on Mathias' experiences as a QA working on a project where the objective of developing a mid layer application which gets messages from JMS queues and topics (briefly explained below), stores them in different databases and publishes to multiple clients. The project involved a number of specific technologies which Mathias had never worked with before, and these are his learnings.
Teams are cross-functional - containing all skills necessary to define, build and ship the new features. The teams are aligned to producing value to the business rather than to the abstract purposes of providing excellence within a functional silo. This not only gives the team a laser-focus on adding value to the business.
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.
We argue that Retrospectives are the most essential of all Agile practices. Not only do they embody the agile purpose of continuous improvement, they also create a learning culture. They are the engine that drives teams to perform better over time. Retrospectives should happen at regular intervals, which means they should be repetitive in occurrence. But they should not be repetitive in nature.
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.
Everyone knowswhat an effective meeting looks like, what factors prevent and contribute to one. So why don’t effective meetings occur more often? Why is it still the stuff ofDilbert comics and prompts a knowing smile from everyone in the room when the topic comes up?
"Agile Coach" is an extremely overused term today: it seems like every company wants one and lots of people refer to themselves as that. At the end of the day, Agile is a means for better delivery of business value.
Recently workshopping with one of our clients, we were asked to take the attendees back to basics, "what does Agile look like"? As you can imagine, this is a pretty broad sweeping question with many possible answers.
It is inevitable that we make mistakes in a new environment. But if we allowed ourselves, and if others allowed us, to make mistakes on a small scale in rapid succession, then we can avoid failing big.