AI is Behind the Storm in Tech Again

A little over a year ago, I wrote a sobering article about tech layoffs in 2025 and how they were affecting developers, Agile Coaches and many tech professionals. I wrote then of the need to become effective and efficient and take accountability for delivering real value to escape the layoff storm.

In 2026 despite the still ongoing AI-related layoffs there is hope, AI is not the panacea that many thought it was, it makes mistakes, it writes way too many lines of code making it hard to maintain, and it needs a competent developer team to make sure the software it helps create is of high quality, and safe for customers.

Security has become the biggest liability of AI, not only because it enables hackers to easily look for vulnerabilities and attack every open source project, but also because it made it trivial to hack websites, and poison code that then is used in open source libraries to steal information from innocent customers.

This year has also made it clear that no technology professional can survive without learning how to use AI as an effective tool, no business should ignore how AI can help them be more productive, but even more important for both people and companies is the need to adopt good security practices because AI has made much easier to attack applications, networks, and companies online.

AI Accelerated Software Engineering and Cyber Security are now a new focus of my work along software development, and ways to be more productive and efficient. I got deep into the security rabbit hole in late 2025 and early 2026 by reviewing the code of the Internet Computer open source code by doing a series of paid reviews of their Rust code. This experience showed me that while AI can help with a security code review it is quite insufficient, because it raises false alarms, and makes mistakes in their overall assesment. Companies need humans who can read, understand, and evaluate the correctness and security of their code, and AI is a useful sidekick but can not do the job alone, it needs smart humans to guide it, and use it as a tool.

If you are a tech professional do not fear, master the new AI toolchain, move forward, and make cyber security a new area to explore.

On the Tech Behind this Website

As I told my followers on X I decided to move away from a platform that has served me well for over 15 years, WordPress dot com.

This time everything you see in this my professional website and blog runs fully in my personal computer first, inside a great and free Content Management System called Hugo which then publishes everything online. Hugo is free, powerful, and I do recommend it to anyone familiar with technology and how websites work.

Where to host the website was also a long search I did, after evaluating many choices I narrowed my list down to two good choices: GitHub Pages and Cloudflare Pages. After careful evaluation of my current and future needs I came to the conclusion that the Cloudflare Pages is more powerful, and better for a professional website that intends to do much more than just static content.

Future Plans

I am growing my small consultancy - Granata LLC - from what was and continues to be areas I excel at: Tech Project Management, and Agile and Lean Digital Transformation to now include AI Accelerated Software Engineering, Cyber Security, Bitcoin & Crypto software, and new ways to achieve higher personal productivity and achieve goals.

I plan to write about these topics, and launch a YouTube Channel and Podcast soon. I have been quite busy, and finally the fruits of my labor will start being visible this second half of 2026.

For those few who read my last post of 2025 the book I mentioned was finished, but I am improving it significantly, that is why it is coming later this year, the tentative title is: “The 14 Laws of Breakthrough for Business.”

So that’s my news and the plan for the year, I will also write about other interesting topics related to my never ending search for Wisdom and applied Common Sense,

Thanks for reading.

What works will remain, the rest will be gone.

Agile is dying, and becoming much less relevant. There are only two paths ahead for Agile to diminish even more until it becomes irrelevant or to finally change to survive by focusing on delivering value and not dogma.

I do hope Agile adapts because despite all the valid criticisms there are still lots of useful ideas and principles inside of the different Agile approaches like Scrum or even SAFe, but the problem lies in a series of processes and meetings that management rightly feels are a waste of time and effort, and the associated dogma that frequently comes with it.

Layoffs for Agile positions are now a trend, and there are much fewer new jobs that focus on Agile responsibilities such as Scrum Master or Agile Coach. Layoffs in Agile positions are worse than those in software engineering, the current economic downturn and AI have made companies focus on cutting costs, and focus on those jobs that truly deliver value.

However, there is a big difference with the world of Lean, Lean is more alive and relevant than ever! That is because Lean has always focused on being efficient, getting things done, and reducing waste across the board, so Lean does not endorse useless meetings, useless charts, or even theory, the focus is always in what works best, what brings value.

Lean’s focus has always been on getting things done, doing things with high quality, and efficiency. The Toyota Production System, The Theory of Constraints, and System Thinking are alive and well respected by those who know those approaches work.

There is a resurgence of interest in the Lean Management approaches precisely because businesses have noticed that those methods focus on getting results first, and the process second. Lean approaches focus on what I call RETURN ON CHANGE: what direct benefit would we have in our bottom line, product, or market share if we do this?

Among the Lean methods and frameworks, I particularly like Kanban, Flow, and TOC which are less well-known, but quite useful and efficient for any business today. Lean is doing well in this post-agile world. Soon my own Lean approach will finally contribute as well to this body of knowledge: The BREAKthrough method, and the book that explains it will finally arrive this quarter, the book is finished, and I am now in the final editing phase.

One last thing must be mentioned: This change has also brought a resurgence in Project Management, so much so that the organization behind Project Management, the PMI, has absorbed the Agile Alliance. Furthermore, jobs for Project Managers have increased significantly despite the layoffs. The reason is clear: Project Management focuses on assuming responsibility for delivering results.

We have entered a new era of efficiency, where getting things done comes first.

Two of the Agile Manifesto lines say:

“Working software over comprehensive documentation…

Responding to change over following a plan”

At the time Agile Manifesto signatories, people like Alistair Cockburn and Jim Highsmith wrote these lines because they were dealing with very detailed planning demands from management, detailed processes like the Rational Process, planning from the world of construction, and engineering that demanded plenty of documents, analysis and planning before work starts.

Software however, is more forgiving than cement, and steel; so that is why they said: “Working software over comprehensive documentation.” It does not mean absence of documentation or planning.

The Planning Paradox

What the Agile Manifesto does tell you is that too much planning is a waste of effort, and a waste of time.

Why? Well because:

The further into the future we plan, the less accurate we will be, and the more mistakes we will make until plans become completely useless.

So a plan for one day is more accurate than one for the week,

A plan for the week is more accurate than one for the month,

A plan for the month is more accurate than one for the quarter,

A plan for the quarter is more accurate than one for the year,

A plan for a year is more accurate than one for five years, and so forth.

Agile Planning in Scrum, SAFe and Kanban

In the world of Scrum there is of course the next Sprint or iteration plan, usually a two-week period, but most Scrum experts would agree a 3 to 6 iteration horizon is best, never just one Sprint. That means 1.5 to 3 months planning.

In the world of Scaled Agile or SAFe there is the Program Increment planning, since SAFe deals with multiple teams and large efforts the horizon for the Program Increment is usually 3 months, and SAFe usually recommends to look into the future one or two Program Increments ahead, which means a 6 month horizon.

Kanban uses continuous flow, but this does not mean it does do planning, in fact they do, they just move planning above the level of the team when necessary. So for a single team the horizons of Scrum makes sense 1.5 to 3 months ahead, and for larger efforts of multiple teams (a Kanban Program) 3 to 6 months are advisable.

The Spirit of Agile Planning

You may say, but why are those horizons picked, what is the rational that Scrum, SAFe and Kanban are using?

In short the Spirit of Agile Planning is to see the future in a way that the plans are useful, and beneficial, and not a waste of time. Plans become a waste of time when they become useless because reality on the ground has made them inaccurate, and wrong.

So the Spirit of Agile Planning means that your plan must match the needs of your product, your team, and your environment.

In you are building hardware, plans are usually at least a year long, because you need to manufacture. If you are building software or apps, the horizon will depend on the level of competition, and your industry, it usually hovers are around 3 to 6 months.

Remember as we move further from the present, plans become more and more wishes, and not realities. Agile planning should establish good foundations to build, and move forward. Carefully choose the planning horizon that makes sense for your reality and helps you deliver!

As an experienced Agile Consultant, certified in several methods and frameworks including Scrum, SAFe and Kanban I have a distaste for magical solutions.

Nothing is perfect, everything has flaws.

Yet, I still recommend a Kanban Variation to most of my customers.

Why?

Kanban, contains the wisdom of the Lean movement, and it also knows the powers of Agile. From the Lean side you get the ideas from the Goldratt’s Theory of Constraints, the clear thinking of Toyota’s Kanban, and the innovations that came from David Anderson and the many Software Managers that adapted Kanban to knowledge work.

Kanban allows you to improve on any method, or framework, and absorb it into the boards, and the method. The boards can span whole companies, they can be hierarchical, or they can show the work across divisions easily.

Even better as we showed many years ago, Kanban can easily incorporate Scrum events, and even roles if needed.

We explained this in detail on this article, on the section entitled the Akashi Bridge: here. You can see the tool itself, below, this image shows how a large Kanban board can manage both the flow of work, and also the flow of the Scrum events in a single view, allowing improvements over Scrum, while at the same time operating all the work under the Kanban flow umbrella:

Like Mixed Marital Arts, Advanced Kanban can take mix and combine ideas and techniques from many Agile and Lean sources into an EFFECTIVE method to deliver results.

Contact us for details, we are sure we can help you improve, we see the Big Picture to deliver BREAKthrough results.

