Radtac was engaged in late 2012 with the objective of enhancing the quality and efficiency of the client’s software development process. They needed to achieve change while continuing to deliver important system and client updates.

The Client was using classic ‘V’ model for development, which was proving less effective as the demand to increase the speed of delivery was continually growing in an environment of accelerating change. Like most successful businesses, their software portfolio is a mix of modern development and legacy systems running on older technologies, and managing the prioritisation of new development versus serving their existing estate of customers is a problem that will be familiar to many of us.

In consultation a mix of coaching and coach led training, tailored to their particular organisation and context, was devised. Radtac conducted one-to-one mentoring with staff members in order to ensure that the learning was embedded by coaching in the environment of application. Through this approach the good transfer of skills and practice is achieved and retained through ‘coaching from the back of the room’.

The team was coached on a clear scope of work currently being undertaken through the use of a Big Visible Chart, in this case a Kanban Board was proposed and was highly effective. This approach identified the ‘stop starting – start finishing’ challenges of having too much work-in-progress and effective prioritisation of work items. The highest value work was the focus for completion, the Kanban approach allowed for the high level of volatility and reprioritisation and ordering of work.

On the technical delivery side Radtac has helped the client with the modernisation of their delivery infrastructure, installing modern Distributed Version Control Software (DVCS), static analysis and Continuous Integration (CI) software in order to automate the process of building, testing, measuring and deploying their software releases (e.g. CI through Atlassian Bamboo Server). As part of the engagement Radtac has delivered software quality training based upon Extreme Programming (xP) technical practices, backed up by one-to-one coaching from TDD experts in order to enable the teams to produce software that has fewer defects and is easier to maintain.

The client has seen quantifiable improvements in their software development process over the past 3 months due to the embedded coaching and delivery roles. Success was measured and it is estimated that £150,000 will be saved over the next 12 months alone against a cost of £30,000 or a 5:1 ratio on ROI. This shows that with effective embedded coaching improvements and value creation can be achieved without the need to ‘interrupt delivery’

Michael Short

michael.short@radtac.co.uk

0203 638 5040  

So what’s the difference between an Agile Fundamentalist and a Terrorist? You can negotiate with a Terrorist!

Sometimes I get ever so frustrated by the ‘Agile wars’ with people so entrenched in their view of Agile; I often see it on Twitter, in forums and also the odd dig at conferences. I have said it before and I will say it again, there is no such thing as ‘one size fits all’ and why would there be?

What is more important is to understand the current problem the team or organisation is currently facing. Then, drawing upon all the tools we have available from all the Agile methods and other approaches:

Create a hypothesis of what particular tool will solve the problem in hand

Create a safe-to-fail experiment to test that hypothesis

Run the experiment and validate whether it solves the problem or not (validated learning)

Keep the change if it is successful or try something else if it fails

Simples!

“This town ain’t big enough for all of us”. Actually it is and taking a blend of approaches and ideas and applying them appropriately to the context makes infinite sense. ”You mean use things from more than one method?” I hear you cry. Yes!

Am I passionate about Agile – you bet. But I am absolutely method neutral!

At the end of the day (did I really say, at the end of the day?) what is Agile trying to achieve? Well, working closely with customers throughout, ensuring that the final solution actually meets the customer’s needs, deferring decisions about detail as late as possible.

If there was a ‘silver bullet’ Agile method, wouldn’t every team adopt that and be successful? Of course the world just ain’t like that and that’s why we need to consider other ways to ‘skin that cat’.

So, I’ve been thinking! And indeed so have many other people! Below are three methods of applying thought to identifying and correcting problems in teams and organisations, all using the term “thinking” in their titles.

Systems Thinking

Systems Thinking is the process of understanding how things, regarded as systems, influence one another within a whole.

Systems Thinking has been defined as an approach to problem solving, by viewing “problems” as parts of an overall system, rather than reacting to specific parts, outcomes or events and potentially contributing to further development of unintended consequences. Systems Thinking is not one thing but a set of habits or practices within a framework that is based on the belief that the component parts of a system can best be understood in the context of relationships with each other and with other systems, rather than in isolation. ¹

