Agile Forest

Find your path to agility with Renee Troughton

Agile Coaching as a term hasn’t been around since the advent of Agile. It was a term that gained traction after the publication of Lyssa Adkin’s “Coaching Agile Teams” book in 2010.

Before then, most people were either Scrum Masters or other crazy terms including process improvement (which always felt at odds with the manifesto) or continuous improvement manager to delivery leads.

Scrum Masters who had a few years of experience under their belts understood that a two day training on Scrum wasn’t enough to learn what worked and what didn’t and began to see patterns of poor practice and better practice emerge through their own test and learn experiments. Over time, they helped to kick off new teams who were trying Agile for the first time. They did this by working with new Scrum Masters and guiding them on the pathway to change.

It wasn’t a role that just came to be one day, it evolved over time to be what it is today. It was initially driven from both an opportunity to scale Agile ways of working quickly and a desire to share patterns of success (and failures to hopefully not repeat). This is why as a community, Agilists tend to have a higher centricity towards sharing information – we are focused on “uncovering better ways of delivering software” (or hopefully now better ways of achieving outcomes). The down side to this is that we also tend to be too focused on the “new shiny” thing rather than practically just focusing on the basics that we know will move us there.

This is what we have evolved to. But what do organisations need? What are their expectations for coaches?

I have had a lot of feedback in the past that I tend to be different from other coaches. I’ve even seen people refer to coaches as two different types, often not in good terms. One commentator referred to the schism as “fluffy agile sprinkles coaches” who are all oriented around mindset and “delivery coaches” who are all oriented around practices and techniques. To this commentator, the middle ground of coaches who are both and have the expertise to know when to use one approach over the other is a dark art that few know well.

I have canvased a number of different roles who sit at different levels of multiple organisations and asked them around what their expectations for their coach is. Rightly or wrongly, the following is a compilation of the feedback I received:

  • I need someone who is pragmatic and flexible. I don’t need a purist answer, I need something that will work for my situation given where people are at right now in their learning journey.
  • I need someone who can pivot quickly on recommendations or facilitate under great uncertainty.
  • I need someone who will give me 1:1 time and tell me the hard truths, giving me a perspective that others wouldn’t ordinarily feel comfortable to do so. Note: this was said by people who actively wanted a coach rather than being given a coach, it is my experience that people who are given a coach don’t want this and you need to build trust and support before someone will give permission in this scenario.
  • I need someone who focuses on the big picture, I don’t want everything to be about “Is my stand up going longer than fifteen minutes”, I want them to be looking at whether we are delivering faster, with better outcomes and sustainability.
  • I need someone who will help me to widen my toolkit so I am better at solving problems more effectively, this could be either practical techniques or mindset/personal techniques
  • I want someone who can help me understand the “why” behind certain Agile concepts rather than the what.
  • I want someone to help me to have more effective relationships with those around me – especially in helping me to manage up when my manager is still thinking the old way
  • I want someone who not only brings Agile knowledge but also has domain knowledge and experience in my domain
  • I want someone who will understand my organisation and how things work in my area (the system I work in) before giving me advice
  • I need a coach to know that it is a journey and that I have other things that I need to focus on which may mean my journey is slower than they would like
  • I need my coach to recognise what I have done right. I’ve been working for many years and experienced many successes, all of me doesn’t need “fixing”
  • I don’t want to be “coached” to get to answers all the time, sometimes I just need to know things that I don’t know which means sometimes I need advice or training
  • I need options and examples of what has worked elsewhere and what are the pro’s and cons so that I can make an informed decision
  • I need to be shown what good looks like which means sometimes I need a coach to be a “player” in the system
  • I need someone who will help push along continuous improvements, which means owning them. I know some of my people need to do this, but there are so many issues I could really use more help.
  • I don’t care whether it is Agile solutions or something else, I want my coach to help us with whatever solution that will resolve the problem

How does this line up to what you are expecting from your Agile Coach (or from what you are expecting of yourself as an Agile Coach)?

Advertisements

I remember thinking when I first started using Agile over fifteen years ago that you couldn’t use Agile for everything in an organisation. Five years later when I learnt of Kanban I began to rethink about whether that was true. I could see that it could be applied in a broader context outside of software development and even outside of projects.

The thought that you wouldn’t use Agile in a project where requirements were defined upfront was also an oddity to me – why wouldn’t you mitigate risk and get feedback as you deliver despite thinking that you got your requirements 100% right? At one stage of my life I was a Business Analyst. I wrote the best business and system requirements. My documents, in my mind at the time, were epic odes to the perfection of thinking. I learnt very quickly that defined requirements never changing was a farce. I was human and my mind had unintended errors and gaps. 

Some would dispute that Kanban is more a Lean method than an Agile one, however I have considered it one element of a wider suite a methods, practices and techniques. This suite used to be known as an “Agile umbrella” but it is now referred to as “New Ways of Working”. It combines Lean thinking, Lean Startup thinking, Design thinking, Agile thinking, Software craftsmanship thinking and much more. 

With such a broad toolkit now at the disposal of organisations we should be solving problems everywhere. But we aren’t. We aren’t consistent, nor predictable in the outcomes of our transformations. Our perfect designs and methods are failing on implementation or their stickiness is not strong enough to handle a significant c-suite change. Maybe we are suffering from the same problem that we had when we thought we could do requirements upfront – that we think we know all the answers when really we are doing it totally wrong.

I had for a while thought that the potential solution lay in experimentation – testing and learning the processes that work for a culture. Part of me is still attached to this thought, especially as I have seen it work more often than not. After all, complexity theory says that in a complex system that ‘probe-sense-respond’ is the best approach. But what if complexity theory is wrong too?

I love Agile. I love what it does to individuals and teams and the difference it can make to them. It is just a lot harder at scale to get it working. There are schools of thought that the best approach is to descale your organisation. I’m not against this as a tactic, but to me it is an overly simplistic answer to a complex problem.

Yes there is tonnes of literature about setting yourself up for success on what you need to do when kicking off an Agile transformation, I probably have a blog or three on this already, but lately I have been thinking that in some organisations we shouldn’t be trying to do Agile transformations. I know, this is very heretical.

I’m not proposing that we give up. I now have a different hypothesis – fix the more critical issues in the organisation before trying to kick off an Agile transformation. What critical issues you may ask? If you have any of the following issues I believe you should try to fix the root cause of these before trying any form of transformation (Agile, New Ways of Working, or something else).

The ‘restructure every three months’ organisation

If your organisation restructures at least every six months (and I know of a number in Australia that restructure its people at least three times a year) then I don’t feel like an Agile Transformation is going to be successful in this environment. 

Agile requires stable teams to create productivity. Every time you restructure you:

  1. Create uncertainty. This uncertainty dramatically reduces individual productivity.
  2. Force teams to go through Tuckman’s model, again decreasing productivity.
  3. Force work to be re-distributed to teams, creating a hold on flow.
  4. Confuse stakeholders who work with teams on where work is at and who to engage/work with, also dramatically impacting flow.

The science of impact on productivity for points 1 and 2 are well understood, but I believe there has been little done to demonstrate the significance to productivity of points 3 and 4. 

I would argue that you should test and learn to what extent your restructures are successful in removing problems. If your organisation restructures more than three times in a year I don’t think there is enough stability to be able to test and learn from. 

Also, all too commonly organisations restructure to solve one problem and inadvertently create new problems, hence creating the cycle of pain where another restructure is required. Any structural pattern will have trade-offs – most organisations don’t spend the time to understand the options, trade-offs and mitigating steps for each trade-off. 

If you are in one of these organisations, before implementing an Agile transformation you should:

  1. Stop restructuring more than once a year (twice ideally)
  2. Learn your choices and trade-offs and implement appropriate mitigations
  3. Test and learn using real data – how do you know your organisational productivity and how does your structure affect it?
  4. Change manage the restructure better to mitigate productivity risks (most organisations say they do this, in my experience I have yet to see one of them do it well)
  5. Performance manage out your people that aren’t performing. This means having a HR group that can actually deal with difficult conversations and managers who have skills to deal with system thinking around performance (assuming Deming’s Law that 85% of issues are the system and not the person). Why did I add this one? Most organisations use re-structures as a means to remove poor performers (mostly due to labor laws) rather than doing the hard yards to remove them through the formal HR process. If organisations did proper systems and performance management a lot less restructures would be required. You could also argue that better recruitment processes would reduce poor performance issues downstream. 

