Why, would you think, are we (oh!) so agile? Why do we do Kanban or Scrum?
a) To have more fun? b) To become a better team? c) To follow industry standards?
„Take a wild guess!“
Laury Anderson
It is neither of it. To give you a hint, I quote the very first Google hits for „purpose of agile“:
To me, agile is all about embracing change to make our customers awesome.
Jezza Sutton in https://www.quora.com/What-is-the-purpose-of-Agile-and-why-are-so-many-companies-using-it
It puts more emphasis on creativity and innovation that is needed to maximize the business value of the solution
Chuck Cobb in https://www.quora.com/What-is-the-purpose-of-Agile-and-why-are-so-many-companies-using-it
Go down the list of all the most successful companies. They are all delivering products faster, better, and cheaper than the competition because they are Agile…
Jeff Sutherland in https://www.quora.com/What-is-the-purpose-of-Agile-and-why-are-so-many-companies-using-it
Got it? Good. So, let me summarize it. In the software industry we are Agile, because we want to a) deliver products the customers benefit from and thus are willing to buy, b) be more efficient (AKA faster, better, cheaper) to gather higher profits (AKA business value), c) to stay in the market, because everybody else does it and proves it right.
Everything else comes second. To be precise about what comes second, third, fourth, or even fifth: a) your fun, happiness, b) team building, c) Good parentship, d) work-life ballance, e) becoming a better person, f) work from home, g) healthy snacks.
All of these points are nice, but basically they are just a means of the primary purposes found above. They are contributing to the primary purposes, or will become obsolete, when management finds out it is not contributing.
Efficiency vs. Effectiveness
Efficiency
Efficiency can be summarized as minimizing waste or „to do things well“. Oh. Waste = Muda, which is a central Kanban term for a good reason.
Applied to requirements management, the founders of Scrum have found out, it may be less wasteful to replace fixed requirements specifications documents by a volatile and continuously reprioritized, hence more efficientproduct backlog.
Applied to team building, intense and immediate collaboration of all required skilled workers seem to be more efficient than silo organizations.
The push principle puts pressure on your people. Often this leads to errors, stress, unnecessary task switches, low throughput, unpredictable processing times. The promise of the pull principle in conjunction with a limitation of work in progress (WIP-limit) is the exact opposite: Happier workers produce better output more predictable.
Effectiveness
Effectiveness can be summarized as „getting the right thing done„.
This is especially tricky in volatile environments. But one thing should be immediately clear: Long cycle times lengthen the periods of feedback points, which is the main reason why a lot (not all..) of waterfall projects fail to produce good marketable products, especially compared to those with short cycle times, AKA Scrum sprints.
The backlog contains committed stories (features, capabilities, epics) for the next N iterations (sprints, program increments, etc.).
Issue, Problem, Risk
Any sprint (iteration) should have a clear sprint goal plus a set of user stories paying into this sprint goal. This is the commitment we need.
When we now think about scaled agile we need to have a product backlog containing features. The top-trio features will go into the product increment planning (PIP) and will be regarded as being set for the next PI (typically: next quarter).
When we are talking mid-term or long-term product development, one of the charms of agile development (actually: one of the key advantages) is the possibility to change our path towards maximum customer value of the product under development.
In Scrum this is done by sprint retrospectives/reviews and re-proritized product backlogs.
„The PI roadmap consists of a committed plan for the current PI and offers a forecast of the deliverables and milestones for the next two to three PIs. For the outlying PIs, these may may be indicated as Features or Epics and even Milestones.“ (cf. https://www.scaledagileframework.com/roadmap/).
Root Cause
You are part of a non-agile organization
If an agile team (agile release train) is part of a non-agile organization, the non-agile management has it’s own ideas about mid-term targets. If the ART has to commit to these targets the product roadmap will be committed for more than one PI as well.
Your have non-agile past
… to be continued.
Mitigation, Remedy, How to avoid
Commit to one PI.
Be clear the next PI feature sets are forcasts, nothing less, nothing more.
A silo organization introduces SAFe in the IT silo. And gets the proof that SAFe is no good.
Issue, Problem, Risk
A silo organization starts to implement Agile in one or more silos, instead of breaking the barriers and thinking of the whole organization as one system.
No end-to-end view, starting and ending at the real customer.
This approach leaves a very high risk for failing in implementing SAFe, because the implementation starts with an anti-SAFe assumption (a violation of principle #2: Apply systems thinking).
Root Cause
Big organizations tend to split their organization into more manageable entities. Quite often these entities are legal entities. And regularly the heads of these entities (or: „principalities“ AKA silos) have to negotiate with the group about their annual budgets, deliverables, etc.
Supposed we have a big telecoms operator with a group HQ, including group ICT, operational/national companies responsible for the local markets, all national companies have their own ICT organizations.
When this organization now wishes to implement SAFe, it is very tempting to start with let’s say replacing the Customer Care & Billing vendor in France, and involve (and only involve) the french IT department.
If you do this, the customer triggering your operational value stream is an internal customer, e.g. the french marketing and/or sales department.
In this case the national ICT organization is treated as an external supplier, the operational value stream of this supplier is „deliver CC&B services“, the development value stream would be called „develop a ‚much better‘ CC&B service“.
Bad luck. Because you stick to the silos thinking which is part of your problem, not your solution.
If you concentrate on ICT, you don’t look at the full value stream. If you concentrate on the ICT of one country this is even more true.
So, first your operational value streams should be triggered by a real customer and ended by having the real customer paying money for the „value“ he/she got from you.
In the example from above, e.g. a real customer is a student entering a shop in Toulouse, wanting to get a new mobile subscription, including a new phone. That’s SAFe’s „Trigger“ of an operational value stream called „new contract“.
This operational value stream ends, when the customer has signed the contract, his/her credit scoring is good enough, and the first payment has been successfully transferred to the organization’s bank account (SAFe lingo: „$“).
In this end-to-end view on the operational value stream quite a lot of departments, teams, etc. are involved, typically you even involve group functions, because credit scoring may be centralized, handsets may be managed group wide, etc. From the top of my head I see:
Product marketing responsible for the current commercial offers.
Marketing for advertising material (TV ads, shop looks, etc.)
Partner management/shop management for shops, shop staff, POS.
Customer management for validating the customer’s master data.
Finance for credit scoring, verification of bank data and cash flow.
Logistics for managing handsets.
IT operations for delivering POS, CRM, billing, ERP systems.
External partners for printing & mailing services.
External partners for quality management and customer satisfaction surveys.
If you now compare this to the „root cause“ example, you might say: I cannot start with this full systems view. Well, if you want to optimize your system, you should do, and actually: you have to. Why?
If you look at the E2E operational value stream,
You are able to identify the biggest pain points along the whole process chain.
You get every involved organizational unit on board.
You talk about real E2E customer value, not about the details of the requirements specification handed over – sink or swim – from budget authority (e.g. sales & marketing department).
Working with other Scrum Masters to improve the organization.
If you do deviate from the Scrum Guide, well: be aware you are on your own and must not call it a best practice until you have your numbers straight („In God we trust, all others bring data“ – W.E. Deming).
This anti-pattern could be also seen as „phased agile“:
You set up a e.g. three months stage plan for stage 1, stage 2, etc.
You expect every stage will deliver at the end of the stage, but the delivery method during the phase is somewhat agile.
Sometimes you even see an „Analysis Stage“, a „Design Stage“, and an „Implementation Stage“.
This anti-pattern likes to comes along with the User Story = Requirement anti-pattern.
Issue, Problem, Risk
The customer isn’t getting things early. But to get customer feedback (or product owner feedback, or business owner feedback) is one of the key reasons we want to go agile.
The cadence and rhythm of Agile (e.g. sprints) are not being used. Thus the boost in efficiency coming from working in cadence and in sync is lost.
Root Cause
The organization either does not know enough about Agile or does not want to become agile. Or both.
Mitigation, Remedy, How to avoid
Get management buy-in to start a small project which is suitable for agile approaches. Continue to record your lessons, try to learn from the sprint and project retrospectives and try to extend this to more complex projects.
In case of Scrum: get trained Scrum Masters who have the power to assure Scrum is properly implemented.
Get Agile Coaches to help the organization to move towards the Lean-Agile mindset.
You now have hundreds of stories, all copied from each of your team’s backlogs and have no clue what your forthcoming Product Increment (PI) is going to deliver.
Your stories somehow have vague headlines, you declare as „features“, but they are rather what they are: headlines of groups of team stories.
The team’s stories are quite detailed, but lack a consistent view or perspective on the definition of ‚Done‘ (or something similar).
Thus it is very likely that these „features“ do not have a single trustworthy benefit hypothesis and that the feature acceptance criteria are empty.
Issue, Problem, Risk
Since the headlines called ‚features‘ are team dependent, the features are not oriented on generating high level (and team over-arching) customervalue, but on realizing something in a team, driven by the team’s product owner.
Since you don’t have features focussing on generating customer value, the mandatory benefit hypothesis is either weak or non-existent.
Since the feature is generated from team stories, there is a high risk the acceptance criteria are not focussing on the ART level customer’s perspective, but on a team level perspective.
Since this is de-facto a bottom-up approach business owners and product managers will have serious problems with the product roadmap and the product vision.
Root Cause
We see the root cause somewhere in between the following:
a weak product manager, maybe not very experienced nor trained: he/she is dependent on the input of the teams‘ product owners, but is not able to turn these low level items into high level items the stakeholders really need.
missing communication between customer (representatives), stakeholders, business owners and product manager(s) – and systems architects (typically responsible of creating enabler features).
lack of time to successfully groom the feature backlog, complete the feature and benefit matrix (FAB) and the acceptance criteria, and prioritize the features using the WSJF method.
Mitigation, Remedy, How to avoid
Don’t write features as stories
If you write features using the „As…, I need…, to get…“ templates, you lose the high level perspective and maybe you lose your stakeholders too.
As SAFe expresses it: A feature is ‚a short phrase giving a name and context.‘
Prioritize using the WSJF method
SAFe makes it clear: ‚The WSJF prioritization model is used to sequence jobs (e.g. features, capabilities) based on the economics of product development flow.‘
So, use it!
Write proper acceptance criteria
Acceptance criteria as founding SAFe are looking like this:
Product Management is using these acceptance criteria to define and determine if the product features are properly implemented and if the nonfunctional requirements are met.
Lean UX
What if we found ourselves building something that nobody wanted? In that case, what did it matter if we did it on time and on budget?
Eric Ries
The Lean UX model of SAFe, also found in Gothelf, Jeff and Josh Seiden. Lean UX: Designing Great Products with Agile Teams. O’Reilly Media. 2016.
If you start using Lean UX concepts including the minimum viable product (MVP) or the minimum marketable feature (MMF) on the feature program level or above, you make sure high level requirements and necessities are met, customer’s expectations are understood and communicated, and short & fast feedback loops lead to ‚elimination of waste‘.
Your company follows a very rigid long-running stage-gate process, which takes around two years between first ideation and go-live.
You have three to four releases per year.
You cannot change anything which already passed a gate.
Issue, Problem, Risk
The 1%-requirements creep rule is ignored, thus after 24 months more then a quarter of your project’s results will be wrong.
Root Cause
If you are held responsible for the software design you will insist on getting a frozen requirements specification document.
If you know your failure will be recognized by your peers down the line and reported through the hierarchies – to finally land on your desk again, you become a cautious and fearful person.
Thus, maybe the biggest reason for the absence of a culture for change is silo thinking in combination with well established blaming mechanisms.
Mitigation, Remedy, How to avoid
Reduce fear by establishing a culture for failure and a culture for change.
Establish a culture for change by establishing a change process for all projects.
Agile embraces change. It is one of the four values of the Agile Manifesto: ‚responding to change‘ and one of its principles is ‚welcome changing requirements, even late in development.‘
Agile thinking requires the working implementation of a concept called ‚feedback loops‘.
Thus whenever we do something, there should be some kind of planning before we do it (Cf. ‚I guess I’m just a fool, who never looks before he jumps.‘ in ‚Everything happens to me‘ as sung by Chet Baker, in https://youtu.be/MaGl6zd3rHg).
And after we did something, there should some kind of check, and some kind of a reaction of what we found out. Other forms of feedback loops:
You have lot’s of stories converted from an old fashioned requirements specification. You have enough to do for the next years. Your customer is raising the bar and starts to put pressure on your deliveries.
Issue, Problem, Risk
A rat race is a rat race is a rat race.
Nobody knows why he/she works so hard? That’s bad and quite the opposite of ‚transparency‘ (pillar #1 of Scrum). Your eco-system should cater for openness and transparency.
Does every member of your scrum team – your Product Owner in particular – have a clear understanding of each of your sprint’s ‚Sprint Goal‘? If not, you have uncertainty on what a successful sprint is and when to kill the sprint because you will miss the sprint goal.
A missing or bad sprint goal will pull your DevTeam into the ‚finish stories‘ anti-pattern. This is quite different from maximizing product/customer value/benefit through a ‚potentially shippable increment‘.
Root Cause
It is just wrong to throw top-down overboard and believe you could deliver „the next big thing“ bottom-up.
If you look at your very own product backlog, you may see not much more than a flat list of quite simple ‚requirements‘:
Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when „Done“.
The Scrum Guide.
That’s about it. And this is why a ton of methodologists had to invent something ‚above‘ this.
PRINCE2 Agile has thought about the matching of standard PRINCE2 artifacts to agile terms, and came up with four possible levels (and I selected one possibility by underlining it…):
Vision
Epic, feature, theme, scope
Epic, feature, function, coarse-grained user story
But be warned: A high level story (feature, epic, whatever) is not just a BIGGER story. At least within SAFe it has quite different attributes for very good reasons.
In essential SAFe (https://www.scaledagileframework.com/) there are two levels of stories: features and stories. But features are not written with a story stencil in mind:
As <who> <when> <where>, I <want> because <why>.
https://en.wikipedia.org/wiki/User_story
No. As an author of a SAFe feature you should stick to this:
Features are defined using a Features and Benefits (FAB) Matrix: Feature – A short phrase giving a name and context Benefit hypothesis – The proposed measurable benefit to the end user or business
Would you please keep in mind that although the sprint goal is mandatory and very important when it comes to meaningfulness. But it is by no means sufficient to really vanquish your team’s worm’s-eye perspective.
BTW: Nexus (https://www.scrum.org/resources/online-nexus-guide) structures sprint goals by adding a higher level nexus sprint goal, which will be fulfilled by each team’s individual sprint goal. This is symmetrical to the concept of Nexus sprint planning versus team’s sprint planning.
If you think about a ’standard‘ implementation, a product increment (PI) takes one quarter because it is consisting of six two-weeks sprints (iterations). Features (turned into PI objectives, for a deeper look into the differences spend some time on how to Differentiate between Features and PI Objectives in https://www.scaledagileframework.com/pi-objectives/) drive the PI. And as a product manager you should have a clear idea about this next quarterly PI. Thus the set of features (to be precise: the set of PI objectives) in the next PI is committed.
The PI roadmap now combines this committed PI with the forthcoming PIs which contain not so clear and sure features. These forthcoming PIs are forecasts and not committed, because you have learned your lesson from
Sadly, Robbin suggest to use a story-like stencil, which is not quite the right way to communicate successfully with top-tier management, product marketing, non-developers or anyone who is not a Scrum-disciple.
The statement of a desired future state.
PRINCE2 Agile
SAFe agrees to this:
The Vision is a description of the future state of the Solution under development.
SAFe https://www.scaledagileframework.com/vision/
But SAFe says much more about your vision: Your vision should be present on all layers of your organization:
Starting at the C-level you should have your strategic themes at hand.
On portfolio level you should have a clear birds-eye view on the long-term endeavors.
On the solution level (covering multiple product and/or systems) and again on the product level (then it’s called product vision….) you should ask yourself
Your IT department is doing pretty good in using Agil, but somebody from the C-level forgot to ‚agilize‘ your purchasing department and/or sub-contractor management.
Thus the contracts with your vendors did not change since 1980 and may be summarized as:
Fixed price contracts,
Contractually binding requirements specification,
Contractual penalties based on
Quality gates
Error levels
Reaction times (typically: analysis only, not resolution)
Project plan including milestones.
Issue, Problem, Risk
If your company is going Agile and your suppliers don’t, you are in trouble.
Root Cause
You startet an isolated bottom-up implementation of Agile.
Mitigation, Remedy, How to avoid
Agile has to start on the C-level and should be iteratively implemented with E2E in mind.
If contractors are involved in your E2E processes (or value streams in SAFe lingo), then you either have to exclude these artifacts explicitly from your Agile universe or your should consider a different contracting approach. Think about PRINCE2 Agiles view on Agile Contracting.
