Agile Forest

7 habits of highly effective Agile Executive Sponsors

Renee Troughton

January 22, 2018

Effective Executive Sponsors for Agile are a rare breed.

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

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

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

But what does a good Agile Executive Sponsor do?

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

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

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

Practice what you preach

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

Behaviours

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

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

Activities (aligned to strategy of transformation)

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

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

Set and grow a clear vision

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

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

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

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

Make the hard calls

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

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

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

Create slack for reflection, learning and improvement

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

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

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

Stop starting (or restarting) and start finishing

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

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

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

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

Go to the place of value (gemba)

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

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

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

Remove impediments

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

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

Conclusion

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

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

A note on enterprise transformations

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

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

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

Scaling Agile Tricks Series: Economically efficient teaming

Renee Troughton

no comments

June 5, 2017

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

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

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

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

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

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

Feature Teams
Component Teams
Architectural Layer Teams
Customer Journey Teams

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

Feature Teams

What is it?

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

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

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

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

Pros:

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

Cons:

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

Component Teams

What is it?

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

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

Pros:

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

Cons:

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

Architectural Layer Teams

What is it?

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

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

Most waterfall teams are setup as architectural layer teams.

Pros:

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

Cons:

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

Customer Journey Teams

What is it?

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

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

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

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

Pros:

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

Cons:

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

Summary

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

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

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

Scaling Agile Tricks Series: Pipeline Management

Renee Troughton

2 comments

May 18, 2017

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

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

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

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

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

Dual Track with separate ownership
Dual Track with team ownership
Just in time team flow pull

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

To Dual Track or Not, that is the question

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

Image result for dual track scrum

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

Image result for dual track scrum

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

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

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

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

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

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

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

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

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

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

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

Just in time team flow pull

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

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

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

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

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

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

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

Scaling Agile Tricks Series: Mitosis

Renee Troughton

3 comments

May 11, 2017

Welcome to the second post in the Scaling Agile Tricks Series.

In the first blog I talked about my favorite scaling pattern – the Leadership Cell. In the second blog post I have a really simple pattern called Mitosis.

Image result for mitosis definition

Mitosis is a very easy solution to a common problem – how do you scale the number of teams? This is a common question for organisations undergoing a significant expansion and commonly occurs in the digital and lean start-up space.

The challenge is, there are very strong beliefs held by the agile community and coaches that teams should remain stable, that is, adding or removing team members is often frowned upon as each time it occurs the team has to begin again traversing through Tuckman’s stages of group development.

One recommendation I have is to grow and divide teams in a similar way that cells divide through Mitosis. Whilst great Agile teams are most effective when sized at seven plus or minus two, to use this pattern effectively you will unfortunately need to grow the team slightly above what is an acceptable norm. Ten to fourteen would be in the ballpark of the maximum size. Once the maximum size is reached you split the team into two. If you need more teams you rinse and repeat, incrementally adding great quality people as you find them until the threshold is reached.

The pro’s of such an approach:

Cultural norms are persisted. The alternative approach of just adding or building a whole new team means that they become culturally ignorant of ‘the way we do things around here’.
Standards and expectations are more effectively understood through team stories instead of reading documents and finding out the documentation is wrong.
People who get on well together can be kept together as the team splits. Conversely tense relationships can be split.

The con’s of such an approach:

Teams are constantly going through Tuckmans stages which is a huge dent on productivity. You will have a productivity issue even if you create a new team from scratch but this will significantly extend that affect.
Whilst teams are expanding beyond ten people the communication costs increase.

Is this a suitable approach for you? Well that depends on whether you are trying to optimise on productivity or optimise on culture and consistency.

Scaling Agile Tricks Series: The Leadership Cell

Renee Troughton

3 comments

May 7, 2017

With so many frameworks out there that tell you how to scale Agile (LeSS, DAD, Nexus, Enterprise Scrum, SAFe, etc) I have for a long time held off adding fuel to the fire by having a blog series dedicated to Scaling Agile. Why? Well because, just like in the early days of foundational Agile (Scrum, FDD, XP, DSDM), it took time for patterns to emerge of what works and what doesn’t.

In this series I plan to not re-iterate the scaling frameworks, but instead highlight the tips and tricks of patterns that aren’t in those frameworks that I have experienced actually works. These are tricks that have worked not once, but multiple times. These are also tricks that I have validated with other organisations, the sorts of things that people have struggled with when implementing agile at scale but amazingly have come up with similar ideas on how to tackle the problem. It is probably worthwhile to note that the sort of work I do is in really big corporations with heavily bureaucratic environments. These patterns have all been discovered and validated at this level for organisations a few years into their Agile journey.

