From project teams to stable agile teams

What do we mean by stable agile teams?

By stable agile teams we refer to cross-functional teams that can carry out an assignment from end-to-end. This kind of team works together on the same assignment full time and is not dissolved when the assignment is completed. They are rather given a new assignment. This change is fundamental if you want to start working agile structurally. Instead of bringing people to the work, bring the work to the people (existing teams). In other words, you keep your teams stable. When a new project pops-up, the work is either taken to the most relevant free team or divided over (the backlog of) multiple teams.

By stable teams we explicitly do not refer to homogeneous teams that divide their people over multiple projects or assignments. We would rather refer to such a silo as a department. In such a situation, teams do not work end-to-end but rather work flows through multiple (specialized) departments.

The value of stable agile teams

As a team member of a stable team you are in one team at any given time. This means you do not have to divide your attention over multiple project teams. This decreases the amount of the required task-switching and increases focus . This ensures stable teams to deliver more value more quickly compared to non-stable teams.

Within IT and software development these types of teams are commonplace. Outside these fields many organizations cling to the idea of (relatively) short-lived project teams. If you want to stay relevant as an organization, you need to make the step towards stable teams.

The best predictor of teamsucces is not what you might expect. It is not intelligence, skills, synergy or even leadership. It is safety. What makes people feel safe? Working together in a focused way for a longer duration of time. Every time you break up a team to form a new team, you have to start this process all-over again from square one. Often it is better to give a mature stable team an assignment that does not completely matches it skillset, than forming a new team that needs to go through the forming, storming and norming phases of team development, before they start performing. High performing teams will quickly pick up the required skills, become a high performing team is a much lengthier process.

Many organizations tell us that setting up stable teams in their situation is impossible. There are too many projects and employees simply cannot focus on a single assignment at a time. This points to a more fundamental problem: the organization is unable to make real choices and prioritizes badly. Paradoxically, as the amount of different things you need to get done increases, it becomes exponentially more important to focus on one thing at a time. Only by focusing and finishing tasks and projects one by one, you will succeed to rapidly and continuously delivering customer value.

Another fundamental problem is the amount of time and information that is lost through slow and sub-par communication. This too can be tackled by using stable teams that work together, preferably at the same desk. When team members are seated closely together, information is easily shared and problems are quickly resolved. If two team members are discussing an issue, and a third has a solution, it can be solved without a need for long email conversations or meetings.

 

 

Would you like to get started with stable agile teams?

The easiest way to get started with stable teams is to simply keep a project team together after the project has been completed. Give the team a clear purpose and allow it to expand its scope to form a full time, dedicated, stable team. Another way to get started is to seek out a group of pioneers; a group of highly motivated colleagues that is ready and willing to experiment and to take on a challenge in close collaboration with a product owner and their stakeholders.

We recommend you to start out small, focus on one or two teams. They will help you to rapidly find any obstructions in the current structure of the organization that block progress. They are the trailblazers that will clear the way for other teams.

Are you also working on too many projects at the same time? Is everything both urgent and important? Do you spend most of your time at work in meetings? Are your team members unmotivated and do you miss commitment? Would you like to know how your company can start to reap the benefits of stable teams?

Feel free to get in touch. We would be happy to discuss things over coffee.

Reptile brain

We’ve all been in this situation: As soon as you walk into a room you notice something is off, without anyone telling you so. The most primal part of our brain, the reptile brain signals you to beware.

There are many factors that contribute to a sense of psychological (in-)security. This article will focus on one of them: the importance of clear boundaries. All of us, as individuals and employees require a certain level of security. For some this means a preference for predictability in their work, others might require a clear awareness of what level of autonomy in decision making the organization permits.

In his research on organizations and change Joost Kampen draws a parallel between insights from remedial education and the behavior of people in corporate environments. It states great leadership is a combination of being available emotionally and setting clear boundaries.

The role of agile leaders

Leadership, including setting boundaries, is not just the domain of managers, team leaders and directors. Wherever you stimulate taking responsibility you may (happily) expect to find leadership.

André Wierdsma, professor of Organization and co-creation at Nyenrode Business University, recently wrote the following: ‘By nature people are very sensitive to authority and in- and exclusion. We are afraid the herd will leave us behind. True self-management, therefore does not exist, because there are always people that take the lead and shape this self-management. All groups require clarity on axes of freedom, values and the rules of the game. Even in organizations with a very flat hierarchy that seek to empower the lowest possible levels in the organization, leadership activities remain important. It is possible, however, to redistribute these activities.’

Boundaries, clear assignments and agile organization