In any large organization, and that includes businesses and government, the people who run that organization constitutes their Bureaucracy. Inside every Bureaucracy you will find two kinds of people:

• Some people who are actually devoted to the mission of the organization and that is to serve customers who need their services. Typical examples are dedicated classroom teachers in an educational bureaucracy, or great doctors in a socialized medicine bureaucracy.
• Unfortunately, there will also be those who are dedicated to the organization itself. Whose main goal is either to do next to nothing, and still get a paycheck, or to climb the organization’s ladders to get more power and money.

The Iron Law of Bureaucracy states that in every case the second group, let us call them the self-serving Bureaucrats, they will gain and keep control of the whole organization. They will write the rules, control promotions, and do very little to serve the customers or the public.

This is a powerful anti-agile pattern in action. And it’s also the reason behind government’s consistent low quality services in many countries. A similar phenomenon happens when a company gets large and has close to monopoly control of any market, those giant corporations usually behave to benefit themselves and not the customers.

A couple examples: have you tried to get a Google employee to reply to one of your customer support emails? It is near impossible to talk to a human being at Google. Contrast that with companies with lots of competition, like Hotels. Usually, you can find a multitude of ways to talk to a human being at any hotel.

Agile and Lean methods, frameworks and practices help private companies and governments fight this negative trend. This is perhaps one the greatest contributions Agile, Kanban, Lean Thinking and the Theory of Constraints have done for people and society, to put the customer we intend to serve front and center.

Jerry Pournelle, was the first to notice this pattern in 2010, I have updated it to cover the behavior of large organizations today, and how Agile & Lean can help.

In the last five years SAFe or the Scaled Agile Framework has experienced tremendous growth and adoption at large organizations. The evidence is not just in surveys, such as the large one conducted by Digital AI which I share below, but also by simple word of mouth that confirms many large organizations are adopting it.

However, SAFe has plenty of issues which are undeniable:

• High level of complexity,
• Long planning events, and even planning for those events,
• An everything-including-the-kitchen sink approach to their methodology, every year it grows, and adds more stuff which makes it unwieldly and hard to fully comprehend.

For these reasons, and also because of some unhappy customers, including Scrum Masters and Agile Coaches, SAFe does trigger strong negative emotions on many.

However, there are very few well organized approaches that are valid alternatives to SAFe right now. Large Scale Scrum, DAD, and Nexus have had minimal success at scale, and even LKU’s Kanban has few large scale implementations.

So what to do? Our first recommendation is not to criticize what’s obviously broken, or sub-optimal in SAFe, but to focus instead on the good parts:

1. The synchronized cadence for all teams in an organization or division is a brilliant idea, follow it. Call it iterations, or Sprints, or anything you want, but have it.
2. Using Kanban for Portfolios, and Programs is right, and commendable. We would add to that that you consider using Kanban for Marketing, Sales and HR as well.
3. The Program Board is the best visual way to show dependencies that I have found in a long time, we do recommend using it if needed. Of course it is better if you could remove the dependencies themselves, but that is another discussion.
4. The idea of quarterly agile planning across teams is a good one, you don’t have to follow their recipe, but doing it is smart.

Now for the most important second step, find a very experienced Agile Coach who has done many Agile Transformations using Scrum, Kanban and SAFe, and who does not show a bias to any approach, but wants to use the best from each. Working with this professional, create a custom agile approach for scaling agility at your organization.

Remember: the goal is to add the minimum amount of agile processes and know-how to make your organization more effective, and efficient.

Over 10 years ago, a lifetime for the technology world, Henrik Kniberg, famous for the Spotify Model, and his brilliant videos for Product Owners gave us a guide for Kanban teams that do software development.

A few years later Yuval Yeret did his own revision to Henrik’s guide but focused this time on Marketing.

Both were generous enough to make the work part of the Creative Commons, and allowing a remix, and updates. Thank you both.

In our consultancy we have worked with many software engineering companies, and also marketing agencies, and departments that need to have this introductory guide and template.

We felt it was time to update these diagrams, and share them with the Kanban community at large.

So here they are both, first an update to the Kanban Software Engineering Guide:

And next the Kanban Guide for Marketing updated for those who want to use it in an agency or marketing area:

If you have other ideas to adapt this work to HR, Security, Compliance, or even Smart Contract development in the crypto industry let us know, we’d be happy to include your updated diagrams here, or link to your articles or both.

To make it easy for you to use this diagrams, below are the PowerPoints for the Software Engineering diagram, and also the Marketing one. We just ask you to give credit where credit is due. Enjoy!

kanban-kick-start-henrik-kniberg-yuval-yeret-joseph-hurtado-v2_softwareeng

kanban-kick-start-henrik-kniberg-yuval-yeret-joseph-hurtado-v2_marketing

On occasion as professionals we observe what seems to be irrational behavior, something that seems to defy logic.

After years of seeing this “irrational” behavior in managers, co-workers and consultants I realized it is usually not irrational, just hard to comprehend.

Most decisions people make involve a complex array of factors, many of which are hidden from us, but clear to our co-worker, manager or customer.

Three categories are particularly important to comprehend what’s going on:

1.- Personal goals.
Decisions sometimes align with personal goals, not company goals. It may not be rational to you, but is rational to the decision maker. One example I saw once was how a Cloud Provider was selected based on the resume impact on the customer.

2.- Gut based Logic.
This is sometimes called “Emotional Intelligence” or Feeling based intelligence. You may call it what you want, but it’s a decision based on intuition, previous experience, and yes feelings!

That is why seldom a consulting sale is made to someone the customer does not like. Gut based decisions are often correct, do not under-estimate them.

3.- Fear or Lack of Knowledge
Unfortunately on occasion our co-worker, customer or even manager may have reasons to fear change, or simply not really know the benefits of an action that may seem very logical to us, but not to them.

It is our role in these situations to be understanding, and help them overcome the fear. We must build trust, and show that we are trustworthy, and that we truly care about the person we have in front of us.

A Deeper Lesson

Billy Graham once said “Confidentiality is the essence of being trusted.” That is a deep truth. Do you want to influence people, do you want to truly contribute to their companies or personal wellbeing? Earn their trust: BECOME TRUSTWORTHY.

Only then they will confide with you their personal goals, share their gut logic, or disclose their fears or lack of knowledge. When they do, be grateful, keep secrets, and share your advice. Not only will they listen to you, but one day as you gain their trust you will become a friend, and that has immense value.

Scrum is the undisputed leader among all Agile approaches today, survey after survey confirms that it is the leading choice for organizations that want to improve their efficiency, and speed their time to market.

However, despite their success Scrum still continues to revise and improve their own framework, their original authors Ken Schwaber and Jeff Sutherland listen to Scrum practitioners, and customers for guidance on how to make it even better. Once agreement is reached a new Scrum Guide is published.

This time the new 2020 Scrum Guide coincided with the 25th Anniversary of Scrum, so on November 18 2020 a live online event was used to celebrate the occasion, and to introduce the new Scrum Guide to the world. The authors of the guide were present, and even better one of them Jeff Sutherland actually took questions from a live audience regarding the motivation behind the changes.

This summary goes over the changes between the 2017 Scrum Guide and the brand-new 2020 edition, but unlike other articles you may find online, it also goes over the reasons behind those changes, as explained by the authors of the Scrum Guide themselves.

Here are the main changes, and the reasons behind them grouped into four categories.

I. Wider Audience for Agile Transformation

The typical market for Scrum has always been the technology sector, in particular software development firms. That is the reason behind the use of terms that come from the Technology, and Software Development areas.

However, increasingly Scrum is reaching beyond software development to areas such as Marketing, Product Development, HR and Finance. It was time then to revisit the Scrum Guide and make sure the jargon is more universal, and more welcoming to all areas of an organization. Ken and Jeff were quite proud of this achievement

.

The 2020 Guide accordingly has done their best to use words that would be easily understood by anyone in an organization, not just the “IT Crowd.” Also you will notice that the section previously called “Uses of Scrum” is gone, the expectation is that Scrum can be used in any organization.

Furthermore the term “Development Team” role does not exist anymore, instead a “Developers” term is used to encompass “the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.”

Another pleasant surprise was to find a direct reference to Scrum’s Japanese Lean heritage with this quote that summarizes a whole body of knowledge inside Toyota’s Production System, and Lean Manufacturing: “Lean Thinking reduces waste and focuses on the essentials.”

II. Scrum Event Changes

They are mostly geared to simplify, or empower the whole team in new ways to achieve the same goals. These are the main changes.

1. Daily Scrum

• The Daily Scrum no longer mandates the use of the traditional 3 questions, instead the Scrum Team or the Scrum Master can now decide how they invest those 15 daily minutes to achieve alignment and make progress towards the Sprint Goal: “The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.”
• I am certain this will be good news for most teams, since it will make the meeting far more useful than a status meeting.

2. Simplification of the Sprint Review

• Compared to the 2017 Guide the current Sprint Review guidance is far more straight forward, and to the point. The goal remains the same: inspecting the outcome of the Sprint, but the way this is done, and communicated is left mostly to the team, and the Product Owner. The Sprint Review is also now considered a good time to Refine the Backlog if necessary.

3. Co-Leadership of the Sprint Retrospective