So what is the first pattern? Well, I will start with my biggest one and probably conceptually a complicated one. It starts pretty simple – when you do Agile at scale, yes you have multiple teams, but what supporting mechanisms to you need around the teams? Whilst a few frameworks prescribe the roles needed to support teams I find that they are somewhat lacking. The term I use is a “Leadership Cell”, not because I see this group of people lording over the teams, but because they are likely to be each leading a backlog.

The Leadership Cell are backlog and decision authority functions of six key areas: Customer Experience, Product Ownership, Adoption, Technology, Delivery and Coach.

These areas each own their own backlog. The Customer Experience area, is focused on customer facing (internal or external) experience, needs, problems, consistency, journey and simplicity. The Product Ownership area is focused on the business needs, problems and worthiness of potential business solutions. The Adoption area is focused on ensuring benefits get realised, change is effectively managed and adoption (internal or external) is successful. In a number of organisations the Product Ownership and Adoption areas are owned by the same person. In smaller scaled environments all three roles may be owned by the one person.

The Technology area is focused on technical problems, needs, solutions. Concerns like increasing technical debt, keeping on top of patch upgrades, sustainability of long term operability of the codebase, etc are great examples of backlog categories of work they may have. Enablers could also be considered technology backlog items, but I prefer enablers to be driven from business need and should be part of Product Ownership.

The Delivery area is potentially more amorphous. In larger enterprises there is a considerable amount of work related to governance, policy and procedures. The Delivery area is focused on getting through these activities. In a great Agile enterprise these activities should be small in number and automated as much as possible, but as most organisations are on a journey this area needs to be the conduit between the old and new worlds, until at least, the enterprise has undergone governance simplification. In addition the Delivery area should be focused on sustainability of pace – are team empowered to pull, is the pipeline realistic given the number of teams, is quality being traded off, is flow consistent? Importantly, the Delivery area is the glue that helps to bind the other areas together if they are not – they are the champion of collaboration across all of the areas and are asking the important questions when a trade-off needs to occur between the areas. They will manage escalations up and shelter the teams, just like a Scrum of Scrums Master.

These areas do not have to be filled by six different people, individuals may fulfill one of more of the key areas – but be wary as it will be challenge to balance decision making.

Note that the Coach role is a little less formal, they may hold continuous improvement and capability (I’m talking about people capability and not product capability here) improvement backlog items, but it is better practice for capability and continuous improvement backlog items to be collectively owned long term by the Leadership Cell itself. In the early days of a transformation it may be useful for someone to be the voice of improvement and hence you could say that rather than “Coach” have the area as “Continuous improvement”, but I believe that continuous improvement should be embedded throughout the other areas, like Customer Experience and Technology and thus wouldn’t separate it out. The argument is then about continuous improvement that impacts across these functions, which might, over time, be enough of an excuse to change the name of the area but I would rather have clarity around the originating tension – ie where the pain is being felt that is driving the continuous improvement and use that area to drive the change. Additionally, the Coach role isn’t a role that I see existing longer term in the leadership cell, it is there to bootstrap the change, but shouldn’t be there indefinitely unlike the other areas.

The more complicated aspect of the Leadership Cell is how these areas interact. Certainly the Leadership Cell should be part of the Scrum of Scrums along with the Scrum Masters. One or more people in the Leadership Cell may also represent impediments as they get raised up above the Scrum of Scrums.

At a more strategic perspective the Leadership Cell starts to veer away from some of the scaling framework guidance. At a regular interval the Leadership Cell should have a prioritisation meeting to balance strategic direction and create a unified backlog for the teams. The frequency of this will depend on the frequency of pull from teams. I generally find that either every four or six weeks with a consolidated backlog of ten items is enough. This meeting is held like a multi Product Owner prioritisation meeting with each person bringing their top five items. As a collective they agree to which items should be pulled next. Like multi Product Owner prioritisation meetings, it does tend to take a few goes at this meeting before it becomes more fair and normalised.

The trade-off discussions can be quite heated, but it should be like a see-saw – sometimes it will be weighted to one perspective and then next time another area may be more heavily weighted. Normally, at scale the Product Owner tends to dominate the work. Using this approach more continuous improvement and operational stability tends to be added as a priority of focus. This is not to say that it will be realistic to have 50% Product Owner work and 50% other focus areas, but more like 80% Product Owner and 20% other focus areas (which would be an improvement from the 95% Product Owner weighting).

The Leadership Cell is also accountable for a lightweight process for agreeing to how to prioritise. I personally like the DVF approach over WSJF, but each has its merits.

