Tag: scrum

Scrum – All the gear, no idea?

Scrum – All the gear, no idea?

I have a problem with Scrum – although the problem isn’t really the Scrum methodology itself, but rather some of the people who (attempt) to adopt it.

I’d liken it to Harley Davidson motorcycles or perhaps Gibson guitars – both great products, especially if they’re acquired by people who know what they’re buying and how to use them. Unfortunately, what tends to happen is that they’re also purchased by people from the outside – usually in their first foray into the sector, without any understanding of what they actually need to make full use of their purchase. For a motorcycle, where and how you ride should normally be an important factor in the type of motorcycle you purchase. Likewise, things like target musical genres and any preferred style of play will dictate what type of guitar you will want to buy (if you regularly play songs in different tunings, you may regret having that Floyd Rose tremolo on your guitar). There are obviously a huge number of other factors to consider, but I’ll avoid digressing further for now. My point is, if you don’t completely understand what you need, you’re likely to go in the wrong direction.

Going with the flow?

So, how does that relate to Scrum? Well, when you’re looking at changing the way you work, you’ll probably have a number of things to consider: what size are your teams and how many do you have, how complex are the products you’re developing, what constraints are you working with (budget, time, organisational structure) and so on. In life, there are very few solutions where one size truly fits all – but a great many tend to make this assumption with Agile – especially in relation to Scrum. More often than not – Scrum is adopted without any form of analysis about what it provides and where it fits. Ask people to list just three pros and cons about what they’ve chosen and many will struggle. Ask them why they went with Scrum and they’ll often tell you that it’s the most popular – so it must be great, right?

Now, the vast majority of people who bought their new Harley or an awesome Gibson SG will find themselves very happy with what they’ve got – but not all… While a bad purchase may have some resale value, chances are that making a bad decision about your approach to delivering software will not see a good a return. At worst, you might have failed to deliver a viable product, drove away your best talent and spent all your money. Game over.

Measure, evaluate, adjust.

Ok, so maybe that’s extreme and in most cases you’ll probably do alright. However, I’d expect a good team to do more than blindly following a prescribed way of working and instead, actually look at what pain-points they have and where their greatest inefficiencies lay. You should have some understanding of where you could improve and what benefits addressing area that could bring. You can do that at any point – before you transition to Agile, after, during – or even if you never chose to adopt an Agile methodology.

Even if Scrum (or any other particular methodology) is a good fit, it’s probably not going to be perfect. If you want confidence that you’re doing the best you can, you should have some understanding of at least some alternative approaches. There’s actually a large number of agile ways of working – some sharing ideas, some diverging. If you adopt a continuous improvement mindset, you should be regularly evaluating what you do and why you do it. Don’t just follow the masses.

Now, you may be aware that Harley Davidson isn’t the worlds only motorcycle manufacturer. If they were “the best”, why do other brands still exist and why do people continue to buy them? Depending on what you measure, who “the best” is can vary quite dramatically. Scrum benefits from being relatively easy to understand and limited in scope (divorcing itself from engineering practices). That might make it a good choice for starting to learn about Agile – but does it continue to add as much value in the different stages of your journey?

A bad workman blames his tools.

One constant I’ve observed is that who you have on your team is much more crucial than the processes, tools or methodologies at hand. A team of motivated, talented people can achieve a huge amount very quickly.

For me, a good methodology provides the least amount of interference required to ensure that all the effort expended is in the right direction (and also provides a clear measure of progress). I’d assert that the level of “interference” should probably take into account the level of skills in your team, their previous track record and how well understood the project’s goals are. Done badly, Scrum can come across as micro-managing and almost condescending. It’s an old adage, but if you’ve hired good people – get out of their way! Let them demonstrate how they’d approach things given a free rein.

If you’ve got bad people, sorry but Scrum isn’t going to magically fix that. Nothing is. However, be careful who you consider to be the “bad” people. Quite often, the developers or delivery team get left with the blame for any project going awry, simply because they’re at the end of the chain. Sometimes it genuinely is poor tooling (yes, you can blame your tools) or a number of other upstream issues that really derailed the project long beforehand. It wasn’t a bad workman. As often as not, the core issue actually relates to poor planning, unclear direction or bad management decisions completely outside of their control. Too many companies shoot the messenger without realising that is what they’re doing.