• The event is now lead by the team who may designate anyone to lead it, not necessarily the Scrum Master as it was recommended before.

III. Enhancements to the Scrum Artifacts

The Product Backlog

It is no longer considered “an ordered list of everything that is known to be needed in the product” instead it is viewed as an emergent ordered list that guides the building of the product.

The Sprint

The 2020 Guide now makes refinement an important part of the work, even inside the execution of the actual Sprint: “The Product Backlog is refined as needed”

Several approaches to forecasting are mentioned, but the emphasis is put in none, instead empiricism is recommended to focus on what actually works: “Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.”

Product Goals

Scrum now has three levels of commitments associated with the work the team delivers. As before we have Sprint Goal to guide the deliverables of the Sprint, and a Definition of Done to guide the individual items but now a new element is added: the Product Goal.

The Product Goal guides the overall building of the product, and it’s considered a long term commitment, not supposed to change unless it has been achieved or a major change is deemed necessary:

“The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.”

IV. Changes to the Scrum Roles

Role of the Scrum Team

Previously the Scrum Team was considered to be both self-organizing, and self-managing. The new guide removes the term self-organizing, keeping only the term self-managing.

Why? On the surface this may seem like a minor difference, but as Jeff Sutherland explained the difference is significant. Previously some Scrum Teams abused the self-organizing, self-managing mandate to become disconnected from the urgent needs of management, and the company that hired them.

To correct this the current guide maintains self-management since the team is the one that can best decide the best course of action to deliver the work, however, organizing the way the team works is now squarely in the hands of upper management, since they are the organization’s leaders responsible to the rest of the organization and the customer.

Role of the Scrum Master

Gone is the term “Servant Leader” which led to much confusion. During the Q&A session of the launch event Jeff Sutherland was asked what was the reason behind this change. He explained that many Scrum Masters have mistaken the Servant Leader term, and had refrained to become true leaders for the team, with some even becoming close to note takers, or guides.

The expectation now is for the Scrum Master to become a leader first, one who serves the Scrum Team as he did before removing impediments, and coaching the team to better use and master Scrum; but now a renewed emphasis is put into impacting the larger organization including upper management, and the Product Owners.

Conclusions

Overall I truly think we have the best Scrum Guide ever, with a wider appeal beyond technology, a more flexible approach to the Scrum Events, and a revitalized Scrum Master role. What about you, what do you think?

Sometimes people ask me, Joseph what’s the simplest Kanban board I could use, one that may even work with a small team?

On those occasions, I am tempted to recommend Trello, but the fact that it does not even have support for Work-in-Progress limits, or mentions Kanban support anywhere dissuades me. Trello seems to have turned into a super-big todo list that uses columns, leaving their users completely ignorant about Kanban.

Today it just happened that I needed one such minimal board, and I thought why not Excel? So I decided to go one better: Google Sheets!

If you need the board to be private, and off-the cloud, easy just download it, and use it with your favorite desktop spreadsheet, I actually like Apple Numbers, but of course there is MS Excel too. And guess what they all have Cloud versions these days, so you have freedom, I hear Apple has better privacy than Google so choose wisely.

Not matter how you choose to use it, here is my Free Minimal Kanban Board, ENJOY!

P.S. If you want to know what’s this Kanban thing, go here or here for a quick high level intro.

Today the vast majority of people think Kanban looks like that picture on top, just some rows and columns of an unusual looking to-do list. And they would be mostly wrong, that’s literally the tip of the iceberg.

Kanban, unlike Scrum deals with systems, large or small. But it thrives in large systems where many teams have to collaborate to build something. How big are those teams of teams? From dozens of people to thousands!

What about WIP, what is it? Well, in short it means Work in Progress. But it involves much more than that. WIP gives you an idea of how much can be accomplished at each stage of the system. And even more important it should help you find the key chokepoints of your system.

Let me explain, imagine you have a top-notch development team, and they deliver about 25 stories every two weeks. However, the marketing team, the ones who give them the stuff to work on, can only provide about 10 fully fleshed out requirements. Who is the bottle neck? Marketing! What is the constraint: 10 stories the WIP of the marketing done column!

What to do? Well then you have the gamut of techniques to deal with constraints, courtesy of Goldratt. In short you maximize what you can do with that constraint, you provide more brainpower to the constraint, or you find a way around it.

WIP analysis becomes quite useful then to improve overall system performance. Not team performance, system performance! The bigger the view you get into the value stream, the bigger the potential improvements you can do.

A way to visualize this Kanban view from the top is to consider Klaus Leopold’s Flight Levels visualization below, as you can see the most effort, the most impact comes from the top, not the team or operational levels. Inside my own consulting practice, I call this concepts, KAFE’s Gear Levels.

The fact that Kanban can bring higher efficiencies, and bigger impact at the top is the reason it can be much more impactful than Scrum, and probably the reason why SAFe uses this concept as well. Because the higher you go, the more you can improve the flow and efficiency of the organization.

There is of course an elephant in the room: radical improvements via a Lean Agile Transformation. These wins are possible when we do not just evolve, or adapt to better manage flow of work; but instead decide to re-design the organization or part of it, to fit like a glove the needs of the customer, and reduce costs and feedback loops too.

KAFE calls this creating a new MOVEMENT, similar to building a better way to tell time inside of a mechanical watch by re-engineering the way each part works, KAFE’s Movement represents the Lean Agile effort to build a better organization, either by improving how the organization works in one division, or eventually affecting the whole company. This is the secret of high ROI for Agile Transformation, transform the nature of work, and the way it is organized to deliver value, so that flow is optimized, and waste is reduced across the board.

As many of you I am a bit shocked by the severity of the corona virus pandemic. I’ve been reading a lot on biotech, bioweapons and bioengineering. Enough to realize it’s certain this will happen again in our lifetime.

I decided to write a few lessons to learn from this plague:

1. Every nation must build a #pandemic fighting force, one that reports to the president or PM, is well funded & has access to people, supplies & specialists to win. This will happen again.

2. Borders work. They do help to reduce the speed of any #pandemic. Use them.

3. Integrated global supply chains can be great, but they are a dangerous thing when a pandemic strikes. Nations should have critical medicines, and machines inside their borders.

4. Bioweapon research & development should be treated the same way as Nuclear Proliferation. The Biological Weapons Convention is not enough to prevent an evil force from attacking humanity
   

5. People in every nation should maintain a reasonable supply of essentials. We should never need to hoard, or fight for supplies when the next pandemic strikes.

6. Finally when this pandemic is over, people will forget.

   NATIONS SHOULD NEVER FORGET. Because it’s certain it will happen again. We have too much dangerous research on bio-engineering, bio-science, and too many bio labs working with dangerous bacterias and viruses to pretend it will never happen, it will.

Releasing software today has many options, they vary in risk profile, and in the way they are performed. In this article we will do a summary of the main options available today. This is a valuable tool chest to have in mind in your road to better releases, less risk, and more peace of mind, in short in your road to DevOps.

High Risk – Big Bang Release

These are usually done or one or twice a year. They are high risk, high profile efforts, that may have a big positive, or a big negative consequence for a company. They also have set deadlines, and can be quite stressful for the whole organization.

Why do businesses still do this? Mainly because they lead to massive events, which can attract a lot of attention. Because of this reason, this large organizations like Apple, Google or Amazon will continue doing these events. What are those advantages? In brief:

• Marketing can build a case for the new release, and highlight the best features they have to offer for current customers, or for people considering their product.
• Journalists and influencers are also invited to the release event. It’s the best time for the company to address their questions, and explain in detail what is being released, including new products.
• Customers usually enjoy participating in the event via news, live video feeds, and social media. Buzz is built in the market.

Now, if your company has a small or middle sized, and it won’t benefit from these kind of large events, I do recommend that you avoid them: they are high effort, high risk, with fixed deadlines. Fortunately, even if you decide to use this large events, all the deployment options detailed below will help you reduce the risk of a big bang event.

Medium Risk – Beta Opt-In Release

Live in production, but done in public inviting users to participate in a public trial.

Apple frequently does this with the help of their registered developers to test pre-release software either for the iPhone or the Mac. Microsoft has also taken a similar approach with Dot Net core, releasing many beta versions to willing testers.

Low Risk – A/B Testing Releases

Live in production, but only for a percentage of users who are unaware they are part of a test. Marketing is usually behind the testing, working along with one or more software engineering areas.

This is typically done only for online web products, and it’s a widespread practice to improve the effectiveness of a website. On the web you never know if you are running the exact same software!

Low Risk – Canary Release

Live in production, but only for selected users who are willing to take the risk of using unstable software. Users selected are usually interested some key features, or they are willing to accept some risks. A typical example is Google’s Chrome Canary software.

If you wonder why the canary name, it actually refers to an old technique mining crews did whenever they went deeper into a mine, and air could be scarce. They would bring along a canary in a cage, as long as the bird was alive and chirping happy all was well, otherwise time to get out!

Lowest Risk – Feature Flag Release

Live in production, but dormant features. Ideal to put production tested code live, but dormant waiting for a date when the software will be revealed to the world. Even better the software can be turned on or off, if a failure is detected on actual enable day.