The most common way to organize in an agile way is Scrum. One of the core strengths of Scrum is that it is highly structured. The product owner represents the customer and has a clear vision on what problems need to be solved. He or she is in charge of what: What needs to happen, and in which order. Budget and time allotted present other boundaries, as do other projects, and stakeholders the team needs to take into account.

Within these boundaries, the team has a high level of freedom. The team is in charge of how. How will we solve the customer’s problems and what should that look like. On the basis of regular feedback the product is developed by the team while continuously focusing on delivering maximum value for the customer.

What happens when you set a teams’ boundaries too narrow? You will rapidly lose all initiative. Instead the team will look to the product owner for even the smallest decisions and all energy will drain from the team. (sounds familiar? non-agile projects are even more susceptible to this)

Personally, I have found that a Scrum team with a Product Owner that has set the team boundaries too wide can usually still function reasonably well (especially compared to a team with very constricting boundaries). What will hopefully happen with such a team is that by using reviews and feedback from customers and stakeholders the boundaries will become clear over time. Either the team finds the guardrails by itself eventually, or the team is able to link the project to the organization’s purpose and priorities.

Real world examples

One of the organizations I am supporting in their agile transformation uses a very incremental experimenting approach. During their transformation I was struck by the lack of clarity and transparency in all steps of the process. Employees were at a loss about what strategic direction the management envisioned as there were multiple conflicting strategic directions. In order to become agile leaders, the first order of business is for the top leadership to agree on boundaries for the organization. On top of this we will devote considerable time to clear communication and leading by example.

Interestingly, in organizations where this is clear, agile teams are quite often not happy with these boundaries right away. Rather they feel they are being restricted in their freedom. True master ship lies in being able to provide teams with exactly the right amount of freedom. Finding -and maintaining- a balance over time is what every agile organization’s leadership needs to make a priority.

A clear purpose

Every team or management assignment should be in line with the organization’s reason for being. This serves as a compass. What are we all about? And what is outside the scope of our organization?

It is often referred to as a purpose, the Why (Simon Sinek), Intention (Wouter Hart). A purpose is not merely about making money. Rather, a purpose serves to energize employees end offers customers a way to connect with your company.

Conclusion

Making boundaries explicit and giving clear assignments is crucial in an agile organization. Only when these are explicit and clear teams will feel the freedom to do what is required for the customer. Leadership’s role is to offer clarity or create a situation in which boundaries will automatically become clear over time. Tip: don’t forget a clear purpose.

Need inspiration? Morning star, a leading tomato processing company works by these two principles: ‘No use of force’ leading to total freedom, and ‘Keep your commitments’ which leads to total accountability.

Leadership Challenge

Micro management is finished… that is, if you choose to work in an agile way. Agile ways of working focus on delivering the most value for the customer. Employees are in close contact with the customer and are given the mandate to do what is required. Clear boundaries are still provided, and — depending on the chosen framework — clearly defined roles and agreements are in place. In other words, employees are given the freedom to deliver value to the customer in the way they feel is best.

What to do if you’re are a leader that preaches agile, but still checks reports for punctuation and proper spelling? Who intervenes in all aspects of what your team, department or managers do? You will need to practice a new style of leadership, starting with such alien concepts as ‘sitting on your hands’ and ‘asking questions instead of providing solutions’.

In an agile organization it is crucial for people in leadership positions to learn to provide clear boundaries, to allow freedom to operate and share responsibilities within those boundaries. And when we say share resposibility, we do really mean share. Compare how a product owner and a scrum team share responsibility. The product owner is responsible for WHAT, the team for HOW and jointly they are responsible for the product.

The subtle art of sitting on your hands

At Organize Agile we are currently assisting a medium sized public organization transition towards an agile organization. One of my colleagues was discussing the transition roadmap with the senior management. During the conversation the focus turned towards the new e-learning platform and what shape it should take. The management team discussed the new platform in detail, until my colleague reminded them that the HOW was up to the development team.

I am struggeling with sitting on my hands

Elsewhere a manager sighed: ”It’s not easy sitting on your hands. I am learning, but I’m struggeling. Especially when I feel the team should do things differently or when my own manager is breathing down my neck”. Sounds familiar?

Coaching instead of ready-made solutions

Agile is all about trust. While plans and micro management create a false sense of security, trust focuses on letting go, daring to trust anothers capabilities and offering support rather than spelling everything out.

I have seen many examples of what trust can do to an agile team. One of the most poignant was seeing an employee passionately argue a case in front of the management team. Something that nobody, including herself, had expected her to be able to do. Excellent!

