DevTeams.AT

In dieser Serie schreibe ich über generative KI, genauer gesagt über LLMs: Warum ich höchst skeptisch bin, welche Gefahren ich sehe, aber auch wie ich sie nutze und wo ich sie vermeide.

Here’s an training activity I came up with a few years ago that I love to do when I want attendees to research a topic on their own. It is great when there are two opposing sides to the topic, and you want attendees to research both sides. If there aren’t two sides, you can often create them ;)

After a two-year break caused by the COVID pandemic, I started a technical agile coaching assignment again in August 2022. In this series, I want to write about how I coach, what I do different than in the past, etc.

Read all posts of this series here:

“How do you implement some functionality in a test-driven way, when you don’t know at all how the solution might look like?”, I sometimes get asked.

You know, sometimes I don’t. I just hack away. But bear with me: Sometimes I don’t—until I do. At the end of this post, you’ll see tests and even test-driven code.

I am currently in the middle (by the time I publish this blog, it will be finished) of implementing such a “hack-then-do-right” feature, so I decided to blog about it:

Transcript and more thoughts about the topic below…

Transcript and more thoughts about the topic below…

Transcript and some more thoughts about the topic below…

There are two teams. Both develop the same feature. In both cases, developing the feature takes 15 Person Days. In both cases, the feature provides the same value over time after it has been deployed.

The only difference is how long it takes them to deploy the feature to production: Team 1 needs two weeks in total, but it takes six weeks for team 2.

Which team produced a better result, financially, for their organization?

A fellow trainer asked me some questions about my remote training setup, especially:

• The technical setup (hardware and software)
• How I keep the training interactive, even though it is remote

So, here is my setup and how I currently run those trainings…

Should companies invest in agile engineering practices—training people on their engineering teams and giving them time to improve? And if they should do that, how much should they invest?

In this article, you will learn why it makes sense for companies—from a business point of view!—to allow their developers to grow professionally, to help them grow and to invest time and money in ways to improve the skills and practices of their teams.

When we write interaction-based tests, using mocks or spies, we make it harder to change those interactions later (*). We make it harder to do some kinds of refactoring! But does it matter?

Not necessarily - there are ways to use those test doubles so that the benefits outweigh the cost. But when you use them to write tests for a bad design - for code that’s hard to test - you are doing it wrong.

And your tests will come back and bite you later.

Over the years, I have been trying different ways of writing commit messages - And I now think that it’s best to write a present tense commit messages that describes the new capabilities of the system I am working on.

Let me explain…

In the chapter “Naming Things” of my book about “Agile Engineering Practices”, I wrote that you should name intermediate results (I will link the whole sample chapter at the end of this blog post).

But sometimes, it’s not that easy…

In my TDD trainings, I sometimes say that I do not test code that is “too simple to break”; Code where:

1. The chance of the code breaking is very low
2. If the code breaks, we would see immediately

What do I mean by that? In this blog post, I’m going to explain…

In the last three parts of this series, I wrote about how one can use the webpack’ed version of a ReactJS application as a template engine for spring boot, how routing and navigation can work on the server side and how to improve the first-load performance of this app.

There is one thing missing in this application: The server side rendering does not use any dynamic data at all yet. With this blog post, I want to change that: I want to show you how the server can pre-render data that the client would usually fetch dynamically.

In the first two parts of this series, I wrote about how to use reactjs together with spring boot on a GraalVM and how to use the same routing / navigation on the server side and in the browser.

Today, I want to look into whether rendering on the server side is even worth it. TL;DR: Out-of-the-box, the improvement in time-to-first-render was not that that much. But with a few tricks, I was able to reduce the time by ~60%.

In my last blog post, I wrote about how I am using ReactJS as a template engine for spring boot. I am running the server side application on GraalVM, and my Spring controller uses ReactJS to render HTML. In the browser, the JavaScript will hydrate the components that have been rendered by the server.

This worked well for the simple example app that I had. But what about navigation? We need the same routing on the server side and on the client side, otherwise the server would render the wrong content when the user reloads a page.

