So, should a Scrum Master be a skilled programmer? In my eyes: Definitely yes!

Why? Well, I think, that is quite obvious. One aspect of the the Scrum Master role is his responsibility for the team. The Scrum Master has to improve the team. There are a lot of facets of what can be improved, one of these are programming skills for sure. Improving the programming skills lead to better code, to clean code in best case. If a Scrum Master finds his team (or a part of it) needing some help in that area, he has to coach it. First, this requires that a Scrum Master is able to recognise this. And second, the Scrum Master must be able to demonstrate to the team better techniques, best practices, and so on. (This is not meant as a prescript for the team. It is more a hint how things may go better. Still, the team can decide in what way it wants to work.) Therefore, to fulfil this part of his role, the Scrum Master must own programming skills!

By the way: Meanwhile, it should be clear what my understanding of a skilled programmer (or better: skilled developer) is. It is not only the knowledge of one or more programming languages, frameworks, and development environments. It is rather the things, that CCD comprises, behaviour/test driven development, domain driven design, design patterns/principles, just to name a few… I think, both sorts of skill are requirements for a skilled programmer which make him a skilled developer then.

Regarding the title of this post, it really feels like being on the developer’s next evolution level. Many things have become clearer to me. As I wrote before, most of the clean code ideas are not new, but they are brought together and verbalised in a quite concise way now.

One of the main points of the CCD approach is the perpetual focusing on a subset of the CCD principles and practices, i.e. on the different CCD degrees. That means, although having reached the final degree and thus keeping in mind all principles and practices, one works on the “coloured” degrees with their specific focus again and again. This is because repetition is a good teacher. Additionally, the principles and practices are not fixed, they are changed or modified from time to time. For example, the degrees comprised rules at the beginning; these have merged into the principles and practices completely.

Definitely, I will follow this track!

Some of the sponsors were present with exhibition stands. For me, that was informative and useful; e.g. I took home some information about a WPF control collection which could help us to solve a problem we a currently facing in my company.

I really like these community conferences. The information given there are absolutely useful for the daily work for the speakers take their topics “from life”. Additionally, it is nice to share experiences with other participants.

The dotnet Cologne this year was held on the occasion of the launch of Visual Studio 2010 and the .NET framework 4. So, the talks, which were organised in altogether 30 sessions and 4 tracks, more or less dealt with these two aspects. That was a quite condensed programme. Even the lunch break was used for sessions! I was this time mostly interested in parallel programming, code contracts, and some goodies of the new .NET framework.

As last year, the sessions were great due to the high expertise of the speakers! The whole conference gave you the feeling of bringing you to the technological state of the art.

What was the benefit at the end of the day? First contact to new technologies or a deeper insight into it, new programming techniques, hints for your daily work - just to name a few.

Of course, there was a raffle at the end of the conference. And you may guess right that I was one of the numerous winners - this time, it was a book.

Not only from my point of view, the conference was a great success. Thanks to the organisation team - absolutely well done (again)!

Thus, I currently focus on these principles and practices:

• Principles
  • Architecture and Implementation do not overlap
  • Implementation reflects Architecture
  • YAGNI (you ain’t gonna need it)
• Practices
  • Continuous Integration (Setup & Deployment)
  • Iterative Development
  • Component-oriented Development
  • Test First

Here, we find a perspective slightly apart from the mere coding. Principles and practices both point out in their own way the relation of design/architecture on the one hand and realisation/implementation (in terms of program code) on the other. Design/architecture may be regarded as being one abstraction level higher than realisation/implementation.

The principles make you keep an eye on the distinction between architecture and realisation. In my point of view, at least the component-oriented development practice can be seen as a result of the implementation reflects architecture principle.

Besides architecture, other aspects of the software development process are involved here. Iterative development and test first address specification: Tests can be regarded as some sort of specification; iterative development results from continuous specification refinement. Finally, continuous integrations reminds you to install an automated setup and deployment mechanism here.

Just to mention it: The YAGNI principle is quite important, so it is repeated within the blue degree.

In summary, this CCD degree focuses on the embedding of the coding part in other aspects of the software development process such as specification, deployment, and architecture.

Green is the 4th CCD degree and emphasises:

• Principles
  • Open Closed Principle
  • Tell, don’t ask
  • Law of Demeter
• Practices
  • Continuous Integration (Build & Test)
  • Static Code Analysis (Metrics)
  • Inversion of Control Container
  • Share experiences

The principles focus proper class design and lead to loose coupling. The same is true when making use of a container. Continuous integration and metrics increase productivity, for they check your software quality automatically. Once more, there are no rules at this degree.

I think I can rush through this degree, because I use these principles and practices (almost) every day. There is one exception: I have to get more interested in the code metrics, for I have really lost sight of that.

Sharing experiences - that is what a blog is for, isn’t it?

About 180 people gathered at the Microsoft building in Cologne. They were presented a very good programme. The speakers were great, the topics of the talks were great, too. The talks were arranged on two tracks most of the time.

For me, it was a quite valuable event. I gained a lot of practical insights into WPF and Silverlight. In particular, the talk on the data binding mechanism in WPF attracted my special interest. As usual, the discussions with the participants during the breaks were interesting as well as inspiring.

In addition, which made the day valuable for me in terms of money or development tools, I won a ComponentOne Studio Enterprise licence from the closing raffle.

Thanks to the organisers and I’m looking forward to the dotnet Cologne next year!

The yellow degree emphasises:

• Principles
  • Interface Segregation Principle
  • Dependency Inversion Principle
  • Dependency Injection (without Locator or Container)
  • Liskov Substitution Principle
• Practices
  • Automated Unit Tests
  • Mockups
  • Code Coverage Analysis
  • Partiticipation in technical conferences and meetings

Here is my attempt of a very short subsumption as I did in my post on the previous degree: The principles of the yellow degree support proper design and architecture, they enhance testability in the same way. This is required for the practices (except the participation in conferences), for these concentrate on (automated) code testing. (There are no rules here.)

Stefan Lieser told me, that together with Ralf Westphal he tried to build thematic bundles for each CCD degree. As I can see so far, they did a good job.

Once more, I am aware of almost all the elements focussed at my current degree. In general, most of the principles, rules, and practices presented on CCD are well-known. The purpose of a CCD degree is to concentrate on the elements of that degree and to try not to violate them. By this, they hopefully will become second nature to you.

The NHibernate Profiler provides a lot of valuable (technical and statistical) data on the current activity:

• SQL statements per session with additional information: Details, stack trace, and alerts. Alerts are some warnings which Ayende explains on his website.
• A session usage report: Number of entities loaded, entities loaded, duration, etc.
• A session analysis, e.g. View by Method which displays all SQL statements generated by a particular method of a module.
• Statistics not only on the sessions, but also on the session factory.

We have used it several times to see, what our modules using NHibernate internally do. In particular, the alert information have been extremely valuable for us.

Obviously, there are still some minor bugs in the beta version of the tool. For example, we get a Use of implicit transactions is discouraged alert although we only have explicit transactions.

Usage

In order to debug an application, the client for monitoring the activity has to be started. This client provides all the information explained above.

The best way to make your application communicate with the client is to use log4net, for the application (and the solution/project) does not need to be changed in any way in this case (provided that you already use log4net in your application). Just add an appender in the log4net.config file and make the required loggers use that appender.

Example:

<appender name="NHibernate.Profiler" type="HibernatingRhinos.NHibernate.Profiler.Appender.NHibernateProfilerAppender, HibernatingRhinos.NHibernate.Profiler.Appender" >
  <sink value="tcp://localhost:22897/NHibernateAppenderLoggingSink" />
</appender>
 
<logger name="NHibernate.Transaction.AdoTransaction">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>
<logger name="NHibernate.Loader.Loader">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>
<logger name="NHibernate.SQL">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>
<logger name="NHibernate.Impl.SessionImpl">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>
<logger name="NHibernate.Persister.Entity.AbstractEntityPersister">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>

As this example shows, the profiler appender class has to be referenced and a TCP sink for the communication with the client has to be declared. The defined loggers redirect the required information to the profiler. Finally, the DLL containing the profiler appender class has to be stored in the application directory. That’s all. When running the application, the NHibernate activities are monitored by the client.