The team of directors of one of our clients, who is currently in the middle of an agile transformation, is currently focused on the question how they can reshape their departments into self-organizing teams. To my mind, one of the most important parts of this assignment is developing the right mindset in empolyees, leaders and supporting services. Managers need to become aware of their new role: if an employee comes to you with a problem, help them by coaching them. Offer trust, not a solution. Ask questions.

Stop looking at your manager!

Employees need to take ownership

To employees this means that they should not bother leaders with every little issue or focus on the manager in meetings. Consider team behavior in meetings: even when a team is highly self-organized, they will behave quite differently when a manager is present. Often you will see that at least a part of the team will direct their points primarly at the manager and look for non-verbal signs of confirmation. The key to changing such behavior is making the team aware of their behavior and coach them to do things differently.

Transparency

Trust includes acces to as much information as possible. Make it easy to access and share information . This includes insight into financial margins, information from management meetings, budgets and maybe ultimately even remuneration. Make sure that there is a way that information and trends teams see at their customers, is shared with other teams and managers. Agile tools and frameworks are a great help. Scrum and Agile Portfolio boards are highly visible and offer easy insight into team activities and ambitions. Similarly, tools like Slack can help make information available broadly. Regardless of the used means, the decision to really start sharing information should be your first stop.

Conclusion

In an agile organization leadership focus needs to be on giving and receiving trust. Agile leaders do not intervene, they coach. Instead of offering ready-made solutions, they offer clear boundaries, direction and ask in-depth questions. Only in such an environment, teams will do their best work and deliver real customer value.

Read the article also here on Medium.com

In order to share both the agile mindset and the hands-on applications that Agile HR entails, we created a new explanimation video. Please enjoy! You can find the script under the video on this page.
Also, feel free to join the Agile HR Community on Linkedin. And take a look at our 3-day Agile HR training in New York City.

 

Agile HR – the new role of HR in agile organizations: the script

Agility is no longer a luxury: it might be the most important competence of organizations in our time. This means a fundamental shift in the way we think of HR. This is what we call Agile HR.
An agile organization often works with multidisciplinary, self-organizing teams. These teams can take on traditional HR responsibilities: team members look for job training together, recruit new colleagues together and sometimes even determine each other’s rewards.

All this change in organizations creates opportunities. With Agile HR, organizations are presented with the unique opportunity to make both the organization ánd HR more agile.
The are different way of doing this: if the HR-department is still a separate department, it can start working agile itself. By using Scrum, or Kanban, or Agile Portfolio Management, which visualizes which big HR-projects you work on, and makes transparent why the HR department makes certain decisions. HR will continuously learn and adapt, while collaborating with internal clients and stakeholders. This way, the HR department is always focused on the things that matter.

Then there are traditional HR instruments that are up for renewal. Like Strategic Workforce Planning, in which you make long term plans about the people and skills your organization needs. But that is still based on predictability and is often made in isolation by HR. Instead, you can try ‘Big Room Planning.’ Every 4 months, all teams share their quantitative and qualitative needs for new team members. And will act on it together. With Big Room Planning, managing the available skills and the recruitment of new people has become a responsibility of everyone in the organization.
The last way to implement agility in HR is for HR-professionals to take on new roles. As a ‘purpose-developer’, ‘trend watcher’ or ‘agile coach’, they help teams to improve their way of working, and make colleagues happier. Take the role of ‘Employee Experience Designer’ – someone who’s focused on improving the experience of the employee in the organization. The Employee Experience Designer ensures employees are serviced in a personal and delightful way, at every step on their journey through the organization.

In the end, agility is a way of thinking. It is not about controlling and prescribing, but about sensing and adapting. With a goal of delighting the customer, done by powerful, autonomous and happy teams. HR has a key role in spreading this way of thinking. That is why we wrote the Agile HR book, in which we share Agile HR practices and cases.
Organize Agile. The thought leader in Agile.

Agile is coming of age

Over the past few years Agile has come of age. This has become highly visible in the way organizations adopt Agile. The software world has been working with Agile since the late eighties, while non-software Agile projects have only been around for four years. Last year has seen a massive increase in full scale Agile enterprise transformations. It has evolved from an ‘IT-only’ party, to a way to tackle complex projects in all sorts of environments, and finally the focus has recently shifted towards full scale ‘enterprise agility’. Not only is the way we adopt Agile changing, the pace at which these changes are happening, is also accelerating.

rise of agileThe rise of Agile

By enterprise agility we refer to the adoption of Agile and its underlying principles and values at all organizational levels. This implies a different way of steering from strategy to operations, and setting up multidisciplinary teams rather than working in isolated pockets. This development involves a fundamental change in the way we lead organizations as well as a cultural shift: it is in fact a paradigm shift.

