The term Scaling Agile seems to pop up everywhere you look. On IT conferences, among management and when HR people initiate recruitment etc. But scaling agile is not just one specific and well defined model to apply. It is a range of frameworks, combinations of frameworks and hand crafted approaches specific to an organisation. And yes, it does matter how you get started on scaling agile.

Scaling agile is a range of skills that can be learned, just like addition in the math classes in the first grades of primary school. But where addition is uniquely defined and has a specific logic (2 + 3 = 5, always) then scaling agile is not uniquely defined and does not have a ‘logic’ in that sense.

Before we dig into these aspects, let’s first recap what agile is.

Agile

The word agile is not new but widely used in everyday language. According to Miriam-Webster, the word Agile has two explanations, namely

1. Marked by ready ability to move with quick easy grace
   // an agile dancer
2. Having a quick resourceful and adaptable character
   // an agile mind

In relation to development of new solutions technology, the more widely used starting point is the agile manifesto

This list of agile techniques is long, where the most widely used are Scrum, Kanban and XP, although the list is far longer. Generally speaking, when being agile, one product is being worked on by one team only, although there are exceptions.

As the agile techniques are structurally different (e.g. organised around an iteration or not), there are also more than one way you can organise your scaling agile efforts.  

A key difference to team-level agile, is that more than one team work on the same product. Whether it is 5-8 teams, 25 teams or 1000 teams working on the same product, depends on the nature of the product (the product definition). Wider product definitions typically have more teams working on the same product, and thereby enable them to handle synergies and dependencies within the domain of the product. Slimmer product definitions leads to a higher number of products in the organisation.  

We will now dig further into the main scaling agile frameworks. And by main frameworks we refer to the frameworks being applied by the Danish organisations, found in the survey by VILMA Consulting you can read more about here.

Levels in Scaling Agile

A key difference between agile for a team (or a number of teams) and scaled agile, is that with an agile team, there is only one level. There is no portfolio-management-like structure ‘above’ or ‘around’ the team; that is, the stakeholdes liase directly with the Product Owner for the teams’ backlog. And each product is worked on by only one team, so coordination needed is between products and not within products. I often Refer to this as team-level agile.

When we talk on scaled agile, we have coordination within a product as more teams pulls work from the same cross-team backlog. This cross-team backlog operates across teams and may therefore be referred to as a higher level. Usually 4-8 teams are grouped together, although examples of 10 and even 11 teams have been seen.

Such grouping of teams may repeat again, so that we could end up having 3, 4 or even 6 levels in the scaling agile structure within an organisation.

• Level 1: Teams (e.g. 5 teams)
• Level 2: Group of teams (e.g. 5 x 5 teams = 25 teams)
• Level 3: Groups of level 2-groups (e.g. 5 x 25 teams = 125 teams)
• Level 4: Groups of level 3-groups (e.g. 5 x 125 teams = 625 teams)
• Level 5: Groups of level 4-groups (e.g. 5 x 625 teams = 3,125 teams)
• etc.

If each team consist of 6 people average, then level 4 would include 3,750 persons, while level 5 would include 18,750, for the number of teams listed above.

Scaling Agile Frameworks

There are basically three ways to scale an agile organisation; 1) Apply a well-defined scaling agile framework. 2) Define your own structure, -or, 3) Form a hybrid of the two. In Denmark we have examples of all three approaches as described in the paper Scaled Agile Organisations in Denmark 2019, which you can read https://www.vilma-consulting.dk/papers/.

The most widely used and well-defined frameworks for scaling agile are SAFe, Nexus, Scrum@Scale and LeSS, all published between 2011 and 2018. Therefore we will focus on these four below.

Nexus

Nexus was developed by Ken Schwaber (co-founder of Scrum) and a group at Scrum Inc. The framework has been available since 2015.

Nexus is a further developments of Scrum, and is formed around repeating the structures of Scrum for several teams, and at two levels in the organisation. In other words, it is based on the analogy that a structure that works for teams, can work for teams of teams and beyond.

In brief, the framework works by having up to 8 teams in a Nexus (team of teams), where they all work from the same Product Backlog with only one Product Owner serving all teams. Team members from all teams participate in the Product Backlog refinement. All teams deliver one integrated potentially shippable product increment, which is demonstrated at the shared Nexus Sprint Review. To continually inspect and adapt, the teams hold a Daily Standup following the Nexus Daily Scrum, and Retrospectives at both team and Nexus level.  

Nexus works in 2 levels (team + team-of-teams), while Nexus+ works for 3 levels, with a number of Nexus’ in parallel.

The structure in a scaling agile framework is designed to optimise for a parameter. In this case Nexus optimises for value realisation. In other words, the objective when using Nexus is to maximise the realised (business) value via the potential shippable product increment done at the end of the iterations.

Scrum@Scale