You can (and due to the licence, you probably must) ship your application without the profiler appender class DLL. There is no need to modify the log4net.config file, though. The profiler appender does not have to be removed. log4net just complains (within its log file), that the particular appender could not be instantiated (because it was not found). If you do not want that message in the log file, you have to ship your application with a log4net.config which does not contain the profiler appender.

Another way to use the profiler is to reference the HibernatingRhinos.NHibernate.Profiler.Appender.dll and make the following call within the application startup:

HibernatingRhinos.NHibernate.Profiler.Appender.NHibernateProfiler.Initialize();

But as this means a change of the application code and requires a reference within the project, I do prefer the first kind of usage. Additionally, the application cannot be shipped when modified in this way. (Remember, you may not ship the profiler appender class DLL with your application.)

The orange degree emphasises:

• Principles
  • One level of abstraction
  • Single Responsibility Principle
  • Separation of concerns
• Rules
  • Source code conventions
• Practices
  • Issue tracking
  • Automated integration tests
  • Read, read, read
  • Reviews

A two sentences subsumption: The principles and rules of the orange degree support readability and understanding of source code. The practices are related more or less to the soft skills of a software developer.

The first degree was comparably easy, because I was already aware of most of its elements. Nevertheless, it took me almost two months not to violate the 21 day rule, which says, that you may not violate any of the aspects of your current degree for that time span before you go on to the next degree.

Just one remark: CCD defines professionalism for a software developer. The application of what is said there leads straight to better (i.e. higher quality) software. It was not expressed that explicitly in my first post on CCD. But it seems important to me.

Due to several circumstances it may be that you have a part-time Scrum Master, who has to switch between that role and the one of a team member. But there are several reasons for that a Scrum Master should do his mastering job rather than being occupied with working on Sprint Backlog items:

• The Scrum Master role defines a full-time job if it is taken seriously. Serving all the facets of that role consumes all of the Scrum Master’s available time.
• Having the Scrum Master role alone avoids conflicts of interests. How can a Scrum Master be neutral and propose an appropriate solution if there is a conflict between the Product Owner and the team, and he is a team member the same time?
• A Scrum Master has a better position for moderation if he is not involved in the everyday business of working on the Sprint Backlog items. This makes him have a more abstract and less emotional view on what happens during the Sprint.
• In case the Sprint Goal is in danger: I bet, a part-time Scrum Master will decide to concentrate his work on the Sprint Backlog items, neglecting his alter ego. This definitely results in a weak Scrum Master and means a danger for a proper Scrum process.

For sure, these aspects are even more important when you want to carry Scrum into your enterprise for the first time. At that time, obeying the Scrum rules is crucial for success. And so, the Scrum Master should not be distracted from doing his job. Part of this job is implementing Scrum and comprises - among others - creating an understanding of the underlying concepts in the mind of the people involved. He acts as a change agent!

If you do have a Scrum Master who is a team member also, you should check the option, that he is not the Scrum Master of his own team. This prevents him from at least a few conflicts of interests and puts him in a better position for his moderation jobs.

Fortunately, we recently had a change. We do not have Scrum Masters any more, who are members of the developer teams the same time. A Scrum Master now is responsible for up to four teams and the same number of Product Owners.

Just two more ideas concerning the Scrum Master role, which may lead slightly off topic, but I find them worth mentioning here:

First, when starting to implement Scrum or trying to do Scrum seriously, I advise a Scrum Master not being part of the company originally, i.e., he should not be recruited from the existing staff. This helps him

• to have a better standing towards the management. A prophet has no honour in his own country.
• to have a better standing towards the team as well. For the team members do not know him, they have an open mind to what he tells.
• to be impartial, because he can be more objective. He does not know all the internal things of the company at the time he starts his job.
• to find out the skills and abilities of the team, because he can have an unprejudiced look on it.

Second, I hardly dare to mention, that of course a Scrum Master has to be well versed in Scrum, agility, etc. in general and to be well versed in his role in particular. I.e., when the decision for doing Scrum is made, an experienced Scrum Master should be engaged. Furthermore, the Scrum Master role requires a lot of soft skills - first to mention communication skills. (But the latter is worth another blog post…)