The key element is to study your organisation as a ‘system’ and on the basis of the knowledge gained, re-design the system to improve performance. The real art is how you analyse the work, then how the design improves the performance and critically how to make the change. Argh, that change bit again!!

A3 Thinking

Is A3 Thinking a way to help you think or a report that helps you think in a A3 way? The A3 report is simply an 11” x 17” (I am old enough to still crave for imperial measurements) piece of paper divided up into several structured sections (what a Canvas – yep!).

The exact structure depends upon the type of A3 and the needs of the situation. A general one consists of the following pattern; however, there are many variations on a theme:

Background

Current Situation and Problem

Goal

Root Cause Analysis (the fishbone works well here!)

Actions Items

Check of Results

Follow-up

It is the act of committing to an A3 that forces you to think in A3! But it is a great way to visualise on just one page.

6-Hats Thinking

To help process the information and clarify perspectives, de Bono created an isolation strategy called the ‘Six Thinking Hats’. Each hat represents a thinking perspective; each perspective being represented by a different coloured hat. The objective? By isolating different perspectives and focusing upon discrete sections of the problem the individual or the group will be able to make holistic and multi-perspective analysis.

Six distinct perspectives are identified and assigned a color.

• Information: (White) – What information do I have? What are the facts?
• Thinking about thinking (Blue) – What thinking is needed? Where are we now?
• Feelings (Red) – How do I feel about this? What do I like about the idea?
• Judgment (Black) – What is wrong with this? Will it work
• Benefits (Yellow) – What are the good points? Why can this be done?
• Creativity (Green) – What new ideas are possible? What is my suggestion?

Coloured hats are used as metaphors for each direction. Switching to a direction is symbolised by the act of putting on a coloured hat, either literally or metaphorically. These metaphors allow for a more complete and elaborate segregation of the thinking directions.

In Conclusion

So what’s the morale of the blog? Life is a box of chocolates – you never know what you’re gonna to get. There are always different flavours.

Darren Wilmshurst

Head of Radtac:consulting

References

Wikipedia http://en.wikipedia.org/wiki/Systems_thinking

Imagine the scenario.  Your company launches a new change initiative “that will transform the company”. The exhortation is to get involved and make the change work. A central task force team has been formed to manage the change and they will be engaging with everyone very soon.

What is your first reaction?

Oh boy, here we go again, yet another change initiative, just like all the others that didn’t work either. I will just ignore it.

Sounds like you are suffering from change fatigue!

Oh boy, time to polish the CV as I don’t want to change, again. Get out while I can.

Sounds like shades of change fatigue, plus elements of disillusionment and personal resistance.

Oh boy, fantastic, finally everyone around me is going to be told to change to my way of thinking and I won’t have to do a thing.

I am enthusiastic that everyone else will change but I won’t have to. To quote Peter Senge:

“People don’t resist change, they resist being changed”

Or any combination of these, plus likely a few others!

The trouble, I feel, is that the language we use when talking about change and the models and frameworks we employ to implement it are possibly not in line with both the pace at which change happens and the new ways of thinking, like Lean and Agile.

Let’s start with the word itself – change.

The word is both a verb and a noun. The dictionary definition of each is:

verb:  “make or become different”
noun: “an act through which something becomes different”

Interestingly the synonyms include “transform”, another term we use a lot to describe the really big changes we are going to make. Incidentally another synonym is “mutation”!

What we should notice is that there is no explicit indication of whether the change is intended to have a good, bad or neutral outcome, it is just going to be different, although there is probably an assumed implication that if we change “X” then somehow things will be better. And if we do a whole lot of “change” then we will have “transformed” the organisation into something spectacular. It is certainly true that a lot of change will almost certainly transform an organisation, but into what?  