Scrum@Scale was developed by Jeff Sutherland (co-founder of Scrum) and the framework has been available since 2018.

Scrum@Scale is a further development of Scrum, and is formed around repeating the structures of Scrum at multiple levels of the organisation. In other words, it is based on the condition that the structure that works for teams, can also work for teams of teams and all the way up to the portfolio level and C-level.

In brief, the framework works by having up to 5 teams in a team of teams. Each team has their own Product Backlog and Product Owner, where items are flowing from the Product Backlog at the team-of-teams level (Level 2) to the backlog at the team level (Level 1). Team members participate in the Product Backlog refinement at the team level.

At each level, there is at least one Product Owner with a Product Backlog. There is one Product Owner (PO) for each Team (Level 1), one Chief Product Owner (CPO) for each Team-of-Team (Level 2), one Chief Chief Product Owner (CCPO) for each Team-of-Team-of-team (Level 3) etc. And for each Product Owner (PO, CPO, CCPO etc) there is a Product Backlog.

The Product Owners (PO, CPO..) work in the Product Owner Cycle from strategic vision (at the highest level) to prioritised Product Backlogs at all levels prior to the teams Sprint Planning. And thereby ensure consistency from vision to each teams’ prioritised product backlog, at any time.

All teams deliver an integrated potentially shipable product increment, which is demonstrated at the teams Sprint Review at the end of the iteration. To continually inspect and adapt, the teams hold Daily Standup followed by Scrum-of-Scrums (Level 2), Scrum-of-Scrum-of Scrums (Level 3) etc until the top level is reached. As an example, an organisation with 3,750 persons would need 4 standup meetings of 15 minutes (60 minutes in total), to escalate from team to top level.

Further, the inspect and adapt workshop, the sprint retrospective, is held at the team level.

Scrum@Scale works for (in theory) any number of levels, starting from 2 and up.

The structure in a scaling agile framework is designed to optimise for a parameter. In this case Scrum@Scale optimises for value realisation. In other words, the objective when using Scrum@Scale is to maximise the realised (business) value via the potential shippable product increment done at the end of the iterations.

LeSS (Large Scale Scrum)

LeSS was developed by Craig Larman & Bas Wodde. The framework has been available since 2014. LeSS is a further development of the patterns that works for teams in Scrum, combined with organisational design, systemic design and Lean principles.

The starting point for LeSS is to reduce the organisational complexity (descale the organisation), prior to scaling the organisation. Thereby the amount of complexity, internal constraints and dependencies have been reduced, which in turn leads to that the scaled setup also becoming less complex. 

LeSS is centered around the product with the Product Owner having the full responsibility. From idea to shippable product, the idea is worked on by the Product Owner and the team, while relevant stakeholders shed light on relevant details. Effectively this means the teams are far more involved in the refinement process, from initial idea and until the item is ready to be pulled into a sprint.

All teams deliver one integrated potentially shipable product increment, which is then demonstrated at the shared Sprint Review. The continually inspect and adapt, is handled by the teams as and when needed. Retrospectives are held at both team (Level 1) and team-of-team level (Level 2).

LeSS works in 2 levels (team + team-of-teams), while LeSS Huge is 3 levels, still aligned in one Product Backlog and one Product Owner.

The structure in a scaling agile framework is designed to optimise for a parameter. The scaling agile framework LeSS is flexible as the organisation is reorganised and may optimise for the desired parameter eg value, secrecy, busyness or any other relevant parameter.

SAFe (Scaled Agile Framework)

SAFe was developed by Dean Leffingwell and was the first scaling agile framework to be released, as early as 2011. The current version 5.0 was released in 2020. SAFe combines Lean and agile principles into a set of lean-agile principles. SAFe is the only scaling agile framework that starts implementing scaling agile at team level and team-of-team level in parallel.

SAFe starts with the organisation’s portfolio level and Lean Portfolio Management. The objective is to have a lean enterprise with a clear description of roles and responsibilities. SAFe is not directly linked to neither Scrum nor Kanban, as teams are free to choose their structure, although within boundaries of a fixed cadence across teams. The cadence is typically 2 weeks iterations, bundled in five 2-week iterations as a longer planning horizon (PI).

The overview of the SAFe framework is actually four overview, depending on the size of the organisations. Above is shown the Full version, covering 4 Levels. Furthermore, there is a version for 2 levels named Essential SAFe, and two versions for 3 levels; Portfolio SAFe and Large Solution SAFe.

The structure in a scaling agile framework is designed to optimise for a parameter. In this case SAFe optimises for outcome. In other words, the objective when using SAFe is to maximise the outcome via the potential shippable product increment done at the end of the iterations.

Other Frameworks

Further, a number of organisations have been inspired by the structure formerly applied at Spotify. The structure has not been described to the same extent as the above mentioned frameworks, just as the people involved in forming the way of working at Spotify, did not consider it being a framework. Their way of working is described in videos, e.g. in these on YouTube here and here. 