A set of guiding principles and a corresponding philosophy are an effective way to cooperate in large scale organizations. Such a universally applicable way of thinking, working and organizing is what we call a social technology. Social technologies are a response to the (digital) technological disruptions in our way of working, organizing and even life. Other examples of social technologies include holacracy and sociocracy 3.0.

Taylorism and Agile are cousins

Agile has become nothing short of the most fundamental social technology since Taylorism. Don’t worry, this won’t be an academic treatise on the merits of different management theories. Rather we believe it is important to understand and evaluate where we come from, in order to decide where it is we should be going.

In 1911 Frederick Winslow Taylor introduced his theory of scientific management. He introduced it with the aim of controlling every work activity, from the simplest to the most complicated. Taylor’s argument was that only by doing so, management could have the desired control over productivity and quality by focusing on the most efficient way to do each task.

We can still see the echoes of his theory in many aspects of modern day organizations. One of the most poignant examples is the way how many organizations treat call centres and call centre agents. Rather than focusing on the best outcome for customers (solving their problems), they obsessively measure and focus on things like call-length and number of calls processed per hour (for an example of the right way to do it, consider this). Not only are we sometimes focused on optimizing the wrong things, this has also created a culture in which we have taught employees to no longer think for themselves. Make no mistake, we are not out to bash Taylorism or a drive towards increased efficiency. Quite simply, we believe focussing on effectiveness, rather than efficiency, yields better results and also makes best use of employees and everything they bring to the table. In our opinion, this is the best way to delight customers. Not to mention it makes work considerately more fun.

Focus on effectiveness — rather than efficiency

Four parallels cause us to classify both Taylorism and Agile as social technologies:

  1. Like Taylorism, Agile is based on a set of underlying principles that guide the way we organize and work. The principles offer guidelines for processes, practices, governance and leadership.
  2. Both combine methodology and mindset. Taylor: ‘The really great problem of the change consists in a complete revolution in the mental attitude and the habits of all of those engaged in the management as well as the workmen’. While we don’t subscribe to Taylor’s strict division between workmen and management, experience has shown that social technologies affect all those in the organization. Not only the business but also the leaders and staff departments need a fundamentally different paradigm.
  3. Technological revolutions were the main driver behind the development of both Taylorism and Agile. While Taylorism was the result of industrialization, Agile was devised as a response to the new possibilities offered by the software and internet revolutions.
  4. Finally, both sets of principles are universally applicable. Agile has taken hold from Australia to Brazil and South Africa to Scandinavia.

Mindset beats method every time

The rise of technologies such as personal computers, the internet and smartphones has radically impacted our lives and the way we do business. We are convinced we are at the dawn of a new era of social technology. As we speak we can see a rapid development in fields such as blockchain, AR/VR, IoT (Internet of Things) and Artificial Intelligence, the true impact of these is yet to be fully revealed. As the pace of technological change accelerates we will also see a rapidly accelerating pace in the development of social technologies such as Agile.

The human mind is ill-equipped to deal with exponential growth. For an example of what that truly means consider the infographic below:

Source: https://medium.com/ai-revolution/how-long-until-computers-have-the-same-power-as-the-human-brain-c1e9741c12de

Principles on how to work and organize can only be effective when combined with a corresponding mindset. When using Agile as method rather than a mindset the long term benefits of using Agile dwindle down to zero. How many times have you seen a team become fully energized when starting out with Scrum only to regress into old habits over time. This is a clear symptom of implementing Agile as a system, rather than fully embracing the philosophy , investing in behavioral change and receiving the full long term benefits. Internalizing such a mindset takes time, coaching, and the willingness to open up and expose yourself to feedback. Teams that fail to do so become demotivated and often abandon Agile altogether, claiming ‘Agile does not work for us’.

Putting the social back into social technologies

For too long the focus in Agile has been on the technical aspects. It is time to put the social back into social technology.

Lasting Agile organizational change is commonly frustrated by the lack of a lasting change in behavior and mindset. All too often Agile transformations are initiated by rolling out a standard blueprint for an Agile organization and simply copying a ‘model’ that has been successful elsewhere. During such transformations the focus is on implementing standard ways of working and associated technical platforms. Rather than focusing on the human aspect, the focus is on systems, processes and technologies. An Agile transformation cannot truly succeed without striking a careful equilibrium between frameworks, technology, and the softer human side, including leadership.

In this context do not take softer to mean inexact, fuzzy or unbusinesslike. Rather it means to act upon drivers fundamental to human nature in order to maximize team effectiveness. Robust enterprise agility cannot be achieved without some form of effective Agile scaling. However, the multidisciplinary team, that works in short cycles on customer delight in a highly visual and transparent way remains the core organizational Agile unit. To ignore the human side of Agile is to ignore at least half of what needs to be done to make your change lasting and successful.

