Sunday, 13 December 2015

Agile Architecture == Reactive Manifesto

These days the Agile label is passed around like the peace pipe. Therefore this article answers the question:
"Is Agile Architecture just another marketing exercise on the Agile band wagon? Or does it really exist? And if so, what is it?"
We want to be Agile. Everyone is at it. However we would also like our Architecture to be Agile too.

But what is meant by Agile Architecture?

It seems most people miss-represent it as a flexible process towards Architecture delivery. Or just modelling the process in a using established design techniques. In other words how people should do it, rather than what it actually is.

This is why a lot of people talk about how Architecture can live and work with the Agile team, rather than what Architecture an Agile team should be actually be delivering.

From the Agile community here are some examples of Process, Design and Modelling masquerading as Agile Architecture in the How rather than the What:

Process Examples:
SAFe Agile Architecture [1], Agile Architect website [2], Agile Architecture Process presentation [3], Agile and TOGAF [4].

Disciplined Agile Framework (formally DAD) [5] and presentations on Agile Design [6], more Agile Architecture with Design Modelling [7].

Agile Modelling Method [7]
All this does not tell us what it is. We need a definition of what an Agile Architecture should be, before we wonder how to do it.

Luckily this has been done for us. In July 2013 several industry veterans (most notably from the company Typesafe) got together to publish a document called the Reactive Manifesto [7].

“We believe that a coherent approach to systems architecture is needed, and we believe that all necessary aspects are already recognised individually: we want systems that are Responsive, Resilient, Elastic and Message Driven. We call these Reactive Systems.”

I shall leave the reader to explore the Reactive Manifesto further, but rather than visit all of the areas within it, it now becomes clear that this not just a manifesto but an architectural approach. TypeSafe on their blog [8] themselves state it as well:

“we believe it is the architecture for the future” and also ....
“to become the default way of writing applications in the future”
Reactive Manifesto

Agile Link:
Then the question becomes is it an Agile Architectural approach?
Reviewing the Reactive Manifesto areas for agility we can directly relate them to the Agile Manifesto [9] like so:

“builds end user confidence, and encourages further interaction”
is aligned to the Agile manifesto like so: “Customer collaboration”

“parts of the system can fail and recover without compromising the system as a whole”
is aligned to the Agile manifesto like so: “Working software”

“can react to changes”
is aligned to the Agile manifesto like so: “Responding to change”

Message Driven:
“communication allows recipients to only consume resources while active”
is aligned to the Agile manifesto like so: "Individuals and interactions"

As is the Agile way it has evolved to next version with this Blog entry on the next version 2.0 [10] of the Reactive Manifesto.

Thus it has evolved through iteration just like my poster and this is why since version 3.1 of my Agile Development Poster [11] the Reactive label has been added as part of the Strategy section.

It is clear to me that the Reactive Manifesto is what Agile Architecture really is. Hence the title of this blog post.

As is the case with Agile now we know the What, how you implement the Agile Architecture is up to you.


[1] SAFe Agile Architecture:
[2] Agile Architect:
[3] Process Presentation:
[4] Agile and TOGAF:
[5] DA Modelling:
[6] Agile Design:
[7] Reactive Manifesto:
[8] TypeSafe Blog:
[9] Agile Manifesto:
[10] Reactive Manifesto 2.0 Blog:
[11] Agile Development Poster: 

Sunday, 25 October 2015

New Poster Update: version 3.1 released

Over time we learn and evolve. Updating and improving the original Agile Development Poster.

The Poster like my knowledge of Agile, Lean and Kanban needs an update.Well I have managed to update myself. This leaves the Poster.

Presented here is the updated poster to a new 3.1 version. It is also published in PNG format and at an improved resolution. The previous JPG version while small did not produce a decent image. The trade off though is now it is much larger at 8.5mb. It should also print fine in Black and White.

Finally it has been retrofitted to the original blog post to avoid confusion.

New Elements:There has been two changes to the Values. Respect has replaced Automation and is a Scrum value [1]. The obvious Customer value has been added [2].

Visibility also includes two changes. Production now has an improved image representing the spikes of activity that can occur during peak times. The original image has be-reused to represent a CFD (Cumulative Flow Diagram) [3]. This replaces the burncharts which become redundant compared to CFD.