The hybrids of scaling agile frameworks often combine one structure for the team level with one or more structures for the portfolio level. There is no clear recipe for the hybrids, but a number of them factor in Lean Portfolio Management.

So, which of the Scaling Agile Frameworks should I choose

Well, that is a very frequently asked question when we talk scaling agile. But first, you need to identify the goal of the scaling agile. What do you want to achieve?

Knowing the goal, you are ready to ask whether you should 1) de-scale the organisation, 2) start agile at team level (rather than start scaling agile at level 2+), or 3) scaling agile is the right next step for you.

Despite the simple nature of these questions, these steps should not be missed – just as you should not skip a step on a maturity model.

And the answer to the question on which scaling agile framework to choose. Well, it really depends on your context. There is no universally right, nor universally wrong framework. The right thing to do for you, is the one that brings you closer to the goal. And the goals are not identical across organisations, just as they are not identical across borders and business domains.

Recommendations

Before you embark on an agile transformation, consider why you want to transform to a scaling agile organisation, what you expect to achieve (the goal) from being a scaled agile organisation and whether you could descale the organisation (or do something else), to achieve the goal.

As the next step, make a comparison on how well 3-4 different scaling agile frameworks could assist you, considering both risk, cost and the people aspect of a transition. The comparison could be structured as a business case, and thereby comparable across alternatives.

When you have made the decisions to embark on scaling agile in your organisation, you are ready to make your first backlog, the transition backlog. And then prioritise the backlog by likelihood of bringing you closer to the goal.  

We at VILMA Consulting are ready to help you on all these steps.

So good luck starting – or continuing- with a scaling agile transformation!

Majken Vildrik Thougaard, Independent Agile Specialist & Owner of VILMA Consulting

PS: If you have started your scaling agile transformation time ago, there is plenty of inspiration to continuously improve to find in the other scaling agile frameworks. Could be if you are interested in Continuous Learning…

Projects are started and completed every day, for the right and the less attractive reasons. Governance of projects and portfolios is focused on making the right decisions at the right time. And governance is relevant irrespective of whether you apply one of the agile methods or waterfall.

But let’s just take the conclusion, so you know what to expect below:

• Can you do governance if you are agile? Yes!
• Can you do governance to same extent as if you operate waterfall? Yes!
• Do you do governance in the exact same way? No!

 

But what is governance all about

When I throw money after a project, I’m eager to see the value. And the longer it takes to show me the value, the more desperate I become in wanting confidence that it progresses best possible.

Project governance is about just that, making sure the money spent adds value. Sufficient value, fast value and more value than the alternative investments (it has the highest marginal value , or ROI – return on investment, if we speak in economic terms). And when running more than one project, which is usually the case when you consider project governance, making sure all scarce resources are used best possible.

To compare project governance for agile and waterfall projects, we first need to describe how we ideally would follow up on and compare projects, irrespective of the method applied for the projects. Had we chosen to evaluate agile projects as we do with waterfall project, we do not give credit to neither waterfall governance nor agile methods.

 

How do we evaluate progress

The ideal situation for project and portfolio governance, is to have a progress-o-meter that consistently measures the progress of any project or initiative, continuously, and flawlessly compares data across the portfolio. The fact is, we only have a prototype for this, and that has been fairly stable for a while – although with room for improvement.

In the perfect framework (that may, or may not yet, have been formulated) for doing a project, we would most likely evaluate a project on these key indicators

• Actual progress + manage expectations related to time
• Actual spending + manage expectations related to cost
• Risks, blockers and what is being done to remedy these
• Fitness for use/ customer/ market

And most likely evaluate the portfolio of projects on these factors

• Are we working on the right things?
• Are we working with the right things, with the right intensity
• How fast can we change (deliver something else) – from new idea to product (increment) deployed to end customer (adaptiveness to change)
• Fitness of resources to current utilisation

 

So how do agile and waterfall compare on project governance

In the real world you probably compare projects on more than just 4 indicators, no matter how attractive it may seem with just four. Further, some indicators may also vary from industry to industry and likely with size of project, regulation requirements and security aspects involved. But the above should apply irrespective of the industry and the project type.

So let’s see how well agile and waterfall governance matches on the four governance indicators described above.

 

How well do waterfall address the governance indicators

 

How well do agile address the governance indicators

In agile governance the indicators are addressed differently. Actual progress is evaluated by the aggregated delivered and deployed, product increment and no credit is rewarded for ‘work in progress’. The Product Owner is key in this, as he is responsible for the approval.

 

Comparison of governance for agile and waterfall

In the figure below, we have added up the accuracy of responding to the governance indicators, where green is (close to) full accuracy, yellow is medium and red is low accuracy.

Project governance is more than just four key indicators, but for the sake of simplicity, these have been selected. In a similar way, programme governance can be compared across waterfall and agile methods.