Special Case – Blue / Green Deployments

This is a strategy exclusively used for web based software. Green represents the latest stable reliable software in production now online. Blue is the candidate release. They are orchestrated through some kind of load balancer or reverse proxy.

When a new release is deployed, both versions of the software are left running online. If all goes well after a week or more, the new software is deemed Green, and Blue may be decommissioned. If anything goes wrong, the old software can replace the new one, and full rollback is done is seconds.

Recommendation

The key principle across all deployment options is this:

Releasing software more often, and having your software used by actual customers before you go live to production is the best and safest way to ensure high quality, reliable software. Moreover releasing high quality reliable software will lead you to gain loyalty from your customers, and gain new ones.

My advice would be to combine these practices, to create a Low Risk Deployment Strategy. The road to DevOps and agility aims to achieve high quality reliable software, these tools will help you get there, but it’s up to you and your organization to lead and embrace them.

Version: 1.0.1
Image Credit: Wikimedia Commons, Google IO Event 2019

In my experience working with Scrum for over a decade, the main challenge with the Product Owner role that Scrum recommends is that the people who usually perform that role have limited understanding of software development, and have different measurements for their job success than the Development Team. For these reasons these POs usually care little about Scrum’s description of what the role should be. More often than not the PO cares mostly about getting more features done, and little about sustainable pace or technical debt.

It’s easy to understand the problem once you realize who the PO works for:

– He is usually part of a lager product management team, and he responds to larger concerns they impose on him, in particular he may be overwhelmed with too many teams he has to work for.

– On occasion he is part of Sales team, and acts as either a revenue maker, or a revenue facilitator. Here his main concern is listening and responding to customer demands, to generate sales, not so much to building quality features.

– Finally the PO may be a part of the PMO, or the Business Analyst team; this case is one of the best since he will truly be a point of contact for all things requirements and usually cares about the PO role, but still his key concern is delivering the project, or making the business happy.

Of course there are some POs who actually perform an amazing agile role, and truly have authority over the product they lead, and even understand software development well, but these are in my experience very few.

What do you think, how has the Product Owner role happened for you the Scrum teams you’ve led or worked for?

Keywords: #scrum #agile #productmanagement

Some who hear about Agile’s thoughts about self-managing teams often make the mistake to think that there is no discipline or structure in the several Agile Methods and frameworks such as Scrum and Kanban, but nothing could be further from the truth.

Agility lies at the crossroads of both freedom and discipline. The careful applying of both forces simultaneusly brings effectiveness, optimism, solidariy and a sense of humor to companies and teams everywhere.

Agile is neither the anarchy of the workers, nor the dictatorship of management, but rather the careful balance of both to establish the Republic of Good Will towards all. This balance is the secret of true agility, it enables everyone to work together, and enjoy their journey!

Fake Deadlines are the biggest life sucking hole
in the history of business.

Fake Deadlines do not follow reason, they are
illogical and capricious.

Fake Deadlines waste the most valuable asset of
a company: their people.

Fake Deadlines are evil because they do not
lead by inspiration, they lead by fear.

Fake Deadlines cause stress, lack of sleep, heart
attacks, strokes, and health problems to millions.

Fake Deadlines are one of the worsts sins
of management because they don’t benefit the business or the employer.

Fake Deadlines grow under the disguise of productivity
and efficiency, but instead they deliver 
bad quality,
higher costs, and human suffering.

Whenever you see a Fake Deadline Good Management and
Agile demands that you be courageous and tell the truth.

However, Lean advices you to be prudent and
tell the truth while you follow the Nemawashi Way.

Nemawashi tells us to carefully raise a coalition
for the truth, and wisely bring positive change.

When all Good Managers, Agile and Lean practitioners
unite against Fake Deadlines they will be defeated!

Remember that every time a Fake Deadline is
beaten, you are delivering quality, real productivity, peace
and happiness to your workplace!
Say no to Fake Deadlines!

To bring positive change to an organization it is vital to build a coalition, to carefully raise awareness about a better way to do things, and to do it in a way that respects management and the people in the organization.

Japanese management has a unique practice that teaches us how to accomplish this, a practice that Lean has used and that we embrace as a fundamental part of KAFE. In summary the Nemawashi Way involves the following steps:

• Find as much as possible about the roots of the bad business practice, bad metric, or fake deadline that needs to be corrected
• Finding out who are the people in authority that need to be convinced to bring about positive change
• Informally gather support from like-minded professionals in the organization to build consensus
• Informally talk with the people in authority to see what level of positive change can be implemented
• Once support has been achieved from the people in authority, call for a formal meeting to make the decision official. If possible full change will happen, but otherwise gradual change will begin.
• Finally implement the change!

If you wish to know more from the Japanese cultural links to Nemawashi today, I recommend you read this article.

“Companies rarely die from moving too fast, and they frequently die from moving too slowly.” Reed Hastings, Netflix

In the last 3 years, Agile has leaped beyond Software Development & IT to find receptive ears in the offices of important CEOs and their management teams. This time unlike what happened in the early 2000s the companies adopting Agile are large corporations that recognize the value that agility brings: happier customer, better collaboration, faster product cycles, and innovation.

Agile was born inside the world of Software Development¹ and IT, after the Agile Manifesto was released in 2001 it experienced high levels of adoption around the world, particularly in North America and Europe. Nowadays surveys put familiarity with Agile within IT departments at over 94%, most CIOs and CTOs have either adopted it already, or are in the process of improving or extending what they already have. In addition Agile is growing beyond software development into other key IT areas such as: Operations, Big Data, Cloud, Security and Agile Program Management. Why? In a word: success. Agile has proven beyond a shadow of a doubt in case after case that it accelerates IT’s time to market, elevates software quality, increases customer satisfaction and helps build stronger morale and participation in IT.

This success in IT has not gone un-noticed. After almost 20 years of success finally CEOs, CMOs, and CFOs have grown interested in the CIOs “secret toolset.” In fact, the latest real world Agile Transformation are happening beyond software development at large corporations such as Comcast, FedEx, John Deere, Microsoft, Sony, Walmart, JP Morgan, Ericson and Barclay’s Bank.

What’s more last year the most important publication of traditional management: The Harvard Business Review did a landmark article entitled “Embracing Agile”² which shows without a doubt that Agile has crossed the chasm of early IT adopters and is now moving to become the new norm of modern management. This quote from that article makes the reasons why this is so quite clear:

“The spread of agile raises intriguing possibilities. What if a company could achieve positive returns with 50% more of its new-product introductions? What if marketing programs could generate 40% more customer inquiries? What if human resources could recruit 60% more of its highest-priority targets? What if twice as many workers were emotionally engaged in their jobs? Agile has brought these levels of improvement to IT. The opportunity in other parts of the company is substantial.”²

This trend goes far beyond DevOps which focuses on uniting the IT Division under a common umbrella of agility, technical excellence and efficiency. Agile for the whole company aims to bring the benefits of agility to the whole company.

Reasons for Agile in the Enterprise

Management has noticed that many of the reasons that made Agile adoption necessary for Software Development and IT have now become very real for their whole company, namely:

• The Speed of Change.
  • Technology and having the Internet everywhere are dramatically changing all industries, especially by accelerating change. This acceleration in change has become an strategic threat, but also an opportunity, and even big businesses are affected³. Ray Kurzweil summarized the decades we are living this way: “the 21st century will be equivalent to 20,000 years of progress at today’s rate of progress, which is a thousand times greater than the 20th century, which was no slouch to change.” ⁴
  • Tesla is an example of a company that leverage the speed of change to their advantage, and now they are challenging traditional car manufacturers ⁵ Netflix is doing something similar with the movie and cable industry, and Apple did it with Nokia and Blackberry through the iPhone.
• A Demanding and Well Informed Consumer.
  • Companies do not have the luxury of years between product launches, or lack of upgrades, consumers can usually switch with little or no effort between alternatives, we are living in the era of the fickle consumer ⁶. Product Cycles are shrinking and Time to Market has become critical. Competitors appear from anywhere with frequent updates and innovations. Traditional 5-year planning has hit a wall, and there is a need for releasing products at least yearly, with cross-functional teams, and tight collaboration between product design, marketing, customers and software development. Agile offers a variety of ways to do all of this via many Agile methods and frameworks available today. In fact most startups today have embraced Agile already, and the established companies have noticed.

What is my Best Option to Embrace Agile Across my Whole Enterprise?

To answer this question, you need to know a bit more about the Agile methods and frameworks, that way you will understand your options. Let’s do a quick summary. During the first decade of Agile from 2001 to 2011 two Agile methods reached dominance: first Extreme Programming and nowadays Scrum. The former has waned considerably in influence, but continues to offer valuable technical practices for software development; while the latter has grown significantly in many software development areas and IT departments, IT industry surveys put Scrum adoption at about 58% versus other Agile alternatives today⁷.

Limitations of Scrum

Despite Scrum’s success it has struggled to grow beyond IT and Software Development. Part of the reason is that it was initially designed for IT and software development, and the same ideas that made it succeed inside of IT make it hard to adopt in the larger enterprise. As I write this, I realize this may sound controversial to Scrum devotees, but let me assure you that I do like Scrum, furthermore I am a Certified ScrumMaster, so these lines come with much respect and experience with Scrum and many other Agile and Lean methods and frameworks.

