Transform Organizations by Surfing on a State of Continuous Flow

Reaching State of Flow for a person means to be completely engaged, involved in nurturing each own talents and intrinsic motivations, while being hyper-productive.

What if we could reach State of Flow at Scale
while facilitating Agile Transformations?



Here you can find the slide of my keynote at Agile Open Day in Naples which took place 2018 June 18th,

Embrace Lean-Agile Leadership by falling in love with the “Principle of Mission”


Changing is hard thing. When it has to do with changing your management and leadership styles, it gets even more challenging.

I’ve found that anchoring in my mind a simple statement which summarizes a set of (great) principles is a very effective way to facilitate the change I am called to face.

Yes, yes, you are right, we are stealing bites from NPL (Neuro Programming Language): let’s use it for a noble scope!

The Principle of Mission is actually what Managers and Leaders of today need to accelerate their process of change towards Lean-Agile mindset. Use it like a catalyst!

We know that complexity, disruption, technological advances and products obsolence, everyday, cause change in customer perceptions and needs, business models: everything is fluid, volatile and uncertain (VUCA).

In these contexts the old-style management/leadership approach is disfunctional.

Command and control approach comes from war scenes.

The general and his officers made detailed plans to conquer a new strategic position and finally gave orders to soldiers (Command).

Ehi, look there! Now that general is sitting on his horse on the top of the hill, observing the results of given orders, and in the meanwhile he is receiving reports from the field (Control) and thus giving additional orders to be transmitted to the troops.

Very Static.

Unfortunately, even if this sounds old and vetust, in many organizations that leadership and management style is still well and alive.

We learned that in context like the one we are living, adaptive and servant leaderships are the only ones which can succeed.

I’ve found that anchoring in my mind a simple statement which summarizes a set of (great) principles is a very effective way to facilitate the change I am called to face.

Adaptive: in the sense of leveraging short feedback cycles, to be able to steer and change plans quickly.

In order to do that, we need to have a clear vision on what objectives we want to reach in the mid-long term period, but need to work empirically, in narrow iterations with short-term goals, which are appraoching stages to the former strategic objectives.

For the manager this means to: have an exciting vision, communicate it vividly, bring transparency, be prepared to review her plans according to feedback, accept failures.

Servant Leadership: in the sense of definitely aknowledging that teams and people working on the field are the experts. They, actually, could see any changes, risks or opportunities far before the manager and, therefore, in order to produce value for customers they need to be free to adapt and chose their ways of working autonomously.

For the manager this means to: be open and lowly, empower teams, promote trust, reduce the distance from the C-Suite to the teams, develop the skills and abilities of the people, remove any roadblocks the teams come accross, work through networks instead of hierarchies.

Such a big stuff to keep in mind for someone which is not used to it, isn’t it?!

And this is when the Principle of Mission comes into play:

Specify the end state, its purpose, and the minimal possible constraints.

Actually, coming back to war scenes, Napoleon was probably the first one who adopted the Principle of Mission: he provided his subordinates with the authority to make decisions in case the situation on the ground diverted from original plans and, more important, without the need to wait for any approval through escalation processes. Thus, his officers could adapt rapidly to changing circumstances.

Getting to the point, the Principle of Mission is a great tool for leaders to inspire through a vision and clearly communicating and stating the final intent of the organisation’s missionand contemporarily, letting the people to decide how to achieve it, avoding micro-managing and command and control.

Oh yes, and ultimately, repeat with me: “Specify the end state, its purpose, and the minimal possible constraints. Specify the end state….Specify the end state….” this will remind you all the flavours and nuances of the kind of leadership you have to develop during your journey. Good Luck!

Agile Testing Practice: First Basic Steps

Agile testing is such a huge topic. Probably we could only scratch the surface in this post. But, what I would like is to talk about some really basic concepts and practices, without which we would not even be able to pick the low-hanging fruits from the tree of Agile Product Development. So, let’s start the journey!

As you know, in Agile/Scrum, value is delivered to customers through the completion of Product Backlog Items (PBIs). A PBI could be :

  • a users story, which brings direct and immediate business value to customers,
  • or a description of one or more bugs, which resolution will help customers to gain business value,
  • or a technical story (e.g. refactoring some source code to improve performance, install a new Continuous Integration server, have some architectural development to sustain new business features, etc.), which brings business value indirectly to customers,
  • or a spike (technical or analysis feasibility, take a look here to one of my previous posts), which value is in gaining the necessary knowledge for the team to be able to satisfy a user need,
  • or any documentation needed (user manuals, technical diagrams, etc.)
  • or any other kind of work or activity which is worth doing for the product!

