Pull-Push Agile Training

The first time I worked with Agile I was a new programmer at a mobile analytics startup that was using “Scrum”. Every couple of weeks I would be pulled into a meeting for sprint planning in which I was told to build APIs for our analytics product. After a few weeks we would meet up again and share progress and I get tasked to build a few more APIs.

For sure, we weren’t following Scrum by the book, but I didn’t know any better, having never read the Scrum Guide, much less having done any training. What I did know is that my APIs never actually got used, so I didn’t add much value to the company while I was there.

Later, when I joined a larger enterprise project that wanted to implement Scrum, I was the only person on the project with any prior experience and I was treated as the expert. I remembered how we did “Scrum” at the startup and that it didn’t create much value, so I took it upon myself to get a certification. I certainly didn’t want to embarrass myself giving presentations about something I knew nothing about!

So I went with scrum.org and got the three base certifications PSM I, PSPO I and PSD I. I then gave trainings to each new scrum team, explaining the process and how they should think about their roles.

However, this training didn’t seem to sink in, probably because it was one-off and fairly dense. So I paired up with someone in senior management to start a Scrum certification program, which was entirely voluntary, but in which the company would pay your test dues, assuming you had studied well enough to ace a practice test.

The go-getters in the project immediately jumped on the opportunity and we had between twenty and thirty people certified after about three months. But on a project with about 150 team members, this wasn’t nearly enough.

So I regularly reported the certification numbers to management, and after a while they saw this as an improvement opportunity and made the certifications mandatory. Suddenly my online Zoom training were filled with 50+ participants, and the recordings I uploaded got hundreds of views.

We ended up certifying about 120 people by the end of the year, and it dramatically changed the interactions between team members for the better.

There were three key benefits that were realized as a result of all the certifications:

  1. We had a common vocabulary
  2. We had a sense of pride in following the rules
  3. There was a desire to learn more

Although I really like the approach of the scrum.org certifications (they are extremely particular about words such as “must” or “should”), I think that the benefits would come from just about any certification that we gave our team. If you look at the benefits above, none of them are particularly unique to scrum.org or Scrum or even Agile.

But I think that switching to Agile inevitably means changing mindsets and adopting new vocabulary. And so if I joined a similar project at some point in the future I would adopt a similar model:

  1. Identify an “expert” who is well-suited to run a training program
  2. Create a free certification program initially, to build up some momentum and peer pressure
  3. Eventually make the program mandatory for the entire team

The risk of not doing this is having a large team that never seem to understand what anyone else is saying and who all seem to be pulling in different directions. And a model of training that is top-down from the start probably isn’t going to gain organic momentum, but rather breed resentment among the team. It’s much more effective to “pull” before “pushing” in change management.

Shoot for Jerk

Like all managers of technical teams, I’m primarily concerned with improving my team’s effectiveness. When I think about the possible ways I can do this, I try to classify them according to the nature of their impact.

For instance, I could make the team more effective by starting to code myself. Since we have an additional set of hands on the work it should (hopefully) get done faster.

There is a clear problem with this method that should be clear to most managers: it has a one-off effect and makes no lasting impact on the output of the team once I stop doing it. I increase output, but since it is a one off, it does not increase the rate of output over time.

In Scrum we typically refer to the rate of output over time as ‘velocity’, and this is our primary metric for each team. One way you might improve velocity is to address technical debt that is slowing down development. In this case you temporarily reduce output to address the debt, with the understanding that output over time (velocity) will improve.

And if you are a manager and you are making this decision for the team, then I would say there is a problem with this method as well — the boost in velocity is a one off and it will no continue to increase velocity once it is finished.

An increase in velocity over time, as opposed to output over time, to continue the physics metaphor, is what I call ‘acceleration’. And example might be allocating a fixed percentage of effort every sprint to paying down technical debt, because each time you do it, it should improve velocity.

In physics there is another term for change in acceleration over time: jerk. In fact there are some funny terms for even higher orders of magnitude of the same concept: snap, crackle and pop!

When I think about how to help a team, I ‘shoot for jerk.’ I consider the ideas I have and how they will impact the team. If at all possible, I look for something with jerk — something that will improve the team’s acceleration over time.

What this generally aligns with is the concept of empowering the team, but empowering is not necessarily a goal in itself due to potential misalignment with business value. There are certainly limits to the type of empowerment a team should receive for this very reason. For instance, you may not want the team to decide on their own salaries, as they have a conflict of interest.

Jerk, on the other hand, is aligned with business value, so I find it to be a better litmus test than empowerment when it comes to management decision-making.

So what is a good example of jerk? A good example is our system in which we rethink our team structures once every three months and make changes based on feedback gathered from all stakeholders: developers, designers, product owners and senior management. Typically the goal of these changes are to streamline communication lines and remove inter-team dependencies. Sometimes we also need to clean up ‘organizational debt’, because the needs of the company have changed or we have had people join or leave the team since the last change. Each change we make improves acceleration by empowering the team, and by implementing a continuous process of team renewal, we added acceleration over time: jerk.

This is not to say that I never contribute code to our project. I actually do this a little bit every week, for the same reason that I try to use our own products regularly: I need to understand the 10 foot view of things, as it helps inform decisions at the 100 and 1,000 foot views. Not everything you do can directly improve jerk, which is natural, since a lot of management work is staying properly informed so that your decisions can have the most positive impact.

Self Introduction

I’m the CTO of a corporate startup in Dubai and have worked on multiple digital transformation projects. My background is well-rounded, as I have a degree in mathematics, worked as an actuary, project manager, financial analyst, web developer and Agile coach. I’ve lived in seven different countries and speak five languages.

I’ve got trainer-level certifications in Scrum and have coached hundreds of my colleagues to their own certifications. I’ve taken a 10 person development team with no processes or standards and grew it to a 25 person development team employing Scrum, DevOps, CI/CD and more. Most engineers who have worked on my team said it was the best experience of their careers.

Despite the successes listed above, I’m extremely critical of my own work and perpetually dissatisfied with whatever my team’s situation happens to be at the time. I always want things to be better and better. Lately I’ve used the concept of ‘jerk’ to describe how I try to approach these problems, which I’ll explain in a future post.

I’ve learned a lot from my past successes and failures, and I hope that from this blog I can share some of this learning with the world.