Summary

Governance is just as relevant for agile as for waterfall projects. Although we evaluate them differently, both agile governance and waterfall governance seek answers to the same underlying questions. We may just have grown so used to one way of answering the question, that we left out attention to the original question in our daily routines.

As a trick, when presented with a metric to report on. ask your self why you report on this specific measure. If the answer is not clear, or is not the root of the reason, you most likely report on a proxy. If you are reporting on an agile project on a waterfall-proxy, you might end up reporting on a proxy-proxy.

The change from waterfall governance to agile governance is best facilitated if you have strong insights into how the value adding activities relate to another. Or, you should consider engaging with an agile specialist to maximise value and smoothen transition.

 

So good luck getting started with agile governance!

Majken Vildrik Thougaard, Independent Agile Specialist & Owner of VILMA Consulting

 

PS: If you look at your KPI structure, you most likely will find similar patterns of approximations, that reduced your awareness to the original question.

 

 

 

Are agile projects best supported by agile contracts? How does agile contracts deviate from traditional contracts? And does it make a difference what you use?

Keep reading and get enlightened on differences and implications of applying agile contracts for agile projects. And here you can get a short introduction to what agile projects are.

Why do we need agile contracts

In the complex world we operate in, projects are often solved by highly skilled suppliers – which is desirable in terms of competencies and cost efficiency. In larger organisations, this often implies a need for a procurement administration and comparisons of potential suppliers, where (as a minimum) expected cost and delivery date are the easily quantifiable parameters compared. Concurrently we see that modification of solution at no extra charge, the option to abandon the project when 60-80% of the value has been realised and only pay for actual cost spending, only rarely are part of the comparison, although this may heavily impact the actual cost.

But this is possible with agile contracts.

Does it matter if we use agile contracts or traditional contracts

The execution of the work is fundamentally different depending on whether it is based on an agile contract or traditionally (also known as the waterfall method). When executing traditionally, the work assignment and conditions are fully described ahead of start, based on the project managers iron triangle; scope, price and quality.

In an agile project you work towards a goal, and the means to reach the goal is agreed on an ongoing basis. In reality this means, that the level og quality is agreed ahead and continuously verified, while scope is added to match the customers needs. The cost is accrued cost (time and material), typically within a predefined range. As an example, a customer may demand a number of development teams consisting of a fixed group of people, whereby the monthly and yearly rates are known.

Traditional contracts

In a traditional contract the basis of the contract is WHAT is to be delivered, WHEN it is to be delivered, and total COST for the project. All of this is very convenient as a requisitioner, but perhaps attention should be focused on the incentive handed over to the supplier to identify any inaccuracies or missing elements – not to mention larger missing parts. Every time a supplier identify an inaccurate description, the reward is that it may be charged. Or if you as requisitioner grow more knowledge in the process, and perhaps even revise your opinion, this will be charged extra and most likely combined with a delay.

The advantage is that cost, delivery date and scope are known at project start.

The downside is that cost, delivery date and scope typically deviate significantly from the expected, plus the additional extra resources spent on adjustments and change requests.

What does agile contracts cover

If your project is covered by agile contracts, you get continuous delivery of the most important features following a fixed cadence, eg release every 2 or 4 weeks. Thereby the customer will get a value add throughout the project, and not only at the end. The duration of agile contracts will often be flexible, eg minimum of XX months with an option to extend. The service the customer buys, is a number of development teams with known line-up, so that the quality level may be assessed ahead and compared to other potential suppliers. The customer continuously receives and accepts product increments from the supplier and may therefore continuously capitalise the investment.

Of course, there is a strong element of trust in the contract, but this is only added on top of the trust element from letting an external supplier to deliver a business critical system.

Since scope is determined on an ongoing basis, you as a customer always have a finger on the pulse on what the supplier work on. Further, the customer continuously has to accept the delivered, wherefore no surprises will line up.

The customer may at any point in time change the priorities or goal, irrespective of whether the change was caused by a strategic change, changed market or anything else.

The basis for the contract is WHO is doing the job, WHEN product increments are released (fixed cadence), and COST in terms of hourly rates and materials (classic T&M).

 

The clear advantage is that the solution is delivered on an ongoing basis, so the customer may start using it and get benefits from it earlier. The customer may at any time and at no extra cost change direction. The contract may be terminated by the customers desire and this will typically happen when the marginal value of another waiting project is higher than for this project. The project may start faster as all requirements do not need to be known, accepted and prioritised, first.

Progress reporting is with agile contracts about what actually has been delivered (working product increments), rather than assessments of what work is still to be done.

The downside is in the taking on of the first agile contract, where a different type of initialisation is to be done, further, the customer must on an ongoing basis prioritise and present requirements and follow the development, which for some is very different.

How can the trust to the agile supplier be created