Any PBI must pass through the Plan, Design, Build and Test phases, before being presented to the Product Owner for the acceptance.

Well, one of the most challenging phases is actually Testing.

Agile Testing

According to the last letter (T > Testable) of the INVEST acronim, a story must be testable and in order to do that, we must pass through some specific steps.

First of all, the product owner gives clear and enough information on what the system should do to deliver specific value, describing it through a user story like this example:

As a user of the home banking portal, I want to print the receipt of a money transfer operation I submitted, so that I can review its correctness and store on my private area in the portal

Then, the whole Scrum team reasons on how the story will be tested and demoed, specificing relevant acceptance criteria (see my previous post here). Usually this is ultimately done in the first part of the sprint planning meeting.

Moving forward, it’s time for the development team, during the second part of the sprint planning meeting, to reason about the “how”:

a first high level design of each committed PBI is done, which ends with technical tasks decomposition.

Oh, c’mon Emi….so far no news at all !!! Ok, ok, let’s push a bit on the accelerator then.

Testing Tasks on your Kanban Board

Regarding the testing activities, the teams should have been created, for each user story, something similar to these tasks: Test Scenario & Cases Design, Test Scenario & Cases Development, Test Cases Execution, Test Cases Automation, Final Validation.

Test Scenario & Cases Design

Firstly, let’s get rid off any misuderstanding about Test Scenario vs Test Cases: a Test Scenario is WHAT behavior we want to test; a Test Case specifiy HOW we are gonna test it (input data, output expected, variables, steps, etc.).

Well, this first design phase is key to the success of the whole story.

The team member/s who will develop the story (let’s call her developer) and the team member/s who will test it (let’s call him tester) meet and discuss how the story will be implemented (UI, any business rules, happy and alternate paths, data, performance, etc.).

This helps the tester to start clarifying all the possibile (known) business workflows a user could walk along and, on top of them, make a first risk analysis to discover what are the paths more subject to errors and crossing them with any business critical points (e.g. money transfer submission, credit card data confirmation, etc.).

The results of this is the identification of test scenarios (and most critical ones) and related cases, assuring an end-to-end functional testing. In this phase is of great help if also the end-user could join the discussion, actually largerly increasing the effectiveness of the final results.

Test Scenario & Cases Development

At this point developer and tester come back to their workstations. The former start developing the application and the latter writing the test cases, according to the design above mentioned.

This testing activity could be significantly time-consuming because pre-conditions, data, conditions, expected outcomes and the like, are finally transformed into detailed steps of the test cases. In case of any doubt, both the tester and developer could meet and clarify and finally review them together.

Two important aspects must be taken into account.

The first regards the fact that product functionalities and feautures are bult incrementally and same is actually for test artifacts: they grow incrementally, therefore maintainability is paramount and must be thought accordingly.

The second is traceability.

Traceability between features, PBIs, test scenarios and test cases, must be assured according, again, to the incremental approach mentioned. Additionally, every eventual new bug that pops up, shall be addressed and the related test case must be clearly identified and fixed.

Test Cases Execution

When the developer finishes her development tasks and move each and every related tasks in the Done column of the Kanban board, if the tester has already finished with test cases creation, it’s time to execute those cases against the new functionality.

Each step of every test cases belonging to that scenario, is then executed following the workflows previously written. Any bugs must be notified to the developer, which should fix them on-the-fly (if possible); otherwise it will be tracked into the defect management system.

Test Cases Automation

Well, when every story is finally successfully tested, it’s time to test automate it. Why?!

Because of the incremental product development approch of course! Starting from the first iteration the team develops some stories, then in the following sprints they build other stories on previous ones and so forth incrementally (like with a construction with LEGO blocks).

If the team does not automate tests, it happens that regression testing will become more and more complicated and, moreover, too much time consuming: while time passess, number of stories developed increase and manual testing everything is impossible. This has two different potential side-effects:

  1. The team in order to deliver the functionalities promised, decreases the attention and related effort towards testing (poor quality).
  2. The team remains fully disciplined and committed to quality/testing, deliverying less functionalities (poor performance).