So are there any candidates for a better term we could use? Well, as I have already mentioned Lean, what about “improve” and “improvement”, which is the term used in one of its two pillars, “Continuous Improvement” (I will come to Continuous shortly). By using the word “improve”, it clearly indicates something is going to be done or changed with the stated intention of making things better. There is no confusion as to the intention (that does not mean the change will always work, but the intention is crystal clear).

This brings me on to the use of the word “continuous”, which addresses the second aspect of doing “change”, the models and frameworks that are usually deployed to carry it out.

The traditional thought is that to introduce a change or transformation, there needs to be some form of management to make sure it works. Hence change management is the order of the day, and there are many models and frameworks around. For example, the Kotter 8 step model is one that is well known. This lays out the steps that an organisation ought to take in order to ensure that the change initiative is successful and is well managed. For reference the eight steps are:

1.       Create Urgency

2.       Form a Powerful Coalition

3.       Create a Vision for Change

4.       Communicate the Vision

5.       Remove Obstacles

6.       Create Short-term Wins

7.       Build on the Change

8.       Anchor the Changes in Corporate Culture

The problem I see with these approaches is that they make assumptions, such as that the change can be defined and driven from the centre, that there is an end-point to doing change, that we can define up front where we want to be at the end, define how we get from where we are now to where we want to be, then close the initiative down when we get there. However, is it really possible in these fast-moving times to define up-front a vision of where an organisations needs to be on a long timescale measured in years? How are we expected to see into the future and predict what is going to happen? It is a good bet that the vision we had this year is going to have to change next year, as outside influences will make the original vision invalid. It is almost impossible to define a vision that will last, then work towards it. Is it not better to keep our eyes on what is happening around us now, then adapting and improving based on the conditions that we know about, rather than guessing? And to keep doing this on a continuous basis? That is what Continuous Improvement is all about. Toyota, where Lean originated, is still in this mode and is still working and improving on its systems and processes after decades. There is no defined end-point.

We know we need to improve, but we need to do it on a continuous basis, and these improvements have to be in the knowledge of what is happening now, not what we thought might be happening a year ago. Hence the model needs to be one of continuous improvement, which does not have an end point; it is just the way the organisation works. This is what Lean refers to as the “kaizen” mind-set.

So if we purport to be a Lean organisation then the only way to do it is to instil the practice of Continuous Improvement. Not have change initiatives run like projects with a start and an end. It allows the whole organisation to continuously inspect its environment and how the organisation is working within it, and then make continuous small adaptions of its processes to improve how it works within the current environment. And the whole organisation does this, it is not just limited to change initiatives or central groups, everyone is empowered and motivated to improve how they work for the good of the organisation, to allow it to meet its goals and aspirations.

By the way, “Continuous” means continuous!  That is, every day everyone is looking at their current situation and making the necessary adaptations to ensure they are always improving. Continuous does not mean having frequent “change initiatives” that address certain areas of the organisation. This is an often misunderstood principle of Lean. Agile teams have this practice built into their processes in the form of regular retrospectives at which they inspect and adapt their ways of working, usually at the end of iterations or Sprints. However, even that maybe not as continuous as needed, as a Sprint may be up to a month long. There is nothing that stops teams like this inspecting and adapting on a daily basis, via their stand-ups, and implementing small improvements where necessary.

So there we have it. By adopting the Lean principle of Continuous Improvement, we have a different way of talking about change that helps to remove some of the traditional resistance or baggage attached to the word, plus a model to enable us to carry out the necessary improvements, but focused on always being current and what the organisation needs at this point in time, in order to meets its goals and aspirations. It engages and empowers, the whole workforce to participate in the improvements making for a Lean organisation.

Sometime ago I asked if I could have a shed at the bottom of the garden, a man cave dare I say. Once my Spanish girlfriend agreed I ordered it straight away, I didn’t want her to change her mind, and in the process of my friends and I building it I was asked what to name it, the best selection was “The Rock of Gibraltar – aka The Rock” – it’s a little bit of England at the bottom of Spain…

More photo’s can be found here