Nowadays, it’s very tempting to adopt fashionable trends – especially when they promise so much (transformation to an efficient, ultra productive nirvana). Scrum is one of many tools at your disposal, just try to ensure you have a clear understanding about the problems that it’s potentially going to solve for you. Agile is very much in vogue at the moment – use it wisely, don’t just be someone with “all the gear”…

Is your Minimum Viable Product actually viable?

Is your Minimum Viable Product actually viable?

Let’s examine one of the most-shared images relating to agile software development from last year. There are a few variants of the idea (and I apologise for not knowing who to cite as the original source), but the basic theme is the same. Instead of developing a car in progressive phases, they show the delivery of simple, usable evolutions of vehicles until the product vision is reached. I’m not sure this is actually a great example of what a minimum viable product is – or what we are trying to achieve.

What is an MVP?

Very simply, a minimum viable product is the very essence of what you are trying to achieve, leaving any non-essential functionality or other features to be added later.

If your product vision is to create a new e-commerce site, your MVP would perhaps include enough to display a list of products, allow users to add them to a basket and then checkout (handling delivery and payment). That’s about it.

Going back to the featured headline image, if your product vision is to create a sports car or a family saloon (sedan), my expectation of an MVP would be a very basic car. It would be drivable, and include the key basic functions you’d expect any car to have (a chassis / body shell, wheels, brakes, steering, seats and a source of propulsion). It’s not going to be a skateboard or a bicycle…


An MVP will not deliver everything you want, its scope is just the bare-bones of your product. Additionally, it will probably not be something you could use commercially (that would be a Minimal Marketable Product – which I’ll cover in another post) or necessarily include everything that you know you’ll need.

Why create a Minimum Viable Product?

There are two important reasons (for me) why I always aim to create an MVP before trying to add all of the “desirements” to the scope of our work:


Creating an MVP forces you to prioritise, with the benefit (hopefully) of reducing the chance of a Boolean outcome – not delivering a working product by the end – and instead creating an outcome spectrum.

It takes an amount of maturity and a good understanding of the product vision, as it’s very easy to create a long list of “must-haves”, but if you don’t learn to chop away at some of the nonessential functions, you may not be focusing on the areas that enable the basic purpose of you product. We don’t have an unlimited amount of time, so what we do needs to occur in an order that reflects any technical dependencies, as well as business priority. A great satellite navigation system isn’t much use on a car that can’t drive anywhere.

A Learning Tool

Most importantly, an MVP should help you to understand some of the key decisions you’ll need to make – and expose any fundamental challenges in what you’re trying to achieve.

There is no value in creating something that doesn’t meet your product vision, unless it answers some of the questions you’re going to face getting there. Does producing a motorcycle provide any experience that will influence your cars design? Not many of the more important aspects, I’d imagine…

Now, I don’t develop cars as a profession, but I’d guess that some of the elements you’d need to consider early on would be the passenger compartment (how many occupants it needs to carry), how it’ll be propelled (combustion engine or electric motor) and how the chassis and wheel layout interact with the design. When you discover that the size of the battery required to power the vehicle means that something will have to be moved or changed to make enough space for it, you’ve learning something. Something useful.

Thinking back to our e-commerce site, we’d need a way to access our product data and display it. How will our web application connect to this repository? Where do we store our images – are they suitable for the web – do we require different sizes etc? Payment integration may provide its own set of challenges. If your e-commerce site can’t take payments, how important is a search auto-complete feature?

Your team’s velocity is another thing you’ll start to understand. Building the basic elements of a more complex product will help you to assess the overall effort required to reach the product vision – but what you do has to be relevant.

Some elements of your MVP may even be throwaway. You might find that something you’ve developed has a significant shortcoming – enough to merit a return to the drawing board. The lessons learned bring you a step closer to the right solution. Learning about a bicycle derailleur isn’t a useful lesson towards producing a car.

If your product is a car, your MVP is a car. Not a skateboard, scooter, bicycle or motorcycle.

Are all developers equal?

In Scrum, only 3 roles are prescribed; Product Owner, Scrum Master and Developer (Team Member). It suggests that we let go of our traditional roles (and job titles) to form an embedded team, that collaborates and cross-skills.

“All developers are equal, but some developers are more equal than others”

I have spoken to several project and delivery managers who struggle to envisage this approach working in the real world. Their opinion is typically that contrary to Scrum’s idealistic vision, in practice they need to be able to map specialisations (and therefore, roles) into a project team to ensure that the relevant skills and experience are present to set it up for success.

