A Good Stand up

 

A Good , Stand-Up

The light goes green , the door opens and i walk into the secure area, my team area is immediately to my left and already i can feel the buzz, the passion the energy coming from my kiddies as they discuss, code and pair.

The clock ticks by and there is electric excitement in the room as they make their way to the stand up area, i follow.

The story wall is to my left as i walk with purpose into the room the team are gathered in a semi circle around the board awaiting my arrival.

Standing in front of the team i see in there eyes and alertness that leaves behind the night before, the early morning starts, the arguments with the partners – there focus is on me. With my arms clasped behind my back , i open with welcome to the morning stand up team, today we will be Awesome i follow this with a intense and bright smile.

My eyes fix on each team member as i watch there body language , there eyes, the position of there stance looking for anything that might be a tell , or out of place or indicate to me that this person is not 100% ready for the days tasks, some thing i may as Team leader have to deal with, i ask each member to describe how he feels in terms of weather i hardly notice the verbal replays as i watch there body language – my team is healthy ready , charged, energised no weak points this morning.

Each member quickly talks about what they did yesterday , what they will do today and any blockers which i take actions to handle.

I say to them , ‘ Lets play, be awesome out there and remember we are the elite’ the team leave the room – talking chatting about the cards they will work on, the challenges they will conquer today.

I meet with my senior team and talk to them briefly about how we must look after the team and about the deadlines and the meetings i had had with management the day before and the medium to long term projections. The seniors leave the room empowered.

Top Level Points 

# Always be on time

# It docent matter how your feeling be full of energy be positive your team draw there energy from you

# Your main job is not to police the cards it is to LOOK AFTER your team and to spot issues before they happen

# Become a expert in body language , get to a point were you can read your team

# Be prepared to proactively go to bat for a team member

# Support your team remember there is no bad teams only bad team leads – if there is a problem in your team find it deal with it don’t let it spread like fungus

# Above all remember these are your people , your kiddies your responsibility your not there to police deliveries or process your there to support and grow your team the deliveries and process will come as a consequence of this.

# In a team , to the outside business it must never be a individuals fault , the team including you takes responsibility for everything the happens good or bad

# Don’t take credit give it to the team, the team will make you shine

Becky martin

New Social Site – To be hosted on Azure

Recently i have started working on a new social network engine with built in communications network using knockout and Signal R asp mvc 4.5. 

This site is currently in the planning stages but will be built to be hosted on Azure. 

Sample page layouts below

Social Nest frontpage  with colourblock for home  v4

Chat page 

22052012 chat section basic release1

John Mitchell and I recently presented on Agile and Azure the perfect marriage of elastic scalability and requirement driven functionality.

 

We are intending to present in more depth at a conference in summer on the subject , plus we are already booked to give a extended talk in Manchester at the end of this month on the subject – dates to follow.
The cut down set of slides are available here and we are happy for anyone to use them and modify them as needed to promote Agile in Azure.

Slides: http://www.box.com/s/nqfo6lixkcmcvfu1668k

If we can be of any help to any team out there trying to find a relationship between Agile and Azure please do contact me and we will be happy to either offer advise or consult as required.

Agile or WAgile – Discussion : Agile Part 1


Introduction

This post represents the first half of a pair of posts which will attempt to lay out some fundamental techniques which i have found helpful in delivering projects that are on time and fit for purpose, in this first post i would like to examine the difference between Agile and what is commonly referred to as WAgile. In the second post i would like to talk about requirement gathering using stories and prototypal design.

At the heart of Agile techniques is a principal of known as people over process, let us for a moment focus on one of the intrinsic component’s of this principal – ‘Collaboration’ – when we collaborate with each other we get more done, this is a historical fact proven in many aspects of life including great engineering achievements from the channel tunnel through to huge military campaigns.

When we collaborate in the Agile setting we need to enter a mind set which can be quite alien to traditional project management, due to the blame avoidance culture we typically find in hi $$ projects we tend to find abstraction and deflection in use rather then clarity and inclusion, this is generally driven by the fear of ‘Showing ones dirty washing , as it were’.

 

For projects to succeed under the Agile banner we must become a team composed from a number of organisations working to achieve an end goal ‘ producing a fantastic fit for purpose deliverable’ for this to be really achieved the boundaries between roles within the project ecosystem and their associated rights and privileges must become so blurred that typically in time they become background noise and new project centric roles spring into place which are flexible and distinct from the persons employing organisation. In short the team becomes a cooperative matrix of team centric players within the project ecosystem, rather than employees of one of the contributing companies.

 

