Agile in Practice

Within the software engineering discipline, we're just as susceptible to fashion and trends as elsewhere - and this is apparent even at the so-called "soft topics" such as process methodologies and practices. In the following I will dive into what is Agile and what is not and call out organizations naive belief that they are Agile just because they make use of the Scrum framework and User-Stories. Last but not least, I will include some practical advice that I have come to make use of myself over the years picked up from industry leaders and my own experiences.

Definition of Agile

Agile is starting to get a bad reputation, but that's mostly because of its misuse and abuse. First and foremost, we must remember that agile is not really a software methodology per se, but is actually just a set of core values and principles as defined by the Agile Manifesto which was formulated in 2002 by 17 reflecting pragmatic software engineers over a weekend in a cabin in Utah. It simple states that we should favor:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Diving a bit deeper into these principles, the Agile mindset recognizes that the construction of software is complex and unpredictable, and attempts to make the best use of our time/money while continuously providing the most value through actual working software. The careful reader will soon start to ask "...but value to whom, the stakeholder or the end-user?". While not mentioned directly, it's implicit that customer value = business value based on the premise that happy customers translates to opportunities and value for your business.

The whole Agile movement is of course a reaction to the waterfall mindset, where we would try to make fixed deadlines through defined phases based on non-negotiable requirements. In Agile there are no phases per se, but rather lots of small iterations where we learn and adapt.

Intelligence is the ability to adapt to change – Stephen Hawking

Last but not least, is the desire to keep things as simple as possible, and take away anything non-essential that doesn’t actually add value. There is a cost to every feature added and the cost rises more than linearly with each feature. If you are a developer, I need just to mention cyclomatic complexity and you know exactly what I am referring to.

It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away - Antoine de Saint-Exupery

This is not a black or white topic of course, over time much development has generally moved from phased through evolutionary to Agile. The key issue to ask your organization is probably, have we adopted enough of the Agile mindset and are we capable of adopting more to further maximize our return of investment? It's the principles that are important, not the process - indeed many of the same principles of Agile can also be seen within Lean Thinking (from manufactoring) and Design Thinking (from UX).

Unfortunately, I believe many companies are a bit too fast in their claim to be Agile. You aren't necessarily particular Agile just because you write your requirements in a JIRA backlog and have adopted the Scrum framework or perhaps even invested in large SAFe setup. To be truly Agile, you must take a holistic rather than dogmatic approach to software engineering where you are true to the values and principles of the Agile manifesto! In essence, your business needs to be value-driven (users in the drivers seat) rather than plan-driven (cost/schedule in the drivers seat) and empower the implementing team with the necessary game of ping-pong! In a typical Scrum setup, this can be condensed into a single statement:

Deliver an improved working product every Sprint and go from there

Whether you can do that in practice, and to which degree, greatly depends on the organizational setup and project type.

Organisational setup

It's fairly common to see IT or R&D departments struggle with Agile. They may be doing everything right but without backup from the rest of the business - and so the Agile only lasts until another order or command is received from above. Even organizations adopting SAFe can struggle in this regard, perhaps having most of the business owners in line with Agile values and principles, only to have their mandate overthrown by some C-level individual who feels strongly about a particular matter. This is unfortunate and happens primarily because customer value isn't seen as business value and focus is on feature quantity rather than feature quality.

So your whole organization really needs to support being Agile or you will never truly reap all the benefits. This is because planning and decomposition are really two sides of the same coin and one inherently impacts the other. An Agile organization may still live under a classic hierachical structure, but it understands that the top operates on high uncertainty/risk; and is ready to respond to challenges when they bubble up from below and tweak their strategy accordingly.

SAFe and Scrum@Scale are gaining growth. And while they definitely try to address a real problem in that being agile only in the IT department is a fallacy, they too are misusing the core values and principles of Agile - probably for commercial/capitalistic reasons first and foremost.

While Scrum is a framework for collaboration and i.e. has no mentioning of either features, epics nor user-stories - SAFe is trying to turn Agile into a process or methodology by mandating composition and steps.

At the end of the day however, unless you iterate, fail, learn, slice, experiment, simplify, evaluate, adapt etc. you are not really following the Agile principles and values - regardless of what that fancy certificate says in your inbox!