Now, both must be avoided. It is very important for team members to find a good compromise on how much effort they should spend in testing automation. This can be done only distinguishing between the different types of automation testing and the relative effort that it is reasonable to spend on it (the design phase above is key here).

Some examples of testing automation practices are Unit Testing, API or Service or Behind the GUI automation testing and UI automation testing. Everyone has its own specificity that desevers more space and time to be covered. I’ll leave this for future posts.

Final Validation

The last task a tester should execute before putting the entire story in the so called “TO ACCEPT” column for the Product Owner, is the final validation, where some explorative, edge testing activities or, if requested, some performance or load testing happen.

Well done!

Now, please, turn around. Look at your kanban board. How many testing tasks do you have on it? What?

Just a single, poor and generic task called “Testing”?

Cheers 🙂

Agile Teams, Measures and KPIs

When you dig into this topic, you find tons of discussions and debates about what metrics and KPIs to use when “running” Agile and if they are helpful or misleading. This post wants to explain when and what KPIs can be used, to lead your team towards relentless improvement.

As a Scrum Master, Coach, Agile Leader, your work is to facilitate your team to grow and improve with a constant pace, sprint after sprint. In doing that, you must be as much as possible objective in measuring improvement; that’s key to drive decision making and to identify actions which lead to increase effectiveness of your team.

One of the most famous quotes of Peter Drucker says:

If you can’t measure it, you can’t improve it.

Drucker meant that unless success is defined and tracked, you never know if you reached it or not. His suggestion was to clearly establish metrics for success, then track progress and, according to that, adjust your process to produce the desired outcome. Without clear [SMART] objectives, you’re stuck in a constant state of guessing.

Another interesting quote from the American professor and statistician W. Edwards Deming says:

“In God we trust, all others must bring data.”

Yes, it definitely makes sense, too.

Actually you should know that, despite any healthy approach and endeavor in helping your teams to improve through any measures and KPIs, better results may be long in coming.

Why?! Reasons may be different:

  • Fear: of changing, of making mistakes, of being judged.
  • Team Dynamics: lacking of trust between team members or unaddressed conflicts.
  • Transparency: unclarity about project’s vision and mission or team’s roles and responsibilities,
  • Burnout: too much stress or overload.

Furthermore, we need to keep very well carved in our mind, that KPIs and measures are just proxies of the reality. Not the reality.


Said that, KPIs could help. Let’s see a short list of them, which agile teams could use to track their progress towards improvement.

Monitoring the Scope

First of all, having a graphic view of the status of the scope in terms what has been done and not done, helps a lot.

Additionally, a high level view of which part of the scope belongs to which release, is another important information. Every information contained in the product backlog is a living element, which is updated according to refinement activities as well as release planning events (which are highly recommended for complex projects).

Once your team planned for a release (usual duration from 8 to 12 weeks), you should be able to draw a Release Burndown Chart, like the following one, where the total scope for the release is reported on the Y axis against time (X Axis) and updated with actual data. This helps to see any deviation from the trend line.

In order to make forecasts for the whole product development or project duration, the tool we can use is the BurnUp Chart. This chart shows:

  1. A (blue) line, which represents the total scope in story points, tracked at each sprint boundary
  2. Histograms (green) that reports the cumulative scope burnt in story points (sum of story points accepted, velocity), for each sprint
  3. A (red) trend line, which projects future performance (velocity) according to past performance

The intersection between the red line (trend) and the blue one (total current scope) gives the future sprint number, when the team completes the whole scope.

When teams want to verify the scope they work on each iteration and investigate on its nature, they could track and plot how many story points are:

  • loaded into the sprint (Committed),
  • added by the team in case of any discovery activites during the sprint,
  • requested by the team when finished to work on the planned user stories,
  • Added by PO (TO AVOID)

Every category (added by PO excluded) is allowed and can be considered a usual behavior. Any recurring pattern, however, is a sign that could be investigated.

Monitoring Performance

The most utilized KPI here is the Velocity, which is the sum of the story points finished by a team (according to the Definition of Done) and definitely accepted by the Product Owner (PO), within an iteration (or sprint).