The DVF approach focuses on Desirability, Viability and Feasibility. It can be mathematically weighted and divided by time just like WSJF. The Leadership Cell balances the DVF where the Customer Experience area focuses on desirability, Product Ownership and Adoption focuses on Viability, and Delivery and Technology look at Feasibility. This is not to say that each Leadership Cell function cannot participate and consider all of the DVF elements as they assess and prioritise the work.

I like DVF because it isn’t just a prioritisation process but is importantly a set of considerations to test the work against. I’ll give a few examples of considerations for each.

Desirability consideration examples – Identify the alignment and contribution to the customer end to end journey; quantify the staff problem or opportunity.

Viability consideration examples – Business ability to absorb the change among other initiatives being rolled out and operating workload; identify and quantify the risk reduction and compliance obligations.

Feasibility consideration examples – Quantify business continuity and information risks; identify alignment and contribution to target architecture.

Along with attending the Scrum of Scrums and managing the pipeline for teams to pull from the Leadership Cell should also be part of a regular cross team retrospection. In essence, they act as if they are in a Sprint themselves but the likely timebox is going to be larger than that of the teams. To be clear, this timebox isn’t necessarily a Product or Program Increment, it should be decoupled from the release of a product (we will get into dependency management and PIs in a future blog).

So in summary, the sort of problems that having a Leadership Cell helps to solves includes:

Having a mechanism to give equal authority of needs so that the team of teams backlog isn’t driven just by business need.
No one person in the Leadership with higher power or authority over another, it is a peer structure where the coach is also considered a peer.
Ownership point for work coming into the team of teams
Considerations that should be applied to work as it comes into teams (DVF like elements).

Stay tuned for my next blog post on the Scaling Agile Tricks Series – Scaling number of teams.

The success of an Agile Transformation depends on…

Renee Troughton

2 comments

April 14, 2017

Is Agile dependent on culture or leadership support for success?

I recently read Silence by Shusaku Endo. It is a book about the early missionaries to Japan in a turbulent time when they were not wanted (to an extent that they were actively sought out and tortured).

As I read the book I was reminded of the analogies that Agile often has from its critics that it is a cult or similar to a religion, and as I read the book I changed the language and words in my head to see to what extent it fit against the criticism.

One page in particular stood out for both its beauty and applicability. I would like to share it with you with the words changed to Agile to see your thoughts on it. Think of it with a lens on the success or failure of transformations:

(Page 117)

“A tree which flourishes in one kind of soil may wither if the soil is changed. As for the tree to Agile, in a another company its leaves may grow thick and the buds may be rich, while in this company the leaves wither and no bud appears. Coach, have you never thought of the difference in the soil, the difference in the water?”

“The leaves should not wither; the buds should appear,” said the coach raising their voice. “Do you think I know nothing? People are familiar with the work of the Agile community; and it is well known that when many projects gave permission for evangelization the number of Agilists reached three hundred thousand.”

The old man constantly kept nodding, all the time rubbing his hands together. Whilst the other managers with tense expression were listening to the words, only the old man seemed completely on the side of the coach.

“If the leaves do not grow and the flowers do not blossom, that is only when no fertilizer is applied,” the Coach said.

The analogy here that management support is the fertilizer, that culture is not the differentiator to success or not.

Do you feel that the tree would flourish regardless of the soil and water?

Grind the tension: Holacracy Practitioner Training

Renee Troughton

no comments

March 9, 2017

This is an interim blog post defining my thoughts whilst attending the five day Holacracy Practitioner Training in Philadelphia. I will probably repost my final thoughts or add some comments when I return back to Australia.

So why do Holacracy Practitioner Training in the first place? It certainly wasn’t because I had client that had an appetite. It was because I wanted more depth on the logistics of how it worked after reading the book a few years ago and after hearing a few people from zappos and other institutions talk about their implementations. I wanted to hear the tips and tricks from the expert and creator, Brian Robertson. I also wanted to do it because I felt that it would be the logical next step for organisations after or mid Agile transformation, especially those that had tried self selection, so I wanted to prepare myself for the future.

What I got was all my desires and more. For the logistics of how it works, the five day practitioner course really is practice focused, with a complex simulation that enables multiple opportunities for everyone to fulfill the facilitator and secretary roles in a very safe to fail environment. As for hearing about zappos and other institutions, well I haven’t heard much about Zappos yet, but I have heard from a lot of people on the course about how it is going in their organisations. The number of attendees already doing Holacracy somewhat surprised me and some of them already had a few months experience up as facilitators (and it showed). I have found that I have gotten as much value out of the people attending the course as those running it. I have enjoyed watching some of these people who have had honest concerns that they are still on the fence about the value of Holacracy change over the course of a few days – often because they didn’t understand the purpose of a particular activity, but more commonly because it was being implemented incorrectly (because this never also happens in Agile transformations right?).