I can hear the collective groan from here now; I can also hear the mutterings of the next question, why am I telling you this here?

Well it turns out my first assignment with Radtac was to go to the real Rock in Gibraltar.

Now what new can I say about Gibraltar, it certainly wouldn’t be “It’s a bit weird”, nor would it be new of me to say “It’s like being transported to the ‘80’s” and it wouldn’t be the first time someone has said “booze and fags are well cheap.” Gosh no, nothing new there.

What is new, well to my ears, was how I feel it’s the best bits of Spain and England all in one place. I would go as far as to say, if only certain areas of the Costa’s took notice.

Anyway, whilst it is important to understand a little about the area, I’m not writing a travel blog here!

One of the first things that stuck out to me was the willingness of the team to listen and learn from each other, a good team dynamic is half the battle when instigating change. It was also clear that a long requirements stage had been undertaken before I arrived which resulted in a large backlog.

So I decided to us Affinity Estimating. Affinity Estimating is a technique many teams use to quickly and easily estimate (in Story Points) a large number of User Stories. This is a great technique if you’re just starting a project and have a backlog that hasn’t been estimated yet. ¹

So we started by reading out each Story to the entire team. I then asked the team to arrange the stories horizontally on a wall in order of size, without talking. We placed the largest stories on the left and the smallest stories on the right. This only took a few minutes. I then gave them a final opportunity to make adjustments to the ordering, again without talking.

I then placed some numbers above the list of stories; in our case, I used the Fibonacci like number series.  Finally I asked the team to group the user stories around the nearest number.

I loved this estimating technique for a number of reasons: It’s quick and easy; it feels very natural; and, the entire decision making process is made very visible.

A really good way for teams to understand how this works is by playing the affinity estimation game….

With a random list of countries ask the team to put them in size order first.  Then get the team to re-size based on how long it would take to walk north to south.

To signify increase in complexity, add new countries (metaphor for requirements) but only showing the country flag; doing this helps to understand unknowns.

Finally, make it even more difficult by adding more countries but this time only showing the native country language script (i.e. not in Roman alphabet).

So…

“Got a huge backlog problem? Although I do not suggest having Product Backlogs of enormous size, I recommend that this exercise is used when you have more than 20 items to size. When less than 20 I find that Planning Poker or a more sequential approach may be more appropriate.

Keni Barwick

Ref 1. Lowell Lindstrom first described this technique

I have always had an aversion to fundamentalists, people who insist that their way of doing something is the only way to do something. I fear that a lot of people who specialise in delivery and management methods run the risk of being method fundamentalists.

A method fundamentalist fundamentally believes all or some of the following ‘facts’ :-

Their method provides the answer to all questions.

Their method must be applied strictly, all problems are caused because the method has been implemented in a non fundamentalist way

All other methods are at best wrong and at worst a direct attack on everything they believe in.

People who disagree with them are either stupid, misinformed or both.

When things go wrong when their method is utilised in real delivery and management environments (ie. when those annoying human being things are involved) it is because the people trying to use their method are cowards who do not have the courage to do their method ‘properly’.

Their method must be protected at all costs, any criticism is always negative and destructive.

The interesting thing is that the methods themselves do not mandate slavish implementation in a fundamentalist way; they are driven by idealistic principles and values, they are about inspecting what the real world is and adapting to meet the needs of that real world.

I’m a pragmatic idealist. I believe that delivery and management capability can be continually evolved to get nearer to an ideal state, however, that ideal state changes all the time. I want to achieve the ideal world, however I’m pragmatic enough to realise the ‘Ideal’ is different on a business by business and team by team basis; and that ‘Ideal’ evolves.

I don’t believe there is a single ‘silver bullet’ approach to managing and delivering Information technology within any single method, framework or tool.

I want to get as close as possible to the ideal world (as defined by the business) and will continually strive to achieve this by a pragmatic mix of best practice methods that evolve in line with the evolving ideal world.