Scrum is strongly geared on the PDCA cycle from Deming. This cycle strongly stresses not only the importance of planning (P) and doing (D) activities and actions, but it helps to focus also (and foremost) on investigating (check – C) results and adapting (A) your plans/behaviors to improve.

This important concept of gathering and analyzing feedback about past iterations, is one of the pillars of the Agile Manifesto (12th Principles):

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Scrum implements it through the Retrospective Event. Any actions which aim to improvement of produtivity, reducing of cycle time, throughput increasing, should be positively reflected by calculating the ratio between previous and current sprints velocity. The result is a percentage that can be plotted as follows.

Tracking Waste

Lean teaches us that waste must be always avoided.

In Scrum everything is built around that concept: batch dimensions (user stories and tasks) are kept small thanks to strict timeboxes (sprint, scrum events duration, etc.), Focus and Commitment are behaviors continuosly remarked and reminded (being also Scrum Values). The two roles of Scrum Master and Product Owner, help in shielding the team and clarifying responsibilities within the team. Colocation enhance communication and decrease misunderstanding, etc.

An important dynamic we would like to monitor, is that every effort spent by the team, delivers actual value for the business. What is expected, hence, is that every story finished by the team, is subsequently accepted by the Product Owner.

Exceptions are obviously more than welcome, but any recurring pattern must be investigated because it could hide communication problems between PO and team, difficulties with Acceptance Criteria, problems with the Definition of Done. The graph below helps in finding gaps between finished and accepted story point values.

It’s possibile to generalize and represent that phenomena as absolute figures. The Focus Factor is the calculated ratio between [Finished Story Points] and [Accepted Story Points]. We can then plot those numbers for every sprint as follows:

Quality Measurement

Creating bug-free products is something we should aim to, but that is not always possibile. This means that keeping track of bugs is a mandatory practice to measure quality. We would like to measure how many new bugs have been discovered during the past iteraction, how many have beed closed and how many are still remaining.

Other important measures we could track are # of Test cases and percentage of automated ones, code coverage % for unit tests, technical debt measurement through static source code analysis (see my previous post “Relentlessy avoid technical debt“).

People Engagement and Satisfaction

Last but not least, we want to measure satisfaction, motivation and engagement of people involved in Agile development.

Measuring team members’ mood is a good habit and it could be done through temperature reading just before finishing the retrospective, or by “reading” the satisfaction through Niko-niko every day.

This data can be collected and shown as KPIs over time as information radiators.


Finally, I like to end this post citing John Hayes:

“We tend to overvalue the things we can measure and undervalue the things we cannot.”

Thus, don’t forget we are humans largerly influenced by emotions; additionally, we, as Agilists, want to enable energy and interactions between individuals, and only then, rely on processes, tools and even on Measures and KPIs.

Safe travels :o)

[2nd Part] Why (What? How?) you should Embrace Agile and Lean, to Manage your Portfolio

In my previous post I explained some of the foundemantals steps for implementing an Agile and Lean Portfolio Management. Want to know how actually strategy drives execution of company Big Initiatives, through Agile and Lean?!

In my previous post I wrote why Agile/Lean Values and Principles are the most critical point to start with, also for Portfolio Management; then I proceeded explaining what are Values Streams and how they drive the whole portfolio development. Going further, I wrote about prioritization through Cost of Delay (COD) and Weighted Shortest Job First (WSJF) and finally proposed a possibile process for portfolio management and the related kanban board.

In this post I would like to explore how strategy is bridged with execution, and how Lean and Agile together create the most effective approach to avoid waste, remain adaptive and deliver value rapidly.

Bridging Strategy with Execution

Strategic Themes

Fine. The journey starts when top management decides what will be the company strategy for the next year/s (1? 3? 5?). Usually this phase produces a list of Strategic Themes the company should pursue. Every strategic theme has at least a title, a description and obviously expected benefits.

Examples of Strategic themes’ titles a compay could have: Attract younger people (e.g. Millennials), Digitalize 80% of Company Internal Processes, Redesign the user experience for retail customers, etc.

Then, a first budget allocation is made, dedicating slices of overall budget, for each strategic theme.

Big Initiatives & Value Streams

Well, now it’s time to identify the list of Big Initiatives that realize the expected value for each Strategic Theme: One Strategic Theme -> Many Big Initiatives.