As for Holacracy being the next logical step past Agile, well I am really not sure about that now and probably need more processing time on that one. It certainly isn’t a pre-requisite (though I never thought it was), but I don’t think people early in the Agile journey have to rule it out either (where I once thought maybe mindsets may not have been progressed enough for this leap).

So for some more detailed thoughts on the course, in a somewhat time based progression format feel free to read on:

Day 1

Introduction of theory was expected but felt long taking up most of the first morning.
Brian really is as engaging in person over a long duration as he is talking in videos. His energy is quite infectious.
Afternoon session – simulation. Now I build games for my training so I know the value of a good simulation and this simulation is the second most complicated one I have ever experienced (Lean car factory being the most complicated one I have). As we went through the simulation I guess I had the unique perspective of not just doing the activity but also analyzing at the same time the simulation itself for the outcomes expected, the constraints and the rules. Now when I build games I build them so they fail first, which this does. But I don’t build them with so much failure that the goal is 100% unachievable – that is, if you are a master, you might still succeed. The Hygean game – well it was built with a 100% failure rate. I could tell very early on what the constraints were, I also had a good background in the simulated value chain so I knew that well. From minute zero of the game I began working to the roadblock of the delays in the value chain. But when the constraint never responded in the first round at all it meant that value was never a possibility. Now I realised in the evening of Day 1 that I had made two incorrect assumptions about the simulation – that value was important (ie the business not running out of money). Lean thinkers will see very quickly that the business is about to run out of money, but it is a bit of a red herring, in some ways the simulation doesn’t reflect reality because people would care a lot about this information. The second assumption was that it mattered to win (ie successfully deliver value). It doesn’t, the point of simulation is to arm yourself with enough ammunition to run through the governance and tactical meetings, nothing more.
Checkins. They feel really clunky. I’ve never been a huge fan of them because I have seen them abused in the past but they did feel authentic in the meetings we had.
Building agenda items – the usage of only one or two words for an agenda frustrated me. I can see the similarities of the activity to lean coffee, but unlike lean coffee, where you spend fifteen to thirty seconds talking about your agenda item, in holacracy there is zero time spent on what the agenda item means. The consequence is that no one actually understands the agenda. This felt incredibly uncomfortable, mainly because I wasn’t quite sure if someone else’s agenda item was similar to my own as the two words were the same and so I didn’t know whether I should raise my agenda item. What I subsequently resolved that evening was that it didn’t matter. It was my responsibility to put my agenda item up regardless. The agenda item is only a refresher for the single individual that created it and nothing more.
Reaction round – the process in a lot of respects feels like the Cynefin Ritual Dissent activity – in that it creates space for a proposer talk without interruption, that respondees can ask questions, respond emotionally without interruption (with a small element on Non Violent Communication) and with dissent. After that it is more like a facilitated processing activity with similar restrictions on who can talk when. In the scenarios that we went through I found this activity at first incredibly frustrating, not because of the process, but because it felt that there were gaps in the structure of the process. As an example, in our simulation with the financials running out a proposal was put forward to make the financial runway visible to the organisation so that we didn’t go out of business. The proposal was opposed because of a concern that people would leave the organisation if they thought it was about to be bankrupt. This was based upon an assumption that was perceived, but was not rooted in metrics and because the objector felt that the information wasn’t safe to test, it was considered a valid objection. My main concern with this outcome was that the assumption was statistically invalid, just that the objector was not aware of it, but importantly that I had no ability to even say this, that the falsehood of information was allowed to continue unabated. Now in fairness, I now know that if we had time it would have gone to integration and that hopefully that information would have come out then, but it felt like time was being wasted.

Day 2