I believe Agile methods have a huge part to play in any business management / delivery environment, however I also believe that agile is not THE answer, it is however a big part of the answer and that the ‘the answer’ changes.  I’m an Agile Pragmatic Idealist.

The Agile Pragmatic Idealist believes:-

Understanding agile is easy, helping human beings transform to being agile isn’t.

All methods and the people that create them have something to offer. Some elements of a method add value sometimes, sometimes they don’t; what adds values differs based on the environment.

People who disagree with the current way of doing things have a good reason for doing so, they are disagreeing because they care, they should be given a good listening to

Agile transformations that stick are implemented in an inclusive evolutionary manner.

We continually strive for the ideal state, however ‘Ideal’ changes depending on the environment………….and that continually changes as well.

The point of methods is to help businesses deliver appropriate quality products at the right time and cost; not to ensure that a particular method is done perfectly. 

A couple of quotes from a few famous people that I think demonstrate what I mean, can you figure out who they are?

Pragmatic Idealists:

We must learn to live together as brothers or perish together as fools. 

The only constant is change, continuing change, inevitable change that is the dominant factor in society today. No sensible decision can be made any longer without taking into account not only the world as it is, but the world as it will be

Method Fundamentalists :

As soon as by one’s own propaganda even a glimpse of right on the other side is admitted, the cause for doubting one’s own right is laid. 

In providing the impetus to change and transformation programmes, Radtac has developed a generic focus tool called the “Three Wall Workshop” (TWW). This is focussed on the general principles of Vision (Why), Strategy (How) and Tactics (What).

The TWW is to be used where there are needs for team development, project management, product delivery, visioning and strategic planning to name a few situations. The principles of TWW are to reverse common thinking within organisations, the TWW approach focusses on people and their need for a clear ‘Why’ they doing what they are doing, rather than ‘What’ they are doing.  A lot of processes within organisations are ascribed value e.g. social merit, return on investment, cash flow enhancement, product development, technical solution. What is often missed is the ‘Why’ they are being done.  It is not that the task or the ‘What’ is valueless, rather that within the confines of an organisation and its direction they have limited ascribable value to the organisation. To further emphasise this point, all organisations and their transformations are different, hence the need for coaching, and therefore this is not a process to define what is valueless within a market, only what has the least or no value within their organisation. ‘What’ you do should come from the ‘How’ you are to achieve things, the ‘How’ we usually put into personas and stories after understanding the ‘Why’.

Often the ‘legacy’ of ‘what we do’ and ‘how we do’ drives a Group-Think attitude to doing more of this ‘stuff’ without questioning Why. You will often find projects and programmes continuing within organisations at great pace and these programmes and projects then start to gather a momentum of their own, what can be described as self-driving projects/programmes. The questions ‘where is the real value?’ ‘Why does this activity support a vision that we value and can achieve?’ are failing to be asked.  It is still true to say that much investment and spend is not appropriately grounded or indeed questioned in these situations. A key area of use is to allow a collective recognition by the team of when a project/programme is failing in its value goals and needs to be written off.  I am sure that we are all aware of projects that are not terminated because the ‘career cost’ of pointing out the obvious is just too great.  Such workshops allow for a collective recognition and a removal of the blame and ‘can carrying’ attitudes that prevent companies from recognising that they need to move on and get to value development.

The ‘Three Wall Workshop’ is an excellent tool used in the hands of Radtac to create the emphasis on first the ‘Why’ then the ‘How’ and, finally, then we can discuss ‘What’. These three questions in that order are an iterative tool that can become very flexible to look at a range of situations where what we do has come to dominate why we are doing it.

Once we have a high level vision of Why, the How of strategy will follow. This process also avoids long periods of navel gazing at long ‘Strategic Planning’ documents. By taking an iterative, leaner and agile approach to building high level stories and relevant personas we can quickly move to producing a lean-start-up environment under the ‘What’.  Here we typically look at the earliest deliverable value, put that to the end user/client as a tactical piece of implementation and allow that to drive the ‘inspect and adapt’ process, shaping the order and prioritisation of the stories and evolving new ones as required. Ordered priority of development of any solution or proposal is a key to leaner agile progress.

