Welcome to BJSSinfo@bjss.com

BJSS Enterprise Agile

“Their maturity with Agile certainly sets them apart. Everyone you talk to at BJSS has fully embraced it. It’s a fantastic method and they’re great at coaching their clients through the process, especially if they’re unfamiliar with the strategy.” Vice President, Global 2000 IT Firm

How is BJSS Enterprise Agile Different?

Planning and delivery activities are driven by desire to eradicate risk early in the project. An architecture-centric approach coupled with early and continuous technical testing avoids late-breaking and expensive architectural changes and encourages the appropriate discussions regarding project priorities.
The applicability and scope of many agile methods is limited to software engineering, e.g. XP/Scrum – these methods therefore tend to become developer-led. BJSS Enterprise Agile expands this limited scope by adding a strong focus on sound management practices and providing guidance for the role of management.
Complete visibility of project status and issues is available to all stakeholders at all times. Comprehensive metrics support calibration of the plan and facilitate joint decision making, leading to a ’No surprises end-game’.
Based around a formal project structure to support early risk eradication and increased certainty of delivery and quality, BJSS Enterprise Agile includes sufficient formal business engagement to support incremental acceptance.
The approach has been proven to scale from small engagements, where it adds an appropriate degree of control, risk management and transparency to global enterprise system deliveries of greater than 100 man years with team sizes of 50 .
BJSS Enterprise Agile is built on our real world experience of delivering enterprise software solutions. It acknowledges and complements existing organisational governance structures whilst retaining the flexibility to scale to a wide range of organisation and project types.

Thought Leadership: BJSS Enterprise Agile

Making the Ascent – Programme Delivery Essentials

Six months ago I started climbing, or more accurately, Bouldering (no ropes, not too high and crash mats). I quickly learned that I needed to develop three things to be successful – the same things that are often required in many sporting, personal and business endeavours.

1. Physical strength and fitness
2. Technical ability to solve the problem and create a route
3. Mental stamina and belief

In the last few months I’d like to think I have developed in all these areas and will now quite happily tackle and achieve results to V3 problems. It is fascinating how these factors interplay with each other. Some problems require a little more strength and some benefit from more technical ability, but all factors come into play to some extent. State of mind also makes a huge difference – a fear of falling or a thought that you cannot do it usually means that you aren’t successful.

What does this have to do with Programme Delivery?

Well it struck me that actually Bouldering is the same as programme delivery in many ways. The same 3 ingredients are required for success:

  1. The strength (resource) to deliver
  2. Technical ability to identify the solution and create a route (plan)
  3. A belief held by the leaders and team that it can be achieved and the stamina to see it though to the end

All too often when I’m reviewing and recovering programmes in crisis I find that some of these basic ingredients are lacking. Frequently, as I did when I began climbing, people assume that additional strength is required to succeed. Whilst you need sufficient strength to complete the problem, applying too much energy can easily cause you to loose grip or balance and fall. The same is true of applying extra resource to a struggling programme.

There is also another element intrinsic to climbing that is required for any successful programme. That component is a clear goal. In Bouldering you have to climb and touch the top hold with both hands. Having a common understanding of the required outcome is also essential for a successful programme.

What happens when you struggle with the ascent?
In climbing you are working against gravity. The same is true of any change programme – if you stop and let go you fall back to the starting position. Organisations and the individuals within it revert to the previous state.

It is often the case that half way up the wall you get stuck. The same is true of many programmes part way through. Generally problems at this stage are due to a shortage of one of the three ingredients mentioned. At this point you can do a number of things. As already discussed more resource is only a solution if that is the genuine cause of the problem. Appropriate interventions in this situation are generally:

  1. Look around a try and find the solution yourself
  2. Take an independent view from someone on the ground
  3. Climb down and try again

Taking any other course of action or hanging in for too long without acting generally results in a fall. It is much better to make a controlled descent than fall and risk injury. Programme sponsors and stakeholders like to see that things are under control – even if that has to be a controlled change to the outcome.

A further challenge is often when your belief in the ability to succeed comes adrift from actual capability. I see this a lot on programmes when mid-plan challenges hit, stakeholders lose confidence and make personnel changes often based on perception rather than fact.

The power of coaching in sport is well established. It appears to be less so in programmes. Agile coaching is gaining momentum but is still some way from being accepted as commonplace. Help from friends on the ground has been incredibly useful for me while climbing both tactically in pointing out the foothold I haven’t seen, providing encouragement or just generally sharing ideas on problem solving. I believe the same benefit is up for grabs in programme delivery.