The feeling of a lot of time wasting in these governance meetings continued as I pondered time and again where lean elements of root cause analysis and value stream analysis fit in. People changing roles and accountabilities without any understanding of the value chain seemed inane. But what I realised by the evening of Day 2 was that it didn’t matter – because the value chain would be discovered over time through continual incremental refinement. In essence, getting roles, accountabilities and the value chain right occurs over time (and isn’t ever right). It is like Agile, the software will never be right by the first sprint, but through continual build, reflect and adaption it will get good enough in the end.
Proposal tension analysis takes a lot of time when the change is a large merge/refactor. It felt slow waiting for everything to be typed in, but then I found out afterwards that you can propose items in advance and write up all the proposed changes beforehand. This made me feel comfortable that corporates would balk less at the time waste if they knew information could be processed asynchronously (which was demonstrated to me afterwards by someone doing holacracy already).
It really hit home to me by the end of this day that tensions are best when they are micro and are frequently worked on. Weekly governance over monthly would be the best way to start, much like short Sprints allow more frequent adaptation. My favorite quote of the day – “Design the org, just in time, for what you need not what you might need.”
Not a huge fan of the ’cause harm’ language, prefer the longer language of ‘can impact delivery of the circle’s purpose’.
The term ‘project’ also feels like the wrong language to use. Many corporates have a deep tie to this word and I feel it would be better changed.
A comment was made (either this day or day 1) that an example of an outcome for a project would be ‘Product page redesigned’ – I would argue that that is not an outcome, an outcome would be the why – ie “Provide a more user friendly experience to increase customer clickthroughs”
How to prioritise tensions – strength of tension, first in first out, shared tension or time criticality. The answer is it depends on your needs and almost all options can be used at the discretion of the facilitator.
Can the facilitator and secretary be the same person? Yes, but it is not generally recommended. I can see through the simulation why for beginning teams this is not recommended.
How do you balance workload if you are working in multiple roles? The answer is holacracy doesn’t specify a solution for this.

Day 3

Root cause analysis can happen, but only if the proposer asks for help/it. So if, as a respondee, I am needing root cause analysis to get onboard with the change then it isn’t the proposers problem, it is mine. Consequently the proposers change should go through without objection and if I care about root cause analysis then I need to raise the tension (proposal). Processing tensions is all about processing the tension for the proposer, not for opinionated people.
Back to the earlier quote – ‘what might happen’ objections which are invalidated result in only a 10% new proposal rate. This isn’t due to people feeling petulant that their objection was invalidated, but that when it comes down to it, the concerns aren’t really that big of a deal, we are just so used to providing opinions that we can’t help ourselves.
Feeling very comfortable with the process and its micro adaptation of the organisation.

Day 4

If you are the sort of person (like me) that likes to help someone refine their need (ie paraphrase) then you would feel frustrated with the experience of the governance meeting as you cannot help the person get there. You have to be more patient and accept it will take more time.
Tactical meetings – not a lot of new content or concepts in here for Agile folk.
Use lead in narratives about the current step so that people understand what they are allowed to do (or not). If people get off track (out of process) guide via “We have space for that comment in the next step,” and then return to the current step.
“It is not a valid objection, but it sounds like you have an item that you may want to add to the agenda.”
Today reminded me a lot of Kanban’s rules – start with what you do now, know your constraints, your policies, respect.
Tactical tipsheet – if the action is volunteered by a person and there is no role accountable then the action is classified as “individual action”
Domain – full ownership for that thing, it no other roles can meddle with it without the express authorization of the domain role owner.

Governance Tipsheet

Present Proposal – proposer can ask for help or root cause, but normally will just be proposer.

Clarifying Questions – NOT a round robin, only people who have questions. Can have multiple questions. Ensure questions aren’t leading or an alternative solution is being presented. Stop people quickly if the question doesn’t start with a “what, how, why, when, or who…” Does not include proposer. Facilitator can ask questions.

Reaction Round – Does not include proposer (even responding). One by one go around, including facilitator.

Amend & clarify – Proposer only. They can choose to change things based on the reactions and clarifying questions. They can also choose to not change.

Objection round – Have proposer last, includes facilitator. Ask “Do you see any reason why adopting this proposal causes harm or moves us backward. As a facilitator you can jump around the objection questions if you feel there is a hint in what is said as to which objection it may fail on. The goal is to facilitate the process, not have emotions. Ask both sides of the question sheet. Anyone can ask in the integration round for an objection to be re-tested if they felt it wasn’t done.

Integration round – In integration, anyone can contribute as long as the facilitator has no objections and as long as the proposer and objector have opened it up. Ask the objector if they have an alternative proposal that will meet the need of the tension. Once done, confirm with objector if this meets their needs. If both are happy then it is integrated, otherwise it goes back for resolution. Another round of objections occurs after accepted integration.

Day 5

Just because you have a need from someone doesn’t mean you can’t talk to someone and ask them to do it. Use the governance process for tensions were expectations are NOT being met…. otherwise you will have dozens of accountabilities.
We seem to try to get agreement on the tension before we process it (consensus build). Holacracy accepts the tension regardless in order to process it. In this respect, you transition the time in an organisation spent consensus building outside of meetings to tension processing in governance. The time is likely to be less in the later.
Can use ‘curator’ rather than ‘secretary’
For Agile areas – keep your retros, have them feed straight into governance. Sprint Planning is often combined with tactical meetings, especially if the circle is the Scrum Team. If the circle has a few extra people outside of the Scrum Team then you may want to split the two.
Have governance straight after a tactical meeting as tactical meetings are likely to drive desire for change.
Address what happens with compensation early in the selling of holacracy discussions.
Existing policies get moved across into the appropriate circle.
Use the habit support program in Glassfrog
Don’t over do the setup at the start. Don’t be tempted to fix tensions as you breakdown job titles into roles.
Don’t give roles very status titles
Don’t try both (ie management and holacracy) at the same time
Developer role with a focus on product X is better when multiple products need to be supported in an area.
Have a role for guild lead, otherwise don’t have circles for tribes.
Be clear on how meetings relate to holacracy – stop doing or cut out the parts that are covered by tactical and governance meetings.
And for meetings that you keep, be clear on holacracy links – ie what roles are invited, tracking, actions, projects, tensions etc.