They assert that the hard reality is that not everyone is a “superstar” that is able to generalise (certainly to the standard required) and that Scrum doesn’t work in its purest (or purist) form with team members of varying levels of ability. For example, a dedicated tester may be adept at test-automation, whereas a junior C# developer may lack this experience. Your project will vary in quality and speed of delivery depending on the composition of the team.


I’d be interested to hear how people have addressed (the perception of) this issue and how they try to ensure each of their Scrum teams has the right mix of skills to guarantee success?

Please share your thoughts and experience by posting your comments below. 🙂

Are Agile certifications worth it?

I recently came across this article on InfoWorld talking about “7 agile certifications to take your career to the next level”. I read it hoping to gain some insight on their opinion of how certification would benefit your career. Did they think the value came from the skills you learn from obtaining the certification or are there certain “Agile” qualifications sought after by employers?

Of course, I already have an opinion on the value of Agile certifications from my own experience – and I have to admit a large bias in that area. Now, whilst I’d actively encourage anyone to attend some of the various training courses and coaching sessions on offer to actively learn as much as they can (in addition to their own self-learning), I don’t personally place much value in Agile certifications. Most can be obtained after a short (in some cases, single day) course with a relatively easy exam at the end (many with near-guaranteed pass rates).

I find they’re usually required by companies that aren’t very agile and typically demonstrate a Dunning-Kruger failure to recognise genuine ability in others (and their own lack of knowledge) relating to Agile methodologies, practices and associated ways of working. This is usually evident from the questions they’ll ask you about your Agile experience. Instead of questions like:

  • What are the biggest problems you’ve encountered using Agile methodologies – how would you try to tackle them?
  • What was your role within the team and what other roles were included in the scope of your team’s work?
  • How many teams were working on the same product – how did you work together successfully?
  • What other methodologies do you have experience of – how do they compare?

You’ll probably just be asked:

Are you a “Certified ScrumMaster”?

It may (or may not) surprise you that this simple question is all too often the first (and only) question asked to assess my Agile credentials…

To me, most Agile certifications are purely a money making scheme for the companies that offer them – and are absolutely no guarantee of ability. The fact that a (very) high percentage of them require you to renew your qualification every 2-3 years – without any additional training or assessment – speaks volumes. Take them for what they are. If you can gain a qualification after just a few days training and with no practical application of those newly gained skills, great – just don’t place any more value on that piece of paper than you would for anyone else with a similar level of experience…

Agile team communication

Agile team communication

Encouraging good communication within a team is one of Agile’s key areas of success. From daily stand-ups to pair programming, refinement and retrospective meetings, working in an open and collaborative way is a core tenet of Agile, whichever framework or methodology you subscribe to.

No hierarchy?

Many Agile approaches attempt to instigate flat organisational structures, where everyone on a team is (theoretically) on equal terms. You’ll also encounter evangelists using somewhat counter-productive phrases, such as “no more managers” or “remove all hierarchy” or similar calls promoting the abolition of traditional reporting structures.

In reality, you’ll find that the world (and by extension, all our work) is inherently hierarchical. Even a typical Scrum team has an implicit hierarchy in the form of the Product Owner. Sure, they don’t manage the team in the traditional sense – and in more mature Agile teams, they won’t be dictating what is included in each sprint – but they do have some authority. They get to choose this feature over that, set work priorities, time-box development activity and more – they’re just not micro-managing the technical development.

Scrum of Scrums

When there is more than one team, one approach to coordinate their efforts is the Scrum of Scrums:

With this approach, each Scrum team proceeds as normal, but each team identifies one person who attends the Scrum of Scrums meeting to coordinate the work of multiple Scrum teams. These meetings are analogous to the daily Scrum meeting, but do not necessarily happen every day.

The team member from each team attending the Scrum of Scrums is generally known as the team’s “ambassador”. Interestingly, the role that attends this meeting is not fixed (it could be the Scrum Master, Product Owner or one of the technical contributors). This leaves three important issues:

  1. What is the agenda and knowledge of the attendee – business and technical roles often have conflicting priorities (and an Agile coach / Scrum Master may not understand either).
  2. When there is inevitably some conflict between teams (priority, dependencies, solution architecture etc.), who is ultimately responsible for making those decisions?
  3. Whose responsibility is it to maintain an overall product direction for the teams? What controls are in place to ensure the Scrum of Scrums team is able to reach a (consistent) consensus?