In addition to the classic tools of references and economic key figures there are other elements in the assessment of an agile supplier.

• The ability to work as an agile team – both internally at the supplier, but at least as important, the collaboration with the customer
• Development speed eg. the Lead Time, the time elapsed from requirement emerges to the solution element is in production
• Number of errors in the production system, in relation to the amount of solutions delivered

If you know the supplier from earlier, it is a big advantage, as you already know the norm of quality the deliver.

If we consider a new potential supplier, an option is to validate them in the specific setup. As an example, the supplier may be invited to an agile trial where they have to both; deliver a solution to a specific assignment, from their own development system to your production system; and the supplier will at the same time be evaluated on their ability to collaborate internally and collaborate with you. In practise, you ask for a 1-2 day-trail in an agile setup and 4-5 day-trail in a scaled agile setup. This investment of resources takes the place of a comprehensive tender documents with hundreds of specific requirements for the solution.

What are the advantages with agile contracts

When the work is delivered via agile contracts you get advantages like

• Direct involvement as customer. The customer prioritises on an ongoing basis what is most important
• Continuous value adds from continuous deployment
• The most important part is delivered first, whereby the project risk on the overall success criteria is fast minimised
• Value adding collaboration, where all parties are working towards the best possible solution for you as the customer, without hidden agendas on possible extra costs to bill
• Absence of change requests, both in terms of your administration and the cost itself
• The option to terminate a contract when the project is sufficiently solved, even if remarkable earlier than expected
• If you choose to test the new suppliers and require a fixed team, you have a deeper knowledge of the delivering team ahead of the project

Who are agile contracts relevant for

Agile contracts are relevant for anyone putting non-standard contracts out to tender or directly to a supplier. Both private companies and public institutions benefit, and the common denominator is that they seek to maximise the quality for money, earlier delivery hence faster time to market, lower the project risk while preserving the option to navigate in a fast-changing market.

We see examples from private organisations and public institutions who put agile contracts out for tender, and the area is growing. In the public domain, in the wake of huge capsized projects, we have seen a clear demand for radical change of the projects governance.

 

So good luck getting started with agile contracts

Majken Vildrik Thougaard, Independent Agile Specialist & Owner of VILMA Consulting

 

Estimation is something a lot of persons just strive to get around, as in not do at all. Or get someone else to do. But why? Estimation and relative estimation is one of the very powerful tools when it comes to bringing insight, if done the smart way. And by the way, there is more than one smart way.

How do you estimate

If you work in IT and have done so for some years, you either do estimations (often on someone else’s request) or you consistently try to shovel it to someone else. Or you belong to the group of people who have learned the power of estimation – and the value it brings to you.

But why should I estimate

There are many answers

• Some one else required you to do so. And they know the people processing your pay check, so don’t mess with them
• You are a manager and asking people to estimate so that you can forecast something. Unfortunately, sometimes you get to fill in the blanks yourself.
• You are on an agile team and do relative estimation in very short time, and apply these estimates for prediction of this and coming sprints outcome
• You are on an agile team and do not estimate at all! Despite this, you are still able to predict the outcome of this and coming sprints

For what are the estimates used

Generally speaking, the estimates are used to predict something either short term, or longer term. But honestly, when did you last see a long-term forecast based an estimate that hit bulls eye? It happens! But does the frequency match the cost of the estimations and updates to them? Also, when you factor in the misses?

How can we do it differently

In the agile ways of working you estimate often, but the time spend is quite limited. A planning session for a two-week iteration is around 2 hours, and you don’t estimate all of that time. Often you get to estimate 6-12 items during a planning session, and each estimation takes from 2-5 minutes. Nothing more. But that cannot be accurate? No, it isn’t. But that is no problem, because it all averages out (if you are really curious, there is some hairy math involved here).

The difference is to do relative estimation rather than absolute estimation. And provide the estimate in a timeless unit like Story Points, or whatever you prefer to call it. The estimates are subject to the team that did it, and can be used for their prediction, of eg how much they can deliver on an average iteration when used in combination with realised velocity for past iterations.

What are the benefits of relative estimation

It simple, fast, cost effective and meets the purpose of prediction to a reasonable extent. And furthermore, it activates the whole team in the estimation, leading to more qualified estimates. Last but not least, the estimation is coupled with Q&A, where more detailed information is transferred from requestor to the team. Information that was not pushed with the requirements, but instead pulled by the team.

Just before you let go of your whole estimation team, they are still useful when you place a bid in a competitive bidding.

Well are there any pitfalls of relative estimation

‘There is no such thing as a free lunch.’ Had there been one universal solution for every case, no one would notice as all other option would have vanished. So yes, conditions do apply. But they are actually fair. Only if you respect these, you can effectively use relative estimation for forecasting.