Key to successfully dealing with the human side of Agile is understanding that every team and organization has two basic goals. A team seeks to attain a certain result, but also instinctively works to maintain the status quo in team dynamics. A similar thing happens at the organizational level. Change is resisted as a threat to the very survival of the team.

The true power of Agile is in the undercurrent

We find the ‘softer’ side of Agile is often ignored. Many teams and Agile consultants tend to focus on more visible aspects, such as practices and tools. In these situations a major aspect of the way teams works remains undiscussed, but strongly impacts the way the team works and is felt by all. We call this the undercurrent. The undercurrent in your organization is agnostic, meaning it is neither good nor bad. Yes, a negative undercurrent can ruin a team, but a positive undercurrent is just as likely to make your team fly. Friendship for example is an undercurrent that helps the team perform: there’s laughter and affection that makes working together fun.

 

 

A negative undercurrent can always be traced back to four basic interpersonal needs:

  • Inclusion: membership and team boundaries. Do I belong?
  • Influence: Who is in charge? Is my voice heard?
  • Intimacy: Do I dare to be vulnerable in this group?
  • Inspiration: Fulfillment. Does what I do matter?

‘Inspiration’ is key. However much you work on inclusion, influence and intimacy, if a team lacks inspiration, all your other efforts will be futile. All interpersonal needs have many different ways they can manifest themselves. Structurally being late might be a symptom of disengagement, and therefore a lack of inspiration. It is the Agile Coach’s job to investigate and diagnose what is behind such symptoms, and apply the right intervention. Only then can we start to make lasting changes.

Don’t imagine the undercurrent as a problem that can simply be solved. It is a bottomless well that requires constant attention. Problems arising from negative undercurrents might distract you from being aware what is truly going on in the surroundings of the organization. As the tribe struggles internally, it fails to notice the tiger in the bushes. While you are struggling with team issues instead of serving the customers needs, you are losing your competitive position.

The only way to deal with the undercurrent is to bring issues to the surface and discuss them. Agile is uniquely suited to rapidly bringing these tensions to the surface. The Agile creed ‘transparency — inspect — adapt’ engrains a process of continuous discussion about results, team culture and collaboration in an organization. By doing so we turn these tensions into fuel for transformation and lay the foundations for the right culture and mindset in an organization. This mindset is not only key to reaping the full benefits of Agile and becoming a high performance organization, but also readies us for whatever social technology comes next.

Agility enables us to deal with massive change

The biggest challenge the future holds is that we simply have to deal with it. Whatever comes next will require us to have a structure and mindset in place that allows us to deal with massive social and technological change. Agile is the most important social technology of this decade because it is uniquely suited to preparing us for the next (unknown) revolution. Considering the rapid evolution of Agile and disruptive technologies, becoming truly Agile is now more urgent than ever before.

Read the article also on our Medium publication.

  1. Reinvent your role: own, don’t manage

“I am running around the organization to keep my projects on schedule, and people don’t even notice.”

In their drive to help an organization, marketeers and marketing resources are often spread out widely among projects and issues. Marketeers will hold different roles, such as project manager or campaign manager, and have to find their own way of keeping everyone involved and happy. They will convince, lobby and drag people around to get (campaign) results delivered on time.
An agile marketing strategy is something you want to own, not manage. That means that as a marketeer, you can reinvent your role and be responsible for:

  • Developing a creative vision
  • Strategic dialogue with the business
  • Developing insights into customers and their behavior
  • Creating the conditions for project execution

Coworkers need to get used to marketeers not being preoccupied with operational hassle; in the end, it will give these colleagues greater autonomy and enable them to organize their work themselves in line with your marketing strategy.

  1. Define and share success

“All that marketing stuff… How do we even know that it works?”

Often marketing is seen as a cost center, and CMOs are busy accounting or trying to account for their expenses. They do show results, but these can very well be circumstantial, dependent on others in the organization or simply unexpected in light of the strategy that was laid out in the first place. An agile marketing strategy is both flexible and well-defined, enabling marketeers to show results in short cycles and keep the strategic dialogue going.
A practical way to set and adjust goals in a marketing strategy is the Definition of Success. It was coined by the agile marketeers at Boardview, and basically helps you to define a marketing goal in one sentence. All goals are then linked to each other and prioritized. Moreover, you co-create and share these goals with stakeholders and redefine goals at set intervals. As you go along, you add the intermediary results to these goals and become accountable in real time.
Definition-of-Success-DoS-Boardview-Brand-Health

  1. Sprint and learn

“Why do I find myself stuck in this campaign, after all that happened this week?”