My advice is to stop emphasizing the Agile Transformation process frameworks and start focusing on the company culture and mindsets - Selena Delesie

Project types

While developers do write software out of their own pleasure, there's usually some professional relationship in place where software is traded in for salary; be it a customer, client or boss. Let us briefly sketch out a few different project types, because this aspect is fairly significant in the context of Agile.

• Startup - In many ways similar to In-house, with the twist that there's a brutal focus on shipping early and with the right amount of features "disrupting" the marked. Communication, documentation, QA are the first to suffer when money or patience start to run out and the amount of stress rises. It demands long hours and a level of dedication probably most suited for either the junior developer with no obligations and little to loose, or the senior developer who already assured himself a sane financial buffer and who probably already went through establishing a family etc. Shipping is king so the release cadence is often quite high, once an MVP (Minimal Viable Product) or enough MMF (Minimal Marketable Features) have been achieved, often hardened from previous POC's (Proof Of Concept) and/or a Walking Skeleton. This is the perfect project type to apply an Agile approach on.
• Tender/contract - Project carried out by entire teams from various companies fighting to win and run the project for some specified outcome or goal. BAE Systems, Thales, Lockheed Martin, Systematic etc. are example of large heavy organizations taking on tenders. Such a contract usually stipulates delivery of a certain amount of features at a certain date. Here it's all about balancing risks between expectations between having won the contract (proposal delivery) and the actual implementation (software delivery). Sometimes it's only fixed price, other times its fixed scope but usually it's both. Because of it's all-or-nothing nature, the release cadence remains quite low in the order of quarters and years. This creates a lot of challenges for using an Agile approach and I have especially strong opinions about this type of project, which you may read more about here.
• Commercial services/products - project carried out by a software company by a designated development team for direct sale "shrink wrapped" to businesses or end-users. Oracle, Microsoft, Google, ADOBE, SAP and similar behemoths fall into this category. Since in the last decades much "shrink wrapped" has now moved to services online, the release cadence is often measured in weeks or months. For this reason, these project types are also well suited for an Agile approach although it requires a significant QA pipeline investment to back it up.
• In-house - Project carried out internally at a company by a designated development team in support of the company's primary operations and means of creating revenue. Some companies or institutions rely 100% on this form, some do it only for their core business operations and supplement with consultants and tenders/contracts. Boeing, Siemens, Deutsche Bahn, Tesla Motors etc. all have in-house development departments. In the 70's and 80's this was the dominating type and the release cadence was often measured in quarters or years, though less so in this day and age. These project types are well suited for an Agile approach even if one has to understand that the value proposition can get a bit murky as the customer chain is often transitive on multiple levels. For some projects within in-house development done at companies like Google etc., agile thinking even has problematic elements which are too centered around short-term thinking (Scrum/Kanban/MVP) for working on revolutionary engineering projects. While much within the agile principles boil down to common engineering sense, some of them are not so well suited to software which has a very simple interface and tons of hidden internal complexity not easily mapped to a feature or user-story. Computer games also tend to fall into this category where internal iterative delivery may indeed take place, but not shipped to end-users until complete and satisfying the whole product vision.

When it comes to constructing software, the project type has a lot to say about the decision making process which leads on directly into the topic of planning!

When preparing for battle, I find that plans are useless, but planning is indispensable - Dweight D. Eisenhower

Planning

In the old days, using waterfall methodologies and phased development plotted into Gantt charts, it followed naturally that before we could test, we had to write the code, and before we could write the code we would need to design it, and to be able to come up with a design, we would need to analyse the requirements which we had previously elicited.

While it looks great up-front on a Powerpoint presentation and gives a nice illusion about predicting the future, few real-world projects fare well under this naive and stringent setup.

Indeed, history has taught us, as pointed out by the Agile manifesto, that you can't do long term planning with any degree of certainty or risk control. Steve McConnell refers to this as the Cone of Uncertainty but I tend to think of it as an S-shaped chart.

So you may look at your "must-win-battles" and do high-level estimation up-front, but don't try to map it to calendar time. If you do so, chances are you are going to need a 4-5 Sprints just doing the analysis - and guess what, then you have just reinvented phased development!