• The team who is going to deliver the work being estimated, are the ones to estimate (estimates are not transferable from team to team)
• The team – and everyone on the team – are doing the estimates. No manager or other is impacting the estimation. Again, the reason behind is that the team are the ones committing to it (not the manager)
• Access to information prior to, and in relation to the estimation from the source, that is the requestor of the work, is crucial. The team need to swift compare the case to other known cases to finalise the estimation.
• Respectful collaboration during the estimation. Whatever is brought up during the estimation, has been brought up for a reason. And this is both known issues that will increase the estimate and short cuts that will limit the estimates.
• The relative estimation is for operational purposes, can be applied for some tactical, but lost power way before the strategical domain.

How complicated is it to get started

The ‘how to’ can be explained in 2 minutes and a team can be operational doing this within an hour. So this is not really where you find the justification for not doing this. And as always, browse for videos or factor in an agile specialist to get you started. smooth and effective.

 

So all in all, I think this is a powerful tool a happily recommend. Low cost implementing, low cost running, and quite powerful predictive power also compared to traditional estimation.

 

So good luck getting started with relative estimation!

Majken Vildrik Thougaard, Independent Agile Specialist & Owner of VILMA Consulting

 

PS: Not to estimate – often referred to as no estimate – is actually also to estimate. The reason is it implicitly assumes cases are of similar size and it therefore suffices to count the number of cases, rather than estimating them. This usually requires a quite mature team to implement.

To start agile is to start a transformation. To start agile is to embark on a journey that will challenge you, and at some point provide you with all the answers to why you should start agile.

Well, if you are all new to agile, then let’s start with what agile is, before talking on how to start agile. There are roughly to ways of doing projects, that is sequential and iterative methods, also referred to as agile methods.

The sequential method, will start doing one thing (phase) before moving on to the second, only when the first is completed. When the second phase has been completed, then move to the next; and possibly passing some kind of decision point when moving phases. Waterfall methods going through phases like Analysis/ Specification – Design – Develop – Integration – Test – Deployment, are widely used.

Iterative methods -or agile methods, on the other hand, will roughly speaking be doing all these steps in parallel, in tiny chunks and reviewing each tiny chunk as it is delivered. Effectively, we only set the course for minor bits of functionality at the time, requiring us to constantly evaluate ‘what’s now most important to do’ as we get see the solution in real life being put together like small pieces in a puzzle. The short clarification and development periods may be as short as 1-2 weeks and still be able to deliver meaningful add-on’s to the project. The more familiar of these agile methods are Scrum, Kanban and hybrids at team level. And as these can be applied at organization level they also support a scaled (program-like and even higher levels) in frameworks like SAFe and LeSS.

Common for all agile methods, is that they best way to run them is quite a bit different to what is optimal in iterative (waterfall) methods.

So how do I figure out, where to start agile?

The good news is, that by asking the question you have already started! By asking this question you are well on the way to realise that it might be relevant to start this differently. And asking means inviting help and knowledge to step in.

“If you want something you’ve never had You must be willing to do something you’ve never done.” ― Thomas Jefferson

1. Team up with knowledge.

If you were to embrace a new market, a new technology or new customer segment I guess you would add knowledge first. And let knowledge (and not theory) guide you on how to proceed. Apply the same logic here, to get started. This may also be the first time you feel that the agile journey will be difficult in more ways than you expected.

Finding the right way to add knowledge that actually applies to your business and your domain, and your timing – possibly even without having the tools to evaluate the qualifications, can be tricky. But you are not the first to do this.

2. Start simple, learn and grow

If you plan to big-bang apply agile methods to the whole company, then I guess your plan is to plan carefully and then launch? Just as you normally run projects and programs in the waterfall comfort zone.

Your pilot on being agile, is the planning of being agile. Go simple and start short term planning. Earn some learnings, and then grow bigger by causing a ripple effect.

You will make mistakes, and there will be lots of surprises. If you embrace that openminded, you will proceed stronger.

3. Empower the right people. And trust them.

Being agile as a company or organization, is about managing expectations. Top down, bottom up, and both ways continuously. Top down you tell your expectations of what is most important, and you will be met with replies to what you get very soon. Your best qualified people, those you empowered, will optimise the how. Bottom up, they will ask for support when relevant, when you support a trust based environment.

Your highly skilled will do their best in all their work, as they also seek success. If you don’t trust them in this, make sure to get people you trust. Or start trusting the people you have, as trust is essential for agile to work.

4. Support the team(s)

One key to success in agile is to inspect and adapt. Another key is to share knowledge as you thereby recognise that you – and you alone – cannot achieve the goal. Creating the trust-based environment where everyone shares big and small issues; some relevant now, some maybe later, itself supports the culture of inspection an adaption. This is where the positive yield starts.

So, share the big picture and the team will apply that when optimising for success. Empower the team to do the optimisation, and they will succeed and earn the trust you gave.

5. Share learnings

