This week I've been working with the System.Diagnostics namespace and in particular the Process Class.

One of our windows services on our remote servers has a memory leak and we are currently using various diagnostics to try and find the source, in the mean time, as a quick fix, I've extended a system that we currently use to check the health of our distributed servers.

I use the Process Class to pull the Process.WorkingSet64 Property for the designated process and do a check against a sensible max value for the process memory.

The Process.WorkingSet64 property gets the amount of physical memory for the working process, the working set memory is generally what you see in the monitoring tools in Windows Server.

We use Pingdom to continually monitor the state of our servers. Every minute, pingdom hits our servers and and triggers several diagnostics checks. With my new check, In the event the memory starts to become a little on the bloated side, I take the server offline and pingdom will send out a text message to the designated support team to let them know that the server is down.

I'm hoping to create a stand alone re-usable version of this that I can build on in the coming months, once I have something up and running I'll post it on my GitHub account.

Horses For Courses

I recently attended a scrum course with Mike Cohn, Mike is one of the biggest names in Agile and has written several books on the topic:

There isn't a lot that mike doesn't know about Agile, he's worked with teams in some of the best technology companies in the world. 

One thing Mike's course excelled in was stimulating conversation between the scrum masters in attendance. 

There were exercises sprinkled throughout Mikes content that often had me debating with one of the scrum masters on my table more than most, as the course went on i realised the reason this particular scrum master and I had such conflicting opinions was down to the maturity of our teams.

I work in a relatively new team that's gone through several transitions and is still not fully stablised, my counterparts team had been running for 18 months with very few staff changes.

Ultimately each team is individual and the only right answer on a lot of process specific questions is the answer that's right for the team.

Newer teams require more structure and a more metric, fact driven, approach to development and much more leniency when it comes to estimation. Once a team becomes more mature, more trust exists in the process and they can tweak the factors to meet the needs of the players.

With any new team it's always important to give them room to find their way and not to assume whats worked for one team can be replicated elsewhere.

Anchors & Propellers

So i'm not long back from a trip where I spent time working with our development team based in Singapore, we undertook a week long session with ThoughtWorks where they provide their 6 monthly Business Agility Review.

One of the first exercises we encountered was an exercise where we took two large sheets of paper and added the heading Anchors to one sheet and Propellers to the other, the development team were then given post-it notes and asked to provide examples of

Anchors: Things that are holding the team back and weighing down the development process, general negatives.

Propellers: Things that are propelling the team, increasing the productivity and agility, general positives.

Each of the team members gave their opinions and stuck them to either the anchor or propeller page.

Once all of the teams opinions were collected we did some groupings of similar suggestions and gave them general headings that encompassed the overall point. For example, we recently switched to Git as our source control system so several mentions of this were grouped under the heading of Git.

The result was some single post-it notes and some grouped post-it notes, the team was then given 3 votes per developer and asked to vote for the areas they feel were of the biggest impact.

At the end of the voting exercise we then took the 3 highest voted for points and did a dissection on what could be done to improve the anchors and ensure the propellers keep propelling.

In this instance the exercise was based over the last six months but it's certainly something that can be done by teams on a more regular basis, perhaps in addition to the regular sprint review techniques.

I'll certainly be bringing this in a fixed intervals to try and monitor the teams overall thoughts on process.

This isn't a scrum team

There's currently a huge problem in the software development industry, it's something that I've encountered a lot of recently whilst being involved in building a new development team and something that I've felt many developers end up with a fundamentally incorrect view of.

The problem is the understanding of the difference between Scrum and Agile.

Let's turn to wikipedia for a helping hand in a clear definition of both
Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

Scrum is an iterative and incremental agile software development framework for managing product development.

On the surface the differences between these two are subtle, the key being agile development defines a group of software development methods; scrum is a fixed framework that is fairly basic in structure yet complex to implement in a correct manner.

I can't tell you the number of times I've seen developers complain about something not being "proper scrum" and then go on to explain the incorrectness of the story points system, or how the user stories don't have enough information to estimate.

These are nothing to do with scrum, these are Agile concepts pulled from XP and other agile methods.

Scrum involves, players in the game, Product Owner, Scrum Master, Dev Team. In addition to this a software development structure; the sprint, sprint planning, sprint review and the daily scrum.

That's it, that's scrum.

Feel free to verify this and re-familiarize yourself with these concepts:
Scrum Guide

The rest is up to the individual scrum team to figure out, it's down to them to try out other Agile methods like story points for prioritisation and user stories for requirements gathering, the team can then figure out for themselves what works for them.

So developers take note, the next time you complain about the scrum process just make sure that's actually the problem and not your understanding of this quite specific methodology and the rules it's played by.