What are "Cross Functional" teams?

A cornerstone of successful agile software development organisations is the “Cross functional team” but what does that term actually mean?

Being facetious, it’s exactly what it says on the tin – a team that’s cross functional. However setting aside sarcasm, maybe the best way to look at it is by breaking it into its constituent parts: “Cross Functional” and “Team”.

The Cross Functional bit

There is a common misconception that the term cross functional implies that members of an agile software development team are Jack-of-All-Trades (and masters of none), able to turn their hand to anything required. While to a certain extent that is the case, in reality what this means is that the team itself should have all the necessary skills within it, rather than the team members. That way the value of having people with deep specialist knowledge in their chosen area of operation is not lost. They need to be aware of those other skills, maybe even have capabilities in them, but they don’t need to really know them provided there is someone else on the team to cover that particular base.

So what are those skills and what is the right mix? Here is my take:

•          Software Development (Coding). On average, ~60% of the team need to be coders
•          Test focussed, ~20%
•       The sort of person who could be a great coder but is primarily focussed on automated testing. Testing is a mentality and it’s important and different enough to require someone who will champion the practice within the team
•          Ops/DevOps ~10%
•       Someone who knows about build/deploy pipelines, networks, etc.: the operational work to deploy and run an application
•          Other specialists. The rest of the team can be made up of people who can provide whatever skills the particular problem requires, the main three would be:

o   Analysts

§  Someone who understands requirements elicitation or system analysis

o   Database people

o   Ux designers

The Team bit

To be effective, the team needs to work together well. It can’t be a collection of mini silos who don’t communicate with each other. Perhaps the team dynamic is almost as important as having the necessary skills and Google have done some very interesting research in this area. The results are covered in this presentation by the inspirational Matt Sakaguchi here https://www.infoq.com/presentations/google-effective-teams . I really would urge you to watch it in its entirety, but the main finding is that there are 5 attributes that are crucial to creating effective teams. In order of importance these are:

1.        Psychological safety – people feel comfortable taking a risk or asking a question and know they will be supported by their team mates
2.      Dependability – the knowledge that team mates will deliver quality outputs and meet their commitments
3.       Structure & clarity – the team has well defined roles and responsibilities, everyone knows what they are supposed to do and they do it 
4.       Meaning – the work has personal meaning to the individual team members
5.        Impact – the team members can see the value they bring to the greater good through their work

And that teams with these attributes consistently outperformed other teams (including teams of “Rockstars”/Superstars) by a significant degree.

The size of the team is also important. If it’s too big there are too many lines of communication for them to be effective. If it’s too small they won’t have enough folk to be effective. Scrum recommends a team size of 7 people +/- 2 (i.e. between 5 and 9 people) and Amazon’s Jeff Bezos famously defined optimum team size as never being so big that they could not all be fed with two pizzas. Putting actual numbers on it can be a bit woolly but there is good science behind it http://blog.idonethis.com/two-pizza-team/ .

Cross functional teams are crucial to success, so it’s worth paying attention to both their make-up and their behaviour.

Reactive forms in Angular 2

Angular (aka Angular2) gives us two ways to create forms: template driven and model driven (aka reactive). The model driven approach provides several advantages:

•         They are more testable
•         They are more dynamic
•                Forms can be built at runtime “on the fly” without changing the application code
•          They are easier to maintain
•                              All the logic is in one place

Reactive/model-driven forms do not use Angular directives such as “ngModel”, “required”, “disabled” etc. Instead of relying on the Angular framework to power things for us, we use the underlying APIs instead. Instead of binding Object models to directives like template-driven forms, we declare and create our own instances inside a component class and construct our own JavaScript models. This has much more power and is extremely productive to work with as it allows us to write testable, easier to understand code that keeps all logic in the same place instead of scattering it around different form templates.

Importing the ReactiveFormsModule

The first step is to import the ReactiveFormsModule (as opposed to the standard FormsModule) into the module that will contain your model-driven form. e.g.

import { ReactiveFormsModule } from '@angular/forms';