In agile often you learn from mistakes – the oops’s! But no one really what to be known as the you-made-a-mistake-person. But everybody would love to be known as the good guy that gave wisdom to others.

So kill the word ‘mistake’ and only use the term ‘learning point’. You can call it cheating, yes. But it works! And this actually leads directly into the last point.

6. Celebrate success. From the first tiny success and onwards

You wow when babies smile the first time, or take the first steps; to encourage them to keep going. And it works. Well, when you do something that may seem just as new to you, the wow-ing also fuels the process. Further, you actually get double benefit of the cheering – the individual will notice it and at the same time it applies as team building, growing the team ownership and the team responsibility.

You are now ready to start on how you start agile!

Team up with knowledge, learn & grow, empower the right people, support, share and celebrate. And take pride in seeing the teams operate agile and taking ownership of what you empowered them to do.

 

Good luck with your agile journey!

Majken Vildrik Thougaard, Independent Agile Specialist & Owner of VILMA Consulting

PS: Down the road you will learn to measure agile experience by the number of mistakes you made, and have learnt from.

One of the main challenges when transitioning to agile ways of working is, that rather than the individual being responsible, it is now the team being responsible. For everything. Personally a big hurdle to overcome, but even bigger for the star developer. If you nurse the transition careful enough, you have a great foundation for a cross functional team.

What is the difference between an agile team and other teams?

An agile team is a team of individuals, that bring individual skill sets and solve tasks just like anyone else at work will do. The main difference between agile teams and traditional (aka waterfall, sequential) development teams, lies in the organisation of the work where the agile team, as a unit, is responsible for the work delivered. And further, that the agile team -as a unit, will take any credit given for the delivered quality, just as the agile team is responsible for continuously improving the settings they work in.

The skills sets needed to do agile development are to a large extent similar to what you need in other development situations; if you develop software then you need developer competencies and tester competencies. Plus competencies in identifying, describing and prioritising requirements, competencies in sales, deployment and maintenance (in broad sense) etc.

On an agile team you combine the skill sets into a cross functional team, so that the team, as a unit, can identify, describe and prioritise the requirements, and can factor in sales, deployment and maintenance. Further, the team on an ongoing basis combine that with current details on the development and knowledge of which parts of the required solution is currently shipable.

What does it take to become a cross functional team?

A team with a number of specialists is expectedly a team with a high level of competencies. Are they good at solving tasks? Well, most likely they are. But; it really depends on what kind of tasks and whether they can solve them independently, or not.

A cross functional team is also a team with a lot of competencies – but one of the highly important skills is the ability to collaborate. A fundamental to collaborating is to understand what the other person says and be able to deliver your own message in a way that the other person will understand, even if it is very detailed and outside your own specialist domain.

Effectively this requires that some competencies be shared across the team members, but at the same time without requiring that all team members are to be exact clones of each other. Just image the cost of this team where all are super stars in all the aspects of requirement identification and prioritisation, development, testing and sales, deployment and maintenance! Potential dream team but likely not the perfect place to work as the individual’s room for improvement is already used.

So how should I then mix a team?

Well, what you are looking for is a combination of deep skills in the relevant domains (development and testers in relevant technologies), business domain knowledge, analysis and problem solving skills and general collaboration skills, just to mention those relevant across different business domains.

And for the team to be effective and robust (eg in times of individuals absence) each skill should, as a minimum, be held by two and ideally three people. Of course, you prefer collaboration and problem solving skills to be held by everyone, but generally you can do with less.

A person with deep skills in one domain and some skills in other areas is called T shaped, due to the deep knowledge in one area and broad knowledge in other areas – just as the shape of the letter T.

So for your team you should be looking for a combined skill set looking like T’s put closely together on a row TTT. This is illustrated here with three T shaped profiles, each having deep skills in one primary area and some skills in other areas.

But nature has already given us a great picture for this; a row of icicles.

How do I start a cross functional team – or at least get an indication of where I am?

Actually, by asking the question you are already far into it! The point is to be aware of each individuals specialist skills, but also to pay attention to the collaborative skills, problem solving skill and general ability to improve on process and tools related to the agile process. The questions can be asked by a ScrumMaster, Product Owner, or revealed by an Agile Specialist coaching the team.

Any skill you identify shortage of, you may be able to grow on the team, or add to the team as and when a new team member is to be included.

 

So good luck, growing a team of icicles!

Majken Vildrik Thougaard, Independent Agile Specialist & Owner of VILMA Consulting

 

PS: Once you have a cross functional team, you are well on your way to having a high performance team.

Is it that simple? Yes!

Never underestimate the value of a really, really good Product Owner, as the Product Owner can make or break, the productivity – in some cases even without knowing. Well, let’s first rewind the story a bit.