The ‘implement change without change management’ organisation

If you are in an organisation that rolls out change poorly then trying to roll out an Agile Transformation is going to be impossible without good change support. Poor change management includes:

  1. Change plans that are never implemented
  2. Change plans that don’t target the right groups
  3. Non existent change plans
  4. Insufficient change plans (for example an email or two is done but nothing to embed a real capability change)
  5. Lack of focus on behavioural value differences. Immunity to change talks about behaviours that are hard to shift because of unconscious needs. This requires a individual or a persona based approach to change management rather than a whole collective approach.
  6. Rolling out a change that has been ill-considered or not piloted

If you are in one of these organisations, before implementing an Agile transformation you should:

  1. Look at the capabilities and process by which you do change management and get real data from people (not managers) within your organisation as to how successful previous change initiatives have been
  2. When you find that they haven’t been as successful as you have previously thought, find out why. Do some root cause analysis and fix these problems
  3. Check to ensure that your change management processes can handle an incremental approach to delivery

The ‘waiting for the next CEO’ organisation

I haven’t seen this pattern often, but it tends to be in extremely bureaucratic organisations or in government organisations that have a fixed date of leadership tenure. In this type of organisation the CEO has had challenges in their leadership style. This includes:

  1. They do not create a safe space; failures are not tolerated
  2. They make outlandish promises to shareholders on what can be delivered and when, without ever checking with the people who will do the work if it is achievable. They often do this under the guise of creating a “strong vision” or “stretch targets”
  3. They don’t connect with their organisation beyond their direct reports

The impact of this is an organisation full of apathy and disconnectedness. People within the organisation don’t want to invest their time in the vision or any changes driven top down. Consequently they do the minimum they must do to fly under the radar resulting in the organisation staying in a holding pattern whilst they wait for the CEO to be exited.

If you are in one of these organisations, before implementing an Agile transformation you should:

  1. Have strong conversations at the C-Suite layer or even the Board about how the CEO is performing and how their behaviours impact the productivity of the whole organisation, how it sets an example for the leaders underneath them.
  2. Think about having an ‘Undercover boss’ mechanism to get real feedback on problems and insights of people deep in the organisation.

The ‘new shiny’ organisation

Are you in an organisation that has trouble focusing? ‘New shiny’ organisations tend to act like a cat chasing after a laser light – everything else gets zoned out. The biggest issues with this type of organisation tends to be:

  1. That once something is kicked off there is little focus on delivery or execution of the work
  2. Which results in lower benefits realisation, lower value to customers and a delivery system filled with waste
  3. And whilst the ‘shiny’ might be Agile, something new will come along and you will end up having an implementation that no longer has any focus or intent to follow through on
  4. Then there are the real problems of the organisation that are never really prioritised as the new shiny keeps everyone’s attention.

If you are in one of these organisations, before implementing an Agile transformation you should:

  1. Stop starting and start finishing. Learn how to create focus through to value realisation before kicking off something new. 
  2. Have a mechanism for being able to understand what the core problems/impediments are in delivery, ranked by waste and track very frequently the steps being made to resolve them. In essence, focus on delivery optimisation.

The ‘we don’t have time to be smarter’ organisation

Are you in an organisation that is so busy that there is no time to work smarter? People are always in meetings. They have meetings on top of meetings. They have lots of people doing the same thing. Each area solves their own problems, but the same problems exist all throughout the organisation. 

Fundamentally this is an organisation that has no slack (teams loaded 100%) and a fixed mindset. To be fair, there will naturally be individuals who in the organisation still have a growth mindset, but the organisation isn’t culturally setup to encourage continuous improvement and to encourage learning.

If you are in one of these organisations, before implementing an Agile transformation you should:

  1. Stop behaviours like cutting project costs or time frames. I see this all too often – executives think a project costs too much, slashes the budget or time and forces the team(s) to deliver under this pressure and think they have saved the company millions. Every time I see the project ends up costing the original figure and time, but because teams were forced to think they had less time they cut corners, reduced quality and introduced technical debt. It is a false economy. Work ends up being costing more over time due to the operational maintainability of the solution.
  2. Introduce slack time into the system – load teams up to only 80%. Slack allows the system of work to handle unplanned exceptions and gives people space to think critically about the what, why and how of their actions before starting them. It also gives people space to look more broadly to other people and other organisations for solutions to problems.

The ‘we’ve tried it six times before’ organisation

Some organisations have already tried Agile many times over and failed. They have this really strong belief that ‘this time it will be different’ which may be true, but all too often, little is done to retrospect on why previous attempts have failed.

If you are in one of these organisations, before implementing your next Agile transformation you should:

  1. Do a root cause analysis on where implementations have gone wrong (it could have been one of the previous types of organisational patterns that has caused this)
  2. Share with the C-Suite and the board these findings
  3. Get buy-in with this group on how this implementation is going to be different and how it is going to address those root cause issues
  4. Test and learn whether it does address the issues before rolling anything out.

The ‘we have five consultancies in here’ organisation

I am not saying that consultants are the problem – just that lots of different consultant groups who are unaligned is a really big problem. Consultancies, much like coaches, can help to give you perspective that you don’t ordinarily have, they can provide expertise and global knowledge and help drive a greater focus towards value. But if their perspectives differ then you are going to be creating deep factions of power in the organisation that are working against each other. Often they also don’t have visibility of what each other is doing. 

If you are in one of these organisations, before implementing an Agile transformation you should:

  1. Think about consolidating/reducing the number of consultant groups
  2. Create visibility about what what each group is focusing on, or ensure that the work is fully mutually exclusive
  3. Determine if there is a lack of alignment between groups and hold workshops between invested parties (ie the people who are working with the consultancies) to reach alignment.

The ‘we have managers (not leaders) everywhere’ organisation

You may have picked up through some of the suggestions above that a few key techniques are being consistently utilised. Agile requires a different type of manager, a leader who can help to change the culture of an organisation, who can think critically of ‘the way that we do it now’ versus the possibility of the future of the organisation. A key enabler to Agile that you should consider prior to kicking off an Agile Transformation is a Leadership Transformation. A Leadership Transformation should: 

  • Focus on lean wastes and flow analysis, systems thinking, and root cause analysis capabilities across the organisation
  • Focus on the difference between management styles (Taylorism, Theory X vs Y, Management 3.0) and what works in the organisation now versus what is needed for the organisation going forward (which does depend on a really clear vision for the organisation)
  • Educate managers on options on how to structure it’s people and what the impact that structure has on communication and flow
  • Educate managers on options of governance and finance and what the impact that these options have on flow, engagement, and values
  • Provide managers incentives to focus on new behaviours (though be careful as extrinsic motivation can backfire)

This leadership transformation creates the internal pull for an Agile transformation, but importantly puts leadership on the journey sooner so that they can be more effective in supporting an Agile transformation through the right behaviours. 

A final note

Agile Transformations are tremendously hard. Don’t make it harder by setting them up for failure before they have even started. 

Agile contracts. Those two words together in the title seem incredibly incongruent with Agile, after all, the Agile Manifesto’s third value is:

Customer collaboration over contract negotiation

But this doesn’t mean that you shouldn’t have a contract with a partner or vendor; it just means that the interactions, collaboration and outcomes that you make together should be your primary focus. 

So what does an Agile contracts really look like? What considerations should you bring into your Agile contract? Whether it be an outcome based contract or time and materials, the following are additions you should consider when working with a deliver partner to produce not just software, but real outcomes for customers.

Team Setup

  • Be clear on how far through a technical stack a team should be setup to include – eg Partner teams must be setup to deliver customer value work through the full technical stack. In complex, scaled environments Partner teams tend to not be optimised for reduced dependencies. 
  • Be clear on which roles you will provide into the team such as Product Owners, Experience Designers, and Service Designers
  • How big should be team be? Good team size is 7 +/- 2, but many Agilists think even this is too big.
  • Do you need to be explicit around what roles you don’t want a Partner to add? For example, you may not want Test Managers or other leadership roles beyond Scrum Masters.
  • How much should a Partner be allowed to move people between teams or taken off the account? Agile teams work because teams are persistent and learn over time how to effectively work together. Naturally there will be exceptions such as where there are personality clashes or capability issues but try to have stable teams.