So what are the key elements for a successful ascent?

I find this analogy quite useful as a reminder of the key things required for successful programme delivery:

  1. A clear objective
  2. The right resource
  3. A solution (architecture) and a route (plan)
  4. Mental stamina and a motivated team
  5. An independent view and coaching

This probably seems like a very basic list, but all too often some of these basics are missed. In the menatime, I wish you a successful ascent!

Should we Measure Agile Delivery Teams?

A common theme in all my conversations with Programme Directors and senior stakeholders is that of delivery predictability. Nobody wants an unpleasant surprise on a project, least of all those who are funding it or reliant on the benefits it will deliver.

This concern is particularly evident in organisations embracing Agile delivery for the first time. Whilst it is easy to see the benefits of having empowered teams working directly with product owners, striking the right balance between devolving control to delivery teams and maintaining the appropriate level of governance and providing suitable direction is less straightforward.

Executives in any organisation are keen to understand what will be delivered, by when and at what cost. To answer, what on the surface appear simple and perfectly natural questions, many turn to reporting and metrics.

Should we be measuring the performance of Agile delivery teams? If so how do you go about it?

Clearly having measures in place is not a complete solution to predictability, “past performance is no guarantee of future performance” but you do need to know where you are in order to move forward.

A full exploration of Agile delivery metrics would take many more words than is sensible for an artcle  blog article but there are a few things that in my experience require consideration when putting in place delivery metrics and presenting data to stakeholders:

1. Have a clear objective

If you are going to measure the performance of delivery teams and meter your projects then start by asking, “Why?” and “What?” in order to be sure that you know what you want to get out of the exercise. Teams will be naturally suspicious and suppliers potentially defensive if they think it is going to impact their standing in the organisation or what they get paid.

Metrics should be targeted and focused on looking at what will provide insight into the direction of travel and the quality of the delivery. Ultimately any detailed measures need linking back to the overall Programme objectives and business case.

2. Whatever you measure will distort behaviours

What you measure and how the information is used will change behaviours within the team. This may or may not be a desirable outcome.

Thinking through the impact of any metric is essential. I’ve seen some pretty awkward measures being used in the past. For example, measuring developer productivity based on lines of code per day (seriously – people still think this makes sense!). This sends out a clear signal that more lines of code is what is required, but that is clearly not necessarily a desirable outcome – if not kept in check unnecessary duplication or deviation from a clear and simple design can occur.

There are of course times when distorting behaviours is exactly what is required and there is nothing like a prominent screen displaying a defect glide path or the number of failing tests on the build to focus attention on where effort should be directed.

3. Tell a story

Numbers in isolation are meaningless. People do not respond to purely charts and spreadsheets – they need to hear the narrative. Telling a senior stakeholder that you have a velocity of 52 or 187 open defects doesn’t tell a story, historic trends can help but don’t always provide the full picture.

As managers of technology delivery we add value by providing genuine insight and context over and above what the numbers are saying. Project managers should never just report the numbers but get under the skin of what is driving them and what the message is.

When reporting metrics it is essential to get to the root cause of any changes or deviation from expectation.

4. People are not machines

Buy-in and clarity of intention is essential if metrics are to be successful and to avoid demotivating a team or worse, inducing them to game the system. We are not measuring widgets coming off a production line but the process of creating a complex software system by highly skilled and highly paid professionals.

Getting the team on-board such that they not only get work with the process but also actively benefit from the information provided is a prize worth seeking. In fact, asking the team, “What information can we provide to our stakeholders to demonstrate the good work we are doing?” is a pretty good place to start.

I believe strongly that irrespective of what measures you agree with your team and stakeholders there are two key guiding principles:

1. Transparency – information should be taken directly from the teams and shared openly.
2. Traceability – it should be possible to relate data over time without changes in currency or dilution of measures.

So my answer to the question ‘Should we measure Agile delivery teams?’, provided these factors are take into account, is ‘Absolutely yes’ – it’s an essential part of keeping our stakeholders informed.

Metrics on their own will not guarantee delivery predictability, but without them you’ve no real way of having fact-based conversations about where you are.

BJSS Enterprise Agile underpins our software delivery engagements. It is a flexible approach that ensures success.

It combines over 20 years of practical experience developing distributed, high performance, high availability software systems with elements of methods such as XP, SCRUM and the Unified Process. It is a practical toolkit that promotes consistent delivery and is successful even in environments dominated by more rigid processes such as Waterfall.

Download the BJSS Enterprise Agile Book:

eBook format