Agile Forest

Seven changes Agile Coaches need to make to support remote coaching

Renee Troughton

May 6, 2020

Organizations dealing with the COVID-19 crisis are needing to reduce costs quickly and are consequently looking to remove or reduce their coaching cadre. This is understandable as it is often more challenging to see the value that a coach brings, after all, coaches are about making their teams shine not themselves. But a coach’s value should be best demonstrated by team’s positive improvement of their speed, quality and value delivered.

Additionally there is a belief that Agile Coaches are only about standing in team’s ceremonies and doing minor course corrections as they overhear work being done by teams. With teams now working distributed, organizations believe that because coaches can no longer see and hear teams, that their effectiveness is significantly reduced. However, Agile Coaches are needed more now than ever before in order to support teams in helping to work effectively whilst distributed. This includes training on using new tools to effectively collaborate, focussing higher on alignment prior to starting work, empathatically connecting with team members to resolve issues and ensuring team members aren’t feeling socially disconnected.

Agile Coaching of leaders is just as equally important for a similar series of reasons that existed prior to COVID-19 including how leaders can best enagage, support and get transparency of their teams using digital tools.

Whilst teams and leaders need to adjust to this distributed world, Agile Coaches too need to make some adjustments in how they have traditionally worked. The following are the top seven changes that Agile Coaches need to make to be more effective in remote coaching.

Build trust virtually. Trust is a critical element to be established in any coaching relationship. If you have an established coaching relationship when working virtually is unlikely to be a significant hinderance. But for new coaching relationships, building trust will take longer and be more challenging to detect nuances in body language. Coaches will need to demonstrate more vulnerability and humility than they may be used to in order to help build a trust relationship. Check out these 13 simple strategies for building trust.
Get familiar with new games and activities that can be run virtually to teach people agile behaviours, principles and practices. Lisette Sutherland, co-author of “Work Together Anywhere: A Handbook on working remotely, successfully – for individuals, teams and managers” has produced a brilliant page of ideas and tips on her collaboration superpowers site. Utilise simple Trello boards to run training agendas and vitual whiteboards or virtual post-it note tools. To inject some competitive, multi-choice activities into training utilise tools like Kahoot.
Adapt your coaching style to focus heavier on general coaching and less on Agile coaching skills. Great coaches already utilise a broad toolkit that includes deep Agile knowledge and strong capabilities in general coaching utilizing coaching models like GROW. With anxiety and stress levels so high, coaches will need to ensure that their coachees are feeling supported and that conversations are focussing on the coachee’s needs over necessarily focusing on Agile maturity.
Focus on open questions. As coaching becomes completely virtual, it will be harder to see the “system of work”. Coaches will not be able to overhear conversations (unless the team is using constantly voice connected platforms like Discord). Consequently it becomes even more important that coaches ask open questions like “why”, “what” and “how” over closed questions that result in a “yes” or “no” response.
Support leaders to not revert back to command and control. When under stress and anxiety we will revert to utilize patterns that have been deeply established in the neurons in our brains. Coaches will need to be super sensitive to this shift in leadership behaviours and watch out for it in emails and in voice communications. When detected, coaches need to be congniscent to the context – maybe the group required some immediate and rapid direction setting as the situation had become chaotic. If the context didn’t require micromanagement, then coaches should be empathetic when discussing this with leaders, appreciating the stress that they are under and supporting them by letting them know when they themselves have failed to re-enforce behaviours and fallen back on old habits.
Ensure teams and leaders have access to the tools needed to collaborate. Along with the tools previously mentioned, ensure that the team has access and training on to tools to manage their work. Look out for plug-ins that can make their work even easier. Help by cleaning up the quality of information inside of the tools so that leaders and teams have better insight into the work.
Strive for alignment across teams. Listen out for team members that are unclear on the purpose and acceptance criteria of their work and help them to connect with stakeholders to resolve ambiguity. Often team members have little visibility on what other teams are up to – coaches are in a unique position to detect cross-team misalignments and should help to resolve these. For teams that are utilizing SAFe to create alignment, coaches should continue to help out preparing and supporting PI Planning distributed. Xebia has done a number of great blogs on how to do remote PI Planning and remote core team ceremonies.

Taylorism isn’t as far from Agile and Lean as you would think

Renee Troughton

1 comment

November 25, 2019

We can see our forests vanishing, our water-powers going to waste, our soil being carried by floods into the sea; and the end of our coal and our iron is in sight. But our larger wastes of human effort, which go on every day through such of our acts as are blundering, ill-directed, or inefficient, and <redacted> are less visible, less tangible, and are but vaguely appreciated. We can see and feel the waste of material things. Awkward, inefficient, or ill-directed movements of men <or women>, however, leave nothing visible or tangible behind them.