And here’s how I did that with react-router…

Since our country is in lockdown now and I cannot (and do not want to) continue with my usual videos, here’s a “normal” blog post about some fun thing I was trying recently. I wanted to use reactjs (TypeScript) as a template engine for server-side rendering in spring boot (Kotlin) so that…

• I can use the client-side app created by create-react-app (almost) without modification
• I can still run the react-app in standalone mode with npm start
• The app works exactly the same when I open it from the spring boot server
• I can use all modern JavaScript features
• Routing works exactly the same on the server-side and on the client side
• REST calls are only done when the JS scripts are running on the client side, otherwise they are direct calls to Java methods

I am not there yet. But I already got the first four bullet points covered, and I am working on the fifth. So, here is what I did so far…

Tim Bourguignon and I talk about public speaking: Why he loves it and about a talk we prepared together.

In this second interview about 3X thinking, Antony Marcano and I talked about advanced topics:

• The fractal nature of 3X
• How 3X relates to the three investment horizons model
• Pioneers / settlers / town planners
• How 3X relates to Agile
• How companies can apply 3X and try radical, new ideas while protecting their existing brands

But first we do a short recap of the last video: What is 3X - or explore / expand / extract - and how can you use it? Watch the video here or read the transcript below.

Tim Bourguignon tells us how he became a developer, then an agile coach and then “chief learning officer” at Mathema.

In this interview, Simon Harrer shows you how code becomes more readable when you do not separate state and behavior.

Tim Bourguignon, agile coach and “chief learning officer” at Mathema, talks about one of his favorite topics: Mentoring.

Simon Harrer and I talk about the chapter “Name Things Right” from his book “Java by Comparison”.

When you already know the algorithm you want to implement, why should you use test-driven development to write it? And how do you test-drive a known algorithm or formula?

Why doesn’t React come with dependency injection? Short answer: Because it doesn’t need it and also because it is not its responsibility.

But how do you isolate your components during testing then? How do you achieve inversion of control for dependencies when you do not have a dependency injection container?

Let’s have a look…

Some years ago I was talking to the technical lead of a medium-sized company. I told them that I had just taught a 2-day training about the new features of Java 8 to two teams at a very large company.

He said: “I will never understand why those large companies spend money on training something like that. Like, language features! I expect my employees to learn those on their own, out of curiosity!”

When test-driving a UI, should I test whether the text of the start button is “Start”? What about the CSS class or style of the button? It’s disabled state?

Of all the possible tests I could write, which are the ones that bring value? Which ones would get in my way later if I wrote them?

Can you test-drive the UI of a web application? And why would you even want to?

With React and some extra tools, testing at least some aspects of the UI is easy. Let’s take a look…

Can you do test-driven development with React? Can you test-drive the UI itself? And why would you even want to?

With React and some extra tools, testing at least some aspects of the UI is easy. In this video series, I’ll show you how.

Earlier this autumn, I attended the “Training from the Back of the Room (TBR) Certified Practitioner” training and then I also became a certified trainer for TBR. After the “certifed course”, to be allowed to run “TBR Certified Practitioner” trainings, we had to complete some writing assignments.

My first assignment was:

A fellow trainer who is a colleague and friend of yours has asked for your help in designing and delivering a new course. But your friend has no idea how to use brain-based training design and delivery strategies. How would you help your friend get started? What information would you consider crucial for your friend's success and how would you explain this information to him/her?

And here is what I wrote…

I spoke about “3X thinking” with Antony Marcano. 3X was originally coined by Kent Beck and it describes the “profile of a winning idea”. 3X thinking will help you to determine whether it’s best to experiment, scale or operate for any given idea.

In this first video, Antony and I talk about the basics: What is 3X thinking and how can it help you as a developer, manager or C-level executive?

Read the whole transcript below the video.

How does an idea become a winning idea?

In Summer 2019, I interviewed Antony Marcano about “3X Thinking”, and this led me to “explore” (ha!) a bit more. Here, I want to collect the interviews with Antony any my own thoughts and ideas about the topic.

Read / watch all parts of “#3Xthinking” here:

• 3X Thinking Part 2: Advanced Topics
• 3X Thinking Part 1: eXplore, eXpand eXtract
• 3X Thinking - All Posts

Tim tells me about his podcast “Developer’s Journey”. There, he interviews software developers about their career, what is important to them, and more.

I interviewed Simon Harrer at Developer Week 2019 in Nürnberg, where we talked about his book “Java by Comparison”. With this book, you will learn how to write clean and maintainable code in object-oriented languages.

Simon Harrer talks about how to avoid negations in your code…

I interviewed Simon Harrer at the Developer Week conference about his book, “Java by Comparison”.

If your employer asked you do do something unethical or something you would not want to do for any other reason, would you tell them “fuck you” an leave?

What would have to be true so that you could do that?

“Why are good people stuck in bad jobs?”

I read that on a whiteboard somewhere and immediately regretted that I missed that discussion.

Now, I decided to start a short video series around the topic.

• “Why do you want me to write wong code?”
• “Why is Red so important?”
• When do you stop to fake?

In the last 7 videos, I answered these and other questions about the “Red” and “Green” phases of the test-driven development cycle.

Today I want to do a short recap.

I have been at the DevOne Conference Linz this year, and… It’s been a blast.

I have already been at some very well organized conferences, but this one was the best so far. The program, the food, the organization: Everything was very close to perfect.

Here’s what happened, my impressions and some opinions…

When you do TDD, “fake implementations” or “wrong code” are OK, as long as they pass all the tests you have so far.

But when do you stop to fake? When do you start writing “real code”?

There’s a rule that helps you decide: The “Specific / Generic Rule”.

“My current test does not test the final version of the feature yet. Should I change the test or add a new test?”

To answer this question, I want to talk about a concept called “Triangulation”.

All the code is tested. All tests are green. But you are at a point where you cannot possibly continue.

To finish the current feature, you would have to change all your code, breaking several tests. You wrote yourself into a corner.

What do you do now?

How do you know which test to write next? How do you make sure you make progress towards your goal, that is, towards implementing a feature that is useful to your customers?

The pair of programmers wrote a test. They ran it, and it was “green”. They started to write the next test.

I said: “Wait, stop it! Your test was green!” They were like: “So what?”

Today I want to talk about why “red” is so important in test driven development - Why you must see a test fail first.

“Why do you want me to write wong code?” an attendee asked me in the break of one of my test driven development trainings.

At first, I did not understand the question: “No, in an ideal world, I only want you to write correct code! That’s why I teach these trainings.”

Then he explained…

One of the first things you must learn when starting with test driven development - or TDD - is how to write a good, “red” test and how to make this test green.

And this is already harder than you might think.

A good red test constrains the implementation you are about to write in just the right way - not too little and not too much. It takes you one step closer to your overall design goal; that might still be pretty far away. It enables you to write an implementation that will allow you to make the next test red again.

To make the test green, you must write the smallest possible implementation that will pass the test. And most people I know were surprised - schocked! - how small is sometimes necessary.

Let’s talk about refactoring again: How can you move some code to different value objects using small, safe steps? In this video, I want to show you exactly which refactoring steps I take to extract a factory method, move it to one value object and move some code around it to another value object.

In my last video about “Refactoring Primitive Obsession”, I did all that very quickly to give you an overview about the whole process. I have added a link to that video in the description.

Today I want to show you a small step from this process and explain exactly what I did.

I sometimes teach test-driven development, or TDD, to developers who have never done it before. And at the beginning of those trainings, most of them struggle a lot with the first two steps of the “Red, Green, Refactor” cycle: How to write a failing test correctly and how to make this test pass correctly.

In this series of blog posts and videos, I want to focus on those first two steps: “Red” and “Green”. You can find all the parts of the series here:

“How did you refactor that?”

After my video about “Primitive Obsession”, a viwer asked me on Twitter how exaclty I refactored the code towards the final result.

Which steps did I take? Which transformations did I perform in the code?

In this video, I want to show you how I would refactor this piece of code to get rid of the primitive obsession.

