Technical activities and practices

Technical activities and practices

Thomas Ringling and I recently created a small maturity model for technical activities and practices, that we would like to share.

We used it recently, in a presentation on technical practices that could help mature a development team and improve code quality. The participants were 19 agile coaches, many of which did not have practical experience with software development and therefore could use an introduction to technical practices, so they in turn could inspire the teams.

As Thomas and I went over the list of techniques and practices that we thought appropriate, it became quite clear that we had more material than what could be covered in a single session.

Another thing that we were very aware of, was that some practices require that you master other practices as well. For instance, there is no point in setting your sights on Continuous Delivery if you do not master a whole other range of techniques like unit testing and automation.

As a result we decided to use a maturity model we have been working for another project, as we needed both to limit the content we would go through and also that the content was context relevant. Some practices would be far more relevant than others, depending on the capacity and skill sets of the teams.

At the presentation we asked the coaches to try and assign the level of their current team and then select activities that seemed interesting, inspired by the model.  The coaches grouped up in groups of two to three and spent around 15 minutes, finding activities that seemed like candidates in the catalog.

We then dot voted on the subjects and presented them one at a time in the order which had the most votes. Sitting in a circle we introduced the top subject and didn´t pick the next subject until the participants were content and had all their questions answered.

It worked out beautifully and it was also great fun!

After the session we were a little bit excited about how well it went and thought perhaps others could use the model in a similar fashion or at a team retrospective for example.

Now before going into details I just want to make it perfectly clear that these activities were freely selected by Thomas and I and they are in no way a complete or definitive list. You can also debate if the activities are placed correctly in the levels of the model, it is only meant as an inspiration.

And finally, we decided to leave architectural patterns out, as they did not match our requirements at the time, but we will probably include those later (like DDD etc).  The only exception is Hexagonal architecture, which we feel is almost an epiphany of earlier/lower level patterns and practices put together.

Now that we got the disclaimers out of the way, we would like to present our take on a technical maturity model, linked directly to technical practices.

 

The maturity model

The purpose of this is to help find interesting practices a team could take on. There are two ways you can do that with our model.

  • You can try assign a maturity level to your team, using the Software Development description or see which activities you are currently doing on the team and then find activities in the level above or at the current level.

 

  • You can read the “Why” section of each activity in the catalog and see if you are experiencing some of the pains described there, to help find candidates for team activities.

 

The catalog

The catalog is a compilation of one-pagers about the practices shown in the maturity model.

The descriptions will start explaining why you would consider this particular activity and what problem does this activity address.

Perhaps there is a word of warning in the “Be aware” section, in case there are some common pitfalls you need to be aware of.

Finally there will be a short description of “What” the activity actually is, often linking to more resources on the subject.

 

 

If you or someone you know needs some inspiration for technical activities, why don´t you give this model a spin and we would love to hear any feedback on the experience and you are also very welcome to contact us, if you have questions or comments.

In goAgiles long experience with Agile Transformation in many different companies, this is becoming painfully clear to us. If the people that are actually building the products (SW, HW, etc) do not have technical skills that Agge and Thomas are talking about, then no process optimization what so ever will have any effect. "Have we not known this always" some might ask. It's just becomming so more transparant with Agile ways of working, where there is "nowhere to hide". I hope that Thomas and Agges ways of mapping the various technical competencies into a maturity path can help organizations better understand and support the continious education and development of the people that are ultimatively building the value.

Like
Reply

To view or add a comment, sign in

More articles by Agge Kempff-Andersen

  • Startup søger mage... (teknisk partner)

    Kære netværk. Jeg har den store glæde at være blevet mentor for et spændende startup der hedder Foopla Foopla vil gøre…

Others also viewed

Explore content categories