Network approach to communication

In Setchu, instead of using the Scrum of Scrums technique, it uses a predefined two-tier hierarchy. Multiple Agile feature teams are accountable to a single control team (made up of a Product Owner and Product Architect on equal standing):

Agile Programme
Network based communication.

Teams (and any member thereof) are strongly encouraged to communicate informally and often, in a network manner, between each other to resolve minor issues and dependencies. There’s no hierarchy between the feature teams, but they are expected to try to reach decisions both sides are comfortable with, for most day-to-day interactions. Whenever that’s not possible or when a discussion highlights a wider concern, the issue is bubbled up to their (mutual) control team:


The control team is able to offer guidance and make decisions that are in the best interests of the overall product. As this team is a split between business and technical concerns, it is able to provide balanced solutions (and assess the wider impact) to their feature teams.

In this model, each team has clear ownership of its responsibility (and authority). When there is any ambiguity, there is a well-defined, central authority present to resolve the conflict – who are also ultimately accountable for the success of the product.

We are not chickens, nor are we pigs!

We are not chickens, nor are we pigs!

I frequently see Scrum teams continuing to use “Chickens and Pigs” to describe someone’s relationship to the team. Despite the potential negative connotations, I often read new articles and documentation still using this terminology – and there doesn’t seem to be much sign of this slowing down…

Now, for some, it may surprise you to know that the origin of the “Chicken and Pig” terminology was deliberately removed from the Scrum Guide way back in 2011 – yet people continue to use it. So, what do these animal names relate to in the real world of product development?


Not pigs!

This is your Agile (product or feature / “Scrum”) team – the people who will collaboratively work towards the team’s goal. Your team may occasionally include a number specialists, consultants and subject matter experts for portions of your product’s delivery (many scaled Agile frameworks acknowledge these as “secondary roles“). If you participate, you’re a participant – simple.


Not chickens!

This is anyone your team is likely to consult or inform. They may be stakeholders, accountable for the successful delivery of your product, but they are not responsible for implementing it (in the DAD framework, it specifically uses “stakeholder” to refer to someone materially impacted by the success of the product). They could also be the PMO, finance or some other function providing wider governance beyond the team’s “what and how” responsibility. All these observers may have influence over the product development, but they aren’t (actively) participating.


If you’re going to attend a daily stand-up, it should be to participate, not just observe. Stating “I’m a chicken!” when it’s your turn to give an update just isn’t helpful. However, always remember that Agile requires collaboration to achieve its goals – so don’t attend if you’re going to try to dictate your agenda (if you have the authority, communicate your priorities via the Product Owner instead, for them to add to the team’s backlog where appropriate).

Don’t derail the process. Let the team be responsible for the level of detail it needs to be to get things done. Trust them to do their job, while they trust you to do yours.

Clear Responsibility

If we are dismissive of any possible offence or hurt feelings from those involved (poor little Jimmy doesn’t like being labelled as a dirty, ignorant pig), then what is the problem with referring to people as chicken and pigs?

To some, it may sound unprofessional, while to others it may be Zeitgeist. Personally, I don’t like overloading common, well understood words with non-intuitive meanings (and we’re already pushing our luck with “Agile”).
Most importantly, one thing Agile is frequently accused of is obfuscating common sense. That is exactly what these terms were doing – replacing words understood outside of the software development and product management context and creating an ambiguous, industry specific usage. That’s two legs baaaad, we’re not farm animals!

Managing technical debt

Managing technical debt

One common question I hear from teams new to Agile is “How do you manage technical debt?”. Agile is often blamed for producing more technical debt than more traditional approaches – whether or not that’s true, everyone should have a mechanism for tackling it.

What is technical debt?

For anyone unfamiliar with the term, very basically, technical debt is any underlying element of your software that you should rework at some point in the future. Usually as a result of a previous decision or (in)activity that will impact the long-term value of your product, if left unaddressed.

It differs from a change initiated by the business in that it will usually be something either imperceptible to anyone non-technical and / or not involved in the technical implementation of the product (or certainly not obvious).

Ward Cunningham, credited with coining the term, describes this concept in the following way:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

He refers to object-oriented programming, but you’ll appreciate the concept applies universally, regardless of paradigm.