Then, for each Big Initiative, a high level “analysis” (Agile Feasibility, not Big Analysis Up Fornt!) is executed, which explores the vision, benefits, raw cost estimation (teams involved, necessary resources), etc, of the initiative itself.

This step is represented in the Portfolio kanban board by the column Analysis (previous post here).

Usually I conduct that high level Analysis or Agile Feasibility, by using the DAD Inception Phase. I wrote about this in one of my previous post here: “Getting a big and complex project off, from the starting blocks with Agile (DAD Inception)“.

Then, people and teams involved, sequence of actions, usage of resources, knwoledge and expertise, represent, all together, the Value Stream through which pursue and deliver expected value: from concept (trigger) to cash (value).

Now it’s time to fund the initiatives. A budget is allocated (and dedicated) for each Value Stream. The picture below puts everything together.

One important piece of news, is that the Agile iterative and Inspect/Adapt approaches are also used for Budget Allocation. Actually budgets, for strategic themes and value streams, are initially allocated as usual, but they are revised at least every quarter. What does it mean?

It means for example that the overall budget allocated for a specific Strategic Theme, is decomposed in slices and assigned to belonging value streams. Then, according to effective progress and results of each value stream, and eventual market change, every quarter budgets could be revised and re-balanced beteween the value streams belonging to that strategic theme. The Portfolio Management team is responsible to autonomously rearrange budget at quarter boundaries,

Flavors of Lean in Portfolio Management

Lean is key to Portfolio Management.

It helps to reduce waste, decrease time-to-market, and drastically improve quality thanks to Pull System and concepts like JIT and WIP Limiting.

A Pull System provides that development or production should be ‘pulled through’ rather than ‘pushed through’ the productive system

Systems like those, are literally driven by customer requests and thus worked just in time, as productive capacity is available. This assures that the companies adopting these systems, to produce what is strictly necessary and actually requested by the market/customers,

Another foundamental gear of a pull system is Just-In-Time (JIT) concept.

In lean manufacturing JIT means producing and delivering finished goods ‘just in time’ , right before being sold, just enough to meet current demand.

It means for Portfolio Management that a new phase of the process won’t start before the previous one is triggered and finished and, furthermore, that work will happen according to available capacity and customer demand.

A final important concept necessary to implement an effective pull system, is WIP Limit. WIP is an acronym which stands for “work in progress”.

Limiting WIP is a strategy for preventing bottlenecks, avoid over-production, avoid waiting times and it generally improves flow by creating a steady pace between the production phases.

Let’s see now how the concepts above mentioned, are applied to Portfolio Management. As mentioned in my previous post, a usual portfolio process and relative kanban board is like this one:

New initiatives or ideas arrive in the Funnel. I usually use this lean canvas which summarizes basic information that finally represents the card in the kanban board:

The subsequent phase Review, is meant to review, refine a bit and validate the basic information, figures and facts of each item in the funnel, assigning a first piority. New relevant information are reported also in the card, stressing another lean concept (Visual Management), in order to facilitate visualization and immediate understanding.

Then, when an initiative is pulled through the Analysis columns, the Agile Feasibily is executed, in order to envisage high level scope, architecture, risks, benefits and costs.

In order to avoid too much analysis, as mentioned in my previous post, this phase is also executed in an Agile manner (using Scrum), collaboratively and doing not much Analysis. The final outcome is a Lightweight Business Case which reports the main assumptions and results. I use the one from Scaled Agile Framework you can download here: SAFe Lightweight Business Case.

JIT conecpt is here applied because the information of every initiative, starting from the Funnel up until Analysis columns, is deepened incrementally according to customer needs (what arrived in the Funnel) and the effective capacity available.

Nothing is worked preventively and stays parked somewhere waiting for something to happen.

Ok, but what about WIP Limit? Well, in Portfolio Management we want to limit WIP because letting initiatives proceed through the kanban system is costly. This is why the Review and, moreover, Analysis columns are WIP Limited.

The Review phase is definitely lighter than Analysis. Usually the review is done by the portfolio management team plus some SME (Subject Matter Experts) and it does not last more than hours. Analysis could last days (for some very big programs even weeks), and it is more resource consuming. This is the reason we want to WIP limit more the latter.