Outstanding questions:

How is this going in Zappos?
Why aren’t there any values/principles in holacracy?
How does the constitution change over time?

Trudging through the misinformation: Another Agile vs Waterfall debate

Renee Troughton

2 comments

January 31, 2016

There is a world of misinformation out there about Agile. Even I have probably created some misinformation once or twice (not deliberately).

There is probably too much wrong to fix, but I saw a tweet recently that I wanted to tackle. It was originally linking to the Segue Technologies blog:

http://www.seguetech.com/blog/2015/11/03/waterfall-vs-agile-infographic

Naturally some people in the Agile community responded and it is fair to say their response was one of confusion and disbelief. Many thought it was a joke, but I suspected that the creators of the information felt it was a reflection of what they believed to be true and not intended as a joke. I tried to seek clarification to which I got a response:

We develop for a wide range of customers. This is a high level info on 2 different methodologies to show non-developers that there are different approaches.

So it was an honest attempt to educate and provide value. Okay. So let me try to give an honest attempt to re-educate on what I perceive to be some of the errors in this infographic:

Agile Pros:

Customer approval during all stages:
Probably just a minor clarification, but approval is a little strong for me. They are involved throughout – what that means is that they agree to the work to be done just in time prior to starting it, then they get to see it when it is nearing completion. In essence, there is a greater focus on building the right product.
Great for quick launches:
Okay, but maybe more importantly, Agile is great for getting a product out quickly and getting feedback immediately from customers to know whether you are on the right track. You can continue to build on this product through subsequent iterations.
I want to take a moment and comment on the usage of the term “customer” through the infographic – I am concerned that it is referring to a customer in the business as opposed to a real customer who uses the product. Also there is a lack of distinction on project and product throughout.
Prioritised by business value:
Business value is important and should definitely be used as one means of prioritisation, but there are often other considerations used in Agile – Weighted Shortest Job First is a classic example of this. For me, in Agile, prioritisation should include consideration of business value, risk (either technical or implementation), cost, cost of delay and learning value.
Customer involvement makes project user focused:
So customer is now distinguished from users (who are the real customers). It may be a little concern of mine, but I do feel the strong focus in Scrum on the Product Owner role detracts us from making greater efforts to get to know the real customers. Yes teams can work hard to ensure they hear the voice of the real customer, but there is nothing like using only customer data to drive your decisions.

Waterfall Pros:

Early agreement on deliverables:
The natural risk here on early agreement on deliverables (and I think they mean scope rather than deliverables) is that as you learn things through development, the agreement is moot. Build the right product, don’t just build the product that you agreed to that meets no ones needs.
If the interpretation truly was deliverables and not scope, there is nothing stopping you from having a great understanding of what needs to be done upfront with Agile. Many teams that I have worked with do an activity prior to going into iterations called “Inception”. The purpose of this activity is to have a common understanding about everything that needs to be done (as best could be understood with so much uncertainty in the complex world of software development).
No need for customer involvement during development:
I read this like ‘In software development there is never a need to clarify anything or to get feedback on anything’. Yeah, like that happens, or like that works out to be a great solution. In the early days of Agile when I heard this twelve years ago my response to the business when they said they couldn’t afford to have an ‘onsite customer’ was “okay, then if this project isn’t one of the most important ones for us to focus on as an organisation, that it isn’t critical to invest business experts in for, then it sounds like it isn’t critical enough to invest IT experts in.” The response was always swiftly met with the provision of a good SME.
Full scope known in advance:
Never in the world of software development has scope always been fully known in advance. This is just a fallacy and it should be stopped being used by Waterfall appreciators.
We never build the same thing twice. As a consequence, software development is not a production line, it is a process of discovery.
Known deliverables reduce chance of “piecemeal” effect:
There are so many great tools out there for dampening the “piecemeal” effect of Agile – let me name just a few: Inception, Story Mapping, Impact Mapping and Feature Parking Lots.

Agile Cons:

Disadvantages when team is dedicated full-time on the project:
Firstly, I am pretty sure there is no rulebook that says teams should be dedicated full-time in Agile. I won’t disagree that it is common practice, nor will I disagree that in almost all instance it is a good thing.
Secondly, I have done some waterfall projects. People were full time in those too, so it isn’t an Agile thing.
Thirdly, we have lots of great scientific evidence around the benefits of having team members full-time on work – it reduces context switching, it focuses on getting the work done sooner, thereby delivering value to customers sooner, thereby earning money for the business sooner. If you are interested in learning more about the science take a look at “Product Development Flow” by Don Reinersten. Another good book is “Slack” which talks about the misconception around being 100% utilised.
Customer may not have time to be involved:
I guess the project isn’t very important then.
Customer may redefine scope:
That sounds like a pro rather than a con. Especially if it means we deliver the right thing rather than waste money on building the wrong thing. The biggest waste as described by Lean is building the wrong thing – in software development this accounts for 64% of features developed.
Edit: in trying to be accurate on this statistic I discovered it was based on a sample of 4 projects. Those sample numbers are definitely not enough to prove anything. Well at least I learnt something new.
Quick launches can cause incomplete tasks:
I don’t know about ‘quick launches’. If this means getting a product to a customer can cause unimplemented scope to occur, then yes I agree it can, and that is a good thing – because we can get value and learn from it. It doesn’t mean that we won’t continue to work on the product, just that when the cost of implementing new features exceeds the benefit then we are probably going to stop. That sounds pretty sensible to me.
Often in Agile environments we try to automate “launching”. The process of automation inevitably should result in better quality of deployment over time (due to the removal of manual errors) rather than creating more incomplete tasks.

Waterfall Cons:

Customer only sees final product and could be unhappy:
In the waterfall projects I have been on with limited customer involvement the ‘could’ has occurred in 100% of instances.
Customer has trouble visualising project in early stage:
This happens with either approach. We don’t know what we just don’t know.
Late changes cause going over project budget:
Again could happen with either approach. Agile projects should reduce or dampen this effect by delivering the higher value work sooner. But I have to be fair, in my experience most projects I have seen (be them Agile or Waterfall) have had overruns of time (not in production delivery necessarily, but overall effort expenditure). Going over project time often means going over project budget. I feel however our focus on budget/time as indicators to success are sub-optimal, but maybe that is a blog post of the future.
Late changes extend project timeline:
As above.

What should factor in your decision – customer preference, project size, customer budget, time to market, customer availability:

No, you should just always use Agile. I know this sounds dogmatic and like I am a cool-aid person, but when it comes to mitigating delivery risk there really is no alternative to Agile. If you want to deliver with greater success, less risk and with the greatest chance of getting the outcome you want you need to use Agile, it just really is that simple.

The Leadership Gift – The Responsibility Model

Renee Troughton

2 comments

January 23, 2016

When I was in Washington for the Agile Alliance 2015 conference I met up with Craig Smith and Christopher Avery for a podcast (unfortunately for me half way through). It was my first real introduction to the Leadership Gift and Responsibility Model. I had heard Craig talk to about the Leadership Gift a few times but the conversation intrigued me.

Recently I have started to have a look in depth about what a fully comprehensive leadership training program would look like and remembering the conversation in Washington I set aside some time to watch the youtube video on The Leadership Gift.

The following are my random notes that I took as I watched the video. They will likely seem contextually disconnected and out off place but I write the notes in the spirit of Non Violent Communications appreciation – to give clarity of what I give thanks for.

So the basic model is as such:

The importance of moving the “inversion layer” eg the layer of management that deals with where teams transcend across coloured layers (as described in Fredrick Laloux’s Reinventing Organisations Book). Eg a green Agile team and amber management – the Scrum Master is the person who is often affected by the inversion layer. The goal should be to NOT have an inversion layer.
A reference to complexity and uncertainty (making me think of Cynefin)
Accountability does not mean responsibility (resonated)
Do we make commitments visible?
The responsibility process demonstrates how we use language when things go through (key message)
Justify = “that’s just the way it is around here”, “there’s nothing I can do about it” (important classification)
Impediments = a conception of elements beyond our control (but are they really???)
Responsibility is the place of freedom – of control and power in ones mind (key message).
Shame is socially considered a level of responsibility, but it is not (aha moment for me).
When we are truly responsible when something goes wrong we acknowledge it but more importantly we focus on what we have done to fix it, to stop it from occurring again and what still needs to be done, or what is outstanding (key message)
High performing teams – go beyond their accountabilities, have highly successful outcomes & have a great time doing it
Reference to Chris Argyris & Double loop learning (re-hearing what I learnt a few years ago)
We weren’t born with perfect knowledge and we won’t die with it either (loved this quote)
… but we can learn through experimentation, trial and error (again reinforcing lean startup to process belief)
Get off shame by forgiving yourself
There is no personal growth when you are living below the line, ie doing obligation, shame, justification, blame or denial
What to do? Firstly intention – create a desire to get above the line with free will. Secondly have awareness – a life long pursuit. Thirdly confront yourself – what change is needed based on awareness. (key message)
Winning is about meeting an achievement not beating others (similar messaging as Non Violent Communication)