Skills and capabilities

  • What is the approach to dealing with gaps in hard to find specialist capabilities – is it the responsibility of the Partner to address this or will your organisation provide a solution?
  • What skills and capabilities (soft or in programming languages) are you expecting of your Partner. Consider where Agile capabilities such as TDD, pair programming, continuous integration and deployment etc. fit in to these expectations.
  • What skills and capabilities are you guaranteeing to the Partner – for example, will you ensure that Product Owners are capable in defining Acceptance Criteria in order to support BDD?

Coaching

  • Who will be performing coaching – the Partner or your organisation? What is the ratio of coach to the number of teams that you are expecting a coach to support?
  • If the Partner is providing coaches how do you ensure quality – do you reserve the right to interview them? Do you have rights to approve or reject them?
  • When a coach starts, how to they get up to speed with your preferred way of working? Do they come onshore for a period of time?
  • How much flexibility do they have to blend the Partner’s way of working with your own? Do they have to fully comply against an expectation by a certain date (for example, an expected level of Agile maturity)
  • How much flexibility do they have in their personal coaching style -is it opportunistic, pathway driven or a combination?

Training

  • What Agile training will be provided or required by the Partner for its people? Is there a specific certifying body, level of proficiency or time period that training should be completed by?
  • Do you partake in the training to recommend improvements?
  • Are you responsible for providing all the content for the trainer or for onboarding the trainer in the delivery approach?

Technology

  • What is the minimum upload and download speed that Partner laptops have to meet? Throttling of connections can severely slow down continuous integration in teams and result in teams that avoid checking code in frequently.
  • Should each team have a permanent open channel (eg Skype or other) between the Partner and your organisation (to enable real time communication) 
  • What other key communication tools should each person have access to? Who provides the licencing for these?

Environment

  • Are there minimum expectations of cross over hours for communication? Often teams and Product Owners have only a two hour window (especially between Australia and India) to communicate – this includes all Agile ceremonies and any other discussions about work. This batching of communication causes significant delays in delivery.
  • What size of meeting room and video conferencing facilities should be available to Partner teams? Often teams have a room, but it is only big enough to squeeze three or four people into it comfortably. 
  • Should all Partner team members (or even tribe) be located in one city and in the same building (or even floor)? Co-location of tribes so that they are seated next to each other is critical to reducing rework and improving speed of delivery.

Tools

  • Should Partner team members be  able to access all tools and information from a single device? Single device support enables reduced downtime in switching devices but also importantly reduces the chance of communication batching.
  • What Story Management tool should the Partner be using? Who will pay the licence cost and how are they expected to use it? Be careful here, setting expectations that all Stories must be closed by the end of the Sprint will only drive inaccurate reporting. Another example is setting an expectation of no outstanding defects by end of Sprint – it may drive behaviour of teams commenting out test cases or code.
  • What expectations/restrictions are there for the Partner to access core tools for coding and source repository?
  • What mechanisms exist for Partners to escalate issues with tools, environments and access to data?

Process

  • What Agile ceremonies are Partner team members expected to attend?
  • What happens if there is a conflict between Partner ways of working and your organisations preferred ways of working?
  • Should the Partner be expected to establish team norms (Social Contract) in collaboration with your organisation?
  • What metrics is the Partner expected to report on? Don’t make this Velocity, it is the wrong thing despite it being  core Agile metric, look towards speed of features into production with high automated testing coverage.
  • What Retrospectives are run at the Partner contractual/relationship management level to continuously improve it?
  • How are new Partner teams onboarded with the way of working? Is there an initial incubation period where they are brought onshore to understand your organisation’s culture?
  • How fast should delivery impediments be resolved?
  • How should a Partner be involved with customer’s and customer testing so that they are aligned with the needs of your customers? 

Culture

  • What behaviours are encouraged? For example, raising objections when a problem or solution is perceived to be poorly conceived regardless of hierarchical position
  • How can you encourage full transparency of status so that if there is bad news this should be as soon as it is detected?
  • What assumptions should the Partner validate with your organisation?
  • How empowered is the Partner to solve problems themselves as they arise?
  • When visiting the Partner, should you be treated as a customer or a team member? Do you treat them as a Partner or a Vendor?
  • How are Partner leaders encouraged to behave with their team members? To what extent to you uphold these values yourself?

Technical Delivery

  • What expectations are there for automated tests and the extent of code coverage?
  • How often should the Partner be checking in their code?
  • On check in, is there an expectation that is is automatically built, re-validated by automated tests and deployed into a test environment?
  • Is bespoke code written for the organisation owned by the Partner or yourself?
  • To what extent do you expect the Partner to use techniques like Feature Toggling?
  • How will the Partner be expected to balance both development and operational support?
  • What SLAs exist for production defects?

Testing

  • Who is responsible for provision of environments for development and testing?
  • How are defects detected within the Sprint expected to be resolved?
  •  
  • What are the Partner expectations for who does testing and in what environments? Where do stubs get used?

Conclusion

Looking at all of these considerations you can be forgiven to think that this doesn’t seem very Agile at all. Where is the collaborative and trusting mindset? Where is continuous improvement? Yes, ideally these sorts of considerations wouldn’t be needed in an Agile partnership, but on a journey to Agility, some clarity of expectations can be better than standard Waterfall contract agreements.

 

SAFe-ty firstThere are now over half a dozen scaled Agile approaches on the market. From Large Scale Scrum (LeSS), to Nexus (Scrum.org’s scaled agile), Scrum at Scale (Jeff Sutherland’s version), Disciplined Agile Delivery (IBM’s version) and the Scaled Agile Framework (SAFe).

Whilst a few of these approaches have only been released in the last few years, many have been in use for a while with SAFe in use the longest from 2011.

They are generally additive frameworks – they utilise Scrum at their core, often utilising the concept of a Meta Scrum, a bigger Sprint across multiple teams that utilise smaller Sprints, first used back in 2006. Often they combine concepts – Meta Scrum, Scrum of Scrums, Scrum, Kanban and principles from Lean. It was because of this that many Agile practitioners like myself were willing to give scaled approaches time. Time to see who implemented them, time to see what worked, time to see how far it worked, time to see whether it resulted in long term change of real value.

Back in June 2016 I received my first long term information on how non customised, scaled transformations were going. I was speaking to a number of people who had spent the last year trying to implement SAFe within a government department. As I described my view on the limitations of scaling approaches, a number of them lamented that SAFe had not yet realised the lofty goals that management had expected of it. After my walk through, they said that they finally understood why it had fallen short.

Transformations do tend to take time and many of us had hoped that scaled approaches would be a gateway to a more comprehensive Agile implementation. I held out in hope that more time would move organisations onward to better agility.

Over the last few years I have seen a number of SAFe implementations, but I have yet to find one where senior leaders after a few years have said “This works amazing for us!”. What I hear instead is, “We thought we would go faster”, or “Getting work ready for the next Program Increment is impossible”.

Enough time has gone by now that I have now lost complete hope that SAFe will realise agility in organisations. Over a dozen senior leaders in organisations that have implemented SAFe have declared that it is not working for them. So where did it all go wrong?

The easy answer would be that it was being poorly implemented, but in almost every instance these organisations had brought in top tier experts in SAFe. So let’s look less on who is doing the implementation, and more to the implementations themselves and see the biggest callouts on why SAFe (or any other out-of-the-box scaled agile implementation) may not be the answer.

People treat it as a silver bullet

In fairness this is not a SAFe callout, or even a scaled agile issue. This is tremendously prevalent in the whole Agile community.

It comes into play when organisations hear the hype curve and think that if everyone else is doing Agile then they should too. They jump into Agile because the marketing tells them that they will deliver 200% more in half the time. They think if everyone has two days training then the results will come.

Today, I am shattering that illusion. If you are a senior leader and you think all you have to do is send people on training and then all your problems are solved, it just won’t happen.

Your people, your leaders, and especially yourself have to make serious change to get the intended results of Agile. And I am not just talking about doing a few ceremonies. I am talking about serious change – both in practices, policies, processes (all processes, not just software delivery), and especially behaviour.