Further articles will come from Radtac around the specific adaption of the Three Wall Workshop model to several specific situations.

Initiating Product Delivery With Customer or… ’The 3 Wall Workshop’

When running training courses or coaching clients we are often asked how to initiate Agile deliveries, whether that is for an Agile project or product development effort. This could apply to the initiation of any type of delivery, whether a delivery capability improvement project, or implementing a new or improved IT system. 

Regardless of the overall approach, we normally utilise a core technique from our transformation framework RITA (RITA Information technology Transformation Approach) called the ‘3 Wall Workshop’. The remainder of this blog will describe the 3 Wall Workshop within the context of initiating the delivery of an IT system rather than, for example, a delivery capability improvement project. If we were starting the delivery of a capability improvement project then the structure of the 3 Wall Workshop would be the same but the products being delivered would be different.

Prior to the workshop we would have already defined the key stakeholders, where a   stakeholder is defined as ‘any group or individual who can help us or hinder us’. These key stakeholders are invited along to the Workshop (remembering that the development team/s are key stakeholders also).

It is probably no great surprise that the 3 Wall Workshop basically uses three walls of a facilitation room to define basic characteristics of what we are going to deliver; the vision, what we are doing, and how we are going to do it.

The first wall defines the vision. This would always be a pictorial or physical representation of whatever we are aiming to build that is defined in a way that everyone can understand it. If the product being created is a heavily GUI based computer system then we would typically define a quick pictorial representation of what the key elements of the system are going to be and how they interact on the wall . If the system is going to be a piece of hardware then typically we start with a cardboard box upon which we draw and model to visualise the hardware features and then define the key software features on the wall. Whatever approach we use the key objectives of describing our vision is that it must :-

Be described via ‘low-fi’ prototypes (in other words prototypes that are as simple as possible no  matter how complex the actual  system may be). This could be a rich picture/s, wireframe/s, simple functional interactions, simple screen shots, simple business process maps, SIPOC diagrams, ‘Product Box’ (create the box the product will be sold in to identify the key selling points), press release,  Product Data Sheet, press review you would like to see on completion; or anything else that allows the workshop attendees to visualise what the product is.

Provide enough information for everyone in the workshop to visualise what the product is, and sometimes more importantly, what it is not.

The second wall describes the key ‘Personas’ (or an instance of a UML ‘Actor’) that interact with the system, this is going to help us prove that the vision from wall 1 is aiming in the right direction and  will also help us get the right coarse grained features  on wall 2. So, on wall 2 we represent the product as a collection of customer focussed Features written in User Story style that describe system (business and / or technical) features that all the people (business and technical) in the workshop understand. The discipline of story writing must be followed so that we get a clear definition of WHO requires the Feature, WHAT functionality the Feature delivers and WHY the Feature is required in terms of delivering value to the Vision. In addition, each Feature should contain a definition of what broadly makes it acceptable. The key aim of writing these stories is to create an end-to-end view of what the key features of the product being developed are and also to remember the core principle of ‘Just In Time Elaboration’; in other words, keep the stories simple and high level and actively endeavour not to drive into detail. If the stakeholders had given us any level of requirements prior to us starting work we would, at this point, either remove those requirements that have been shown to be not needed, or create traceability between the requirements that are required and the high level Story Features .

So, the first wall has represented for us what the vision of the product is and is not, and the second wall has helped us understand who will interact with our product and what the key Features of our product are.

Wall three starts us thinking about who needs to be involved in building our product and also what infrastructure they will require. It may be that this product will eventually require 10, 50 or even 100+ teams (each team being around 7+/-2 people), however, our aim at the moment is to get just enough people and infrastructure in place so that we can start building potentially shippable Product Increments. On wall 3 we start to define the core skills required to start us off and how we are going to employ those people; we are going to start thinking about the basic technical environments they will need to start delivering vertical slices of the working product, we’re going to think about provision of office space, desks, PCs and other basic initiation needs. The bottom line here is that we aiming to get the team in place to enable delivery of working product as fast as possible (weeks not months, no matter the size of the delivery) so we can then evolve the capability from there based on provable known facts (Emergent Design).