Quick show of hands: Who here likes retrospectives? Who loves them?

Many people I have met so far would have kept their hands down. They would rather work on the next feature than sit in a retrospective.

That’s because, in many teams, retrospectives are boring and ineffective.

Did you ever see some piece of code that uses primitive data types, like Strings or integers, in it’s public API? I am sure you have, because most code is written like that.

But that can cause problems. Today, I want to talk about a code smell called “Primitive Obsession”. And I want to show you how code often becomes easier to understand and “nicer” by eliminating primitive data types - especially, but not only, from it’s public API.

Do you remember how you first learned about object-oriented software design? How they teach it at University?

You probably looked at objects from the real world and their is-a or extends relationships. A circle is-a shape, and it extends shape. A cat is-an animal, and it extends animal.

Today I want to re-visit this kind of approach to learning object-oriented design and discuss it’s advantages and shortcomings.

Test Driven Development, or TDD, seems to be very popular among some software developers, but most of us are still skeptical and not using it.

Those who use it say that TDD helps them to write better code faster. Those who do not use it often say they have tried it and it does not work.

How can some technique be very helpful to some people and not work at all for others? I think a part of the reason is what I used to call the “mock objects trap”, but now call the “TDD trap”…

Did you ever hear phrases like “Agile is not faster” or “You need to do un-intuitive things to become agile”? Did that make sense to you?

To me, in the beginning, those phrases made no sense at all. But now I think that they are the main reason why so many companies do not get “agile” right. They “do” agile only to become faster. But they do not “get” some of the most important underlying principles.

Today, I want to talk about a very important but also un-intuitive principle: You must slow down to move fast.

How can you, as a team, start with continuous improvement when your company does not want to give you enough time? And if they do not give you a budget to spend?

A learning lunch - where, once a week, you use your lunch time to learn something new - can be a great starting point. And it requires only a small investment of your team members’ personal time and money.

When we give a size-, effort- or time estimate, like “5 Story Points”, “7 ideal engineering days”, “this will be finished before End of May”, what does that actually mean? And how useful is the number?

That depends on what question we are actually answering with that number…

A lot, it turns out. Or, maybe, not “go wrong”… But the result you get might not be the result you expected.

This article is part of the series Planning Software Development.

Suppose your team must estimate the effort of the work packages (User Stories, …) it is supposed to work on.

This article is part of the series Planning Software Development.

When we develop software, people often will ask us questions like:

I already wrote quite a few things about estimation in this blog. But this is only a part of the picture.

Now, I want to collect some thoughts about software development. This page collects all the blog posts in this category.

Throughout my career, I tried to create some products (Books, courses, video tutorials, software). Most of them failed, especially the ones in the early years. They failed in a really un-spectacular way: People were not even interested in them.

And I think the ones that failed, failed because I wanted to finish them before showing them to anybody.

At conferences (and when talking to others), I often hear discussions about specific agile methodologies.

About the relative merits of extreme programming vs Srcum. About how SAFe is not actually agile (or why it is agile). About whether Kanban is agile or lean or both or none of the above.

Yesterday, I got dragged into a #NoEstimates discussion on Twitter again. It was a mistake: I really dislike how those discussions usually unfold. With all their half-truths and over-simplifications and attacking straw men and the passive-aggressiveness, most turn basically into a flame war. I think we need a more nuanced discussion, if we even need that discussion at all.

But I could not stop thinking about that discussion. So, here’s another blog about Estimates and other stuff…

Suddenly, in a large company that has been around for a very long time, the C-Level executives realize that something must change. Smaller, younger companies are out-competing them.

“Everyone else is doing this Agile thing. So we have to become agile too. From now on, we will all do Scrum!” (Or Kanban. Or SAFe. Whatever.)

Some days ago I tweetet…

Do (some of) your developers hate Agile? You need technical AND management coaching. Contact me - I can help, or connect you to people...

— David Tanzer (@dtanzer) 16. Mai 2017

Why do developers hate Agile? Allan Kelly has a theory, and according to him, it mostly boils down to three reasons:

I was fascinated with agile software development from the moment I first heard about it in an eXtreme Programming course at University. And when I was a developer in a Scrum team for the first time, I decided that I have to become involved in this “agile” thing / community.

Because of that moment almost 10 years ago, I started to learn more about Scrum, Kanban, Software Craftsmanship and other “agile” stuff. Because of that moment, I write on this blog, give conference talks and try to help people become better at developing software.

So, your Scrum Master (or product owner or some line manager) is out of office. She cancels the daily standup meeting, a.k.a “Daily Scrum”. Did that ever happen to you? Does it happen all the time? If yes, stop doing daily standup meetings. Yes, completely stop them.

You are not doing the daily standup meeting for the team. When it gets cancelled because a certain person is not there, you are doing the meeting for that person. There might be several reasons why this is happening:

This article is part of the series Your Company Will Never Be Agile. It is a case study about a company that successfully introduced devops to a big team.

This article is the second part of the series Your Company Will Never Be Agile. The previous part is Organizational Structure Prevents Companies from Becoming Agile.

Imagine you are a manager in a company that has annual budgets and bonus systems. A team that you are responsible for wants to work in a truly agile fashion (self-organized, re-planning every 2 weeks, working with emerging requirements, …). Do you allow them to do it? Under which conditions do you allow them to?

This article is part of the series Your Company Will Never Be Agile. It is a case study about a company that managed to stay small and agile throughout their history.

This article is the second part of the series Your Company Will Never Be Agile. The previous part is Your Company Will Never Be Agile - Intro.

In order to be good at software development, you need an organization that's optimized for software development Samir Talwar

Your company wants to become agile. Most companies want that. So they hire some consultants, do a couple of re-orgs, call their line managers Scrum Masters, and so on. And then they declare success: Development is a little bit cheaper now. But many of those companies with “successful” agile transitions did not really become agile. They don’t have real business agility or sustainable development or truly self-organized teams.

The ugly truth is: If your company is not already agile, it most likely will not become agile. Not within a reasonable period of time. Sure, you can do all the little rituals that Scrum mandates. You can even fully implement all the extra stuff that SAFe wants you to do. But this does not make you agile. This is not what I am talking about.

After my last article, Intrinsic Motivation and Technical Excellence, a reader of my newsletter told me that something I wrote is apparently diametrically opposed to something Uncle Bob wrote:

[...] when a company employs someone, the company is responsible for training the person to become the employee they want! Intrinsic Motivation and Technical Excellence

Whereas Uncle Bob wrote in The Clean Coder:

In my last article, I wrote about how managers are responsible for creating an environment where intrinsic motivation can happen. Here is one thing that I’m sure would help a lot of companies / teams:

Allow your people to achieve technical excellence!

I sometimes hear managers complain that their people are not intrinsically motivated. “We need people who love what they do, not the people we have, who are only here for the money!” Saying something like that as a manager is a bit ironic because…

You are in charge here. If your people are not intrinsically motivated, it’s your fault.

Earlier in this series, I wrote about what happens when management try to change people’s behavior with KPIs, targets and bonuses. Some will try to game the system, or your KPIs will cause unwanted behavior. If they find the right set of KPIs so that cheating and unwanted behavior become impossible, they’ll probably destroy motivation, morale and teamwork. But what if they find that right set of KPIs and manage to create an environment where everyone stays motivated and nobody quits?

In the last post from this series, “Bonuses and Wasted Resources: The Right Set of KPIs”, I wrote about how it’s really hard (or even impossible) to find a set of KPIs where cheating or wasting resources becomes impossible for the people being measured. But what if management can really find that right set of KPIs, that makes it impossible for people to cheat or waste resources? Now the performance of all employees will improve, right?

Turns out, no, you still have problems. It turns out, most (if not all) people actually want to do good work.

In an earlier article, I wrote about how competition and bonuses encourage cheating and waste. I wrote a personal example, where I eperienced that I cheated and wasted resources during a competition that didn’t even matter to me. I got a lot of positive feedback, including:

Not new, but a nice example of why metrics are bad: http://devteams.at/competition_and_cheating by @dtanzer Jens Schauder (@jensschauder)

Yesterday I was at TopConf Linz, and one of our speakers, Louise Elliott, wanted that everyone in the room gets a card with a red and a green side. She needed us to have those cards because she did some experiments where we could vote by showing either the red or the green side. But to me, what happened before the actual experiments was even more interesting…

Louise gave me and another person a deck of cards, and we should distribute them to the people in the room. I was to distribute them to the right side, the other person to the left side. And the side where everyone would have their cards first would win.

A couple of days ago, I wrote the article Well Crafted Code Will Ship Faster. It contains some reasoning why well crafted code is also cheaper and faster, and some ideas what you can try next to get there (like, “first do things right, then do the right things”). This article sparked an interesting discussion on Twitter.

We should stop using misleading generalizations for concepts that exist on a scale. That's my point. Benjamin Reitzammer

I agree the science we have is crap but does that mean we should stop trying? Christoph Neuroth

At a conference, I was listening to a talk by a “famous” speaker. I was rather unimpressed - He was switching topics in a confusing way, and the talks also was a bit boring. But it was OK(ish).

But then he based one of his arguments on the Chaos report. Now, you know, I am really skeptical when someone uses the chaos report - especially data from before 2015 - to back up their arguments. Especially when they talk about agile software development.

This is the third article in the mini-series “Why Do We Need Those Estimates”.

The reasoning goes like this: “Our customer only hires us on fixed price. We need detailed estimates to calculate that price, so we can even enter the bidding process”. Of course, there are variations to this reasoning. But the bottom line always is: We need estimates for our customer.

In this article I first want to discuss fixed price projects, and then move on to other ways for running a project. Then we’ll look at how estimates fit into this picture, and what kinds of estimates are useful and what kinds are not.

Next year, I will co-organize a conference about IT management. It will take place at the Slovenian city of Piran, right at the mediterranean coast:

www.advanceit.io

This is the second article in the mini-series “Why Do We Need Those Estimates”.

One of the reasons teams and managers need estimates is to know how far they are in the project and when it will be finished. The reasoning is simple:

• We know how far we are by dividing total estimated time by total elapsed time.
• We know when we will be finished by adding up all the remaining estimates.

I have worked with several clients who do detailed, task-level estimates (in hours). Or at least detailed story-level estimates (in Story Points or Person Days). And for most of them, their process seemed to work fine. From their point of view. But I always had the feeling that they didn’t realize their full potential. That there was some waste in their process. Of course, I also told them. They hired me as a consultant, after all.

Their answer (most of the time): “But we need those estimates!”

This, of course, begs the question…

I have seen some implementations of agile software development and heard about several others that faced major difficulties. Difficulties that shouldn’t exist in an agile project - Or that was what I thought. Then I re-read the Scrum guide, and the “three pillars” caught my particular attention.

Lately I have been writing a lot about Estimates and #NoEstimates. I am not particularily for or against estimates and estimating - I think they are a tool that can be used well or badly. I just got interested in #NoEstimates because of some things I have experienced in the last few years while consulting clients.

Here are some things I have seen regarding estimates and estimation:

I am still thinking about estimates and #NoEstimates, and I am still writing my findings down here. In the last article, “A Spectrum Of Effort Estimates”, I wrote about different ways of estimating software development effort. Today, I want to explore what an estimate really is.

Heute möchte ich über verschiedene Arten von Schätzungen schreiben – und die Techniken entlang eines Spektrums klassifizieren.

How can you get started with #NoEstimates when you use Story Points to estimate right now? Easy:

Just replace all story point values with “1”. Then use all the analytics you used before to make predictions and do planning.

Ok, that’s a grossly oversimplified view on #NoEstimates, but it’s the gist of it. You can start now.

In this series of posts I will describe how the agile doctrine [1] relates to the agile manifesto [2]… For example, “Individuals and interactions over processes and tools”: The frequent interaction of developers, testers, product owners and customers will reduce the distance between problems and problem solvers.