Some do take Agile a bit too far though and assume that within the Agile mindset, no planing is possible nor needed. Indeed, in the early 10's we even saw an No-Estimates movement. It follows fairly naturally, that if we don't estimate, we can't really plan either! In order to secure budgets and human resources, often we still do need some high-level planning.

The key thing to notice about Agile though, is that planning should not be done just once, nor just be done at one level, and that there are inherent differences to the operating precision of the associated estimates. If an estimate is just a guess, we want to be able to turn bad guesses into good guesses and in Agile we do that by updating our guesses all the time.

Your organization probably has an overall strategy and roadmap to back it up. Below the C-level, a SAFe setup would then introduce the planing level known as a Program Increment (PI). A PI itself consist of some no. typically of Sprint iterations. Even a daily standup meeting is in some way a planning meeting, where you will often coordinate with your colleagues regarding an activity. The difference here is first and foremost the degree of certainty and precision.

An Agile organiztion will know not to let high-level estimates somehow become a locked plan turned into hours and dates, and operate on suitable abstractions. This means planning is strategic and with a prioritized vision based on go/no-go cost-benefit analysis. Further down at the product planning level, decomposed into epics of a Program Increment (PI), dates may start to appear on the radar. However, only when the team is allowed to refine user-stories (the what?) and ultimately break down into tasks (the how?) can we realistically look at fixed calendar dates and do release planning.

Of course, the most mature Agile organizations (Spotify, NetFlix, Google etc.) don't even do release planning but instead operate on top of a automated feedback-loop, where they release to production constantly (Continuous Deployment) and monitor/react (DevOps) feedback, often utilizing A/B-testing for validating which experiments brings the most value and then promote these to 100% deployment.

Most organizations can't really do this for political (coordination) and practical (legacy systems) reasons but can still achieve a potential release (Continuous Integration) where deployment is just the click of a button.

Fixed time

If faced with a hard deadline, Agile becomes all about focusing on delivering the best thing possible in a set time period. We do this by looking hard at the requirements, simplifying where possible and prioritize. On paper, planning just becomes as simple as:

1. Determine no of iterations (Sprints) which can fit
2. Estimate velocity (Points/Sprint) for the executing team
3. Multiply the iteration count (Sprints) with velocity (Points/Sprint) to get to the capacity to prioritize from the project backlog

So if you have a deadline by some date, you can convert calendar time into an iteration count (say 8), use yours teams story-points per Sprint average (say 25) and multiply those to infer that feature work for about 200 story-points can be delivered by that deadline.

Fixed scope

If faced with locked down feature set, say an MVP or MMP, we modify the equation a bit and thus arrive at:

1. Add up the backlog story-points (Points) making up the desired features
2. Estimate velocity (Points/Sprint) for the executing team
3. Divide the sum of backlog by velocity (Points/Sprints) to get the time needed.

This really isn't much different than fixed time, except this time around we put the uncertainty range on the time axis. So if you have a fixed scope of say 250 story-points, and your team has proven to be able to deliver about 25 story-points per Sprint, then you're looking into 10 sprints which can be mapped to calendar time.

Fixed time & scope

One of the hardest problems to deal with, is that of fixed time and scope, since this is directly at odds with many of the Agile principles and values. If faced with fixed time and scope, you are screwed and you should be very careful at applying Agile to it anyway.

You will have very little legroom for adapting and you'll be stuck at the nasty corner of the project management triangle - thinking about ways and costs of scaling up resources.

However, if you think you can just scale by adding resources naively, you ignore factors such as communication overhead, team dynamics, solution coherence, code quality etc. and it's usually a recipe for trouble.

It follows, that you must have a stable team with a known velocity. It may be used to estimate staffing for an entire project if you have the guts to do so (hint: not really Agile), but where it truly excels is in filling the Sprint backlog and avoid pulling in too little or too much. Nobody likes never making the Scrum goal because it's always too full and nobody likes spending 5-6 hours over-planning for multiple Sprints.

In a bidding situation, your best bet is probably to try to nail down the most important features to the fixed part of the contract and model the remaining as options on top. The commitment risk is still there, but at least you've added some handles to utilize later on while not being dismissed on the grounds of incomplete capture of requirements.