This could be a quote written a week ago, but it was written in 1919 by Frederick Winslow Taylor in his management book of the century The Principles of Scientific Management.

A lot has been said about Taylor’s book that eventually led to the movement of Taylorism. The most commonly held indictment is that it was mechanistic thinking, taken in an era of solely mechanical manufacturing and no longer applies to the modern world.

Winston Royce also wrote an article about software development, citing that a linear approach to development, aka waterfall, would be the wrong approach. Readers misread or misunderstood this leading to a world of in appropriate application of techniques and patterns.

Whilst Taylor’s belief systems in the book may be held up to scrutiny today, like Royce, Taylor’s work has been misinterpreted and vilified by those pushing modern management methods*.

This blog post will discover where Taylor’s Principles of Scientific Management aligns with current modern management thinking, where it is in stark contrast and the grey zones that need further discussion.

Aligned with modern thinking

The following concepts described within The Principles of Scientific Management are aligned with modern management methods:

It is important to ensure that individuals are suitably trained to be competent for their job. This should be considered over hiring in skills.
Competency is not just people contributing value to the product or service but also leaders.
To have a prosperous organization, you have to have prosperous people.
People need to be paid a fair wage (also noted as a first pillar of motivation and a basic human right in Dan Pink’s book Drive)
Managers know that the collective wisdom of those underneath them far exceeds their own wisdom. Because of this, managers are best placed to provide a clear problem and then steer clear of going into solutions.
Management is a co-operative activity, managers should guide, done daily, but even if guiding should be partly accountable for the outcome. Managers should not direct or coerce.
The importance of customer is a critical third pillar of any organization – employer, employee and customer need to be considered together.
There are no silver bullets for solving organizational problems.
Inefficiencies are most often due to the system.
Time and motion studies should be utilised to assess and remove waste or simplify steps. The modern take on “time and motion studies” is value stream mapping and optimization.
One of the bigger challenges that people have to applying Lean in Software Delivery is that removing waste doesn’t apply to knowledge work and that it is best applied to manufacturing. Whilst it certainly cannot be denied that Lean excels in a manufacturing environment, waste does exist in knowledge work. For example, in software development, if you are running too many branches at once then you have merge motion that multiplies out. Another example is unstable development teams, which result in knowledge waste.
“Sweat shop” conditions don’t make for an effective organization. Sustainable pace of delivery is important to flow and optimal value output. This means having breaks and suitable working hours.
Productivity, that can result in a competitive advantage, is obtained through efficient usage of both humans and importantly machines/automation
Some methods/techniques are better than others for specific problems. A large toolbox is valuable and knowing what the right tool to use for the situation is important. Use real data to give insight to what tools work best in what circumstances.
Run experiments to find what works more effectively, this is especially true when the problem to be solved is complex.
Quality over speed is never an acceptable trade off. Quality needs to be kept high in parallel to improvements in efficiency.

As you can see from the points above, Taylor’s Principles of Scientific Management aligns quite heavily with Lean and to some extent the works of Agile, Systems Thinking, David Marquet’s Competency model and Lean Startup.

Unaligned with modern thinking

With the movement of time, however, there interestingly has been a cyclic return to concepts that Taylor is directly advocating against. These include:

Management is a true science with clear laws, rules and principles. Scientific management is applicable to all kinds of human activities.

The Principles of Scientific Management sometimes also refers to itself as a Task Management approach. It was brought about in the industrial age and was dealing with human to machine interaction. Whilst the world back then was typically a heavily physical interaction, now days it is more of an intellectual interaction where the machine is the conduit for activity between individuals through human built programs. The statement above is why Taylorism gets labelled as “mechanistic thinking” rather than “ecosystem thinking” but it is not surprising when the problems that were being dealt with back then were either simple or complicated.

Most work place environments are complex where the laws, rules and principles are spread out over so many sub-systems of management and are often conflicting with what was the original intent behind the Principles of Scientific Management – that of an efficient individual producing quality output. We have gone awry with controls and convoluted value streams and should seek to first simplify. This isn’t to say that all things complex can be simplified down to a complicated or simple space of problems, but that there is still a lot of simplification opportunities out there, though getting management to a stage of science is probably an unlikely goal and dismissive of the human element. Enforced standardization for everything is not the answer, but in some cases some standardization may be beneficial and in other cases removal of standardization may be beneficial – the point is, you need to understand the problem space you are dealing with and the impact that standardization (or lack of) is having.