Unplanned technical debt

Unplanned technical debt is usually the consequence of external change, time pressures or a lack of understanding.

For example, maybe you produced a service that made heavy use of a rate-limited external API, on the assumption that your expected traffic volumes would never approach close to that value. Then, your product is a runaway success and you end up with more traffic than the rate limit allows, degrading performance.

Another example could be that your project made use of a UI library to produce your website, but now there are newer browser versions that the library does not handle, breaking layout and functionality in modern browsers.

You may have written an inefficient search algorithm, as you had to produce something very quickly at the time – but with further optimisation you could save significant server resources, needed for other processes going forwards.

From personal experience, I’ve had situations where I’ve discovered a much more elegant solution to a problem after the fact (where refactoring would improve pace of change and customer experience), towards the end of a project.

Planned technical debt

Sometimes you just have to accept that being able to produce something fast is occasionally better than (pro-actively) spending additional time on quality. For example, it’s quite valid to attempt to prove a concept in the quickest way possible, usually to answer an unknown factor (“will this work?”), over longer-term concerns.

This could result in things like a conscious decision not to include logging or perhaps you chose to skip adding any build automation, knowing that they would both be useful longer term. The key points with this approach is that the team has agreed the priorities, potential impact and any mitigation up front – the consequences of the situation are understood. As long as you address the issue later (or make a conscious decision to live with the issue), based on the business value balance, that’s fine.

When planned technical debt becomes particularly unhealthy, is when it emerges from a pressured, one-sided source – instead of as a natural result of collaborative effort. In Agile teams, this is usually the result of a dictatorial (bad) Product Owner – or someone else able to pressure the team into focusing on non-technical priorities, over the team’s overall agreed priorities. You could argue this is actually unplanned debt – but that divorces the responsibility from the stakeholders, who ultimately need to acknowledge that they have chosen this path.

The danger here is that the potential consequences of this type of technical debt are not understood. That’s a risky place to be – unbounded problems have a tendency to spread quickly – akin to spending on a credit card with no limit (and no one ever checking the balance). If your technical debt exceeds the value of the product, you’ve failed.

Balancing value

Successful software projects eventually need to achieve a level of balance between business functionality and technical architecture.

Too much focus on either side is not good. Businesses tend to focus on tactile features over practicality, while development teams want to produce academically elegant solutions that no one may actually want (or simply spend more time on it than the business value justifies).

Regardless on the cause of the debt, the way you tackle technical debt is largely the same. The team needs to prioritise effort together.

If your backlog refinement meetings are genuinely collaborative then you’d ideally have discussed and agreed your prioritisation of work to include a balance of business and technical needs – minimising debt in the first place.

While that may be the ideal, striking that balance isn’t always very successful, for a variety of reasons. Additionally, unplanned technical debt is a constant unseen threat – and it can build up at any time, even with the best of intentions.

Newly discovered technical debt should be bubbled-up (flagged) so that it can be addressed by the team. This means adding a story to the backlog with a description of the problem and optionally including a proposal to resolve it. When your backlog refinement meeting (grooming) occurs, you should have a mechanism to trigger triage of new stories, prompting a discussion about the issue. From there, your technical debt becomes like any other story being groomed:

  • Flesh out the requirement – is it a problem?
  • Break down any large chunks into smaller, manageable activities.
  • Agree the acceptance criteria for it to be considered resolved (done).
  • Prioritise based on the value to the product / feature.
  • Add the stories to the appropriate sprint backlog.
  • Review your balance of priorities again at the next planning session.

That’s it – when you become aware of technical debt, flag it by creating a story to represent it, let the team decide when and how it needs to be tackled – then deliver on your commitment.

Common problems adopting Agile

Common problems adopting Agile

Agile is not a silver bullet – despite what many claim. Agile doesn’t magically improve delivery, but it can bring significant improvements if approached in the right way. Let’s take a look at how not to introduce Agile into your organisation.

Beware of Waterfall in Agile clothing

I’ve found on many occasions that when a business issues a diktat that they will now implement Agile, it can be difficult for them to make the conceptual shift. Sometimes they’ll (unintentionally) keep their existing structure and processes and simply go through a renaming exercise instead. However, as we well know:

  • The Scrum Master is not a project manager
  • The Scrum Team are not all developers
  • The Product Owner should not be a business analyst