In a delivery situation, your best bet is to look for the largest composites of the system, letting different teams have a go at these and hoping that the final integration efforts won't be too demanding.

Requirements

Regardless of the process methodology and working framework in use, to various degrees, we still need to elicit, analyze, prioritize, track, version and verify the underlying requirements for our software. This activity has never been easy, but it's so fundamentally important in order to get a successful outcome where software has been delivered to the satisfaction of stakeholders.

If we consult the Agile Manifesto, it ignores the subject matter entirely and one might almost infer something like "There shall be no requirements document, only working software and happy people". It sort of makes sense, in this day and age, even writing comments is considered bad practice (refactor the code for clarity instead says i.e. Uncle Bob) and the ultimate documentation for a piece of software is of course the actual source code itself which is guaranteed to never fall out of date.

A comment is a failure to express yourself in code. If you fail, then write a comment; but try not to fail - Uncle Bob

However, although the Agile Manifesto remains mute about it, in practice we do of course need requirements. While it can definitely work well on small projects to just handle requirements ad-hoc over email, phone and other meetings, this approach seize to work the moment there's a difference in expectations or functionality, and we all know the human brain is far from flawless. Most corporations thus make use of JIRA or a similar issue system to track requirements in a project backlog.

If you analyze the source code for any substantial software project, you are likely to see cyclomatic complexity numbers shoot through the roof. Even the most skilled developer utilizing all his knowledge about language constructs, patterns and practices, will introduce branching and side-effects as a result of complex, messy and interrelated requirements within the software. That is the nature of our business and the best we can do is to lay down the appropriate abstractions so that we may bury the various messy bits and pieces in a designated black box with a big fat lock on it. Actually, that's not entirely true - the BEST we can do, is to just say no and make the business understand (and react to by simplifying) how complex software means more buggy applications which are harder for a user to figure out - but that's an entirely different story. ;)

Do the simplest thing that could possibly work - Ron Jeffries

In the old days, we would try to document requirements using extensive prose buried in vast nested hierarchies of bulletpoints. This is still seen today and it makes sense to some degree to start out like this, but it's sure to break down over time as the software develops, the world changes and the requirements mutate accordingly. There's even an IEEE standard for this (830-1998) which states that requirements should be Correct, Complete, Unambiguous, Consistant, Prioritized, Verifiable, Tracable etc. The main problem is of course how it requires an enormous analytical effort, discipline and skill to nail down such a document for readily use by a development team - and in no way does that guarantee a successful end-result. For more on this, you may read what I have to say about fixed-price development.

User-stories

So even if we in the Agile mindset don't write a 200 page requirement specification, we still do need to hold a firm conversation about features so that we know what the software should do. All hail the lightweight concept of a user-story! I see it as a practical successor to the more theoretical use-cases on the late 90's, and the idea is simple enough of course; express some functionality as seen from a defined user, associate criteria for when the feature can be considered complete and let it be tracked as a conversation piece in a project backlog which can be further refined, prioritized, estimated etc.

INVEST

User-stories should be approached using the INVEST mnemonic, that is a good user-story should be:

• Independent - ideally not depend on other user-stories
• Negotiable - not be set in stone but be allowed to mutate as we get smarter
• Valuable - provide value to the end-user or product
• Estimable - be understood good enough to be able to hold an estimate
• Small - not be so large it can't be completed within a sprint
• Testable - contain criteria for how and when its considered validated

To me the beauty of user-stories revolves around their headline characteristics and how they can and should be molded for simplicity. If there is one universal thing I have seen over the years in the industry, is that small and simple is king - if and when you can get away with it. For this reason I am especially fond of user-stories and user-story mapping since it forces you to think about delivery milestones and priorities.

How do you solve big problems? Start with a smaller one.

SPIDR

What often happens in practice, is that user-stories turns out to be quite tricky to break down accordingly - especially the independent part can be troublesome. Mike Cohn has some valuable insight in this matter and introduced us to the SPIDR mnemonic:

• Spike - A research activity can give you the knowledge you need to split a complex story. A Spike is usually just some time-box within a sprint to be used on a topic and can be a good idea if a story can't readily be broken down further but is still associated with very high uncertainty. Spikes should be the last resort if there are no other way of breaking down a story.
• Paths - If a user can do something in multiple ways, that’s a great area for splitting. You're probably already doing this implicitly, by neglecting to account for various alternative paths/branches in your logic handling error-conditions. Even if some feature only supports the golden scenario and not yet shippable, it's still valuable progress to the PO to be able to get a feel for it.
• Interfaces - Splitting your story by browser, or hardware, or deliver a complex interface in iterations. A mobile friendly, or printer friendly rendering of a report is one such example as are Mobile Phone platforms.
• Data - You may be able to deliver value in an iteration by focusing on a lacklustre or subset of data sources rather than everything at once. This is particular useful when working with legacy systems, where the chance that you will get access to everything needed without issues, is slim.
• Rules - Relaxing support for the rules in an iteration can make large stories smaller. Business rules or process criteria may be simpler to begin with, in an effort to poke a hole in the subject and do a first iteration. Even if not deemed shippable by the PO from a marketing perspective, the goal of a sprint is to get to potentially shippable from a technical perspective.

Simplicity - the art of maximizing the amount of work not done!

Connecting the pieces

So breaking down stories is great, but you are then likely to get to the challenge of managing inter-relationships. Although INVEST states that a user-story should be Independent, that's not the same as saying a user-story can't build upon another. How to go about this depends a lot of your issue tracking software and your own preferences on the matter. I'm colored by having worked with several methodologies over the years and JIRA, so I like to think of a hierarchy of Epic > Feature > Story > Task and crosscutting Themes.

• Feature - Very large body of work for "go/no-go" analysis, POC work etc.
• Epic - Large user-story, good for overall initial analysis and refinement of user-stories under
• Story - Appropriate functionalty written as a user-story that satisfying INVEST and SPIDR (completed within a sprint)
• Task - Tasks are the smallest unit used in scrum to track work and can be considered a concrete TODO item needed to implement a story. Ideally this is small enough to be completed within a day, such as to avoid "I'm doing the same as yesterday" situations at the daily standup and allow the Scrum master to step in to remove an impediment or other team members to offer their assistance.
• Theme - Crosscutting non-functional aspect which has no lifecycle associated but runs through the project (Accessibility, Security, Localization etc.)

Out-of-the box JIRA only support 3 layers of the hierarchy (Epic > Story > Sub-task) so you have to use the Portfolio plugin or Structure plugin to represent more levels such as Feature > Epic > Story > Sub-task.

Agile Do's

• Do make use of a user-story template. It's not important which template variation you make use of, but by being forced to think about the who, what and potentially why, you formulate a short yet informative requirement as a headline. This ensures that the requirement becomes a placeholder or conversation piece for further clarification. It also brings the actual end-user in focus while helps to filter out technical tasks and non-functional requirements.

As <who?>, I can <what?> [so that <why?>]