Scrum is a transformational framework, in order for it to work it calls for a revolution to the way work used to be done. Key foundational parts of Scrum are:

1. Small Team Focus. Scrum was designed to work with teams between 3 to 8 people. It has proven to work very well on this context, especially for software products.
2. Self-Management. Which means the team largely organizes itself on the way it solves the challenges ahead. This usually means that other managers are either eliminated or converted into ScrumMasters.
3. Three Roles within a Team. Scrum recognizes only three roles within a team: Developer, ScrumMaster and Product Owner. These are quite useful for the developing of software, but can very limiting in other contexts.
4. Multi-functional Always. Meaning the team must have all the people it needs to build a product, or required functionality for a service.

Now within an IT organization that makes the effort to transform itself Scrum can bring many benefits such as increased speed of releases, happier product management and a happy customer.

However, beyond IT the transformational nature of Scrum becomes a challenge since every aspect of it brings a corresponding challenge and resistance:

1. Political and Leadership Challenges from Management. They come as a consequence of Scrum’s demand for self-management, and a perceived lack of recognition of the value that management can add to the organization. This leads to friction and resistance from many business areas that see Scrum as a threat.
2. High Cost of Adoption. Mainly because Scrum ignores specialist roles in a variety of industries (such as Data Scientists, Actuaries, Security Experts, Corporate Lawyers, Cloud Architects) calling instead for cross functional teams in all situations. Many companies can not accommodate this structure because of real budget constraints.
3. No Portfolio or Large Team Agile Structure. Because Scrum was designed for small teams from 3 to 8 people it struggles once the teams become much larger. It has no built-in mechanism and Agile techniques for orchestrating large Agile teams of 100s or 1000s of people.

Attempts have been made to try to address these limitations from a Scrum centric view. The most well-known is Large Scale Scrum or LeSS⁸, and although LeSS does address the needs for Portfolio or Large Teams it keeps the other two key limitations that I mentioned above, for that reason the amount of transformational effort they demand is significant, since they must deal with the management challenges that come from attempting enterprise wide self-management, and enterprise wide multi-functional teams. This article will not focus on LeSS for those two reasons, however if your organization is already heavily invested in Scrum, we recommend you evaluate LeSS, it may work for you. LeSS has talented, great people behind it.

Market Trends Among the Agile Scaling Frameworks for Large Organizations

VersionOne began tracking agility at scale three years ago in their 2015 Annual State of Agile. This is not ordinary survey, they received over 20,000 responses for their last 11th Annual report in 2017, and it keeps growing. We are grateful to them for continuing to share this valuable data, and we encourage you to participate on the current survey⁹. Since then they have published three surveys, and now we can finally examine some trends. We have analyzed their findings and created the chart below for your analysis, as you can see it shows that although initially “Scrum of Scrums” was the most popular option to scale agile, interest fell considerably and it now is slightly below SAFe. We think that part of the reason is the limitations we examined before on this article, and others related to the appearance of other competing alternatives.

On the other hand, the graphic shows that the Scaled Agile Framework¹⁰ has steadily grown, without a doubt the market and the people of IT have noticed the extensive knowledge and experience it has accumulate to bring agility to large corporations, and big technology teams.

Personally I believe there is no silver bullet for agility at scale, agility at the enterprise level is a significant challenge that should not exclude other ways beyond SAFe, Scrum and Kanban, a point I have written¹¹ about. However it is also true that SAFe does offer a compelling toolset for this particular mission, and the rest of this article will elaborate on this further.

SAFe – The Best of Scrum and Kanban Together to Achieve Business Wide Agility

SAFe builds on the strengths of both Scrum and Kanban, from Scrum it uses at the team level where it excels, from Kanban it leverages its flexibility, Lean Thinking, and visualization power to manage work at the portfolio and program levels.

Most people are familiar with Scrum, but few are familiar with Kanban¹². So, let us elaborate: What does Kanban bring to the Program, Portfolio and Strategy levels that makes it valuable? Kanban adds three important features to achieve agility at scale:

1. Acceptance of Business and IT Roles. Unlike Scrum, Kanban does not impose new roles or responsibilities, it works with what the organization has in place now. It improves from there. Kanban welcomes leadership and management, it sees both the team and management as key stakeholders in producing value.
2. Visibility at the Program and Portfolio Level. Kanban boards bring visibility of work not just to the team level, but they unlock hierarchical, aggregated views into the Portfolio and Program levels. Boards can even map whole value streams across many companies.
3. System Level Improvement of Value Streams. Kanban is able to understand, examine, and improve whole value streams, and large systems across many organizations and locations. This is possible thanks to the knowledge-base Kanban has received from Goldratt’s Theory of Constraints, Toyota’s Production System and Lean Thinking over many decades.

It is quite likely that those advantages motivated over 71% of IT professionals surveyed by Gartner¹³ to report that they are using Kanban to practice agility at scale. This also explains why SAFe has incorporated Kanban as the way to design their system for agility at the Program, Large Solution, and Portfolio levels.

To illustrate below is a sample SAFe portfolio view of initiatives a company is executing. Bear in mind that each card represented could be a whole board, in fact some software products allow you to drill-down from the portfolio level view, down to the team. Notice also that this level of visibility is facilitated by portolio level Kanban boards that are designed with SAFe in mind. The example from LeanKit shows a portfolio Kanban board¹⁴ with SAFe.

SAFe leverages the 3 key advantages Kanban brings to the table to serve the enterprise. And coupled with SAFe’s support for Scrum it becomes a powerful framework. In the last 3 years, the Scaled Agile Framework has experienced steady growth and increased adoption, in part because of this pragmatic approach. Several case studies and customer stories are available such as the ones from: Sony Playstation, Rosetta Stone, HP Enterprise, TomTom, Accenture, Intel, John Deere, Phillips Medical, Astra Zeneca, and many more¹⁵.

SAFe’s Secret Sauce

SAFe’s secret sauce is a deep understanding of large businesses, and organizations, they know their challenges, and also their pressing need to become faster, and more responsive than even before, they need business wide agility. This secret sauce is evident by the breadth of knowledge the framework has regarding enterprise roles, governance, compliance, and upper-management expectations in IT and beyond. SAFe welcomes specialists, PMOs, Project Managers, compliance officers, Security Specialists, and management. It provides a clear path to scale agility with the teams already available by leveraging its own know-how, Scrum and Kanban.

SAFe does not compromise agility, it emphasizes quality, efficient flow, high-throughput of value, and much more; but it fits the enterprise from the CEO down to a single software developer. That allows agility to become a Strategic Advantage!

On the subject of DevOps SAFe also embraces this increased efficiency for IT, the latest version of the framework has clear guidance on how to achieve this vision within the whole of IT, SAFe calls it the CALMeR approach to emphasize the connection between Culture, Automation, Lean flow, Measurement and ability to Recover from any release.¹⁶

SAFe is a vast Agile framework. So, if you ever see the Big Picture diagram either printed or on SAFe’s website you might feel intimidated, do realize however that what you are seeing is a blue-print for agility for organizations the size of Boeing or Walmart. SAFe is designed to accomodate large businesses with thousands of people, but it can also work with medium-size businesses, it starts above 50 people. For smaller organizations consider other Agile approaches like Kanban or Scrum, but if you are facing enterprise level challenges I encourage you to give SAFe a serious look, I think you will like what you find.

Finally if you would like to evaluate SAFe or Kanban to scale agile in any area of your IT organization, Agile PMO, Strategic Marketing, or across your whole company do consider us as your guide in this journey, we will always remain impartial in your search for Strategic Agility, we welcome Scrum¹⁷, and we will work with you to find the best solution that fits your organization today.

References

Agility is a higher concept than just Agile. One we should embrace more. When a business pursues #agility it opens wide avenues for improvement, not just through one framework or method, but an open-minded approach to get better, and never stop improving. Agility goes beyond technology, or Agile Transformations. It seeks three main goals: do things faster, do them better, and truly care for all people.

As Agile Coaches, and Agile Managers it is time to see Scrum, SAFe, Kanban, XP, DSDM, DAD, and so many others as tools for agility. Agility has the power to revolutionize work, but even more important it can make business and organizations better anywhere, not just IT.

But how, when many frameworks & methods attack each other? By refusing to engage in the agile wars, and instead focus on people & customers.

Only then agility will become reality across large and small businesses, non-profits, governments and startups. We win by flying higher. We can make it happen.

The philosophy behind Agile, Lean and Kanban can go beyond business projects or products to actually inspire our life, our dreams, and personal projects. Guided by this fact, and also by the writings of Bre Pettis and Kio Stark, I give you the 12 Commandments of Done, hoping they can inspire you to conquer your mountains:

1. Thou shall not procrastinate. Today you shall start, tomorrow may never come. Today is your present.
2. Thou shall focus. Distraction is the way to failure; only concentrated effort leads to results. Like water can be harnessed to cut metal, so can your mind be concentrated to achieve the impossible.
3. Thou shall have a vision. Every large effort requires a dream, an inspiration to go higher, without that clear vision we lose hope. Remind yourself of that vision, and have faith you will achieve it.
4. Thou shall not waste your efforts. Remember activity, just doing something does not mean progress. First find out what is the wise way to make progress, never walk blind, understand reality, and never punch the air.
5. Thou shall stop analyzing and do things instead. Planning has some value, especially when it paints a vision, and leads us in our walk. But never allow analysis to become a never-ending quest that leads you to paralysis.
6. Thou shall recognize that the path is found while you walk forward. One cannot see the future, without walking towards it. Therefore, start walking, and notice the road ahead.
7. Thou must rest, and follow the rule of 8s. Remember you are a fragile human being, without rest your health, and your mind are doomed. 8 hours for work, 8 hours for your life and chores, and 8 hours for sleep. And give yourself one day of real rest each week. You can bend this commandment, but you will always pay a price for doing so.
8. Thou shall have smaller achievable objectives on your way to your big dream. Nothing frustrates more than never seeing the end of a tunnel. Therefore, make sure your plans lead to small victories along the way.
9. Thou shall never lose heart. Without enthusiasm, with no love for what you do, nothing worthwhile can ever be achieved. Protect your heart, make sure you enjoy the work.
10. Thou shall ask for help when needed, and be generous with those who bless you. All worthwhile efforts need more than one person, carefully find those kindred souls and be grateful for their help.
11. Thou shall learn from your mistakes. Remember there is no failure, when we learn even failure help us to progress toward the goal. True failure is abandoning your dreams, and doing nothing. Be a winner, do something, and keep doing it, victory shall come!
12. Finally thou shall recognize that the highest inspiration comes from above, and not from inside or even around you. For that reason, honor God in your life. Live your life to do good, and make this world a better place.

Image Credit Eduardo Astu – Pico de la Hoya, Spain.

My SAFe Journey

Before answering the question that is the main topic of this article, I would like to comment on my own personal journey to the Scaled Agile Framework or SAFe. As an Agile Coach, ScrumMaster and Kanban Ace Trainer I frequently run into the challenge organizations face to extend the benefits of agile methods: such as responding faster to change, achieving higher productivity, and a much higher success rate for software development projects; but this time applied to serve a large organization, and not only for the areas of software development, and product marketing but to reach across several other business and IT areas such as customer support, finance, compliance, IT infrastructure, database operations, analytics and marketing strategy.

For this reason I explored, read, and evaluated the three main agile scaling frameworks available today: SAFe, LeSS and DAD. I went beyond just reading, and also attended talks about them, heard valuable opinions from people I respect from the agile & lean communities both in person and in written form. One aspect that tipped the balance towards SAFe was the fact that it presented a well designed coherent framework that leveraged both Scrum, and Kanban. Given the fact that I am certain Kanban can easily scale to cover and optimize any value chain, SAFe gained in my view a powerful advantage over the other alternatives. It was then that I decided to become proficient in it, and I became a certified SAFe Program Consultant.

In the paragraphs that follow, I summarize what SAFe is, and hopefully it will motivate you to explore it further as a valuable alternative in your toolbox to bring agility to larger organizations.

What is SAFe in Brief?

SAFe is a large coherent framework, that you can see as a unified toolbox that provides principles, values, practices, tools and techniques to bring the benefits of agile and lean methods to large teams, with a strong emphasis on software development and the whole IT area.

Before SAFe, there was a growing consensus among technology companies, that teams who leveraged agile methods or frameworks such as Scrum, Kanban and XP were able to deliver products faster, and with more success, than those who used traditional Waterfall methods such as RUP, or PMBOK inspired project management. In addition, companies with agile teams report experiencing a better ability to respond and adapt to change, which is a constant in today’s marketplace. Agile has become a must not only for small startups, but for today’s corporations and Fortune 500s.

However, the vast majority of agile methods, literature and books were designed to deal with small teams from eight to twenty-four people. Scrum for example has a limit of 8 people per team, and once you have more than 3 teams the coordination effort becomes quite challenging. Scrum’s answer: using Scrum of Scrums has very little in the form of specific guidance, or details on how to implement it, or manage it.

Another problem that came with larger teams adopting agile was the reality of working across sites, meaning some of your developers, testers, and marketing team are not in the same city, the same country, or even the same continent. Scrum’s insistence on co-locating teams did not help to address the reality of today’s global teams. Kanban proved it could work in this context, but adoption is much less than Scrum, and the knowledge-base for large scale implementations is limited.

Moreover, after Scrum is adopted within the software and product development areas inside a company there usually arises a need to apply these benefits across the rest of the IT organization. However, Scrum does not easily fit the IT infrastructure, database teams, security and DevOps. In this context Kanban naturally shines, since it does not disrupt existing roles, and it can work on any area or department by embracing their workflow, and improving productivity across IT areas.

SAFe’s big advantage here beyond other scaling methods, is that it embraces both Scrum and Kanban. At the product and software development level Scrum is preferred, which is understandable given Scrum’s large user base inside many software development and product marketing teams. But to scale beyond this area SAFe leverages Kanban to reach to the Program, Value Stream and Portfolio levels. Companies adopting SAFe can benefit from the best of both.

Dean Leafingwell, the creator of SAFe frequently shares the story behind his Big Picture diagram which explains in one single image most of SAFe. Dean says after explaining for some time his vision for Agile and Lean for a large company, the customer asked: Could you draw me a picture? That would truly help me understand it. And that is how he began the work of translating that vision into the Big Picture diagram; and lately Essential SAFe to address Program level implementation.

In both cases the Big Picture diagram summarizes all the major pieces of the framework highlighting the organization and cohesiveness of SAFe’s approach. However someone who sees the diagram for the first time, it can be either an amazing experience (since you immediately understand it) or a perplexing moment (given the complexity) for that reason I include below Essential SAFe which focuses only on the team and program level.

Do not worry you do not need to understand the Big Picture yet, just remember the basics: at the team level Scrum is the foundation, and at the program level and above Kanban helps the agile teams organize the larger efforts. In case you wonder, you could also have Kanban at the team level, but you would need to a version of Kanban with built-in support for Scrum such as the Kanban-Ace Framework which welcomes and leverages Scrum via the Akashi Bridge.

In future articles, I plan to cover other aspects of the framework such as the principles behind the framework, recommended adoption patterns, and common criticism and myths that have mostly to do with lack of knowledge of the framework. One thing is certain though, if you are planning to scale your agile initiatives to large groups from 30 to 1000s of people you must carefully consider what SAFe has to offer, as the chart below shows the market has already discovered SAFe and many are adopting it to scale Agile.

Featured Image Credit: Tobi Gaulke CC BY NC SA, Grimselpass, Switzerland.

As a developer and project manager I always wondered why Scrum has so many rules, detailed processes but still calls itself Agile. Sure many of the ideas from Extreme Programming, another Agile method, are sound and programmer friendly, but they also represent a long list of practices to follow. This is evident by looking at the drawing above. Scrum has over 17 componets, XP between 13 to 36, can this be called Agile? Shouldn’t Agile be a truly simple way to start doing things better, and after starting being able to continoulsy improve?

I do believe there is a better way. Why not take the best ideas from Lean and Kanban and use them to build a better, lighter, simpler and more powerful Agile 2.0 method? Take a look at this article, and tell me what you think.

“Twenty years from now you will be disappointed by the things you didn’t do than by the one’s you did. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover.” – Mark Twain

Wise words that reminds us of the immense value that courage has for entrepreneurship, initiative, and to create anything of value. Courage is the stuff dreams are made with.

Any product or service has a natural audience, a group of people they serve. This part of this infographic shows clearly who Twitter serves. The larger diagram shows the same for the rest of Social Media.

The reason I show this graphic is to remind you of the key question for any business, or even career choice. Who do you serve? Forget about markets and niches and demographics. Picture that person or that group of people, imagine who they are.

Now, do you like that person? Do you truly want to serve him? Do you want to make their lives more fun, better, easier, or are you just interested in their money? Money should never be the motivator. Making a difference in that person’s life should be! Money will always come after you do things right. Don’t worry, it will come, just do things the right way, and rewards will come your way. Be a servant leader.

Remember the good advice of a scientist and a philosopher:

The true destiny of any individual is to serve rather than to rule. ~ Albert Einstein

Good leaders must first become good servants.“ ~ Robert Greenleaf

I would like to share three brilliant quotes by Andy, he is one of the best developers in the world, and was part of the original Mac team:

1. “First and foremost, you are your own customer: You build stuff that you love yourself. What Woz did with the Apple II was he just filled it up with so much love — love because it was his lifelong dream… That’s the basic approach I learned, to work from your heart, and to really, really care.”

2. “We try to operate at the intersection of design and engineering. One of the reasons why things aren’t as good as they could be sometimes is that the engineers and the designers don’t work closely together enough” This quote repeats a fundamental idea of Steve Jobs, that he wanted Apple to operate at the intersection of Liberal Arts and Technology.

3. “The real breakthrough of the Macintosh was that we cared about UI… I learned in a formative experience that caring about UI matters, and if you do care about UI, you can make the world a better place.” Another core value of Apple, create an Experience no one else can match.