After the 3 Wall Workshop and usually before we initiate delivery we would capture the  Workshop outputs as follows :-

Wall 1 – Vision è Evolves into a simple working prototype that the business and technical people can play with. Vertical slices of this prototype will then be delivered. We also typically create a very simple technical architecture that supports the prototype; we are looking here for re-useable services or components that could be used as we move forward or whether there are any technical risks or areas of concern that we need to get addressed early.

Wall 2 – High Level Features è We should have created only a horizontal view of what the product features are, not any level of detail, and we should have created a simple traceability matrix between those Features  and the stakeholders requirements if we were given any. The next job is then groom the highest priority stories down to the right size for delivery (typically around 1 to 5 days effort size).

Wall 3 – we take enough people on board to start developing the product and provide them with just enough infrastructure to enable them to start developing. The product architecture, code, documentation, design, further teams and everything else will evolve from this point forward.

So I have described how  to use the 3 Wall Workshop in order to understand the key elements required to start delivering the product on a firm footing.

Typically a RITA 3 Wall Workshop shouldn’t take more than a few days.

The longest RITA 3 Wall Workshop the author has run is 2 weeks, and that was to get focus within a multi billion £ public sector programme that been running for 12 years without delivering anything !

The RITA 3 Wall Workshop is not always suited to every initiation need, but very suitable for most.

Radtac have been supporting all manner of organisational teams achieve change and transformation for over 20 years. That experience has helped us construct our Radtac IT Transformation Approach (RITA) framework for looking at enterprise wide change where IT is a core driver of the business delivery and / or product development.

In implementing change we talk about the Three (3) Layer model in an enterprise. These layers encompass the complete value chain from top management to low level delivery teams, with layer one being at the top, sometimes referred to as the portfolio or strategic layer. Layer two sits in the middle, commonly referred to as the programme/project layer, with layer 3 covering the delivery teams. Sometimes this can be extended to Four (4) Layers in extremely large and / or complex environments but more than 80% of our clients fit the Three Layer model.

To get effect transformational change in an organisation it is necessary to have appropriate leadership, focus and ownership throughout the enterprise, and this should be vertically through each of the layers as the figure below illustrates.

There are three recognised patterns that such a transformational change can take on, described using the metaphor of a wave, but only one of which is truly effective, the Sustainable Wave.

Radtac finds the advantages of this model to be:

·         Simplicity of understanding from all parts of the organisation

·         Creates a model from which previous ‘failure’ can be understood

·         Illustrates the importance of leadership over management

·         Provides a clear picture of how change will work

·         Provides for the concept of feature teams, value flow and ‘vertical slicing’

Feel free to contact Radtac if you would like to discuss further our approaches and how they can help you.

#Michael Short

michael.short@radtac.co.uk

0203 638 5040

One size does NOT fit all

I have said before and I will say it again each team is different (different skills, capabilities and experience), each project is different (different budgets, schedule, scope and risk profile) and each organisation is different (different value chain, operating in a different market). Even as individuals we are all different (phew!)

So why, oh why do companies think that a one size fits all? If I do what the successful people do, I will get the same success. Right? Nope!

“So I have decided to go ‘Agile’ and implement Scrum.” This is not an uncommon statement I hear from companies!

Well just back up there for a moment! Why are you implementing Agile, what problem are you trying to solve? Agile is not necessarily a silver bullet to all your corporate ailments!!

Moreover, a word to the wise… understanding Agile is easy, transforming to Agile ain’t! Most successful change and especially a change to using an Agile process like Scrum, must include both top-down and bottom-up change because Scrum is so pervasive i.e. not isolated to just the development team!!