• Do take the time to define your user-types, user-role or personas; how can you develop good software if you don't have a concrete user in mind? If you write "As a user..." chances are you have some work to do here. Occasionally I have seen this to be tricky because the system may have too many users, but even in this case, there still are some archetypes users making up the predominant user-base of the software which you should cater to (think of the Pareto principle, 80% of the system is probably used by 20% of the user-types). There is tremendous semantic value in being able to read the title of a user-story and know exactly what kind of user it's referring to.
• Do break down stories to tasks. The larger and more complex something is, the harder it is to reason about. By having to break a user-story (a requirement) down into workable tasks (TODO's), you are forced to reason about the actual work needed by the developer - a database change might be needed, a migration script is probably also needed then, a query has to be optimized etc. all serve to drive down risk even further and go from a relatively fluffy concept of story points to a more concrete unit of time.
• Do hold and vary your retrospectives. This is where we look back, reflect on what we might do better and try to improve it the next iteration - which is the essence of Agile! While this can sometimes become just a complaining meeting repeating the previous retro and with developers trying to escape it, doing so is missing the point of Agile. For this reason, retrospectives should never be done quite the same way each time.
• Do include Acceptance Criteria on your User-stories. Not only will it facilitate estimating and potentially splitting, it is necessary to write the test cases. A big bonus on top is that it becomes are run-book for the demo part of a Sprint review.
• Do try to document your requirements (Acceptance Criteria on your User-stories) through test-cases. In practice, test-reports documenting flow and behavior can bring tremendous value to both the client and customer as it removes much ambiguity. Furthermore, you are able to trace back to exactly where some behavior received its stamp of approval.
• Do dare to question the business who tends to equate software features with user value; simple software is good because it's caters to usability, maintainability and a whole lot of other non-functional requirements. The Agile manifesto has a good definition but my preference remains the one from Antoine de Saint-Exupery, who states "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away".
• Do create cross-functional Scrum teams. Just like we do away with phases in agile, we also do away with functional silos in favor of ease of communication. This means that in order for a Scrum team to be successful and deliver on their mandate, they need to have ALL required resources at hand and available within the team. Beyond developers, this includes business personel (PO), testers and UI/UX.

Agile Don'ts

• Don't think of a Scrum cycle as completely independent. In practice, Scrum cycles needs to overlap at the analysis/refinement level and even better, there needs to be some overarching business unit planning when several teams are involved. Jeff Sutherland talks about Scrum A, B and C for maturity here, where too many stay within a type A neglecting to do proper refinement for the next Sprint. In recent years we see type C popualized as Scrum@Scale, SAFe etc.
• Don't force everything into it a user-story template. I.e. "As a developer, I want the database to be transactional so that I may obtain consistency". This is actually a technical design decision (non-functional requirement) and thus belongs in Definition of Done. Writing a story on this form violates several of the Agile principles, as it is not end-user centric at all. It also tends to create bottlenecks and deadlocks, as a technical pre-requirement. If there is no end-user in play or the result can't be demoed at a sprint review, it's not a user-story!
• Don't think of agile as no planning being needed. The difference in agile is that there's a focus on planning iteratively (again and again) and relatively (new story A vs. completed story B). If you go into a sprint without having thought about what has to be achieved, what you are really doing is Scrumban - a hybrid that emerged from teams who continued to add value, but failed to do so by fixed increments (Sprints) due to complexities and unknowns.
• Don't estimate stories using a time metric for story-points, because it will inherently and automatically be translated to calendar time somewhere. Remember that an important trait about stories is to be able to gauge relative effort/complexity, and especially to determine whether something needs to be broken further down to reduce ricks. For this reason, I prefer using T-shirt sizes (XS, S, M, L, XL, XXL) since it tends to bring down the time needed for the planning session. You can still operate with story points, just assign these numbers to the T-shirt sizes and account for the Fibonacci skew (I.e. 3, 5, 8, 13, 21, 34). Let time (hours) be reserved to tracking at the task level where it belongs and can provide velocity data for the Scrum Master (I.e. a medium story takes roughly 12 hours) while not making developers believe they have to be 100% correct when estimating.
• Don't break up the team into smaller ones for doing pair-grooming estimation. It's unfortunately commonly seen that managers try to optimize by parallelizing analysis and estimation activities, but it's a dangerous practice for multiple reasons. When you do take the time to estimate, you do so to arrive at the best possibly guess at the given time. This is NOT done by disqualifying potentially important members of the team nor by limiting the no. of data-points that make up the estimate. Remember in Agile it's the conversation and aim at developing the right thing and the right time that matters. It's fine and even expected for individual developers to carry out refinement activities before the planning meeting, but all team members should understand the commitment of a story and have a say in its estimation.
• Don't refer to the first sprint as sprint 0. This can be observed as managers claim "Please wait as Sprint 0 will set us up for success in later Sprints" which quickly extends into Sprint 1, 2 etc. See the problem here? It essentially introduces a preparation phase, conflicting with the core of Scrum, which seeks to deliver an improved working product every Sprint.
• Don't refer to Sprint demo but instead Sprint review. While showing the product-owner and other business stakeholders the progress of the actual working software is paramount, it's not the only activity at the end of the sprint. Equally important is the associated conversation and ability to respond to change from the stakeholders who just saw the new features. It is essentially the final acceptance gate from the stakeholder, either a feature is deemed ready for shipment/release or it needs further work.
• Don't make multi sentence Sprint goals. If you do this it's a strong indicator that there's too much work in the Sprint and/or a lack of focus. A Sprint goal should be clear and concise. What tends to happen is that lots of stories gets started while nothing gets finished, because the focus is too broad and thus not refined enough. Beyond the fact that context-switching is difficult and has a cost, you're also going to have a very hard time doing a burn-down chart which shows how many stories are completed rather than how many stories are started. Last but not least, any attempts at figuring out a sane velocity number becomes down right impossible.

Stop starting, start finishing

• Don't wait for the Scrum master to ask at the Daily Standup meeting. If nobody starts on their own, ask someone to start. This helps to drive self-organization and empowerment. Daily Standup is not a reporting meeting, it's a synchronization and facilitation meeting.
• Don't wait for a sprints planning meeting with writing product backlog items. When you write the new sprint’s product backlog during the planning meeting, you do not give the product owner meaningful time to think about which items are most important for the team to begin working on immediately. Similarly, writing product backlog items in the sprint planning meeting gives the team only whatever time is remaining in that meeting in which to ask clarifying questions about the items before the sprint begins. Stories should be written by at least a couple of days before the planning meeting.
• Don't confuse Sprint capacity (points) with team velocity (points/iteration). Velocity is the amount of work that a team is capable of within an iteration based on some long-term measurement for a stable known team. It bounces up and down a bit, so only really useful to talk about an average here. The best way to judge a teams capacity is to look at its past velocity. You simply calculate an average from previous iterations, throwing away 10% of the lowest and 10% of the highest data-points. Only by knowing both the velocity (points/cycle) and capacity of next sprint, can you actually derive meaningful and accurate expectations from the team!
• Don't let the same person wear the hat of project manager and Scrum Master. They have two very different roles to play where the manager caters to the customer and the Scrum Master to the team. It's very unlikely a team will ever self-organize or be open in retrospectives under such a setup.
• Don't assume work hours to be 100% efficient. Unplanned meetings at the coffee maker, helping out a college, context shifting all add up over the course of a day. Time estimation typically comes up during planning where stories are split into tasks, though not all teams do this. So if you are going to factor in time anywhere, you will want to work with effective time, and typically that's 6 hours rather than 8 hours.

Environmental setup

An often overlooked aspect that often hits organisations trying to embrace agile concepts, is having the appropriate flexibility from operations and being able to access and manage environment and supporting infrastructure (databases, services). What's often seen, is a fairly static environmental setup on a form like this following:

Development ► Test ► UAT ► Pre-production ► Production

Any seasoned developer will immediately recognize problems associated with such a naive pipeline. In reality, the coordination needed for this to work in larger organizations creates such overhead and frustration that it can paralyze progress. What's actually needed to be able to move fast following the agile mindset, is a fan-out at the lower layers - ideally containerized (Docker/Kubernetes) or virtualized at an epic level.

Development ► Test ► UAT ► Pre-production ► Production

Development ► Test ► UAT

Development ► Test ► UAT

Development ► Test ►

Development ►

At the lower levels, new environments should be possible to spin up in a matter of minutes - in the mid levels integration and coordination needs to take place moving up the QA pipeline on the way to production. This notion is also captured by Release Trains of SAFe, although what tends to happen in practice is that there are still a fixed (read: not enough) no. of static development and test environments to support agile development.

Conclusion

So there you have it. I am not an Agile leader, nor am I even an Agile coach - but I have seen my share of projects over the last 20 years to have formed a strong opinion on the subject.

Far too many organizations claim to be Agile, when in reality they are not. I hope more organizations in our industry will eventually go all-in as they realize that only catering to the user and providing value and RoI, will your business be as successful as it could be.

Last but not least; just say no to fixed-scope on a fixed-price - it barely works for building a house (which I just had done) where unknowns are small but it definitely doesn't work for constructing software where unknowns are huge!

References

I've been inspired by a lot of people over the years, but these 3 gentlemen stand out to me as particular valuable when it comes to process and practices.

• Mike Cohn: https://www.betteruserstories.com/
• Steve McConnell: https://www.construx.com/
• Mark Shead: https://blog.markshead.com/

The usual disclaimer applies here, the above does not necessarily reflect the views of my employers but by me as an individual.