Yes, now you should be ready to reason about prioritization through WSJF, GO/NOGO decisions, management of Portfolio Backlog and finally how to match capacity with demand when it’s time for initiative to be pulled into development….but these topics will be covered in next posts.

Enjoy! 🙂

Why (What? How?) you should Embrace Agile and Lean, to Manage your Portfolio

Lean and Agile are great approaches to increase effectiveness in Product Development and in Project/Program Management. What could be the most important things to do, to improve the development of your products and services?

If you are managing your portfolio of projects using the traditional way, probably you encountered several of the problems listed below.

What? You are already using Agile for Product Development?!

Well, even in that case, if you are stil running you portfolio in a old-fashion traditional way, you will find yourself creating local sub-optimization that, in the very end, will still lead the whole system to create waste and delays.

So, let’s see the reasons that should convince you to use Lean and Agile also at the portoflio level, what to do and how to embrace them.


Is your organization suffering from one of these?

  • Everything is top priority (means no priorities)
  • Projects’ effort is always big one. No short releases, neither MVPs (Minimum Viable Products)
  • Too many simultaneous projects
  • Too much time passes from ideas generation to product creation
  • Waste coming from multi-tasking is huge and not visible
  • Technical work is hidden and difficult to explain/justify
  • Too much interrupting work
  • Lack of visibility of how strategic goals are pursued through initiatives and related priorities, etc.

Well, those are symptoms that your portfolio management needs to be rethought…and not only in terms of practices or tools or techniques.

The most important thing to understand and to work with, resides just beneath the surface: values (and related principles) that drive decisions, behaviors of the people involved in portfolio management.

These are: openness, trust, commitment, focus, collaboration, courage.

Why Agile/Lean Portfolio Management?

This approach, if well understood and applied, will always lead you towards how to produce real and effective value for users: VOC (Voice of the Customer) is paramount.

It strongly organizes work around Value Streams (derived by analyzing VOC) and makes the process flow visible and transparent. Everything is thought to avoid waste. This is done by using pull systems to avoid over-production, limiting WIP (Work In Process), always stressing the importance of quality and making Continuous Improvement a pillar of the whole process.

Visualize your Value Streams

First of all, you need to visualize your Operational Value Stream:

how you are producing, or will produce, value for your customer, visualizing the systematic steps that create value and who is involved in this process, from concept (order) to cash (delivery).

Now, is time to see what systems are used, teams are involved and what features allows the organization to release value through that Operational Value Stream. This collection of teams and systems are called Development Value Stream.

Actually, identifying the people, teams, systems involved and making them consistent and cohesive, is a pillar of Lean/Agile Product and Service development, because the porfolio will be developed around these development value streams and, thus, around these long-lived teams: cross-functional teams which permanently work on same product lines or suites of products.

This concept is a core one when it’s time to talk about capacity. In Agile Portfolio Management, in fact, the smallest unit of measure is actually the team, not single individuals, neither pool of resources assigned for a predetermined amount of time and then moved to other projects (traditional project management).

Funding shall be also arranged according to these value streams, assigning dedicated budget: one budget to one value stream.

Well, in order to start the journey, you need to assess how your portfolio is managed in terms of numbers of project executed, duration, money spent, people and system involved, value delivered, available capacity, etc.

This is a necessary step in order to create the baseline against which to measure the effectiveness of the new approach.

Lift-off the Program/Portfolio Management Team

According to the analysis and the assessment above, you should know who should be part of the team. This team is, again, cross-functional and shall have senior leaders able to make effective decisions, coming from the different organizational areas impacted: IT will obvioulsy be represented (Demand? Architecture? Engineering? Q&A?), Business and others areas as well.

This team shall dedicate some time to create the right Mission, Vision, Objectives and Success Criteria for the portfolio management; this is a very important moment where people start to collaborate and to create team working agreements that specify for example:

  • the cadence and frequence when the team meets to work on the portfolio and for how long
  • decision making process
  • roles and responsibilities within the team
  • communication tools, channels, etc.

We usually use the Lift-Off Lean/Agile model to launch these teams.

Again, collaboration, open communication and willingness to work together is key to the success of the initiative.

Agile/Lean Portfolio Management Process Definition

Now is time to define which process (as much lean as possible) to put in place.

This in order to gather any new idea or initiative born in the organization and let them mature in terms of understanding of needs, possible solutions or approaches, any high level analysis of related costs and benefits, to finally arrive to a GO/NO GO decision for the implementation.