So let’s assume that there is good reason to implement an Agile approach in your organisation but that does not necessarily mean that it has to be Scrum. Agile and Scrum are not synonymous! Agile is an umbrella for a number of frameworks and methods and Scrum is one of those frameworks!

Don’t get me wrong, Scrum is by far and away the most popular Agile framework. In the latest Version One State of Agile Survey [http://www.versionone.com/state-of-agile-survey-results, Scrum and Scrum variants make up more than 72% of the methods used. That still doesn’t mean that it is right for every team or project! You know what I mean?

Over the last couple of months we have worked with two companies that have decided to go Agile that had specifically decided on Scrum as their framework. Both companies embarked on a major training initiative and based on that training (and that training alone) implemented Scrum across multiple teams. Impressive!

Sometime later, we were called in to assess their adoption. What did we find?

Well in the first instance both companies had made baby steps in their Agile transformation but were far from optimal. Moreover, Scrum was not necessarily right for all the teams. On the face of it, Kanban, the new kid on the block, would have been more appropriate in some cases.

So what’s the morale of the story (blog)?

If you are going to embark on a transformation – get help! Use Change Coaches that can support your adoption to help realise the benefits quicker.

More importantly, please don’t sheep dip your teams in a method until you know it is the right method. A little upfront investment in understanding the problem domain and appropriate solutions will save you spending a whole bundle of money on the wrong training!

Radtac Kickstart is an Agile Readiness Assessment; the most important question is ‘Why?’ Start your journey with a clear understanding of your current capabilities followed by measurable goals and objectives defined to make success a reality and a pragmatic strategy for achieving it.

Large or small, get the foundations RIGHT and set your team running to a flying start with a focused kick-off which builds a powerful shared understanding and commitment to your business visions, priorities, Agile team organisation and delivery plan.

Darren Wilmshurst

Head of radtac:change

0203 638 5040

change@radtac.co.uk

When considering changing work, technical and delivery practices, training is one way to help that process. I can hear you all waiting for the ‘but’…..in fact it is an ‘and’. Training is not a change programme it is only an element of a change programme and coaching is probably a more important component.

Coaching, as we describe it, is different to mentoring. Coaching is supporting someone to understand how you implement a change of work practice, the application of new skills and improving those that you already have. Mentoring is a senior/experienced person in an organisation taking someone under their wing to help develop that individual within the organisation. The ‘right’ definition is only important so it is clear what this article refers to.

When Radtac first engage with organisations we often experience the desire from the customer to tell us ‘What’ they are doing. This is not always delivered with a clear expression of ‘Why’ they are doing things. Coaching is all about ensuring that the ‘why’ you are doing things can be achieved through the ‘how’. Coaching enables the translation of the Vision – ‘why’ - that you have articulated into the strategy – ‘how’. The tactics - ‘what’ – of implementation is just that, what tasks you are doing to affect the delivery of ‘how’. Good training is aimed at the ‘what’, great Coaching is aimed at “Why” and “How”.

Coaching demands that the coach enables the recipient to be the best they can be, that they focus on doing the right things before doing them right. Most transformations and change programmes when boiled down are simple on paper. Do things that the end user/purchaser of the products want, in the order that gives them most value, early, in the most efficient way. Coaching supports you, the team and the organisation to adopt innovative and improved ways of working to achieve these goals.

So the value of any training is only achieved if that learning is coached and adopted into practice. It is probably true to say that most people would benefit first from some coaching before they start any training. If you look the logic above it is clear that your need to work with the elements that are coached before you understand the ‘doing skills’.

Radtac use Coaching in our ‘Three Wall Workshops’ and our ‘Kickstart’ tools to support teams to get them to ‘change’ or be ‘improvement’ ready. If that approach is not adopted it is our experience that all the training in the world will not be as effective as it could be.

It is interesting to note that many athletes have the skills and capability to be great; few achieve greatness without a coach, and sometimes a series of coaches.

Michael short

0203 638 5040

enquiries@radtac.co.uk