The reasons to change your strategy and execution can be diverse: from a sudden PR disaster to shifts in customer behavior and new possibilities for marketing automation. However, when you are all-in on a number of projects that are hard to rein in, you will miss a chance to change. Instead, you want to be able to iterate and learn.
This is why sprints are a central concept in organizing agile: they provide a set cadence for learning. A sprint helps you to see the bigger strategy through the lens of the last week or two. So no matter how ambitious a certain goal is, you will have to evaluate it after every sprint and be able to change course.
Also, sprints force you to slice projects into smaller chunks and thus reduce risks. In that way you will end up with what the Agile Marketing Manifesto calls ‘many small experiments over a few large bets:’ http://agilemarketingmanifesto.org/.

From principles to change
Now these principles are far reaching and necessitate organizational change. For an agile marketing strategy needs an agile organization. There are plenty of opportunities to get started, though. The next time your marketing colleagues draft a plan, you can help them with the Definition of Success. When a new big campaign is orchestrated you can suggest to carve it up. And when you are being dragged into a project manager role, keep distance.
Want to continue this discussion on Agile Marketing? Feel free to contact me at gidion.peters@organizeagile.com

We are looking for a different type of banker. A banker that embraces and accelerates change, is frantically focused on the customer and is a techie at heart. A banker who sees herself as an engineer of customer experience rather than a guardian of corporate stability. In this pamphlet for the agile banker, I discuss the characteristics of the central figure of a renewed and agile banking organization. Some of these bankers are already walking around in big financial institutions, but they may not always be heard or acknowledged.

After the financial crisis hit, many of the bankers I know kept their profiles low. Their trade was under scrutiny, many of their colleagues were losing their jobs and the prospects were all but rosy. Over the past year, the banking sector has experienced a modest resurgence. In the US, 2016 was a good year for big banking stocks and that trend continues. It can’t be a reason for bankers to return to pre-crisis attitudes though. There are new challenges and opportunities on the horizon. Think of the accelerating change of customer behavior, online-only banks, peer-to-peer lending and blockchain technology. Banks will need a specific type of people to handle these challenges.
What describes these agile bankers best, compared to traditional bankers?

 

Agile Banker Traditional Banker
What is a bank? Tech company that is in financial services Financial company that uses IT
Organizational preference – How do I grow? By applying my knowledge and creativity in new ways By climbing the corporate ladder
Preferred work setting – Who do I want to work with? Members of my multidisciplinary team Colleagues in my department
Pride and identification – What is the source of my company pride? The prestige of my organization The coolness of my organization

 

The foundation of the agile banker’s character is the way she looks at the industry. She recognizes that technology is at core to delight her customers using their financial services. Lending or saving money or making an investment is about providing customers with the technology they need to do so with a maximum of ease and reliability. And an agile banker supports that technological core with all the financial product knowledge and human-to-human support that is necessary.

  1. How does an agile banker grow? Taking down the corporate ladder

Most bankers find themselves somewhere on a ladder: there are people ‘lower’ and people ‘higher up.’ Climbing the ladder can be very tiring and it is an inefficient form of growth that does not always benefit the organization at large. A hierarchy of people is not the same as a hierarchy of good ideas, and the irony is that in strongly hierarchical organizations, you need those ‘higher up’ to make ideas actually come to fruition. In banking, the ladder has guaranteed a certain measure of stability and control, but it has made innovation strenuous at times because of all the approvals needed to get something done. An agile banker is not patient enough to wait for the next slot above to open up, and instead wants to put her creativity and knowledge to the task right away. This asks for new organizational models, in which decision-making is decentralized and sped up.

 

Holacracy flat agile bank organization

Example of a flat organizational structure called Holacracy

  1. Who does an agile banker want to work with? The rise of the multidisciplinary team

There is little more dispiriting than lobbying for a project for months, then getting it approved and working on it for months, only to find it cut short by other managers before it is completed. Much of this has to do with the competition of departments for power and resources. An agile banker doesn’t want to wait for other departments, but instead wants to feel as if she is working for a startup. That means: identifying customer needs and building and iterating solutions rapidly with a small team. A bank has an amazing pool of data that enables such teams to target micro-segments of the market, create offerings and test out new distribution models. It could mean launching robo-advisors, pop-up banks, self-service kiosks or predictive mortgages faster than any department could. A bank needs to create and enable these teams to make the agile banker feel at home. It is one of the reasons why ING Bank chose to reorganize their headquarters staff into multidisciplinary ‘squads’ of 9 people comprised of specialists ranging from marketing to product and user-experience.

  1. How to make an agile banker proud of her company? Fostering a cool employer brand