Because Agile needs behavioural change to realise its benefits this is never going to be a journey taken overnight. Human behavioural change takes time, a lot of it. It takes anywhere from five to nine months of continually performing a new behaviour for it to become unconsciously triggered under stress. And leaders are often stressed. In this time, people will make mistakes, and they need to have a safe environment to learn.

If someone told you that the Agile Silver Bullet for a single person took six months and was fraught with failure would you think it was a Silver Bullet? No way! Stop thinking it is. Most organisations take five to ten years to complete a transformation across all its people. Agile really isn’t a sprint, it is a marathon, a 3100 mile Self-transcendence marathon.

It encourages massive batching

In the early days of Scrum it was mandated that Sprints were four weeks. I remember looking at this and after a few months of trying it wondering “Why a month?”. Not long after that, I started experimenting with three week, two week, one week and even one day sprints. Apparently I wasn’t the only one that felt it was odd, with many others experimenting and finding that two weeks almost always worked better than one month. Nowadays, if you tried to use a four week sprint, Agile folk would look at you as if you were crazy. They would lament that the feedback loops weren’t fast enough and that you should try to release something of value sooner.

My most significant issue with SAFe is that it is stuck in a similar vein of early days Scrum thinking – that larger is better. Program Increments (PIs) can be smaller, but everyone tends to implement them as a quarterly activity, this is because it isn’t a huge jump for organisations that already release quarterly, it can just fit in along with the existing organisational enterprise release cycles. Another reason that groups tend to have large Program Increments is because the effort to get a whole release train into a room for two days is phenomenally expensive, including the preparation time.

People implementing SAFe aren’t thinking really questions like, “How can I have smaller Program Increments?”, “If I had smaller PIs, would I need less time with everyone together?”, but critically, it doesn’t ask the biggest question of all, “How can I de-couple dependencies and better define the work so that it doesn’t have dependencies between teams?”. After all, if you can remove dependencies between teams than you don’t need a Program Increment at all. Teams could then just simply discover/incept the work once they have finished delivering a capability.