Scientific management doesn’t work in complex environments where the best outcome is non deterministic. That said, scientific management also concedes that in complex spaces, an experiment approach should be taken to find the more of the successful patterns to implement. This is not unlike a ‘Probe-Sense-Respond’ approach that Agile utilises.

People have a natural instinct and tendency to loaf

This is certainly a divisive statement. Those people familiar with the Theory X vs Y work will recognise this statement as coming from a Theory X leader, that is, someone who is naturally pessimistic about their people, thinking of them as unmotivated and needing constant direction.

Taylor goes on to say that systematic “soldiering” (underworking) is intentionally done to keep employers ignorant of how fast work can be done. It is in each person’s self interest to not work faster than anyone has in the past before. They work as slowly as they dare.

Whilst these are certainly shocking statements, one thing of note however is that there has been a growth of science to back up some of the statements made in the area of social loafing. This is not the say that the solution to the problem should be command and control management and standardization, but interestingly the transformation approach within the Principles of Scientific Management actually had the answer – to separate the team and one by one reform a higher standard, re-integrating individuals one by one to negate the chance of social loafing. Taylor’s approach also made it clear that each individual’s contribution would be assessed and rewarded as an individual over as a team to ensure performance. Interestingly, these are two of the steps to combat social loafing.

But how does modern management approaches deal with social loafing? Agile tries to keep people accountable through setting regular small goals and helping to support the team to achieve them on a daily basis. I was once a Scrum Master in a team where one person in the team was underperforming. It was obvious to everyone in the team (including the individual involved). The person actively opted to exit the team citing that they knew they couldn’t keep up and didn’t think any level of support would get them to that state. This is exactly what is described in the book – that not all individuals are cut out for all work and even despite support and training, sometimes they should just find something better suited to them. This individual went onto a production support team and continued to perform well and happily. The more horrible version of this is the opposite effect. I was once in a job where I was pulled aside by my manager. They said, “I have had a few comments about your performance. You seem to be going fast against everyone around you. We need you to slow down the pace of your work.” It wasn’t that I was conceptually ahead of everyone, it was that I was literally putting too much output out and getting complaints because of it. I discovered that if I stopped work at 11am each day I met the pace of everyone else around me. I was forced to loaf at the pace of others so they didn’t feel bad about themselves. Acceptable performance rates are defined by the norms of the majority. I really don’t think anyone has a great solution to this problem yet.

People need to be financially incentivised or incentivised for a promotion to work more effectively

Dan Pink’s ‘Drive’ book and the studies referenced within highlight that people need basic rights incentivisation to be motivated to work, but that extrinsic rewards like bonuses do not work in knowledge work environments. ‘Drive’ does note that this works for simple problems, especially manual problems so it isn’t surprising that Taylor came to the conclusion that bonuses are an effective way to motivate individuals, but it is clearly a statement that doesn’t work for problems requiring human thinking. Some organizations are already taking the step to remove bonus systems not just because of this but because of the time effort invested in it and because of the conflicting environment it creates. It should be noted that when Taylor talks about incentivization, he specifically says that quarterly or yearly bonuses are not the solution and are not frequent enough to make an impact on behaviour. So whether you take Taylor’s opinion or Dan Pink’s, the point is neither of them are advocating for quarterly or yearly bonuses that 90% of the corporations still use.

Hard work can only be achieved through uniform process definition and adherence.

Again, we now know that motivation has a huge factor on performance and hard work and that mastery, autonomy and purpose play a huge hand in intrinsically motivating individuals. This is not to say that process is bad, but intrinsic motivation is the trump card. Those who follow Agile believe in “individuals and interactions” over “processes and tools” because it is through motivated an connected teams that delivery teams best succeed. If you have to deliver work as a team, then you need to be a team and no process is going to solve deeply personal issues between two individuals.

People cannot train or learn by themselves. A manager’s job is to define the process and train others.

People want to improve. They want to solve problems and get better as a person with a trade/craft. Forcing only one way of learning on them is quite limiting by today’s standards and again Dan Pink’s “Drive” book describes the importance of self-discovery of better ways of working to being a significant enabler to intrinsic motivation. Taylor made this statement because of the complexity of knowing the better way being unobvious to most people. In fact, they recommended getting the highest performers together and studying them to find the patterns of performance to find a new value stream. Experiments were run and then the value stream was further tweaked through constant refinement. Logic wise, it is hard to argue with the approach – amplify the patterns that are working. This is actually what happens in Agile as teams share patterns of success with others.

The step wrong that Taylor made was in thinking that there was no way to self-organize to find these patterns themselves. Modern management methods have just given us a set of tools for individuals in teams to share patterns and learn from each other without managers having to be involved in the process. That said, Lean strongly advocates for “Leaders as teachers”, is this very different?