Some will recognise the CFD as a Kanban trait and they would be correct with more Kanban elements that have been added. Such as Limit WIP [4], Forecast (replacing estimation) and Lean Flow [5].

Other additions include: 
DoR (Definition of Ready) [6]
DoD (Definition of Done) [7]

Which are from Scrum and also represent Kanban Explicit Policies [8]. Reactive stands for the Reactive Manifesto [9]. Story Mapping [10] and Road-map MVP [11] provide acknowledgement to Product Owners everywhere.

The rest is mainly as it was before. Use if you need otherwise click on.


[2] Agile Manifesto Principles:
[6] DoR:

Friday, 17 July 2015

Review of the Certified Scrum Developer (CSD) course

I have noticed that there are not many reviews of the Scrum Alliance CSD [1] course on the net.

According to the Scrum Alliance Member Directory [2] not many people do the CSD. At time of writing this is less than 3 thousand out of 330 thousand members. Less than 1%. I presume most are often preferring to do the CSM and CSPO to garner the points for the CSP. Is this because most of them are not Developers and avoid it? Who knows.

Anyway this post will cover my recent experience taking the CSD course and the exam. Hopefully providing insight to others who may wish to take the CSD in the future.

After many years doing hands-off Agile Coaching my technical nature got the better of me and I moved into a more Technical Agile Coaching Delivery role. Despite the Business often courting me to cross-over as a Lead Product Owner, I never relented. It was good to be back in the depths of the techie world.

But I had a problem, while I have always kept up to date on technology, the practical side hadn't been battle tested for a while. I needed to get back in the trenches. How to solve this?

The CSD I believed provided my answer and so it came to be.

The first issue I hit was the CSD is not readily available like the other Scrum courses. So, finding a course was hard. Then it got harder.

Most of the CSD courses have a requirement of knowing GIT (no issue for me), bringing your own laptop and coding in C#.  Now if we are all honest most developers sit on either the C# or Java side of the fence. I am a Java developer so, this became the next problem.

In reality your looking at either CSD C# or CSD Java. Where to find the Java version in the UK? It became quite hard and I even searched abroad for a CSD course.

Luckily one company in the UK Agil8 [3] do have a CSD Java variant that they run now and again. That’s the one I went on. Later on the course all the students remarked that they had the same tough experience searching for the Java version. Which seemed to surprise the course instructor. 

As is well known it is a 3-day course and most of this was spent coding practicals on the laptop, as well as going over the XP [4] concepts.
So, where is the Scrum in that? Well some of the Scrum concepts are covered on the course, but it has been of great debate within the Scrum community that the CSD should exist at all. According to the Ron Jefferies [5] the CSD is needed because:
"It has become clear, though, that on the average, Scrum teams are not getting the benefits that they might, and that one reason is that they do not figure out what technical practices to use."
And the course solves this by providing an:
"understanding of what the basic practices are, and experience to show why they are necessary"
Thus the course it seems to me for a Developer in a Scrum team, is more about learning good development practices such as XP to support your Scrum deliveries than knowing the Scrum process. That is what the CSM is for. Here is a diagram to support that view showing how Scrum encapsulates XP with areas of direct intersection:

Amongst the practicals, Agil8 taught the theory behind many of the well known XP practices on the course such as:
Acceptance Testing, User Stories, TDD, Red-Green Bar test patterns, Test First development, pair-programming, PARTI, Test Frameworks, SOLID, Agile Architecture, Agile Modelling, Refactoring, Code Smells, Mocks, Continuous Integration and more.
Many of these including Scrum are of course represented within my Agile Poster too [6].

This was performed by referencing a hard-copy ring-bound presentation of over 100 slides. A lot gets done in those three days!

On the last day there is the exam. It was 50 multiple choice questions within 45 minutes.
An example of such a question could be:
Q: Which one of the following best describes code that smells?
     a) Code that works but is hard to understand
     b) Code that has no tests
     c) Code that has no comments in it
     d) Code that is more than a year old
I managed to pass with a 96% pass rate, only getting two questions wrong. I would say it is slightly harder than the CSM, but you can run out of time if your not careful.

Agile Link:
Well it's Scrum!

The course provided what I needed. A refresher on good developer practice within a Scrum team. For me it was money well spent and Agil8 delivered the quality training I needed. This is not a course for the non-coder though.

I recommend that only people who like developing should go on this course as it is heavy on practicals.