In the ideal world, the list of requirements, the Product Backlog, is always in perfect condition; that is, it is well specified; both in terms of what is needed and what is not needed, but also the desired quality to be delivered. Further, the product backlog is chunked in feasible parts, for the development team to deliver within a sprint, and finally uniquely prioritized by importance to avoid misunderstandings.

The preparatory work of planning the delivered output at the end of the sprint, is organized efficiently as answers are present, and predictable as adequate information supports the sizing of items and hence, the forming of the overall expectation for the sprints delivery, the sprint goal. During the sprint expectations are managed, as and when something happens. Yet, the team is able to consistently deliver on the promises made.

But, I live in the real world!

Yep, just as most of us do. Things break, rules change, competition strikes, basically ANYTHING can happen on an ordinary day at work. How well we handle that, tends to come down to how well we prepared to handle the unknown.

So what should I do?

To get an indication of how well you do, you need to know what you are overall aiming at. What is important for your company, for the team and maybe some shareholders?

• Lowest average cost of development
• Shortest average delivery time from idea to the feature is ‘live’
• Zero bugs detected in production
• Fastest reaction to market (or other significant) change, or something else?

Once the objective is known, start collecting data and measure the objective, diligently and consistently over time. Add visibility by continuously share the number(s) with the team, celebrate the improvements big and small – and you will get more improvements.

But WHY will things improve?

In a trust-based environment, the striving for team success will reveal all the places with transfers of knowledge, that can be improved. And these, by and large, involves the Product Owner and (part of) the team, no matter whether it is about collecting the information, effectively structuring the information, distributing the information or being available for additional information on any of the items – for both team and stakeholders.

So in short, the Product Owner can make or break, the productivity.

To get to that level of understanding, you can either start turning every stone, or, team up with an Agile Specialist  that can guide you on which stones to turn and get the results faster.

 

Good luck with your agile journey!

Majken Vildrik Thougaard, Independent Agile Specialist & Owner VILMA Consulting

 

PS: The Product Owner cannot do magic, so please make sure the Product Owner is empowered to succeed in the role!

Yay! We now have agile ways of working and everyone is happy. But is ‘that’ it? Could we do (even) better, could we deliver (even) more, could we be ‘more excited by our agile transition’?

As how can you really know if what has been done is ‘good’ or simply ‘good enough’ and how much better could it become? And how can you achieve that?

Suppose you do the agile meetings as described, maybe you have a scrum board (digital or physical board) and a ScrumMaster – well, that should classify as agile! Well, maybe – but it is not guaranteed. You could also be agile without the meetings and board (although this requires something else).

 

Therefore, you do not get the full benefit of being agile!

Ways to self examine is eg. How long time passes from idea to product is alive? How well de you react to changes? How are you impacted if a key person on the team is removed? How often and for how long does team wait for clarifications? How motivated are each team member? Does the team deliver at a high and steady level? Do each team member thrive on the team (and do you believe they are still there in ½ to 1 year)? Who represents the team?

These are examples of questions that indicate that you can benefit more from the agile ways of working.

But, how can I tell?

Well, you need to look for answers; listen as and when it is articulated. And be aware that in some cases others can get answers that you cannot obtain. Perhaps because these are not always expressed on a 1-10 scale, but surfaces (indirectly) eg. in a Sprint Review or other inspection point. An experienced and shrewd Agile Coach that has personally operated in the various agile roles, knows how this emerges and should be able to tell from the teams interaction and cooperation, that there is an issue, and specifically where.

Good luck with your agile journey!

Majken Vildrik Thougaard, Independent Agile Specialist & Owner of VILMA Consulting

 

PS: If you already invested in the agile transformation then remember to collect the value add! No one will thank you for leaving that behind.

 

Working agile is as simple as riding a bike, when you know how to do it. Only few things you need to know – do you break by foot or by hand, driving left or right side of the road. And you are good to go.

The same applies for agile methodologies where the principles are stated in the agile manifesto (http://agilemanifesto.org/) although these are quite wide. The good thing is they are brilliant as guidelines in complex questions, but they are close the useless if you are just about to start your agile journey.

So what to do?

Depending on your urgency to deliver faster and at a lower cost – you can either chose to try your way and learn agile by yourself, – or team up with someone who knows all the pitfalls, how to avoid them and move away from them. A person that can guide you to get started faster, smoother and most likely end up performing better.

Chose the first if you have lots of patience and care less on budget and more on organic learning in a sustainable pace. You will be good at learning from your own mistakes and feel full control of the journey.

But, chose the second and add heavy hands-on agile experience, if you care about your profitability (both cost and revenue), ability to predict and meet goals; and not least important, are eager to get started and running. The initial investment in a coach will by far be matched by the sustainable delivery of working product increments, a higher quality and faster time to market (the cycle time from idea to sellable product or internal value add).

Good luck with your agile journey!

Majken Vildrik Thougaard, Independent Agile Specialist & Owner of VILMA Consulting