Which brings us to another point about SAFe’s batching – when teams are delivering in a Program Increment they are also busy discovering/incepting the work for the next Program Increment. Let me step through what happens:

  1. New to SAFe team runs a Program Increment and makes a commitment for the next quarter.
  2. Because of the two day PI timebox and no pre-work, they have a lot of outstanding questions for the work
  3. They spend a week or two trying to get all the questions answers whilst trying to deliver on their commitment
  4. Because they have spent unplanned time getting these answers and because a commitment was made based on poor information they get crushed at the end of the PI
  5. At the end of the PI retrospective they vow to never get into this situation again and their solution is to plan a little better leading into the PI
  6. But because they have only just discovered this insight, and they are about to start another PI, they accept their fate that the same problem will happen again. If they are smart they don’t load up the full PI to handle the unknowns
  7. If they are really smart they also set aside capacity for planning for the next PI (but they usually don’t do this until PI attempt #3)
  8. Eventually they get into a position of 65/25/10 – 65% of effort focused on current PI delivery, 25% focused on next PI planning, 10% in support of previous PIs

Great Agilists know that there is a price to context switching – it impacts productivity quite significantly.

Working in Program Increments not only delays release of value, reduces the speed of learning better ways, but also encourages greater context switching.

It encourages old world thinking on estimation

It is probably a minor point, but SAFe encourages teams new to story point based estimation to use the concept of “Ideal Dev Days”. Putting aside the fact that for a while now Agilists haven’t recommended using Ideal Dev Days to estimate, or that the definition of what an Ideal Dev Day is is still widely open to interpretation (is a tester a Dev, are all Devs of equal competence?), the very fact that SAFe encourages starting estimating by relating it back to time is missing the point.

Yes the website does say to do this only once, but most teams don’t read past the “start by doing this” remark to see that the next time that they estimate they should be using a different mechanism.

It doesn’t change leadership behaviours

On the positive side, SAFe is one of the earliest certification bodies to focus on leadership training explicitly. The content is also quite good. If you are lucky, 5% of your leaders will really listen and get it, but most won’t invest time to be trained.

If you want to quickly and easily find which leaders will make the change, provide the training as an opt-in activity. Go see who attends and important who doesn’t. Those who want to attend are more likely to have a growth mindset that is well aligned with Agile values.

Regardless of what scaled Agile framework you choose to take, leadership coaching is a must. Leaders will need to make space in their calendar, not just for the new ceremonies but to have dedicated time for coaching. More importantly, they will need to be open to new approaches to their own behaviours. Coaching will likely attempt to alter not just the impact a leader is trying to make, but their words and body language as they undertake their day to day activities. The easiest way to get started is for the most senior person in the organisation to open themselves up and be vulnerable to coaching and then advertise this to all of their leaders – this creates the much needed demand for coaching support.

It doesn’t force a change in organisational structure

SAFe describes all teams as “Feature teams” but does optionally describe the difference between Feature and Component teams. It’s definition is somewhat lacking in the difference between architectural and component teams and tends to combine both under the “Component” umbrella. It also fails to suggest other alternatives like Journey or Episode teams.

In every SAFe implementation I have seen in Australia, teams have started their SAFe journey as Architecture teams. Why? Because that is how they were already structured prior to starting their release train. In some respects this is understandable, after all, change is easiest when you start with what you are doing now. The biggest issue I have is that this creates an anti-pattern of SAFe co-dependency. Let’s walk through the steps again:

  1. New SAFe Release Train kicked off
  2. Teams are setup the way they are today (architecture/system oriented)
  3. First Program Increment planning session – massive dependencies between teams, but thankfully teams can now see the dependencies and co-ordinate to mitigate risk against them.
  4. Teams deliver despite the dependencies
  5. Because SAFe enabled a reduced risk approach to deliver with dependencies the team setup is not questioned further.

SAFe recognises this anti-pattern. Inside of its teams page it highlights that teams should be setup to minimise dependencies and handoffs, but it is written as a statement at the end of the page and most implementers ignore it.

I have seen one instance where a team recognised (with the support of their coach) that the dependencies were challenging due to team setup – primarily in a scenario where there were split teams for iOS and Android development. It took eighteen months for that release train to re-configure themselves into joint iOS and Android development teams.

I understand why SAFe implementers don’t push for this change day 1 – it requires potential HR changes, but at the very least consider if you can virtually get people together to reduce dependencies from day 1. Test and learn what works through virtual teams and then push for a formal HR change.

It doesn’t change the system around delivery

In the original days of Agile and Scrum, there was a criticism that teams were often in their own bubble doing delivery. Efficiency and effectiveness was limited to the delivery only portion, and whilst this bubble continued to expand over time, there were areas that were rarely touched – funding, governance, and HR processes and practices.

SAFe, continues to suffer from the bubble issue – it is just a bigger bubble, one that goes to a program or even portfolio level.

What it doesn’t fix includes:

  • PMOs still exist
  • Gating processes remain unchanged
  • Funding processes remain unchanged
  • Capex/Opex models remain unchanged
  • Release management processes still exist
  • Training and go to market processes remain unchanged
  • Reporting expectations to senior leaders remains unchanged
  • People hiring and onboarding processes remain unchanged
  • Performance management, rewards and renumeration remain unchanged

Yes there is nothing stopping you as part of your SAFe implementation in tackling the above issues, and you should, but it isn’t clear that all of these problems will remain unless you additionally tackle them. As highlighted in the expectation that frameworks are a silver bullet, changing the above elements of the organisation is not a simple feat and certainly not something that will happen with an out-of-the-box implementation of a “Quick Start” release train.

So is there a better way?

For education and training, SAFe does a good combination of Scrum, Scrum at Scale, and some Lean and Leadership thinking in a combined session. The alternative option is a simple Certified Scrum Master course with a whole pile of other information tacked on, or some more generic scaling information in ICAgile’s offering.

As for transformation, there are other alternatives to using SAFe that you should consider if you are serious about Agile in your organisation:

  1. Find your own way. Scaled frameworks are there to get you to think of another way, it doesn’t mean that you can’t define your own approach. There will be pro’s and cons’s to some of your choices so it is a good idea to get help from an enterprise agile coach on how best to do this.
  2. Tackle the big problems. Fix what is the causing the most pain in delivery. Funding models is a common complaint amongst teams and yet it tends not to be the first thing that transformations try to tackle.
  3. Get the right people on your leadership team. There are three types of leaders – those who have done Agile before and live and breathe the values, those who say they have done Agile before but their actions indicate otherwise, and those who haven’t had the opportunity to give it a go. You want the former group to outnumber the latter group (and don’t keep those who say they’ve done it but their actions show otherwise). Over time, those who haven’t had an opportunity will end up being either true Agile champions or command and control managers in hiding or denial.
  4. Re-enforce the right behaviours and don’t reward the wrong behaviours. It sounds simple enough but this is hard to do well. Ocado is an online shopping website in the UK that invested heavily in this by having a program where once a week employees could nominate anyone in the organisation that was living their behaviours (or not). These behaviours were heavily influenced by the Agile values. If you were nominated you received an email with the comment that was made about you. If you had poor commentary, you didn’t get promoted. If you had consistently good commentary, you were eligible for promotion. Did this work for them? You bet.
  5. Focus on technical excellence and automation. Highly capable developers who know how to build software that can be automatically built, tested and deployed should really be the norm and not the exception to any business.

Good luck, and remember, no transformation is ever easy or safe.

The outward delusion.

A shaman, a seer,

a parent and teacher,

without fear.

 

If you don’t know

you cannot see.

If I tell you

I cannot be.

 

Only in the silence

does truth lie.

Only in the journey

do you try.

 

Don’t fight for time,

nor status or power,

but for the moment,

the second, not hour.

 

All other realities

are just an illusion.

Only the choice matters.

The inward delusion.

One of the biggest mistakes that I see new Agile teams (or teams at scale) do is moving too quickly into a different format to do a retrospective.

It isn’t too surprising when you see that there are so many different ways to do a retrospective, after all, if there are that many options then surely you are meant to switch it up at the end of every Sprint?

So when should you move onto a new retrospective format? Well naturally if the format you are using isn’t working then consider using a format (more on this moment), but to help here is my decision tree on the matter:

Okay, so maybe there was a simpler way to say this…

If you haven’t used the original technique for more than six times in a row then don’t try something new.

Why six times? It is enough to get a pattern, to feel comfortable with the process so that you can maximise the focus on the intent behind the practice.

If your team has been doing it the same way for longer than that and don’t want to change it, then as a Scrum Master DON’T CHANGE IT. It is their decision not yours to switch it up in this instance.

I’m not going to go into the menagerie of options that you can use for a retrospective, but I would recommend that when you start keep it really simple. Ask two to four questions, no more than that. I still use the original ones:

  • What worked well
  • What to do differently next time
  • What puzzles us
  • Lessons learnt.

What I find is a lot of retrospectives fail, not because of the process per se, but because of the little additional “gotchas” that seem to be hard to find as guidelines/rules on the topic. Here are my top tips:

  1. Start you retrospective by reviewing your previous retrospective actions. If they aren’t done then focus the retrospective on why the actions themselves aren’t getting done.
  2. Don’t commit to more than five actions. You just won’t do more than five.
  3. Fix the root cause not the surface issue. To do this, you need to make sure that you actually discover the root cause within your retrospective.
  4. Treat the retrospective as a law of thirds – one third define (brainstorm), one third discovery (share) and one third determine (next actions). Teams often make the mistake of not managing time effectively that result in not enough time for actions.

 

What if the characters from Game of Thrones happened to be Product Owners? How would their personas come to live in Agile teams? Let’s see how some of our favourite characters as Agile Product Owners.

What would Game of Thrones Characters say if they were a Product Owner?

Arya Stark – Stick bad ideas with the pointy end

This is a PO take on Arya’s statement “Stick em’ with the pointy end” referring to her high prowess and knowledge on how to wield her sword ‘needle’.

The Product Owner rule here is to stop starting work if it doesn’t hit the mark from a analytics and validated learnings perspective. We’ve all seen the HIPPO (HIghest Paid Person’s Opinion) effect in action – work that we know shouldn’t go ahead that seems to be fast-tracked. The best Product Owners are ones that are unafraid to terminate work when it is a bad idea, knowing the risks that it may have to their job but holding steadfast regardless.

Ygritte – You  know nothing without validating your hypotheses

Whilst Jon Snow arguably knew nothing according to Ygritte, so too do teams and Product Owners if they blindly go building capabilities without validating problem-market and problem-solution fit assumptions.

Lean Startup gave us a huge shift in the mindset of software development when it began to re-wire our thinking to stop considering everything a requirement and to start to test and learn on our riskiest assumptions.

Great Product Owners not only test and learn on their riskiest assumptions around problem-market and problem-solution fit, but they are critically aware of the different types of cognitive bias and actively struggle against their better-self in order to ensure that the best possible solution goes to market.

Jon Snow – Benefits are coming

It might as well be winter with how much money is spent building work that doesn’t result in the expected benefits. Although most people have heard the of the 2002 Standish Chaos report that cites 64% of features are rarely or never used, this has yet to be considered statistically valid. Again the biggest challenge to how products deliver benefits has come from the Lean Startup community by focusing on a lifecycle that deeply embeds into its core a process of Build-Measure-Learn with critical decision points at the “Learn” stage to pivot (changing problem goals), persevere (continuing on same path, changing solution options) or perish (stop the work altogether).

There is still too much “throw it over the wall and it’s done” mentality in the industry. Leading organisations are deeply embedding this learning cycle into their development approaches and moving away from heavy batch to more flow based lifecycles. Whilst the Scaled Agile Framework (SAFe) is continuing to grow momentum, it is lost on many that implement it, that applied poorly, it creates massive three month batching.

Think about what this means from a test and learn perspective – you release something to market and begin to gather analytics and data. At the same time you start your next Program Increment meeting and create a firm commitment for the next three months of work. Let’s say that after three weeks you get enough data to validate what you just released and with great concern it just isn’t resulting in the outcome expected. You have an assumption about what you need to pivot, but it will require two weeks of work. What do you do?

You can wait to the next Program Increment, which is another two and a half months away, and then deliver a change in another three months (just over a five month pivot – yikes!). You could pull something out of the Program Increment, thus breaking the expectation that was set, further delaying the scoped benefits. If you were smart you would have built in some slack into the Program Increment to allow for pivots on released work.

In the field, I have rarely seen either of these decisions occur. Leaders don’t generally allow any slack in a Program Increment and instead tend to drive for the whole increment to be filled up, and then sadly what happens next is they push to have the teams deliver both, breaking their sustainability with a promise of “we won’t let this happen again”, which it inevitably always does.

Whilst you could argue that these leaders haven’t been coached effectively and are misunderstanding the core Agile manifesto value around adaptation for Agile (responding to change over following a plan), it doesn’t deminish the fact that SAFe as it tends to be implemented results in massive batching which in turn reduces the time to benefits and pivoting for benefits optimisation.

Great Product Owners know this and will be empowered to push back against the organisation’s leaders to ensure benefits optimisation. To do this, again the Product Owner will likely need great courage to fend their decision against leaders within the organisation.

Littlefinger – Backlogs aren’t a pit, backlogs are a ladder

For a while I considered using the Petyr Baelish quote “Fight every battle everywhere, always, in your mind. Everyone is your enemy, everyone is your friend. Every possible series of events is happening all at once” twisting it into a quote about stakeholders, customers and predictability of needs, but in the end I used the more known quote, “Chaos isn’t a pit. Chaos is a ladder. Many who try to climb it fail and never get to try again. The fall breaks them. And some, are given a chance to climb. They refuse, they cling to the realm, or the gods, or love. Illusions. Only the ladder is real. The climb is all there is.”

Backlogs are real. The climbing through them to deliver is (almost) all there is. Importantly a backlog shouldn’t be a pit. Product Owners tend to acknowledge all requests from stakeholders and politely put them into the backlog. These get prioritised down at the bottom of the backlog and languish for all of eternity. Great Product Owners will look at not just the important and prioritised work in the backlog as part of backlog refinement, but will also actively remove aged items within it, work that will never get done because it is deemed as too low in priority or value.

Product Owners will also appreciate where they are in the Explore-Expand-Extract stage of their product development and their backlog’s content will be reflective of the stage.

Tyrion – A Lannister always prioritises by value

Need I say more? The answer should be yes. A good Product Owner will prioritise by value, a great product owner will prioritise by value with an understanding of cost, alignment to strategy, market and competitive trends. Value can take many forms – customer value, business value, risk reduction or meeting industry obligations. Balancing value with cost of delay and job size will mean Product Owners can realise benefits sooner. A weighted shortest job first algorithm with relative estimation can be utilised to compare work in the backlog in order to ensure that the highest valuable work is prioritised higher.

Daenerys – I’m not just going to tell the story, I’m going to live the story

Daenerys Targaryen may be the breaker of chains with a goal to break the wheel, but as a Product Owner she epitomises the role of a story teller. Product Owners are passionate about the problem they are trying to solve. They want to get to the heart of it and do this best by engaging directly with customers and deeply knowing the data, insights and pain points about both customers and the business. Ideally the team would be attending the customer testing, but if they don’t then the Product Owner really has to be the voice for the customer, to put help the team to put themselves into the customer’s shoes and deeply understand their needs.

This is where Lean UX and Design Thinking intersect with Agile in order to build the right thing.

More Product Owners in Game of Thrones?

Do you have a good quote conversion from a Game of Thrones character to a Product Owner? If so post in the comments below.

Effective Executive Sponsors for Agile are a rare breed.

In the VersionOne 11th Annual State of Agile Report 2017 the importance of Executive Sponsors is highlighted both to the success of scaling Agile and to mitigate challenges.

 

 

 

 

 

 

This importance has grown dramatically over the last five years as Agile transformations have moved past the realms of just changing teams, projects and even programs and have expanded into the whole organisation stratosphere of transformation – trying to address the problems of governance, finance, HR and leadership within the enterprise.

I’ve seen a vast number of Executive Sponsors over the years, some amazing and inspiring, others competent, and sadly a few who were dropped into the role (or used it for a launchpad to boost their career) who didn’t believe in Agile.

But what does a good Agile Executive Sponsor do?

They are a role model, with a vision, a growth mindset and willing to invest their time and reputation against making the tough calls and re-wiring the culture of the organisation. How does that translate to activities and behaviours on a day to day basis? Highly effective Agile Executive Sponsors will:

  1. Live and breath agile
  2. Set a vision and not stop talking about it
  3. Make the hard calls
  4. Give space for reflection, learning and improvement
  5. Stop starting and start finishing
  6. Go to the place of work, and
  7. Invest a considerable amount of their time to removing impediments.

Let’s look in more depth at these seven key activities and behaviours:

Practice what you preach

As an Agile Executive Sponsor, if you are asking teams and people to change their behaviours and activities, the first person that has to change is likely to be yourself. How much are you living the values of both the organisation and Agile? How often do you check yourself to ensure that you are living by those values? Ask yourself these questions:

Behaviours

  • Do you collaborate to get insight when making decisions or make decisions by yourself?
  • Do you delegate decision authority down or make it centrally come to you?
  • Is strategy defined collaboratively or defined by yourself?
  • Are you seeking input on the strategy from a diverse set of people, regardless of hierarchy, or is it done by yourself and your immediate reporting line?
  • Are you making yourself available to anyone in the organisation for feedback and insight or do you get insight only from your reporting line?
  • Are you giving yourself time to reflect and improve or are you too busy to stop and think?
  • Are you coaching and mentoring rather than advising and telling?
  • Is your work, decisions and assumptions transparent to everyone or just limited to the people you have conversations with?
  • Do you share information and encourage others to do so as well or you ask for reports to be made for you?
  • Do you proactively seek the root cause of issues and look for patterns or you react and try to fix things as they arise?
  • Do you see failure as a learning opportunity or do you remove trust on failure?
  • Do you encourage simple, lightweight approaches to solve customer and business problems or do you ask for a plan before committing to trying anything?
  • Do you treat all assumptions as hypotheses to be validated or encourage solutions to be built because you already know the problems?
  • Do you ask for help or is everything on your shoulders?

If you answered “yes” to the left hand side of the questions then you are fast on your way to becoming an Agile Executive Sponsor who practices what they preach.

Activities (aligned to strategy of transformation)

  • Are you having stand-ups?
  • Are you attending showcases?
  • Are you removing roadblocks raised to you?
  • Are you participating in ceremonies that encourage continuous improvement and innovation?
  • Is your plan flexible and adaptive as your discover new insights?
  • Are you attending customer tests?

If you said ”yes” to these activities then you are setting up the environment around you to work in a more Agile manner.

Set and grow a clear vision

Agile Executive Sponsors don’t set a vision by themselves. They aggregate many people and many narratives to be able to understand the current state, the constraints in the system, the appetite for change and build a vision for the next state with these in mind. They set a very simple high level vision and focus on only the next or or two steps that need to be made immediately.

The vision isn’t just talked about once, it is re-iterated many times opportunistically through conversations and clarified when needed.

The vision isn’t set in stone but can adapt and change as both new information comes to hand and as experiments are run.

On a day to day basis the Agile Executive Sponsor seeks out narratives and stories by people which indicate that there is a misalignment on the vision and seeks to bring people together to re-establish connectivity to the vision.

Make the hard calls

This seems to be the most challenging of Agile Executive Sponsor capabilities. There is a paradox of behaviours and activities in conflict – on one hand as an Agile Leader you are encouraged to care deeply about people because you know that it is through highly engaged people that magic happens, and yet enterprise transformations call for a significant shift in capabilities and roles in the organisation. Some roles will remain unchanged, some roles will cease to exist, some roles will be consolidated and simplified and new roles may be created.

Making the hard calls may mean changing who remains in the organisation. It may mean having crucial conversations with senior leaders in very traditional parts of the organisation to shift their focus, to challenge their thinking and their behaviours. Your influencing skills have to be strong.

There will be winners and losers in an enterprise Agile transformation. This sounds rough, but it is a harsh reality. Not everyone is going to like what you are attempting to do, but whilst it will be hard there will be many people around you to support you, if you ask for help.

Create slack for reflection, learning and improvement

Changing an organisation from a fixed mindset to a growth mindset (also known as a learning organisation) doesn’t happen overnight. There is often an overwhelming pressure for delivery above all else. It is relentless, and in its wake learning and slack are the losers.

After making the hard calls, one of the biggest challenges for Agile Executive Sponsors and leaders is how to give space for reflection, learning and improvement. Here are the top tips for Agile Executive Sponsors to create slack:

  • Don’t load up teams and people beyond 80% allocation. In Agile teams this is done through a technique that may not be immediately obvious – yesterday’s weather – where teams load up their planned velocity for an Iteration based on their previously achieved velocity. The hidden assumption in this is that the previous velocity takes into account unknowns and re-using that velocity will automatically build in slack for the Iteration. The reality is this tends to be true 50% of the time. Why 80%? Studies have shown that 80% gives enough space to handle unforeseen urgent items.
  • Encourage goals that weight learning equal to delivery. KPIs are often unilaterally or predominantly focused on delivery – is it any wonder that learning tends to take a back seat to delivery when this occurs?
  • Understand that working smarter rather than working harder will have an incremental payoff that will take time. As learning and improvement grows, capability will grow and teams will find better ways, quicker over time.
  • Slack and introspection are as equally important to yourself as they are to Agile teams. With slack, people tend to think more creatively about problems which results in better solutions.
  • Understand that personal change takes considerable time and re-enforcing of behaviours.

Stop starting (or restarting) and start finishing

One of the most frustrating experiences I have ever had with enterprise Agile transformations is the one where the vision, goals and activities of the transformation were continuously changing. Just as change was starting to happen the goal post moved again (and again).

It’s okay as an Agile Executive Sponsor to not get your vision right from day one, it’s okay to change and adapt the plan, but if all it turns into is talk with no change after a few months then there is a big issue with your transformation.

Agile Executive Sponsors get fearful that they have to do a change perfectly for everyone at once. Instead, focus on a small change through multiple experiments across multiple teams. Use this information to work out what changes work better and then amplify the patterns that are successful.

Agile Executive Sponsors also think they need to have lots of different work on the go – just like delivery teams, it is better to focus on getting the few changes done well than trying to do everything at once.

Go to the place of value (gemba)

In today’s age of distributed teams it seems to be a common excuse that leaders can’t go to their teams as they aren’t sitting together. If their teams reside in the same city it really is an excuse and one of the highest priorities of an Agile Executive Sponsor should be to move people and teams together.

Lean uses the term ‘Gemba’ to refer to the act of going to the place of work where value is created. Agile Executive Sponsors should make a constant effort to sit and move around the teams who are delivering work in order to gather insights on the challenges that teams and individuals face through overhearing conversations and being available for direct conversations.

But it isn’t enough to gather insights, highly effective Agile Executive Sponsors will follow through and solve these problems.

Remove impediments

Removing issues that are either blocking teams or slowing teams down from delivering should be the primary day to day activity that Agile Executive Sponsors focus on. They will need to integrate all of the above six practices together in order to successfully achieve this. Start small and simply, getting some early runs on the board of solving issues. An Agile Executive Sponsor must be fully empowered by the CEO in order to achieve this, otherwise they are highly likely to fail in a system that is still heavily dependent on positional power to enact change.

This doesn’t mean that the Agile Executive Sponsor personally has to solve all the issues, rather they have the connections, pathways, influencing power and tenacity to follow through on delegated issues as they are raised across the organisation. The biggest challenge an Agile Executive Sponsor will face is that there will be so many issues how to best prioritise them – using both Agile techniques and insights gathered to prioritise.

Conclusion

Transformations take a long time, are fraught with many issues as adopting new changes is hard for everyone. Aside from performing these seven habits, Agile Executive Sponsors will need to have a tempered balance of both patience, resilience and tenacity. Too much patience and the transformation will stall, too much tenacity and the change will be fully rejected, too much resilience and people will be change fatigued.

In a few weeks we will take a look at Agile Leadership and see how the role of a Manager changes in an Agile organisation.

A note on enterprise transformations

I have seen some great Agile Executive Sponsors who started an transformation by not being very strategic or proactive and instead focusing the transformation in a one step at a time fashion. Primarily they did this for one of three reasons:

  1. They don’t have the authority to change elements outside of their boundary of influence
  2. There was limited organisational appetite at the C-Suite for an enterprise change
  3. There was limited understanding at the C-Suite about what an Agile Enterprise Transformation meant

These executives were highly successful in the areas that they championed the change in, but in all instances the change stalled and was limited in its effectiveness. As an approach, if one of the above three problems exists in the organisation it is highly likely that a such a champion does need to step up and perform a smaller scoped transformation so that insights can be gathered at the C-suite level before a wider scale change is endorsed.

Welcome to the fourth blog in the Scaling Agile Tricks Series.

So far we have covered The Leadership Cell, the Mitosis division of teams, and Pipeline management techniques.

In this blog I will cover how to setup teams so that they deliver more efficiently. I am not the first person to talk about different types of teams and would like to highlight that a lot of this content has already been previously covered by Kenny Rubin in both his presentations and his book.

What is economic efficient teaming? To me it is about:

  • reducing handoffs and dependencies
  • which in turn is about reducing risk and improving efficiency

There are a number of different options when structuring teams who work at Scale:

  1. Feature Teams
  2. Component Teams
  3. Architectural Layer Teams
  4. Customer Journey Teams

Let’s take a look at what each of these means and the pro’s and cons of each of them.

Feature Teams

What is it? 

Let’s take a look at the example feature below.

If we have a product that relies on multiple types of systems, lets say a mobile banking app, you would likely have to build both an android and an iOS front end. Additionally on the backend, to talk to the core banking system you would have a number of interface points – in this example a simple .net controller before a middleware tier. In this scenario most of the middleware services already exist due to an existing web front end system.

The design of this team is such that any business feature can be delivered wholly by the team without any other interactions to other systems or teams. The team has all the skills that it needs to build a feature across both of the front ends. They can even adjust the web banking solution if the feature needs it to.

A feature for this type of team would be “As a banking customer, I want to know if my recurring payment will overdraw my account, so that I can manage my accounts to not get an overdrawn fee”. The feature goes to only this one team to deliver.

Pros:

  • No dependencies or hand-offs with other teams
  • Encourages big picture thinking – the team can consider the need and fully implement an alternative solution if they believe it will better meet the need
  • Low inventory waste – assuming there is some investment in cross functional capabilities, the movement of work is limited to only the capacity of the team. The team can swarm to get work done and fully own the reduction of work in progress to deliver the feature.
  • Low integration – the feature can be integrated across the multiple systems by the team itself without having to co-ordinate across teams for integration
  • Very low end to end cycle time – all of the above factors compound to a really low cycle time.
  • High cross product knowledge
  • Low susceptibility to peaks and troughs of work

Cons:

  • High investment of cross functional capabilities with a moderate change concern of people having to learn systems and languages outside of their comfort zones
  • Unable to scale easily past a few systems – if the team also had to do the middleware changes and the core banking system changes this approach would fall down heavily due to either too much knowledge having to be retained in the the team or over bloat of the time size. Commonly this risk is mitigated by having one or two middleware developers shared across the set of teams that move in and out of the feature teams depending on the feature.
  • System instability due to lower ownership of architecture and technical debt – because multiple systems are being maintained there is less strength and care than what occurs when only a single code base is being changed. Feature teams do result in higher amounts of technical debt being created if the Technical Lead role in the Leadership Cell is not empowered.
  • Reduced likelihood of asset reuse – the feature team will tend to not think outside of the box of how the feature could be extended for the future. They will build for the knowns of today without knowledge of similar trends being delivered by other feature teams around them.
  • Higher chance of code merging – because other feature teams may hit similar screens or pages there is an increased risk of misaligned user interface design and increased code merge cost.
  • Higher costs to get consistency in practice – best practice will need to be shared with all the team across all of the feature teams for all of the systems in the scaled cluster.
  • Higher chance of defects due to dispersed knowledge of the product.

 Component Teams

What is it?

Using the same feature as before, it would be split and handed to two different teams to implement. One team will do the detection mechanism on knowing if the recurring payment will overdraw the account, the other team would process the notification to the customer.  The two teams would need to agree on the design, implement them separately and then integrate it when both have completed.

Component teams are especially useful when the code base is all one massive system and you want to break it down into logical groupings. Spotify is renowned as being a heavy user of the component team concept where portions of the screen that you see are owned by different teams. It isn’t mandatory that component teams are used where just one code base or system exists – in the above example you may still have an iOS, android and .net developer in each team. However it is likely that team composition will differ in the component team scenario.

Pros:

  • High technical ownership of debt and architecture – teams have a strong purpose and focus on cleaning up their area of the product, they are also likely to have peaks and troughs in work that gives them the time to focus on this as well
  • High asset reuse – if the work goes to the notifications team, they would likely focus on ways to make that component re-useable or available for other teams in different ways. Additionally they would likely have visibility of multiple similar requests.
  • Low chance of code merge – the team are the clear owners to the code and are highly unlikely to have code merge clashes
  • Lower defect likelihood due to depth of understanding in their part of the code base

Cons:

  • Highest number of dependencies for delivering a complex customer need (economically nonviable at scale)
  • Cross product knowledge very low
  • Susceptible to peaks and troughs of work
  • Small picture thinking (my job is this one tiny bit)
  • Requires integration

Architectural Layer Teams

What is it?

Using the same feature, teams are split by their specialties and consequently the feature has to go to three teams and then be integrated together.

In my experience architectural layer teams are often mistakenly called component teams, but the key difference is that work is split by capability and not by a portion of a product.

Most waterfall teams are setup as architectural layer teams.

Pros:

  • Minimal disruption to challenging people’s specialties, resulting in low change resistance
  • Supports massively complex organisations where a single change impacts dozens of systems
  • Favors contractual agreements
  • High technical ownership of debt and moderate ownership of architecture
  • Reduced costs to get consistency in practices
  • Low chance of same code being worked on by two different teams

Cons:

  • High dependencies, which leads to long cycle time (very high if each team is part of a separate agile release train)
  • High inventory waste (work sitting idle waiting for integration)
  • Discourages sharing of information through silos
  • Small picture thinking (my job is just this bit)
  • Moderate susceptibility to peaks and troughs of work
  • Requires integration
  • Cross product knowledge very low

Customer Journey Teams

What is it?

Using the same feature, multiple teams exist for the product, each one taking care of a logical portion of the customer’s journey through the product. Let’s say that this feature came about due to a number of complaints of people leaving the bank because they cited their hatred for overdrawn fees (especially as they believe the bank would have known it would have been overdrawn if the scheduled payment occurred).

Because customers were leaving, the feature went to the Retention team.

In this example the end to end product is supported through a number of different systems. What teams have what system capability is dependent on the system relevance at the journey step. The Retention team needs to have capabilities in both System 4 and System 2.

Customer Journey teams are the newest team structuring kid on the block, and whilst there is still not a lot of evidence of whether it works or not it has a lot of promise as it is more like a cut down version of feature teams.

Pros:

  • Very low chance of the same code being worked on by two different teams
  • Low dependencies or hand-offs with other teams (unless the feature crosses multiple customer journey steps)
  • Encourages big picture thinking – the team can consider the need and fully implement an alternative solution if they believe it will better meet the need
  • Low inventory waste – assuming there is some investment in cross functional capabilities, the movement of work is limited to only the capacity of the team.
  • Low integration – the feature can be integrated across the multiple systems by the team itself without having to co-ordinate across teams for integration
  • Low end to end cycle time – all of the above factors compound to a really low cycle time (unless the feature cross multiple journey stages).
  • Higher empowerment in reducing technical debt
  • High likelihood of asset reuse

Cons:

  • High susceptibility to peaks and troughs of work (certain customer journey points tend to be heavier in work than others, especially in a banking app solution)
  • Low cross product knowledge
  • High investment of cross functional capabilities with a moderate change concern of people having to learn systems and languages of their comfort zones
  • Unable to scale easily past a few systems
  • Low cross ownership on architecture
  • Higher costs to get consistency in practice – best practice will need to be shared with all the team across all of the journey teams for all of the systems in the scaled cluster. A good example is consistency of UX elements and design.

Summary

Who would have thought it wasn’t so clear cut how to split teams? The struggle often is that people don’t know of these options and the trade offs that they are choosing. The choice is not clear cut.

You also don’t have to have all of your teams in one pattern.  In one organisation I moved four architectural teams into two component teams and two feature teams. The number of feature teams eventually grew to over ten, but we still found it useful for quite a while to keep the two component teams in place because of the significant complexity in that part of the code. To grow capability of the architectural teams into feature teams wasn’t easy either, it took half a year of struggling and many frustrations, but I had multiple people tell me a year later that it was the best thing that happened to the area and worth it despite the pain (and this was from some of the most strongest opponents).

Feel free to post a reply if you disagree with the pros, cons and have any other team cutting options.

 

Welcome to the third blog in the Scaling Agile Tricks Series.

So far we have covered the Leadership Cell pattern and the Mitosis pattern.

In this blog I will cover my personal sentiments on managing, refining and decomposing pipelines when delivering using Agile across multiple teams.

Generally I use the word pipeline management instead of terms like Program or Portfolio Kanban, mostly because the term is simpler to understand and the usage of Kanban implies a solution that there may not be a problem for.

I have seen three patterns used for pipeline management at scale:

  1. Dual Track with separate ownership
  2. Dual Track with team ownership
  3. Just in time team flow pull

Let’s take a look at the pro’s and cons of these in some more detail.

To Dual Track or Not, that is the question

Dual Tracking is a concept that originated as part of Dual Track Scrum – where teams were often seen doing some backlog preparation or actual initial thinking of work one Sprint in advance:

Image result for dual track scrum

When doing this technique the reality is that it creates context switching for individuals across two sprints – the current and the next planned Sprint.

Image result for dual track scrum

My main issue with Dual Track Scrum has always been that it has been dressing Agile up in Waterfall clothing. It creates and encourages the idea that Discovery occurs in one Sprint, Delivery in the next Sprint and, dare I say it, scarily some people end up doing testing in the following Sprint.

Well, imagine that at an even bigger scale. This is what it tends to look like:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

From top to bottom this is the context switching breakdown (worst case scenario). Firstly, delivery teams may be supporting any production issues that arise from the previous increment that they have delivered (note I use the term increment to indicate a number of Sprints that has resulted in a release).

Secondly the team is working on the current increment, delivering user stories. If they are unlucky they are dual tracking here too – ie working across two Sprints (2nd and third rows).

Thirdly they may be involved in the shaping of the work coming up for the next Program Increment. In the three pipeline management options I gave at the start of this blog this equates to the second pattern “Dual Track with team ownership” as the initial discovery isn’t done by a different team or subset of non team individuals.

In the advent of a really massive piece of work then there may be even further upstream work, breaking massive boulders of work down to feature like rocks. Think of this as a rock crushing machine. In my experience, at scale teams rarely get involved in this activity.

And lastly we have all the other stuff that teams end up having to do – <insert bureaucracy activity here>. If they are super lucky they get to have time to think and reflect on themselves as individuals and seek opportunities to improve their own capabilities.

It shouldn’t be a surprise to anyone that teams barely deliver when put under these constraints and expectations, and yet I do find that often it is very unclear to leaders of such teams that such extensive context switching is occurring.

The first pipeline management option, “Dual Track with separate ownership” reduces the amount of context switching down by having either a different team or key individuals like a designer and an architect look at bigger work coming down the pipeline in order to assess its customer and business desirability and viability and whether it is feasible given constraints, value earned over cost, etc. More commonly than not, these people aren’t or haven’t for quite some time been involved in actual feature delivery. Whilst they can provide a buffer to the team having to do some of this activity, it is at a high risk that the solutions that they are coming up with are unimplementable, over designed, or are based on poor assumptions. Additionally they create a need for a handover, which is often poorly executed.

Whilst you could certainly put in process to reduce these risks, why over engineer the process?

As a core principle for Scaling Agile, my number one rule is “Remove handovers and dependencies”. Which brings us to…

Just in time team flow pull

Each option has it’s pros and cons. The Just in time pattern means that the backlog for the set of teams is very lightweight in fidelity and knowledge. Think of these backlog items as initiatives (I am trying deliberately to avoid words like Epic, Capability and Feature as the hierarchy varies based on which scaling model you use). In my mind, an initiative is the sort of thing you might put on the release notes to customers when you do a new app store release, or something big enough to do a sequence for customer onboarding. Initiatives can take as little as three weeks or be as big as six months of work for a single team.

Initiatives are de-coupled from the other teams delivering in the same product through good shaping of scope and good team design (which we will cover in a future blog post). As a team finishes delivering an initiative they will pick up (pull) a new one and begin the discovery process on it. It tends to look like this:

 

 

 

 

 

 

 

At the tail of this approach the team is likely to prioritise first and foremost the release and support activities. Their next priority is doing Discovery/Inception on the next initiative. In the learning period where they may be waiting for customer feedback they can fill the gaps with technical debt.

You can see visually the difference between the reduced context switching of this picture and the previous one is quite significant. It does come at a cost – the cost of ensuring that the team is as independent as it can possibly be from the other teams delivering on the same platform. It requires not only good work prioritisation from a backlog perspective to limit two teams working in the same area, but also great technical practices to limit integration risks and be able to release at any point in time.

I really love this approach because it empowers the team to release when they are ready and empowers them to know when they are ready to begin coding. One risk is that they may spend too much time in Discovery, but even Dual Track has this risk. Another risk is that they may begin Discovery and then determine that the initiative isn’t viable. This could also occur in the Dual Track scenario, but a new backlog item would then need to be picked up and potentially those stakeholders may not be prepared to spend time in Discovery. The core of the issue is that there is no buffer time if the stakeholder(s) are unavailable, whereas buffer time exists in the Dual Track approach.

The reality? Out of about forty-five initiatives I have seen an initiative be cancelled once, so why design a process solution for such a small occurrence rate? Where you work may be different and more work may be cancelled in Discovery, so choosing which approach to take may be dependent on the failure rate of Discovery.

As a coach I try to move organisations towards Just in Time team pull but it takes time to remove the dependencies and handoffs first.