Minimal Viable Agilist

Renee Troughton

no comments

January 23, 2016

What is a Minimal Viable Agilist?

I have been doing some hiring lately. The two roles I have been hiring for are a Scrum Master and a Business Analyst. I used the opportunity to test my recruitment questionaire – questions that I am expecting the organisation to ask in the future when I am no longer there in order to ensure that they are getting quality candidates into the roles.

The questions had some basic Agile bits, the sort to ensure that we were getting people who culturally understood T-shaping, the values and principles of Agile – not that they had to ring them off by rote, but they knew and understood what it felt like to experience them.

And then there were the role specific questions. For the Scrum Masters the test predominantly comprised a series of pictures with a question per picture. An example (without showing the picture) was “Take a moment to orient yourself to this wall – what issues do you see with the team/the work?”

If the Scrum Master applicant passed the basic Agile questions and the wall picture questions, stage three was getting them to demonstrate facilitating in a mock scenario.

Somewhat thankfully our search for a Scrum Master didn’t last too long – candidates that recruiters passed through to us all failed abismally. All of them didn’t even pass through the first stage to begin asking the picture based questions. Feeling despondent we did the whole ‘Who do we know who can do the job and are actively looking?’ thing. Interestingly they passed all three components of the test quickly.

So then the challenge was finding a Business Analyst, and that was indeed difficult. We had resumes without even a reference to the word ‘stories’, ‘Agile’ or ‘Scrum’ being put forward by recruiters despite being exceptionally clear that we were looking for Business Analysts who had strong experience in an Agile environment.

There were a couple that got through to stage two testing – but they were few and far between, many of our interviews got cut at 10 or 15 minutes.

It was very frustrating; we weren’t asking questions that were hard – we were asking questions that anyone who cares about being good at their job should be able to know the answers to.

So let me put this as simple as I can – if you aspire to be an Agile Business Analyst, or you think you are worthy of being an Agile Business Analyst and selling yourself as one, then these are the things I feel you should be able to answer (naturally these questions are more fluidic and are asked when a conversational element exposes their relevancy):

How do you decompose something down from a big idea to something that can be delivered by the team?
What qualities does a good user story have?
How do you know when a user story is small enough?
If you had a user story that was too big, what are the different strategies you would think of/use to try and break it down further?
What is the difference between Acceptance Criteria and Definition of Done?
On average how many Acceptance Criteria do you have per user story?

If the answers to the above questions are correct then the interview goes onto stage two – scenario testing. Similar to the Scrum Master test we provide a simple User Story and ask the person to define some Acceptance Criteria. Then we ask them to look at a number of poorly formed User Stories and tell us what is wrong with them.

Stage three, like the Scrum Master is practical, asks for a demonstration of analytical and breakdown skills through a scenario, ultimately to test facilitation skills and on the spot thinking.

Now I won’t reveal the answers to the questions above, but if you feel like giving a try and responding in the comments you are welcome to. Additionally I have left out some of the thinking processes that we have been looking for but I can reveal that answers like “I just do what I did back in waterfall – I talk to people and write the requirements. Business Analysis is no different in Agile than in a Waterfall environment,” is probably not going to get you the job.

But through all these interviews what I was most surprised with was how little people cared about the quality of their skills in their chosen profession. I am often frustrated and don’t know the answer as to why people know so little about their profession. Here are some possible root causes I have conceived of but I don’t know which is the right answer (I suspect it varies based on the person):

I am too busy doing my job to learn how to be more effective in it (too much work)
I work hard when at work, in my down time I don’t want to think about work or read about things related to my job, I just want to relax
I studied at school and for my degree, I was so glad when that was over I didn’t really want to study anymore
I am awesome and don’t need to know any more/get better
I am sick of people telling me what to do and how to do it, I am just going to do the smallest thing I have to in order to get my paycheck.
Understanding this change threatens my job in some way
I get by, no one else has commented on how I do my job

And so the ultimate question that it came down to in the interviews were “What is a Minimum Viable Agilist?” To me it is a person that cares about their craft, that understands the value of spending time to make themselves better and in doing so making the product better.