@NgModule({

  imports: [BrowserModule, ReactiveFormsModule….

FormControl

Each element on the form is mapped to an instance of the FormControl class. It tracks the value and validation status as well as offering a set of API methods for accessing the form data.

The declaration of a FormControl class takes as parameters (in this order):

1. Initial value & state (e.g. disabled)
2. Any synchronous validator, or array of sync validators
3. Any asynchronous validator, or array of async validators

See the API documentation for more details: https://angular.io/docs/ts/latest/api/forms/index/FormControl-class.html

Here is an example declaration:

zipCode: FormControl;

zipCode = new FormControl({value: '', disabled: false}, validators.required);

This code declares a variable of type FormControl, then assigns it to a new instance of the FormControl class which has an initial empty value of and is not disabled. It also has a sync validator of “required”.

FormGroup

A FormGroup is just that – a grouping of FormControl instances. At the highest level it represents the form itself, but FormGroups can be nested to represent sub-groupings that can make the form easier to manage. Other advantages are:

•        Allows validation at a FormGroup level. E.g. the “submit” button could be enabled/disabled based on the valid status of the FormGroup, which in turn would depend on the valid status of the FormControls in the FormGroup. It would also allow us to implement custom validation
•          FormGroup provides a convenient way to declare many controls at once. An array of FormControls can be constructed, e.g. from reference data or a backend service, then passed into the constructor of the FormGroup

Example declaration:

    const form = new FormGroup({

         firstName: new FormControl(‘Tim’, Validators.minLength(2)),

         lastName: new FormControl('Hodkinson'),

       });

       console.log(form.value);   // {firstName: 'Tim', lastName; 'Hodkinson'}

       console.log(form.status);  // 'VALID'

 

Binding to the template

The final step is to bind the code to the html template. We do this using the Angular [formGroup] directive  to bind an html form on the template to the FormGroup. We can then use the formControlName  directive to bind individual FormControls in the FormGroup to the html form control elements using the name key. For example:

<form (ngSubmit)="onSubmit()" [formGroup]="form">

      <label>Firstname:</label>

      <input type="text" formControlName="firstName">

      <label>Lastname:</label>

      <input type="text" formControlName="lastName">

      <button type="submit">Submit</button>

</form>

In the code above [formGroup] binds the html form to the FormGroup we declared in the last section, which we called “form”. The inputs are then bound to the firstName and lastName FormControls in the “form” FormGroup.

Clean Code - What is it anyway?

It's become a meme that the tech industry is in the middle of a tsunami of change and a lot of software houses are running scared that they are going to be the next Kodak or Blockbuster - the octopus that sees the hungry dophin coming, but doesn't change colour fast enough to avoid being eaten.

After a decade or so of stagnating in a marsh of mediocre talent, idiotic management and poor standards, denigrated and career repressed , it has suddenly become cool to code again. Companies are suddenly seeing the value in those socially inept code monkey losers as they realize just how hard to find and hire their special skills are. 

Amid all this there has arisen a movement calling itself software craftmanship, which even has its own manifesto: http://manifesto.softwarecraftsmanship.org/ 

Among all this there is much talk of "Clean Code". So it’s worth spending some time asking the question: Just what is “clean” code?

While being a familiar concept among software professionals, it’s fair to say that the concept Clean Code was first comprehensively defined in a book by “uncle” Bob Martin called “Clean Code – A Handbook of Agile Software Craftsmanship” first published in 2008. Martin begins the book by asking “What is Clean Code?” of several of the most respected leading lights in the field (Bjarne Stroustrup, Grady Booch, “Big” Dave Thomas, Michael Feathers, Ron Jeffries and himself). Their responses are remarkably consistent. 

For them, clean code:

• Is readable
• By human beings, not by compilers
• Is easy to understand by someone other than the person who wrote it
• It uses meaningful names
• It isn’t too long and meandering
• The design is easily understood
• Is adequately commented
• All intention cannot be conveyed simply by the code logic itself
• Is concise and to the point
• It does one thing well
• It does not contain duplication
• It minimizes the number of entities (classes, methods, functions etc) required to implement the design
• Has automated unit tests
• Has minimal, explicitly defined dependencies
• Provides a clear and minimal API
• Is cared for and maintained
• Dave Thomas uses the analogy of the “broken window theory” 
• They advocate adopting the Boy Scout Rule

Each of these deserves its own post in itself, but the overriding message is that, above all, “clean” code is really an attitude. It’s about taking a professional approach to writing software and continuously improving the code you work with.

Cold eye has risen from the dead!

"That is not dead, which can eternal lie...." H.P. Lovecraft memorably wrote this about the Elder God Cthulu who lay sleeping under the waves, waiting to one day return. Like Cthulu, this blog has been sleeping for many years. I'm now resurrecting it (hopefully not like Cthulu) so you can look forward to posts on tech, agile, angular 2 and all the other stuff that drifts past me in the near future. Looking forward to re-making your acquaintance.

 

Burn-up Charts and MuSCoW

Every one knows about burn-down charts in Agile software development: They are a great metric for tracking progess on a project. Less well known, or perhaps I should say less well understood, is another type of highly useful metric: the burn-up chart.

Burn up charts are great for overall project planning and quickly assessing the impact of additional or changing requirements.

Once the release backlog has been estimated into story points, and you have a velocity (or estimated velocity) of how many story points you can get through per iteration, the next step is to make sure the backlog is ordered on the MuSCoW principle: ie. Must-have, Should-have, Could-have, Will-Not have (Yes it is a bit convoluted).

• Must Have– if these features aren’t in, the product cannot be released
• Should Have– important but success does not rely on it
• Could Have – nice to have in, but can be left out if necessary
• Will-Not Have – not this time

You then can map these out with the y-axis representing the story points int eh backlog (i.e. scope) and the x-axis is the number of iterations (i.e. time/schedule).

Its then pretty easy to plan how many iterations should be needed to complete all the “Must-haves”, the “Should haves” and “could haves”. The sponsor can then decide how much of the non-vital functionality they are prepared to pay for (in terms of time). Similarly, if you add story points by adding or changing requirements, the graph line shifts up, and the point where it meets the x-axis moves out: The number of iterations required to complete the new functionality increases.

Example below:

The IJTC: where was everyone?

I've just returned from 2 highly informative and enjoyable days spent in Dublin at the Irish Java Technology Conference (IJTC). Hosted in the extremely cool new Science Gallery at Trinity College, speakers included various movers and shakers in the Java world. Now in it's second year, the IJTC offers the opportunity to hear directly from the horses' mouths information on the more significant events currently causing the seismic ripples in the Javasphere, a somewhat rare opportunity for those of us living and working on the Irish Island.

Charles Nutter provided 2 sessions: One giving an overview of the front-runners in the non-java languages that run on the JVM (JRuby, Groovy, Jython, Scala and Rhino) that if we are not already using, we will be soon. His second session concentrated on his specialist subject, JRuby, and showed how the productivity gains offered by Ruby on Rails can now be combined with the power and scale of the Java programming language.

On a similar theme, the ever entertaining and enthusiastic Guillaume Laforge covered Groovy and Grails. Sam Brannon from Spring Source outlined how to develop web applications in an OSGi environment using SpringSource's new DM server. Jasper Potts from Sun gave us a look at JavaFX 1.0 and the potential it offers for rapid development of genuinely cross-platform rich internet apps.

This year's conference was sponsored by JBoss, so had a strong Red Hatted flavour, with speakers covering Jboss Cache, Drools and Messaging.

Besides all this there were also sessions on developing software for international markets, Data Grids, agile software development, SOA, cloudware and just about any other the other current buzzwords you can think of.

All in all a great conference and at €229.00 for both days, incredible value, which leads on to something that genuinely puzzled me.

As far as I could judge, the total number of those attending the conference couldn't have been much more than 40 people. Given the price, the quality of the speakers and the topics being covered, it seems astonishing to me that among the thousands of people who work in software development in Ireland not even 100 of them could see it as useful or possibly of benefit to avail of this great opportunity right on their own doorstep. IT is a fast changing world and conferences offer the best way to stay on the crest of the wave. Personally I usually try to attend at least one conference a year, and what I learn at those usually ends up informing what I work on for the next 12 months.

As the economy continues to nose-dive the onus to work ever more smarter, to take advantage of advances in technology to give us competitive edge and to do more with less, grows ever greater. You would think that Ireland's IT folk would be keener to grab anything that can help competitiveness, or are we just too complacent, or perhaps even arrogant?

Agile Zealots and the problem with agile terminology

Any change needs people to drive it forward, particularly if it involes breaking or changing existing working practises, or introducing new ideas. Agile software development is no different.

One very effective way of spreading Agile techniques through an organisation is to have small groups of interested, informed people (communities of interest) who can work on developing agile processes and techniques, spread the word about agile and provide coaching and mentoring to adoptors. Having dedicated people who are interested in the subject, and who collaborate on developing it tends to give agile adoption within a company a impetous all of its own that top-down management directives can't always achieve: sort of like the way a viral marketing campaign can be more effective spreading the word about a product than a multi-million pound advert slot shown during the break in "Coronation Street".

On the other hand, communities of interest can also tend to attract agile zealots. These are the sort of folk who see agile software development as some form of religion or political movement attempting to overturn 200 years of corporate economic enslavement going back to the industrial revolution. You probably know the sort of folk I mean: They also tend to be incredibly intolerant of anyone who is not "agile" and even more intolerant of heretics who don't follow their particular true, pure form of the agile path.

These people are a disaster. Before you know it, your communities of interest will be more splintered than the People's Front of Judea as the one that favours Scrum will either be refusing to communicate with the folk who use Agile UP, or worse: actively trying to undermine their work. Soon the rest of the organisation is getting confused, mixed messages and those reactionary folk who are against the whole thing anyway will be sitting back smugly with crossed arms saying "I told you so: This whole agile thing is just a recipe for chaos."

I just found out that one of the agile communities of interest in the organisation that I work in has decided to call itself the "Agile Liberation Front". Never mind the fact that since 9/11 terrorism just isn't sexy and cool any more, this is a prime example of this sort of thinking. Calling yourself something like this promotes the idea that you are some sort of subversive, radical element which no doubt is great for the self-esteem of those involved and makes them seem a lot cooler than folk who write computer programs for banks normally are, but its the sort of thing that makes senior management run a mile. Ultimately, the support of senior management is vital to the success of agile adoption in a company.

On the wider point of terminology, the agile community does not do itself any favours by its choice of jargon. Terms like "Scrum Master", "Sprint", "Pigs & Chickens" etc. appeal to early adopters (the "dude that’s cool" sort of folk) as it gives an aura of something new and different. However, when large financial organisations and mainstream corporations start adopting things, these terms actually tend to become a barrier to further acceptance, as they seem a bit silly or frivolous for management with years of experience in large Fortune 500 enterprises. The point being that there are already perfectly good, well understood terms for these things already: (e.g. Project Manager, Iteration and Stakeholders). Scott Ambler entertainingly rants about this in this presentation.