The process shall take also into account how to match the demand with the available capacity; here is where the Lean Pull and WIP Limit approaches, come into play.

Lean Portfolio Backlog Prioritization

Lean obsessively fights any waste.

A great concept that helps to avoid spending money for something that has small value, is the Cost Of Delay (COD). It tries to answer to this question:

how much does it cost to your organization, to delay a project in terms of business/user value, time criticality, risk reduction and enablement of new opportunities?

The COD, then, can be divided by the estimated duration of the project, which is the Wighted Shortest Job First (WSJF) that SAFe suggests to be a great tool to prioritize your portfolio backlogs.


Now it’s time to build your Kanban board which reflect the process above. SAFe suggests the following columns/statuses which are, actually, a great starting point.

The Portfolio team uses the board to visualize the work and the relative flow and cards to show the most important information of each initiative. Every column represent a status of the process:

  • Funnel: every new request, idea, initiative arrives here. They are arranged like a queue (FIFO). A standard, lean, minimalist template is used to describe the initative in order to be inserted into the funnel (everything is short and high level: description, top N feature, benefit expected).
  • Review: every initiative is, here, quick reviewed to see everything is clear, understood and well described. A very raw estimation of COD and relative effort is done in order to have a first prioritization.
  • Analysis: during this phase an Agile Feasibility of the initiatives reviewed in the previous column is done, in order to describe high level: the overal scope, architecture, estimated effort, expected benefits, risks, systems and teams involved, etc. The feasibility is run using Scrum and a virtual cross-functional team is formed that has the final objective to create a lightweight business case that contains the information above mentioned, which helps the portfolio team to take a final GO/NO GO decision.
  • Portfolio Backlog: every initiatives arriving from the previous column analysis, with a green light (GO decision), is introduced into the backlog, which is prioritized according to WSJF and here awaits for enough capacity from the teams to be implemented.
  • Development: this columns show everything that is under development
  • Done: all the initiatives that are finished and put on production are reported into this colums.

Well, we saw many things, but many others are necessary to have an Agile/Lean Portfolio Management in place (e.g. pull system, pull policies, limit WIP, buffers and definition of done, information on cards, definition of value, etc.).

So, let’s discuss it again in one of my future posts.

Be good 🙂

Back to Basic: User Stories and Acceptance Criteria

Every new user story presented to the team for development, must be accompanied with a set of user acceptance criteria which can drive development and testing.


Acceptance criteria is a great tool to ensure that the product being developed is actually what the Product Owner wants. Every user story is accompanied by a set of criteria that specifies how it will be tested and verified, in order to be accepted.

The concept behind acceptance criteria, hence, extends itself to the fields of user acceptance and testing activities and in general it means that every endeavor in developing must be guided by a specification of how it will be tested.

Often it happens, indeed, that if no acceptance criteria have been specified, developers finish to code, pass it over to tester and Product Owner for testing and acceptance phases, which reject it because it doesn’t satisfy their expectations.

Even more discouraging is when the story is rejected because of some minor issues caused by misunderstandings.

The trick here is to start in the right direction from the very beginning, that is when the Product Owner presents the stories during the planning meeting.

Let’s take the user story below as an example.

As a home banking user 
I want to make a money transfer 
So that I can pay the loan even if the bank is closed

To specify the user acceptance criteria (UAC) I like to use the GWT (Given When That) syntax, which is explained below:

Given [a specific condition] And [...]
When  [an event occurs] 
Then  [outcome] And [...]

Now, let’s see three basic acceptance scenarios which can be used to test and accept the user story above.

Scenario 1

Given that the account balance is2.000,00
  And the user is trusted
  And the beneficiary bank account exists,
When the transfer amount is800,00
  And the security operation code is correct,
Then the bank should transfer € 800,00 to the beneficiary 
  And the account balance should be updated to € 1.200,00

Scenario 2

Given that the account balance is500,00
  And the user is trusted
  And the beneficiary bank account exists,
When the transfer amount is800,00
  And the security operation code is correct,
Then the bank should not operate any transfer
  And a message must displayed saying there are insufficient funds

Scenario 3

Given that the account balance is2.000,00
  And the user is trusted
  And the beneficiary bank account exists,