Customers rely on their identification with a brand when they make decisions. And increasingly, the same goes for those looking for or switching jobs. Employees still find compensation important, but also want to associate themselves with an organization’s purpose, behavior and image. It goes much further than the glamour and prestige an organization shows on the outside; it is about how people actually work on the inside. It is why Zappos lets you meet their great people and work environment on Twitter at @InsideZappos. In banking, the agile banker can show in 3D video to her friends the cool and innovative office she works in.

 

Agile Headquarters ING Bank

ING Bank’s new agile office

 

Banks are consistently overrun by other companies, mostly tech, when it comes to reputation. In the Glassdoor Best Places to work 2017 top 50, there are zero banks. The agile banker wants to show more than a paycheck and an established name on her business card; instead, she wants to share the great atmosphere and cool work filling up her days.

Agile bankers are not born overnight

The agile banker is not just a concept: it is a type of professional that is among us and is strongly needed. To attract them, banks will compete with a host of other technology companies, including Fintech. A good number of agile bankers, however, will be loyal to banks when the conditions are right. It means moving forward toward an agile organization that empowers multidisciplinary teams all across the business to delight customers continuously. Many banks already started their agile journey years ago in the IT department (see JP Morgan). But that is not enough for an agile banker: she is not a fan of departments; she is a fan of achieving results with small and fast teams. All this necessitates structural change within current banking organizations and the courage of their leaders to realize it.

What if a 5 year old sends you a letter, saying your product line is lacking? And asks you to better cater to her wishes? It happened to Gap recently, when a girl complained that the girls section is full of “pink and princesses,” while she prefered “Superman, Batman, rock-and-roll and sports.” She advised Gap to start making cool girls’ shirts, or just do away with separate boys and girls sections.
What if a middle aged driver sends you a tweet, complaining that your charging service is being misused? It happened at Tesla, when Loic Le Meur saw his Supercharger spot was taken by, in his words, “idiots” (e.g. people that shop at the nearby Whole Foods) that used it for parking, not charging.

There are basically two ways to respond to requests like these. And as an Agile company, I would choose both.
Now before we dive into these two options, let’s never forget the importance of listening. Now specific feedback will tell you that you need to change and progress as a company, and this is how:

Option 1: Drive change through the CEO

For some customers, the CEO is a very prominent representation of the organization. New school CEOs have added to this luster, by being vocal, public figures with a personal following. In the case of Gap and Tesla, their CEOs effectively marketed the organizational change that was needed. They became CEO-Change Marketeers (CEO-CM), doing two things at the same time: driving change as championed by the customer, and marketing their organization’s responsiveness and adaptability. Speed is essential: Elon Musk reacted on Twitter within 20 minutes and changed the product in 6 days, Gap’s CEO responded in 2 weeks and a new Chewbacca shirt is coming out this month.

Option 2: Drive the change through the organization

Obviously, tweets to the CEO are only one of the many touchpoints an organization has with customers. There are in fact thousands of opportunities for an organization to listen, learn and adapt every day. Again, it starts with listening. That is why at ING Bank for example, new employees spend the first week at their new job at customer support.
If you give your teams enough autonomy, they will feel they have the authority to act. They can be their own chief executive when they listen to customers, and can align their response with company strategy. This also is an opportunity for marketing and branding your organization’s responsiveness, but on a much more direct level. With the right measure of freedom, Agile teams create change even faster than CEOs, and do it simultaneously on a very large scale.

The Agile organization is the best of both worlds

An Agile organization embraces customers and listens to them attentively. It may even be helped by the CEO to communicate to a broad audience. But the Agile organization’s sustainable change capacity comes from its teams. They are at the forefront of the organization, and should be at the forefront of change. So that when a busload of 5-year old girls and middle aged men knock on your door, you are ready for them.

Agile Portfolio

The core of SNAP is the Agile Portfolio. The Agile Portfolio focuses on flexible cooperation within the scope of the program. It helps teams by creating connection, insight and focus. Agile portfolios can be implemented on all organizational levels. This means that one Agile Portfolio could be completely found within the focus area of another Agile Portfolio, since, ultimately, the goals of a team are tied to the higher goals of (part of) the organization. This opens up the opportunity to connect all different agile teams working in the Agile Portfolio; this is the beginning of a scaled agile organization.
In a SNAP organization, teams can choose different methods, such as Scrum for projects, or lean appointed processes for continuous work. As long as they work together towards their ambitions on the Agile Portfolio level. The decisions following these ambitions are not made within a hierarchical management structure, but rather by the concerned team members and product owners from different teams.

Permanent reorganization

