During July 14-17, I will give a training on Steering Agile Architecture on the Praslin island in the Seychelles. The technical program will be complemented with social interactions to allow the participants to go in-depth and learn from each other.
The training is organized by Kumbayja, and the package includes hosting. There are a couple of places left, and if you are of interested, please contact me.
Next week, during March 3-4, I will give a course at GOTO Academy on Steering Agile Architecture. The registration form can found on the event website.
The course is based on the humane assessment method and it offers a novel and practical approach to dealing with architecture in an agile project. It is based on interactive sessions, it offers live demos, and exemplifies the lessons through real-life case studies.
Humane assessment is a versatile and generic method. That is both a strength and a weakness. The strength is that it can be applied in many situations. The weakness is that it is perceived to be too distant from concrete scenarios that development teams face.
To bridge the perception gap, I have started to look since a couple of years for classes of problems that are concrete enough to be directly applicable. The first one is that of steering agile architecture for which I designed a 2-day course.
The concept of architecture started to regain traction recently. For example, two new industrial conferences were launched recently on the subject [1] [2]. That’s a good thing.
However, there are still quite some open questions as to how architecture fits within agile development. Of course, the main focus still tends to be placed on how to create architecture, and less about how to deal with the existing one. Humane assessment fills the latter space quite well. Specifically, the daily assessment process helps teams to make architecture concerns explicit and keep track of what goes on in the system. That is why the course is not about good or bad architecture. It’s about knowing the real architecture of your software system, and choosing to how to steer based on that reality.
If you are interested in working with me, please drop me an email.
Here is a teaser video.
On January 23, I will give a half a day tutorial on Humane assessment as part of the SI-SE event on Managing technical debt (Zürich).
This tutorial is a shorter version of the Humane assessment primer course and it focuses on examples coming from real-life case studies. If you want to start the new year with a dynamic view on how to make software engineering decisions, this is a good opportunity.
The official description goes as follows:
Humane assessment is a method for making software engineering decisions. Assessing software systems to make decisions is a critical activity that needs to be approached explicitly during development. Read more about humane assessment at humane-assessment.com.
This tutorial offers an example-driven introduction in the method. It requires general technical knowledge and it is targeted both to technical managers and to software engineers.
The examples cover the essence of humane assessment:
- why assessment is economically important (hint: because you already spend some 50% of the development budget),
- how adopting crafting analysis in-house can solve the problem,
- how to integrate it in the development process,
- how to embed it in the organization, and
- how to support it via a new breed of tools (all examples are based on moosetechnology.org).
On Wednesday, November 20, I will give a lecture on software assessment to second year students from the University of Bern. The lecture is part of the introductory course to software engineering, and it comes right after the software quality one.
Software quality tackles things from general to the specific by instilling rules that might have an impact on future development. Software assessment goes the other way around and offers skills and tools that help developers tackle specific problems. Interesting enough, the easier software assessment is, the more quality there is.
Assessment is tough to teach outside of a real context. The problem with context is that you have to be in it to relate to it. Talking about it in general can be entertaining, but it has less impact.
The setup of the course happens to require the students to work in teams and to develop actual projects over the course of the semester. In this particular case, they have to build Android apps. To make them relate to the idea of crafting custom analysis, I will use their own systems to exemplify assessment scenarios.
In the meantime, here is a teaser picture showing the system attraction view for each of the 9 systems. The grouping shows the systems that tackled the same topic. The visualizations reveals that even when tackling similar requirements and even in a short amount of time (a handful of weeks) distinct teams will produce radically different structures. Software development is a complex game and we have to approach it accordingly.