Management take over all the work that they are better suited to, specifically this includes all the work plan to deliver against (activities, and timeframes).

I have seen a manager once create a project plan for their team of fifty people to deliver it to. They did it overnight with their buddy. You can imagine how horrible that plan was. The project that ran against that plan was seven months late and twenty-five million over budget. Nothing ever runs to plan which is why in Agile the belief is “Responding to change over following a plan.”A plan is important, a plan that is responsive is better, a plan that is made with the people who are doing the work is best. If you don’t include people in on designing and adaptations of the plan then they don’t feel accountable for the outcomes.

Principles of Scientific Management is all about individual goals and individual tasks.

It does this because it believes it is the most fair approach for people and organizations. It believes that herding and working as a gang is a bad thing (most likely due concerns to loafing) . This is probably acceptable for simple problems but for a complex problem where multiple specialists are required we need to find ways in modern organizations to have teams working successfully together. Because of the heavy focus on individual tasks, it could be said that Scientific Management seeks only resource efficiency and not flow efficiency like Lean does, but I think it is less about individual utilization and more about simplifying everything down to single piece, single person flow.

Lastly, and probably most importantly, the Principles of Scientific Management is incredibly disrespectful in a number of instances to human beings. With comments like workers being stupid or idiots and “you do what you are told to do, when I tell you to do it, and don’t talk back”, it stinks of Theory X command and control attitudes. Respect for human beings is a significant pillar in most modern management methods.

Taylor’s writing is symptomatic of the era and time that it was written in – it faced problems that are different to ones organizations are facing today with attitudes that would easily get you fired by today’s standards. But everything isn’t rosy or wrong, so let’s take a look at the perspectives that need more discussion.

Could go either way

The following perspectives from the Principles of Scientific Management are worth discussing further:

Underworking (deliberately working slowly to avoid doing a full day’s work) is the greatest evil.

Loafing is just one element of underworking. The more common type of underworking I see is apathy, where people either don’t care about what they do or are unengaged. The causes for this are simple, but solving it is less easy.

Firstly the purpose of the work could be disconnected from how a person perceives it, for example, an employee cannot see link to activities to the bigger goal, or they don’t believe in bigger goal, or their activities or the goal changed from when initially brought on board. Secondly, it is possible that there are interactions at work that have led them to feeling disconnected – either through struggles with other people or struggle with the system that they are doing work in. Thirdly, sometimes people have so much going on in their real life outside of work they just don’t have the cognitive space to give everything to their job during working hours. Whatever the reason, none of these should be considered “evil” attitudes.

Managers should plan at least one day in advance, with written instructions, describing the detail of the task to be accomplished.

Detailed task instructions is pretty ridiculous in today’s modern corporation. A more modern approach is to set a clear goal and outcome and give people the space and support to get there themselves. What I do find interesting about this statement is the “at least one day in advance” bit. This suggests that Taylor’s take is that plans can be quite rapidly adjusted and just in time based. In Agile, teams plan in Sprints that are a week or up to four weeks planned in advance. Teams also do Daily Standups which is intents of a plan for the day for each individual (though this isn’t the key intent of a Standup).

You should train and transition people into new ways of working by having an individually tailored approach, creating a new target state one person at a time.

This was one of the more intriguing statements to me. When we transition people into new ways of working, yes there is individual coaching, but we also tend to transition whole teams. It reminded me a little of the Monkey and Banana Syndrome, where a new norm is established one person at a time with little explicit expectation setting on how you are manipulating the people. It is important whenever you introduce new ways of working with people or teams that it is something that they want to try, but also, that the reason why is made clear to all involved.

Conclusion

It is not uncommon to hear from people implementing new ways of working statements like “That’s not Agile” or “That’s not Lean”. In a similar manner, the Principles of Scientific Management has equally suffered from poor application and consequently received a worse image than it probably deserves (Theory X style language aside). In a similar vein, Taylor also conceded that a transformation wasn’t a quick solution, but a multi-year journey, acknowledging that the human change element was one that would take the longest time. Interestingly, Taylor also recognized that transformations often took a pattern of being easier once one quarter to one third of the organization had made the change – this is more commonly referred to as crossing the chasm.

But has Taylor’s Principles of Scientific Management helped us or hindered us? The fact that so many of the beliefs are still valid suggests that it has been helping us, but I can’t help but think of the opening statement, that was Taylor’s cry for change, remains unresolved – our forests are still vanishing, our waters going to waste, the end of oil is certainly in sight. We still have people blundering, inefficiently working, often with little appreciation. The question is, is Agile and Lean or any other modern management method getting us further along – probably yes, and with more respect and connections to humanity, but not fast enough.