If you do not feel it is possible to facilitate this type of relationship with the client and the other parties involved,  other techniques might come into play such as the use of a ‘Internal Customer’ who can be the bridge between the client and the team. However this is not optimal and many projects find themselves gradually slipping into a waterfall style methodology consequently blaming Agile for a failure when in fact they were not practising agile but a hybrid methodology that is classically referred as WAgile process – see the diagram below for how this might look.

Diagram : WAgile in action

Agile ciommunication in wgile setting v5

Within the Agile space there are 2 primary approaches to Agile Development

  • Scrum
  • eXtreme Programming

It could be argued that there are other front runners such as DSDM and then we must also consider the LEAN methodology sets as well, the distinction between different flavours of Iterative development techniques  is becoming increasingly more blurred as this group of methodologies gather a growing number of converts each contributing their distinctive flavour to the community.

However ‘What is Agile?’ is beyond the material I wish to discuss in this post , so let us instead accept that there are a number of buckets of techniques which all at their heart have the principals of the Agile Manifesto (http://agilemanifesto.org/) the guiding principles of which I quote for convenience below:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

As you can imagine with this amount of scope for variation an agile environment can take many shapes; so instead of trying to cover each possible variation, I will provide below a diagram which illustrates some of the common factors that can be found in a Agile environment:

agile-diagram-for-publication-v5

The biggest differentiator between the WAgile illustration  and the Agile illustration is the communication dynamics between stakeholders, the team, we also see a distinct difference in the team value statements.

Commentary

The WAgile environment uses artefacts such as project plans , long meetings , vast swathes of documentation to try to provide an accountable environment were every thing is locked down to the following factors:

  • Who takes responsibility for doing it
  • How long will it take
  • Who holds liability if it all goes wrong
  • Who’s going to pay for it
  • What is the immediate profit margin on the work
  • Do we project that this will take us over budget
  • The above quite often translates into stress / toxic pressure expressed as can we push elements of the team harder to get this done faster

While there are important issues illustrated in these points, trying to mitigate them creates a huge risk to project completion. Classically the techniques used in a Waterfall / WAgile environment to constantly answer and document the above points leads to a lack of freedom and flexibility  and a total inability to do what is needed to just get it done at the coal face. It should be noted that we also generate a environment of fear where people and companies are scared to take risks, once there opinions or improve quality.

With the on-going need to document everything and to have a paper trails for all aspects of the project, we find we end up creating roles within the team who’s sole job is to protect the company or shift liability onto other individuals, partners or companies. Thus it can easily be seen that in the attempts to lock down the Cost, Liability, exacting time frames and Risk – we find that making even the smallest movement in the project space has huge cost and requires layers of sign off and discussion this effectively knee caps the teams ability to flex to changing conditions and to innovate when the opportunity presents itself. All of the above leads to teams creating yet more documentation in attempts to fully lock down requirements in advance including some of the following documents which quite often make for miniature novels they are so great in length.

  • BRS [Business Requirement Specifications]
  • Static Wireframes
  • Business flow diagrams
  • Huge Class diagrams that document architecture which might not be needed
  • Ultra high quality creative tied down to the exact pixel
  • In depth NFR’s [None Functional Requirements]
  • Massive Risk logs which at times almost go as far as to include acts of god

Worst still for the team is the fact that most of the above form some sort of reference material within the overarching contractual agreement which generally means making changes to them takes a huge amount of time, effort and stress. One of the other factors to add into the mix is that quite often the wrong people have written these documents or the right people have written them under huge time pressures – the end result is tends to be more a set of hand-cuffs as opposed to empowerment.

The Agile environment drives for the concept of people over process, as such the number of inflexible paper artefacts are reduced, meetings tend to take the format of time boxed [normally 15 mins or less] whole team meetings these are quite often known as touch point meetings. In terms of risk most teams tend to practise ‘Don’t put off for tomorrow what you can deal with today‘ This can take the form of writing technical debt cards and having a regular technical debt review cycle or more preferable dealing with problems as they pop up.

The classic Agile environment will also try to practise philosophies like ‘Better to ask forgiveness , than to ask permission’ in general the the Agile player is a brave soul who just gets in there and gets it done, he can afford to work like this because of the tight communication across the team elements regardless of discipline he/she is given further confidence by knowing that team shares:

  • Shared Code Ownership
  • Shared Feature Ownership
  • Shared Liability
  • Shared responsibility for getting right
  • The team practises open communication and transparency across all discipline
  • Fear is not part of the team culture
  • The team makes joint decisions in transparent meeting and the concept of ‘Command and Control’ has no place in the Agile teams culture
  • Personal Ego is left at the door
  • Team Ego and identity of team self is implicit to an agile team
  • One is none , two is one [Pair Working – across planning, programming and all other applicable activities within a agile team]

One of the techniques an Agile team frequently borrows from Lean methodology is the concept of a [Red flag], this concept says that no matter a persons position inside an Agile team that person can raise a red flag , physically , by Email, by calling a meeting when they believe things are going to come off the rails and the effect of this action is everyone no matter their position stops and there is a conversation to put the situation right before the team continues.

The one main driving force behind an Agile team is not who’s fault it is , a true agile team even one split across organisations operates on a Zero blame culture because it operates on a understanding that everyone is doing there absolute best to achieve one single aim – Continually deliver high quality , demonstrable software that is 100% fit for purpose and it is this one aim that members of an Agile team no matter the company they represent or the horizontal stripe to which they belong in the ecosystem strive for, and this is one of the biggest differences between WAgile / waterfall and true Agile, true agile concerns itself totally with delivery not politics.

I as the author of this post can understand that the above statement may seem naive in the high dollar industry in which most projects live, but I would challenge back to you and ask you one simple question – would you bet all your process , artefacts and safeguards against project success – because an empowered agile team given an even playing field with a bought in client will be successful and will deliver with low bug counts and high feature saturation.

Emergent Design [Overview]

30 Second Overview.

This technique says that ‘As our requirements are implemented so our underlying design will emerge’ although it is likely that we will have made some over arching decisions such as the client application will be Silverlight we will use RIA services and so on.

In simple terms the design decisions are delayed until we are driven to make them by following our Tests and the artefacts produced by those tests. So there is no upfront design phase and no need for a architect or technical lead as all members of the team are equally empowered and responsible for architectural decisions as they get to the point a decision can no longer be delayed.

Emergent Design says also that all developers in the team are equally empowered and there is no need for a tech lead or over arching solution architect / design authority although you may still need a gate keeper for the domain / domain architect to enforce company wide design options and integration between systems.

Using this principal, communication is imperative across the team , headphones should not be warn in this type of environment information saturation via Osmosis is beneficial as is courage to speak if you don’t agree with something you over hear.

It is also a classic aspect of this type of team that documentation will live in card task lists and although at a seconds notice any team member will be able to draw for you on a white board the solution architecture no architecture diagrams will be produced and generally Visio is a dirty word as each member would expect his colleagues to be able to run a white board session to explain the current architecture therefore making diagrams a outdated slow moving asset that has no place in a emergent environment.

Some of the advantages

  • Fast iterative cycles
  • Flexibility within the architecture to change as the requirement dictates ( flock of swallows principal )
  • Spread of architecture knowledge across the team
  • High quality development , is achieved by architectural chooses under continual review by all developers
  • Highly empowered and motivated team
  • Distributed code and architecture ownership
  • Encourages small checkins and atomic coding practises
  • Highlights weaknesses in the team quickly and encourages individual and team level skill patching
  • Iteration 0 /1 is a productive iteration rather than spending it debating architecture
  • With this style of team everything is immediate you see it , you deal with it very little technical debt is built up as the team will feel uncomfortable with passing by a architectural issue and not solving it immediately, this could probably belong in both challenges and advantages though i see it as the latter speaking from a personal stand point.
  • This method tends to lead to a lot of code reuse and due tot he high rate of refactor that is performed with this method the code tends to be of a very high quality with very little fat and subsequent lower maintenance foot print.
  • Because the code is under continual review by the whole team plus the reliance on B/TDD techniques the bug count at point of release is normally very very low.

Some of the challenges

  • Recruitment becomes very difficult as all the people on the team must pass a minimum bar there is no room for juniors on teams practising this principal, or passengers. ( Principal the team is in this case as strong as its weakest member and as fast as its slowest pair )
  • High code churn as the architectural changes are implemented on the fly across the whole solution not just the focus of that particular card , a architectural refactoring must be cross cutting across preceding code as well as the current card scope.
  • Team must communicate verbally , its imperative that the person proposing an architectural change communicates that change to the rest of the team and they respond in a speedy and honest fashion – fast white board sessions are ideal for this ( hint: time box), there is no place to hide in this sort of team.
  • Velocity can become uneven as people make large refactors, reducing there perceived productivity.
  • This technique does not work well in distributed teams, with out implementing a lot of overhead.
  • It is imperative that there is a understanding of you touched it you own it , in other words just because you didn’t write it , doesn’t mean you can see something you disagree with and pass it by and mentally think ‘ oh well its not my code’.
  • If used with teams that lack maturity or teams that have an element within them that has not brought into this technique , this technique can cause a lot of animosity.
  • It is imperative that this technique is practised with full test coverage , a solid CI (Continuous Integration) it is generally a rule with teams that practise this approach that the code base is constantly deliverable, demoable and a candidate for shipping should it be required, any high risk development is done in a branch and then integrated and generally is spik’ed out first.
  • This technique works best in self organising teams and works badly in command and control style structures.