When the transfer amount is800,00
  And the security operation code is NOT correct,
Then the bank should not operate any transfer
  And a message must displayed saying the code is incorrect

With this information available, developers and testers could immediately work together to refine the behavior of the functionality.

Thus, the tester can work on test cases and scenarios and the developer has a clear understanding of how her work will be verified and tested; she hence will develop only the minimum amount of well-written code to make all tests pass.

Simplicity actually starts from here: do your remember the Agile Manifesto principle?

Simplicity–the art of maximizing the amount of work not done–is essential.

Simple, isn’t it?!

Speaking at Italian Agile Days 2016

Very glad and proud to be one of the speaker of the Italian Agile Days conference, which will take place in Pavia November the 19th.

The talk I am proposing is about how to accelerate Agile transformations by applying the XLR8 change management model by J. Kotter, beside any agile scaling framework chosen. A great tool which strongly leverages principles like mobilized leadership, cross-functional teams, strategy networks and agile as well.

So, see you there 🙂

To change or not to Change? When Resistance slows down your Transformations

Everything in nature tries to maintain its equilibrium status.

Everything in nature tries to maximize benefits, against costs.

Change is “expensive”. Modifying any habit, approach, behavior, does cost. It costsmoney for organizations, it costs energy for human beings. It takes time for both.

Daniel Kahneman in his book “Thinking, Fast and Slow” explains that our brains are comprised of two parts, characters: one that thinks fast (System 1) and one who thinks slow (System 2).

System 1 operates automatically, intuitively, involuntary (e.g. driving, recalling our age, etc.). It operates on heuristics, which may not be accurate. This consumes small energy, it is almost effortless.

System 2 is used when concentration, focus, reasoning are needed and hence it deliberately slows down its rhythms.

This is used when something new needs to be faced, which not allows to jump to quick conclusions and solutions (e.g calculate a math problem, choose how to invest money, fill out complicated forms). Here the system spends much more energy to operate.

Habits rely on experience and heuristics and are executed by System 1. Changing habits, on the other way, uses System 2.

Furthermore, is far easier to establish new habits than changing old ones. This because the latter requires, firstly to dismount past ones, secondly to build up new ones on that.

So, changing well-established habits, cost even more.

Well, this is the first motivation on why human beings resist to change: it costs much, much, much more, than not doing it.

But, there is at least another reason, even more important, which consciously or not, drives resistance; it has to do with fear. The change could threaten us in our social or professional position, stature, power.

Fine, but how could we recognize resistance?

Resistance could be acknowledged by verifying active responses to change stimulus (complaining, being negative or destructive, etc.) or, more tricky, passive ones (ignoring, not attending to meetings or replying to e-mails, not being committed, avoiding doing activities or making any decision, etc.).

Both the two strategies are somehow simple to address when confronting with a single person. But what if the organization or part of it, is resisting to change?

Organizations are systems.

Any system has just one single objective: no matter what happens, it strives to maintain its internal state of balance.

That state is called status-quo: when a system reaches a stability in which everything is familiar and predictable. Everything in that state can be somehow categorized and managed accordingly. Surprises are rare.

Every person being part of that system, feels himself safe and protected and does not want to change. Remember, change costs effort and brings uncertainty.

But, to remain competitive organizations shall change. A big mistake organizations make is to decide changes top-down, “pushing” it from above.

When a change is so-called “injected”, every part of the system could react, each, in different ways: some by visibly fighting against it, others ignoring, still others delaying, mitigating or even initially “encapsulating” the change, but finally “rejecting” it, with a satisfied grin.

Managing such a resistance could drain all energy of any good change manager, coach, manger, even CEO.

Before managing resistance, organizations, should “manage” involvement.

They must learn how to involve people in order to be supported and helped in intercepting any big opportunity and create the underlying change vision, having employees on-board from the very first moment.

This ever-changing world needs diversity, passion, motivation, creativeness, inspired leadership to be totally understood. And the more the people being part of this “game”, the more the possibilities to be successful.

Organizations cannot accelerate their capacity to change and innovate without those ingredients. What is needed is what J. Kotter in his book XLR8 (accelerate) callsmobilized leadership: people who, guided by a strong and inspiring vision towards the change, are empowered to take action and to self-organize to change the old ways of working.

WordPress Themes