* Note: Whilst ‘Modern Management methods” is quite a broad generalization, for the purpose of clarity it includes the work from approaches, frameworks and concepts from Agile, Lean, Lean Startup, Design Thinking, Dan Pink’s Drive, Complexity thinking eg Cynefin/VUCA, David Marquet’s Turn the Ship Around, and Systems Thinking.

4 global trends from Agile 2019

Renee Troughton

1 comment

August 25, 2019

A few weeks ago I had a joy of returning to Washington DC to attend the 2019 Agile Alliance conference. The last time I attended the conference was in 2015 when there was a high focus on scaled approaches as the new kid on the block. This time, I found a lot was the same but also some new concepts so let’s take a look at the key trends.

A very strong shift away from process and methods towards values, prinicples and mindset.
It seems the day of over-indexing on process and tools over individuals and interactions has finally ended. There were certainly way more talks on the softer side of agile than there was in process, practices and techniques.
The introduction of a ‘self care’ track.
Somewhat aligned with shift towards the softer side of Agile, this new track is finally recognising the challenge that many Agile Coaches face in keeping up their personal momentum and health when potentially having little support mechanisms inside of an organisation that they are helping to change.
A strong focus on coaching skills and capabilities
Not entirely unexpected or new, but it was great to see conferences moving away from basic or ‘introductory’ content to support the continued growth of those who have been doing agile for a few years. This is a sign that Agile is continuing its momentum by not just focussing on Scrum Masters and Product Owners.
Clean language and NLP. According to a few other coaches this is not new and has been around for the last few years but I seemed to have missed the messaging on this. The intent behind this isn’t too dissimilar to Non-Violent Communication, in that it is a way of deliberately using/choosing language to limit interpretation or suggestive reframing.

In addition to these new trends what stayed the same included:

A continued focus on technical practices, especially associated with automated testing and DevOps
A continued growth of focus on Business Agility, but still not a lot of stories of people doing this and still quite a bit of confusion on how to apply Integral in this space.
Great corridor conversations! Stay tuned to a few of these turning up on the Agile Revolution Podcast.

What do people want Agile Coaches to do?

Renee Troughton

2 comments

May 7, 2019

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)?

Maybe Agile isn’t the answer for everything

Renee Troughton

1 comment

February 20, 2019

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:

Create uncertainty. This uncertainty dramatically reduces individual productivity.
Force teams to go through Tuckman’s model, again decreasing productivity.
Force work to be re-distributed to teams, creating a hold on flow.
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:

Stop restructuring more than once a year (twice ideally)
Learn your choices and trade-offs and implement appropriate mitigations
Test and learn using real data – how do you know your organisational productivity and how does your structure affect it?
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)
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:

Change plans that are never implemented
Change plans that don’t target the right groups
Non existent change plans
Insufficient change plans (for example an email or two is done but nothing to embed a real capability change)
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.
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:

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
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
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:

They do not create a safe space; failures are not tolerated
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”
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:

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.
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:

That once something is kicked off there is little focus on delivery or execution of the work
Which results in lower benefits realisation, lower value to customers and a delivery system filled with waste
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
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:

Stop starting and start finishing. Learn how to create focus through to value realisation before kicking off something new.
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:

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.
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:

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)
Share with the C-Suite and the board these findings
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
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:

Think about consolidating/reducing the number of consultant groups
Create visibility about what what each group is focusing on, or ensure that the work is fully mutually exclusive
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

Renee Troughton

no comments

September 18, 2018

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.

Why SAFe is not the scaled Agile approach you need

Renee Troughton

8 comments

June 24, 2018

There 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:

New to SAFe team runs a Program Increment and makes a commitment for the next quarter.
Because of the two day PI timebox and no pre-work, they have a lot of outstanding questions for the work
They spend a week or two trying to get all the questions answers whilst trying to deliver on their commitment
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
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
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
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)
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:

New SAFe Release Train kicked off
Teams are setup the way they are today (architecture/system oriented)
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.
Teams deliver despite the dependencies
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:

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.
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.
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.
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.
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.

Ode to an Agile Coach

Renee Troughton

1 comment

April 25, 2018

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.

Switching up your retrospectives? Think again.

Renee Troughton

no comments

April 7, 2018

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:

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.
Don’t commit to more than five actions. You just won’t do more than five.
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.
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.

Product Ownership – Game of Thrones style

Renee Troughton

no comments

February 24, 2018

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.

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.