Andy is working now to make Google+ a success. His care for design and code shows all over Google now, and is evidence of how important is to have the right people in a team.

The connection between individual talent, and team goals are the reason behind every great success. People are extremely important, and caring about them makes better projects, better products, better services and ultimately a better world for us all.

Source: *[San Jose Mercury News](http://www.mercurynews.com/business/ci_20132893/apple-pioneer-brings-emotion-google-andy-hertzfeld)*Image Credit: Traczine Blog.

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

Tom Cargill. Bell Labs.

It sounds a bit funny, yet so many times it’s true. The question is why?

The reason is what I call: “The Waterfall Trap.” Any project, at the moment it starts, uses logic, knowledge, experience and good practices to guess the future. That’s right the plan is at best a very good educated guess.

Waterfall methodologies for software development, or project management turn this guesses into stone. Stones usually called Milestones, Targets or Deadlines.

The funny thing is as time goes by, everyone can see the future more clearly, everyone can guess we won’t make it. But the Waterfall Trap includes a clause of Inflexibility, no target is ever revised, any revision is seen as a failure from the plan. So instead of improving the prediction, the team often goes to a land of overtime, where quality decreases, morale falters and even health suffers. Only when disaster strikes in these circumstances are plans revised, but usually under an unfair banner of targets missed.

The truth is, we can only guess-timate the future. Can you even predict you will be alive tomorrow for sure? Now you can’t! A car could hit you, you may slip down the stairs, etc. So if we can’t predict our own tomorrow, it’s no surprise projects where multiple resources and challenges are involved, are hard to predict. It’s actually rather remarkable that Waterfall projects, or any project with dates set on stone makes it within the 90-90 rule!

The Agile Way however, is quite different, it embraces chaos and unpredictability, through open, sincere communication, it prepares and adjusts for change, and for unexpected problems. It is not against planning, but rather as we move forward in a project it adjusts to reality on the ground. As a consequence it allows the team, our “troops” to work hard, but with strong morale, and good pace, to deliver a quality product.

General Patton once said:

Make your plans to fit the circumstances.

It doesn’t get more Agile than that. Agile planning means intelligent decision making, every step of the way, including revising estimates, and moving the team to victory. An Agile Team should never live the 90-90 rule, they should be close to 100% every time, simply because they acknowledge reality, and plan for it.

“Good wine ages well. Always.” ~ Yours truly

Several people have asked me to explain the basics of Kanban’s Agile approach to Software Development. This presentation is a simple, straight forward, fun way to get what Kanban is all about.

UPDATE: This presentation is from 2011, wow! Still pretty good. But if you want to know where I am now in Kanban land, I created Kanban Ace, and I am in the process of creating a scalable Kanban inspired tool called KAFE.

You can click below to see my first Kanban presentation:

(Source: http://www.slideshare.net/)

One key concept to grasp in any form of goal setting, project management, or actual effort in life is that we should strive to never do more than needed, but have a goal of simple elegance. We must realize that More is Less.

Perhaps one of the best ways to illustrate this principle, it to quote Seth Godin with some comments added by yours truly:

Good enough, for those that seek perfection, is what we call it when it’s sufficient to surpass the standards we’ve set. Anything beyond good enough [MEANING MORE] is called stalling and a waste of time.[ MEANING LESS]

Ultimately, when maturity arrives we will also discover that LESS is MORE. We will eventually notice that if we remove stuff from a project, product or service, and yet keep it elegant, and good, we will reach excellence.

In book writing this comes from editing a 1000 page manuscript to 250 good pages. In software interfaces this means a beautiful, simple UI that even a kid can use. In projects it means simplicity over bloat. One side benefit of this philosophy is that you will have more time to enjoy life!

Image Credits.

Less noise, less “information”, leads to less stress and that equals more peace.

Image Credits: here.

Which is actually one of the main principles of Kanban: Limit Work in Progress. It also relates to something I call Holistic Kanban or HKanban you can learn more about it here: </2010/12/23/hkanban/>

STANDING ON THE SHOULDERS OF GREAT MEN

Like so many Project Managers and busy professionals I too have discovered that is not just enough to manage other people, or the work at hand, we have to manage our efforts in and out of the office, and daily life can be the biggest challenge of all.

The first author to show us ways to improve our productivity was David Allen, his Getting Things Done book was a landmark that I continue to browse occasionally. However I could not get the system to work for me. I wanted something simpler, but still effective.

Upon discovering the Kanban Method, and especially David J. Anderson’s book on the subject it became clear to me that the principles behind Kanban could be taken beyond software development, or manufacturing into our daily personal life.

Kanban is an Agile Software technique and set of tools that makes work visible by dividing it into individual tasks, and then those tasks are grouped into different stages in time. We have a backlog where all the inventory of stuff to be done is located. A Ready stage where we place the relevant tasks from the backlog, think of it as the list of tasks or projects we believe we can handle in a period of time, usually a week or a month. Secondly we have the Working area where we track the efforts we are doing now, and finally a Done area to archive our success.

Jim Benson, also noticed that Kanban’s division of effort into a logical work flow, from backlog to done, not only helps in software projects, it also helps regular people. It achieves this by reducing complexity, and making work visible. Our brains can not handle unlimited efforts; we have to limit those efforts in time, and in quantity. Kanban calls this Limiting Work in Progress (WIP.) When we limit WIP we suddenly see our work actually move from Ready, to Working to Done fast! We reduce complexity, and life starts to make more sense, we have this wonderful feeling of accomplishment. Jim has written extensively about this, so I won’t go into all the details, but I recommend you check his site: PersonalKanban.com, and yes he will have a book quite soon. By the way Jim, thanks so much for your comments on the first draft of this article.

THE H IN HKANBAN

As you have probably guessed it, the H in HKanban stands for Holistic. I would also call it humane, and human friendly.

HKanban goes beyond simply achieving goals, its main objective is to achieve goals but to do it while keeping your health and well being intact. What’s the point of achieving goals and dreams or being super effective, if we get a heart attack, lose our family or stop enjoying life?

A QUICK INTRODUCTION TO HKANBAN & THE HKANBAN EQUATIONS

After some reflection, I realized that our capacity to achieve meaningful work is limited by a series of factors. Effort being just one of them.

The Capacity Paradox

Capacity is the availability of time, well-being, strength and resources to make our dreams reality. The cheapest and most valuable resource is time and well-being. Well-being means you have good health, and a positive spirit.

There are many dreams we have, but only limited capacity. We must deal with capacity to succeed. But without health and well-being (the Holistic factor) our capacity tends to zero, therefore it is critical we achieve our objectives in a wholesome way.

Here are the main equations behind HKanban’s Theory:

HKANBAN CAPACITY EQUATIONS

PersonalCapacity = [WorkTimeAvailable * FocusedRatio] ^HolisticWellBeing
We can also express the above equation this way:

pCap= [WorkTA * FocusedR] ^H

Oversimplifying, let’s assume pCap refers to a specific dream or goal. We will call it pCap for x, or pCap(x), x being a specific goal or dream.

HKANBAN ACHIEVEMENT EQUATION

Given that:
pCap= [WorkTA * FocusedR] ^H

Achievement(x) = pCap(x) – HoursOfEffortRequired(x)
When Personal Capacity pCap(x) exceeds HoursOfEffortRequired(x) you get achievement!

Where:
pCap= Personal Capacity | WorkTA = WorkTimeAvailable
FocusedR= Focused Effort Ratio % | H = HolisticWell-being

INTERPRETING THE EQUATIONS

A full explanation of the equations is beyond this brief introduction to HKanban, but here I would like to focus on the key factor. Notice that to achieve anything we must maximize our Personal Capacity or pCap.

Personal Kanban, GTD and so many other methods help people improve Personal Capacity, but they focus on the left side of the Personal Capacity equation, meaning the overall focused, effective effort. Even fewer methods go into the Achievement Equation. When you read that one, you realize how important that Holistic Well Being or the power of H is (^H.) Given that:

PersonalCapacity = [WorkTimeAvailable * FocusedRatio] ^HolisticWellBeing

If H is zero you deliver next to nothing and are probably on the quick way to a heart attack, if your H is equal to 1 meaning healthy you do fine, if you are super-healthy and with a good spirit, you can actually make H > 1, you will be incredibly productive. How much more productive? Probably up to twice normal, but the fact remains if you forget your well being everything collapses.

HKANBAN WHOLESOME PRINCIPLES

There is mounting medical evidence that you need to follow these principles to achieve meaningful, sustainable success:

1. The Rules of 8s. 8 hours of work, and 8 hours of sleep are fundamental for steady, reliable capacity. Study after study confirms the importance of sleep and you’d do well to follow that good advice. And just in case you wonder, those remaining 8 hours are yours! Live life!

2. Body Equilibrium. Not just eating healthy or doing exercise, but resting are key factors for sustainable effort.

3. Spiritual Well-Being. Avoid situations where you feel hopeless, have a positive outlook in life, and have faith. All these hard to quantify elements are fundamental to keep you healthier inside, and maintain good spiritual well-being. Psychology and brain studies do show that it works, and surprisingly it seems that indeed we are wired for faith.

4. Avoid Loneliness. Friends, the ones that actually talk to you and help you out, are not only worth keeping, they are a key factor in your overall productivity in and out of the office. Cherish them, and treat them with respect. And be even more close, and grateful with your own family. Because after all, who’s got your back?

I hope these principles from HKanban and beyond help you. Reflect on the equations, challenge them if you wish. The more you do, the more you will realize you have the key to productivity staring you in the face. So what are you waiting for? Take the next step, and make it happen.

“In business and in life:
the lighter we are the higher we get.”
~ Miguel Gómez Arbocco, a good friend.

Lean is a whole way of thinking that fundamentally tells us: keep the most valuable, discard the rest. Because the rest is weight, is useless inventory, that drags you down, and makes everything harder.

When you go lean, you also get lighter. On a personal level you de-clutter, and keep the truly valuable things now. On a business level this means real agility requires less process, less meetings, less reports, more value, more communication: SIMPLICITY. I often call this ultra-light methods.

To soar high in life, and in business we must learn to be light, SIMPLIFY and FOCUS.

Traditionally Project Management has identified three constraints that must be managed to achieve success on any project, namely:

• Time: or the schedule, to meet deadlines and deliver
• Money: our available budget, and financial resources
• Scope: extent of work that has to be performed.

Collectively they are known as the Project Management Triangle, and for decades they have been the focal point for the project manager’s efforts.

Lately however the Project Management Institute (PMI) and Agile Kanban have noticed that this simplistic 3 constraint model is incomplete. PMI today does add three new constraints: Risk, Quality and Resources, while leaving the door open to even more constraints that might be identified (PMBOK 4th. Edition, page 6.)

On this article however, I’d like to focus on Kanban’s contribution to the classical 3 constraint model. One that I believe is sometimes overlooked, because it gets lost in the details of the Kanban Method itself. Although I have not seen these constraints formally identified before, they are fundamental to the Kanban Method and they are present in most documents from different authors.

Luckily any reader familiar with Project Management should be able to follow this discussion, without knowing the Kanban method. However, for those who would like a quick introduction I recommend the following: Dr. Dobbs Introduction to Kanban, the Kanban Definitions by the Limited WIP Society.

In my opinion, Kanban identifies 4 additional key constraints for a project success:

1. Value – Mission First
2. Flow – Healthy pace
3. Focus – Less is More or LWIP
4. Waste – Quality by default

On this blog post I will concentrate on the first two.

1. Value – Mission First

“A Kanban System visualizes some unit of value.” Karl Scotland, founding member Lean Software and Systems Consortium.

Unlike other Project Management methods, the Kanban Method emphasizes that we must first identify what is the key value the system must deliver, and then improve on it.

We can see this focus on value at the micro project level on this typical scenarios Kanban ask us to answer: what value does this User Story delivers?, What is the purpose of this Requirement? What do we really need to deliver for this Minimal Marketable Feature to deliver value to the customer?, What is the key value we are delivering in this project?

At the macro level the Kanban Method can evaluate whole departments and even an organization by mapping the value stream and asking: how can we deliver more value? How can we improve from here? How can this department deliver more reliable code? What do we need to do to ensure the customer is satisfied with our customer service? How can we reduce time to market for our key new product? How can we foster innovation at our development department?

Once people, and management start thinking in terms of delivering value, not just for shareholders, but for every person on the organization, value creation in the company grows and a culture of Continuous Improvement (Kaizen) is born.

2. Flow – Healthy Pace

“Are we outraged that work-life balance is considered the pursuit of the soft, lazy and uncommitted?… Are we outraged that overtime working is expected?” David Anderson. Speech at UK Lean Conference, 2009.

Kanban sees Flow, and the optimization of workflow as fundamental to a project success. It optimizes flow by identifying bottlenecks, and using a variety of tools (mostly from the Theory of Constraints) to remove or minimize bottleneck impact.

Some of the tools used to identify bottlenecks are: work flow diagrams, demand analysis, and the Five Focusing Steps from the Theory of Constraints. By using those tools Kanban is able to make continuos improvement to the overall flow of work, and keep progress steady and predictable.

However Kanban does not recommend Flow optimization so high that workers can barely cope, and it strongly discourages over-work. It advocates sustainable pace, and therefore work-life balance. A good Kanban Flow must have slack so that the people who work on the system, can remain productive, healthy and motivated.

Comments, contributions? Do let me know. Next week I will cover the last two constraints.

Get the Best Tools – Why most pros should consider the new Macbook Air?

If there is a principle in project management, and Getting Things Done that I have learned is that we should use the best tools possible for the job. For over 7 years the best tool for me in the area of computers has been an Apple laptop, and although I’ve used Windows PCs also, believe me when I tell you that Apple has been doing something great with their computers for a while now. And on this subject I’d like to update you on what I think about Apple’s Macbook Air.

First let’s recap a little, for a long time people who considered themselves mobile professionals, went and got the fastest laptops, with the beefiest specs they could afford. If you liked the Mac, that meant you buy a Macbook or even better a Macbook Pro.

So for years software developers, photographers, videographers, designers, engineers, even people who just needed a word processor did. It was simply the only way to have a mobile computer! Then something happened on late January 2010, Apple introduced the iPad. And slowly but surely journalists, lawyers, project managers, doctors, and many mobile professionals realized that they truly didn’t need a “heavy” Macbook, the iPad was enough most of the time. Steve Jobs called this new class of computer a “car,” regular Macbooks were “trucks” and someday most people would use a car instead of a truck.

So guess what, last Tuesday Oct. 20th, we got our first cross-over “car”: the Macbook Air. It gets the best from the Macbooks, and the best from the iPad today.

Why is this important? Well for one the Macbook Air can do almost anything a Macbook Pro can for many pounds less in weight! And given a choice of power vs. mobility I choose mobility.

You may say why? Let me explain with a quote from photography that’s been around for decades:

“The best camera is the one you have with you.”

This principle applies to laptops like a glove. Think how much more productive you could be if you actually carried your laptop everywhere without hurting your back in the process! Anyone who’s carried 5 to 7 pounds of laptop gear knows what I mean!

That’s the magic of the Macbook Air, at just over 2 pounds of weight and 5 to 7 hours of battery time it hits the sweet spot between an iPad and a Macbook Pro! The pro features are a bit different this time: first you get instant-on, so you can resume work anytime, anywhere in a second, and continue from where you were last time. Second you get a Flash or Solid State drive that makes the running speed of your Macbook Air processor feel closer to a Macbook Pro computer.

So if you are a mobile professional who’s serious about getting things done, I recommend you put the Macbook Air in your toolbox as soon as you can. It’s the closest thing to a Leica camera in quality, portability and elegance I’ve seen in a long time; but with the price of a micro four thirds!

**The Gap Logo Fiasco:**Corporate Identity in the Age of Social Media

In case you didn’t know already last Wednesday Oct. 6th, Gap introduced a new logo (seen above) to replace the classic design. Reaction was almost universally negative to the new creation, many actually calling it a piece of %!$@#, and yes you can pretty much sum up everyone’s opinion right there.

For a while pundits in the press and PR community thought maybe this was genius, to introduce a horrible logo on purpose, get free press from the reaction, and then crowd source a replacement. But it didn’t work like that at all for Gap. In fact, Gap had actually paid good money for that ugly looking logo, and their online store was brave enough to use it. Free press quickly became a PR crisis with hundreds, thousands of people ridiculing their brand all over the Internet!

Why did this happen so fast? Because in the social media universe we live on today, a big part of the press is regular people, not journalists. Regular people who in their very opinionated way influence public opinion from their Twitter feed, Facebook page, Blog or wherever they can express themselves socially.

The consequence of this active public engagement in the creation, and editorializing of news is huge. Instead of the usual cycle from news, to press, to public opinion; we now go from news to public opinion! The press and the people have somehow merged into “influencers” and the time it takes for a story to go from news to public opinion has been shortened drastically.

The end result is that if “buzz” on Twitter, Facebook, and Blogs already say that your new logo sucks, it probably does! And the worse part is that this is not the press talking, this is public opinion already! In a matter of days, your brand can sustain a big hit.

So what can companies, agencies and social media professionals learn from Gap’s mistakes:

• 1. Focus Groups and Surveys can’t Ignore Social Media Any More. I am sure Gap paid good money to test their new logo, but I am also quite sure they ignored Social Media almost completely. Result: failure.
• 2. Brands and Companies must listen to Social Media and React Fast. Gap is actually a good example, they did not wait a month to react, in 6 days, meaning today they scrapped the new logo! They got 2000 very negative comments on their Facebook fan page, and that plus the Internet backlash helped them correct course. However, if they had properly listened to the conversation they could have done it much faster, probably in 2 days flat, or even better they could have avoided all this issue completely if they had tested it with Social Media influencers first.
• 3. Don’t Underestimate your customers. We live in a world of savvy customers, let us treat them with respect and they will continue to give us business. The golden rule still holds on the Internet age.

Real artists ship.

Andy Hertzfeld, member of the original Mac team.

No amount of vision, no dreams, no project plans, patents or detailed battle plans are worth anything without real working execution!

Hard work, and shipping are the big difference between amateurs and pros.

Pros ship!