With SNAP your organization could constantly be rearranged. When it turns out that different teams work on the same priorities or projects, they can either cooperate, or come to the conclusion that reason for existence has shifted. Then, purposes and ambitions need to be rearranged among the teams.

Agile organization wide

Just rearranging your organization is not enough. Using SNAP, your organization also needs to (further) develop leadership, (re) define customer value and adopt agile methods. More to follow on that subject!

At the end of this article you find some reflecting questions. Want to get started to become a (better) Scrum Master or Product Owner? Have a look at our training and workshop overview or contact us for coaching-on-the-job.

1. Getting too involved

A Scrum Master finding the project too interesting has the tendency to join in, to make suggestions, to start focusing more on the project than on the process. This makes you less objective, especially when you think your suggestions are the best.
Tip: as a co-worker there might be a chance to share your ideas with one of the team members on a different moment. Or, for the next time, you can pick a Scrum project that is less interesting to you. Before each and every Scrum session consciously remind yourself to not have an opinion about the content. Ask a Scrum coach to join you during one of the session and ask for feedback (positive and negative) and use these to focus on developing your skills.

2. The urge to fully understand the content

A Scrum Master who wants to fully understand the project’s content will ask clarifying questions that are only useful to him/her. These questions will take the speed and focus off the sprint sessions, this is a waste of everyone’s time. A Scrum Master does not need to fully understand the content of the project. Understanding parts of the content only is enough, giving you the ability to ask good questions, separate content from the process, summarize, start ceremonies and make the agenda for the review. We go as far as stating  that it is better to not fully understand the content in order to stay objective in the process.

Tip: Assure yourself that once the process has made progress you are going to understand more about the content, enough to make better summaries and ask better questions. If it helps you in your role, ask for clarification after the session. Trust your team members and Product Owner to have the capability to divide the work load, define the backlog items including correct definitions of done, then you can focus on guiding the process at best. Moreover, in the intake that you have with the Product Owner at the start of the project you define a clear assignment; this is also the right moment to position the content correctly for you as Scrum Master.

3. Taking over the role of Product Owner

A Scrum Master taking over the role of Product Owner, will, for example, arrange that team members get dedicated time for the project. Or the Scrum Master states in a session what he/she thinks is the most important work load for the upcoming sprint. These are the Product Owner’s responsibilities, not the Scrum Master!
Tip: Make sure you know what both roles entail. It can also be helpful to talk to the Product Owner and set a clear set of rules about the respective roles and responsibilities. You could also ask a Scrum coach to join you for a session and give you feedback afterwards. And, who knows, maybe you are also a good Product Owner, a role you might take on for the next project.

4. Feeling responsible for the result

A Scrum Master who feels responsible for the result will consciously or unconsciously steer which backlog items will be handled in the next sprint, influence the definition of done, express that the team is not working fast enough, etcetera.
Tip: Reflect with a Scrum coach on this subject. Why do you feel so involved with the result? Think of what you can do in your role as Scrum Master to help the team get the best result. Might an extra retrospective help to continue on learning together? Can you help the team, for example, to spend less time on making plannings, but to define more intermediate and ‘minimal viable products’? Can you suggest to the Product Owner which stakeholders he/she should invite next time to get better targeted feedback to the team?

5. Being too nice

A Scrum Master who wants be liked is less likely to interrupt or steer the team on the process. For example, not interrupting content discussions in the stand-up, and not addressing the Product Owner that he/she is not inviting stakeholders.
Tip: You can be nice in your own time. Experience shows us that the team is mostly not or barely affected by a ‘strict’ (clear) Scrum Master than the Scrum Master him/herself is. The team benefits from effective ceremonies, ultimately the team members want to start off the sprint in the right direction, as soon as possible. Here it might also help to ask for feedback or get coaching on the job. And add, for a change, the subject ‘Scrum Master’ to the agenda of the retrospective.

6. Getting lured into ‘a little bit of scrumming’

Of course ‘a little bit of Scrumming’ does not exist. Before you realize it, your schedule will be filled with all sorts of projects of which you are the Scrum Master, but you also have other responsibilities and tasks. And then there also is the encounter with a Product Owner who underestimates your role as Scrum Master.
Tip: make clear agreements with your supervisor about the amount of time you can spend. Take care of yourself. Highlight the benefits of Scrum; if you can show progress, then receiving more time for a project will be easier. A good intake with your Product Owner is crucial. What does the project entail? What is the lead time and the sprint frequency? And how much time do you need as a Scrum Master?
Now I ask you the question: which of the above described situations do you recognize? What could you possibly do to recognize, avoid or terminate those pitfalls?

To wrap up: learning is a must as well as experimenting, and making mistakes is human. Enjoy!