So, if you have simply filled new Agile roles with the nearest equivalent traditional job title, there’s a strong chance you haven’t changed much about the way you work – instead you have simply renamed your current methodology to sound more “Agile”.

You’ll also see projects become “epics”, requirements may become “stories”, meetings are suddenly “stand-ups” and planning is now called “grooming” – but has any of this your improved your output?

Evangelists cause issues

Once a decision has been made to become “Agile”, an early step embarked upon for many businesses will be to recruit an Agile specialist. There are a two important issues with this approach:

First, these specialists are often aligned to one specific methodology (we’ll discuss that later). At worst, they will apply it dogmatically, without the pragmatism required to effect change in some larger or more traditional organisations.

Second, the criteria for recruiting these specialists is often that they have a relevant Agile certification, as that is the only way they have of assessing a candidate’s Agile credentials. For any methodology to be successful, sufficient practical experience is required. This doesn’t come from books or (one-day) courses.

Don’t default to Scrum

Scrum is Agile, but Agile is not Scrum. Scrum isn’t the only Agile methodology in town (even as I often default to using Scrum terminology…), yet it’s often adopted without any consideration about what it actually provides and what limitations it may have.

Scrum may be the best-fit for your needs, but you should always perform some analysis based on the specific situation you’ll be working in. Furthermore, don’t fall into the environment / scalability trap. All too often, I’ve seen Scrum trialled isolation, with a small independent team, then it gets rolled out across a much larger organisation with several teams (and their complex dependencies) thinking that it will just work. It very often doesn’t.

Each software methodology has its pros and cons – what looks good in theory may not be as successful in the real world. Try some out.

Narrow scope limits change

The most common mistake when trying to become more Agile, is that changed practices are only applied to the technical phases (usually just build). Requirements are still gathered up front, then there is a design phase. After the now “Agile” build phase, a test and release phase follows and so on. This is a red flag that you’re actually using a sequential methodology (like Waterfall…) instead of an agile methodology.

This is a problem because you’re going to be severely limiting the potential benefits that can be realised by adopting a more Agile approach by constraining the scope of change in this way. As many businesses eventually discover, the build phase is often the least of their problems when it comes to successful project management.

Sometimes other phases are actually included in the “Agile” scope, but they will occur in an isolation fashion instead of collaboratively. The scope of a Sprint is dictated by the business and Scrum Master (in private), rather than agreed by the team.

Divorced responsibility

Another pseudo Agile anti-pattern is “pushing (problems) over the fence”. This will typically take the form of the business expecting the Agile team to deliver requirements that haven’t been articulated or even formed yet – and then not being involved in the activities designed to find them out.

Issuing requirements akin to “whatever it does now” also demonstrates a distinct lack of stakeholder engagement. The business needs to take responsibility for ensuring their team has a complete understanding of their expectations if that is what they hope to deliver. Collaboration is one of the most important aspects of Agile and can be the most difficult culture to change.

Effective backlog refinement meetings

This video from CollabNet provides a great insight into how a model backlog refinement meeting should be run (and how it shouldn’t…).

Importantly, although not the primary aim, the video also demonstrates Agile collaboration and negotiation done right.

This is exactly the right attitude towards Agile development:

Originally sourced from http://scrummethodology.com/scrum-effort-estimation-and-story-points/

Are you authentically Agile?

“That’s not Agile” is a phrase I’ve often observed, usually from people espousing specific methodologies. What they usually mean is that you’re no longer following a specific approach exactly as written. That may be a good thing…

Whatever Agile software development methodology you have adopted, if you want to claim you’re being (authentically) Agile, you should be honestly subscribing to the following principles. Ask yourself if your ways of working are:


Agile responds to change pragmatically. It tries to adapt rather than relying on prediction, acknowledging that some things may not (or cannot) be known in advance.


Agile aims to reduce uncertainty. It achieves this by taking small steps towards its overall goal rather than multi-phase delivery.


Agile uses evidence to make informed decisions. It changes based on what has been produced or discovered along the way.


Agile’s success is based on working together, with shared responsibility. Everyone needs to understand the goal and how to contribute as a team, to reach it successfully.

That’s it. Moreover, being Agile means that while you value those principles, it doesn’t mean you’re bound by them in all situations. You should respond to changing situations, different circumstances and constraints. That’s being agile (the adjective) and that’s being authentically Agile (the noun).