“Agile Doctrine”, as defined by Jason Yip, is:

Does your agile team need to improve? Yes it does, no matter how good you already are - because continuous improvement is a main characteristic of agile software development.

This free course will help you with your continuous improvement initiative.

But where do I start?</a> Maybe you just got started with agile software development, so you don't really know where to start. Starting can be very hard for teams and individuals who are not used to doing continuous improvement. Either you do not see any improvement opportunities because you have developed so many blind spots over time. Or you see so many improvement opportunities that you do not know where to start. Maybe your team has been working together for a long time, and you have reached some kind of plateau. Retrospectives are getting boring, and you only find minor improvement opportunities anymore. Maybe you have deveoped some new blind spots over time: You have solved all the obvious problems and got used to the rest. So you are looking for new ideas. This course will teach you to find out where and how to start.

Will this be another wast of my time?

Some email-courses only dump information on you. You get an email once or twice a week, read it, and forget about it. After them, you have learned a little bit. Still, you feel like you have mostly wasted your time. This course is different: All the e-mails you get focus on acting. With every email you'll have something to do, a little exercise to solve. First, you will assess your current situation. Then you will plan your improvement effort, based on the assessment. After that (and even during the course), you should start improving. In the coming months after the course you will receive three more emails. Those should remind you to stay on track with your improvement plan and give you a chance to contact me with any questions you'll have. All of this will happen on a time scale you can easily handle. Improving an agile team is a long journey. There is no need to rush at the start. You will get an email every week for five weeks, each containing a little exercise and all the information you need to do it. You can easily do the exercise within the week until the next email arrives, without disrupting your day-to-day work. Every week you also get the chance to ask me clarifying questions and to ask me for help with the exercises. After five weeks, your improvement plan will be sketched out and you can get started.

Why should I trust you?

I have been working as an independent consultant and coach since 2006. During this time, I was on different agile teams in different roles (Developer, ScrumMaster, Coach). I guided teams who were starting with agile from scratch and mature teams who were working togehter for several years. Teams where I was a developer had hired great external coaches and trainers. I learned a lot of them. I was always interested in how teams can work together efficiently. I read many different text books about this topic. I spent a lot of time reading and writing blog posts. I discussed ideas with coworkers and people I met at conferences and industry events. I wrote blog posts and spoke at conferences about these topics and got valuable feedback. This course contains my compiled knowlege about assessing your current situation without wasting too much time and planning improvements based on those assessments.

What can I expect from this course?

In this five part email course, you will learn how to improve your agile software development process. In the first three parts, you will assess your current situation. You will assess how you currently define work packages for your team, how your team works together and the quality of the software you are creating. Then you will define where you want to be and find ways to get there. The course provides you with a structured framework for assessing your current situation and planning the next steps. After the five parts, you will have a concrete improvement plan. But the course does not stop there: I will send you three more emails. They will remind you about your plan and hold you accountable. They will also remind you to contact me with any questions you might have.

This course is for you

Are you a Team Leader, Product Owner, Scrum Master, Developer, Tester, ...? It does not matter what role you play on your team. As long as you are interested in improving, this course is for you. It might be easier or harder to convince your team to start the journey with you, depending on your role. But after this course, you will have some data and ideas that can help you convince them. Whether you work on an agile team or in a traditional environment, with this course you can learn about starting a continous improvement initiative. What you learn will help you to see where to start and to become un-stuck when you don't know how to continue. If you are interested in continuous improvement, this course is for you. Start it - it's free!

Get Started

You are now ready to take the free online course “Improving your Agile Practices”. You will receive the first email in the next few days.

If you have friends or colleagues who might benefit from this course, please tell them about it. You can send them the main page of the course, where they can find out more and start the email course:

Improve your Agile Practices: The Course

We use cookies on this site to enhance your user experience

The software we use to create this site sets cookies. We also use third party analytics software to enhance your experience, which sets cookies in its current version (as of June 2014). We also display content from other sites (Google, Youtube, Flickr, ...) which may or may not set cookies. We do not control these cookies. Please check the third party web sites to find out about their cookie policy.