Just because we think something has value, does not necessarily mean it is valuable.
Often our perception of what has value is driven by a personal bias, such as that t-shirt from college you just can’t throw away. That t-shirt delivers value in the form of memories, however, you can’t derive anything valuable from the t-shirt outside of your memories.
There is a difference between perceived value and delivered value.
Value cannot be realized unless it can be quantified in some way.
This may sound like a semantic exercise but I think the distinction is an important one that needs to be made as it drives how we fund software development projects.
When organizations go through their annual planning cycles, they ask their functional leaders to come up with software projects that they want to do.
In this context, leaders may often turn to what they perceive will provide value, however, the value they perceive may not deliver the value the organization requires from a strategic standpoint and it often is not quantifiable.
This happens when the organization is not aligned with a shared understanding of the strategic outcomes that will deliver real value to the company.
There is often an inherent imbalance in many organizations, where you have one part of the organization working to eliminate some technology or functionality that another part is actively seeking to implement. These are real cases I’ve seen as a coach.
The way to deliver valuable outcomes (ROI) to the organization is to align your work to your strategies.
My valuation model takes your strategies and converts them into value factors that are applied across your entire software development Portfolio.
Using a portfolio investment approach we then define the organization's risk/return profile which will ensure that we are focused on investing in work that is both foundational as well as aspirational.
If you don’t have balance you will never reach your aspirational goals as your foundation can’t support it.
Software development is an expensive endeavor with annual investment running between 5%-10% of total revenue or more for most organizations.
Not knowing that your investment is delivering real value makes that cost go even higher.
Transparency, Accountability, and Predictability - A Trust-based approach to Adopting Agility
These are the three pillars that I believe are the foundation to creating a successful Agile organization. So much so that I’ve created an approach called TAP2 Change.
Each pillar supports the other and without developing all three pillars your ability to become an Agile organization will have only marginal success.
But what do we mean by ‘becoming Agile?
The Agile Manifesto was expressly about improving how we developed software, and though it highlights the need for high levels of business and technology engagement, it has a gaping hole in it that has left it hobbled and unable to realize the full benefit of being Agile, which is that the entire organization must change to support the Manifesto.
Being Agile is a state when your organization no longer thinks or acts in the previous way that you work, rather Agile is your new state of operations. Unfortunately, Agile has been sold as a silver bullet, a product that will solve ALL of your organizations' problems and all you have to do is bring in a cadre of coaches and viola! your organization is Agile.
In any organization, we are always looking for better ways of working, Agile is just a new ‘better’ way of potentially working. Just like your waterfall days, you will always be attempting to make Agile better.
But what is interesting is that virtually all organizations that grew up with Waterfall have their entire organization optimized to run in Waterfall. Yet Agile has stayed almost entirely within the domain of Technology.
You are asking for your organization to deliver more quickly, yet you don’t optimize your organization to support that. As you start your Agile journey, you must consider the organization holistically, which is what TAP2 Change does.
This is why Agility requires you to build three pillars - Transparency, Accountability, and Predictability.
These pillars have nothing to do with the frameworks that have grown up to ‘operationalize’ Agile, they can support the pillars if that is your choice, but they are not the entirety of what Agile must be if you are to have long-lasting transformative success.
TAP2 Change is designed to provide you with guidance, not directives, on how you can approach becoming Agile. At every organization I’ve been at, we talk about how we are different from other organizations, and you are entirely correct and to think there is a single framework that will work as-is is not being realistic.
As a coach, I have had much success in helping organizations become more Agile, yet each one had its unique aspects that required that I tailor what we did to accomplish Agility. And what worked at one organization may not work in another, being flexible in how you define Agility is the key to success.
Again it’s not about the frameworks, at best they provide you a veneer or window dressing of ‘doing agile (note the small a) if Agile is a mindset then right now our mindsets are centered around Scrum, SAFe, LeSS, DAD, the list goes on.
Though I will be writing in more depth on what each Pillar is all about at a high level here are the three pillars you need to develop as part of becoming Agile:
Transparency –
This starts at the top, with leadership providing a clear understanding to people why becoming an Agile organization is important, what are the threats to us if we don’t become Agile, what are some of the expected changes that need to happen to support Agile (both organizationally and personally).
Conveying how can everyone in the organization both participate and also succeed in this new operational paradigm is another transparent layer of successful Agility.
Creating a clear Agility Mission and Vision and making it transparent will create the north start for everyone as they begin to ask the important question, how can I contribute to our collective success.
Accountability –
Here is where we start to see the real aspects of the operational side of Agile. And again it starts at the top. Leadership can’t what I call a ‘fund it and forget it’ approach to this adoption, they too must change how they lead, manage and think about their organization.
As a leader you are accountable for the success of Agility, you can’t outsource change to outside consultants (we can help but we aren’t the real change agents despite what everyone may think).
Planning and delivery comprise a large part of Accountability, which touches every part of the organization and top to bottom. You can’t be Agile if the only thing that changes is that you deliver your waterfall projects in 2-3 week sprints. Your organization must change everything from Ideation, Intake, Planning, Funding, Operations, and Staffing to support organizational Agility. Absolutely nothing is untouched by Agility if you are doing this right.
Empowering people at the lowest levels of the organization leads to high levels of accountability, building trust is the single most important part of the accountability pillar.
Predictability –
This is the most controversial pillar of the three because Agilists see predictability as a means to continue to have projects that are fixed scope and time. Yes, this happens in many Agile organizations, this is not what I mean by being predictable.
It is important that we not ignore every organization's need to deliver predictable results, whether they are a public or private entity. Leaders are the public face of our organization and when they provide feedback or guidance on how or where the organization is going, investors and customers alike, are listening.
Predictability is the final pillar of TAP2 Change and the real focus of this is to optimize our Product Development teams to deliver consistently, What this means operationally is that in an Agile organization there are no fixed scope/date projects. Rather there is a Product Roadmap that provides visibility into small incremental improvements to that which we are working on, be it a brand new product or an existing one.
Leadership with a high level of engagement can see progress (transparency) and know that their teams are being accountable (accountability) for delivering incremental value consistently (predictability).
One of the most important aspects of Agile is that it changes your entire organization, whether you want it to or not, eventually, the pain of living in the multiverse of Waterfall and Agile, will become too painful. You will more than likely in this scenario go back to Waterfall, as the path of least resistance.
Because Agile is an organizational change, you must build trust with everyone involved. And you must provide transparency to everyone in your organization regarding what, why, and how Agile will change their work. Without this, you will not be able to convince people to change and Belief Perseverance (which we often mislabel as resistance) will be what keeps you from achieving your goal of moving you to Agile.
Changing Your Funding Model is a Requirement for Success in Agile
When you are considering moving your organization to Agile the single most important decision and change you will make has nothing to do with the frameworks that you will select for your teams to operate under.
The change that provides the foundational support for these frameworks is about how you fund the work that these teams will do.
Agile frameworks are not designed to support fixed budget, date, and scoped projects, yet that is exactly what happens when most organizations ‘Go Agile’. Teams start working differently but Management and Finance stay aligned to annual funding cycles and weekly project plan read-outs.
To lay a foundation for success in Agile, you need to change your funding model, moving away from funding projects in annual planning cycles to one that funds dedicated teams where work will flow to teams continuously.
Much of the resistance in making this change comes from the fear that Finance will never change and this is just the way that they have to manage the books. The reality is far from that, organizations can and do make the shift from funding projects to funding teams, and when they do the entire dynamic of how work is managed and delivered changes dramatically.
For Finance this shift simplifies financial management because instead of having to manage the P/L for hundreds to thousands of projects, you will have a single entry for each team, which on average costs (blended rates) around $1 million annually. So if your organization has 40 Product teams you can expect the cost of delivering software to be $40 million.
By changing the funding model from projects to teams you can then shift your focus to Value, building a value-based Portfolio approach that identifies a risk/return profile for your organization and products which will allow for the appropriate investments to be made.
The shift to funding teams requires a change in decision-making that ensures that we are balancing what is identified as the most valuable against the cost because not everything we do can or want to should be done. Moving to funded teams does not remove the fiduciary responsibility everyone has to make sound investment decisions.
This change to delivering features in a continuous fashion allows for capitalizing on a more frequent basis which has its own benefits from a financial reporting perspective.
Why Do We Need to Scale Agile?
That is a question I have been grappling with over the past few weeks because even though I’m an Enterprise Agile Coach, who is typically brought in to support scaling Agile, usually via SAFe, I struggle with the whole concept.
Scaling Agile on its surface sounds anti-Agile as it implies a level of structure and conformity that will kill creativity, which is what Agile is really about.
However, ever since Agile had success in small settings, there has been a rush to sell Agile to large organizations as the cure to solve all of their issues.
Scaling frameworks sprung up to support this desire to move to Agile and with it came everything that will kill real Agility.
Here’s the thing, those initial successes you had were with small teams, working on things that could be isolated from the rest of the organization, and were provided a space to try new ways of working, without the pressure to conform operationally to a fixed date and scope project.
That was my experience, working in a completely Waterfall world I became the Scrum Master for a team that was going to build an entirely new product. We were very successful and in about six months we had a market-ready product. Though everyone was impressed that was the end of the organization’s experiment with Agile but was the beginning of my journey towards it.
It was many more years before I worked at an organization that needed to change everything about how they worked and it was the first time I had a view of what the needs of a larger organization might be related to working in Agile.
Though we were provided space to work differently and to make mistakes, we also as a group kept ourselves informed as to what other teams were doing and if something was working we’d look into whether that made sense to adopt.
We become more structured in how we worked through months of trial and error, while engaging our leadership to gauge what they needed so that we moved towards a common goal and outcome.
Though we worked in projects (note the Agile Manifesto has the word project in it so it’s not something that goes away) we helped our business and PMO partners understand that by moving to Agile we were providing them much greater transparency as to how we were progressing and more importantly it gave the business a greater understanding of the complexity of the work we did on their behalf.
Over the next 18 months, we went from a poorly performing development group to one that had gained the trust of the business and was given ever-larger initiatives to work on, ones that transformed an entire organization.
The key thing you need to understand with Agile at scale is that the primary thing you are trying to do is to unleash the creativity of your people. You hire tons of very smart people and then turn around and tell them exactly how they have to work, we don’t like that.
The problem with this? Your organization isn’t typically set up to support this and the scaling frameworks don’t even address people and creativity as important elements of Aglie.
By unleashing creativity you are allowing your people to figure out best how to work as a team, across the organization, and deliver increasing amounts of productivity, quality, and value.
I believe what has been the focus of scaling Agile is to provide Sr. Leadership an allusion that Agile is a thing we implement, like Salesforce, and then turn on. If everyone follows the same processes, attends the same ceremonies, and acts in the same manner, then the entire organization must be Agile, right?
If you are on an Agile journey already or are thinking about starting one, don’t start with a scaling framework first. If you need one later, consider it.
Instead, start by changing your organization structure so that it supports letting people who do the work figure out best how to do the work. What is required from Leadership is to establish guidance focused on:
o How the organization makes decisions — What is our mindset for them? We’ll align our decision-making around those expectations, ensuring we are all on the same page.
o How the organization decides what is valuable — This one is the hardest, look to your strategies first. By providing understanding to both what is value and how we can derive it, your teams will make good decisions on what work will bring the best value in the moment.
o How we will empower you — Allow failure to be part of the journey. No framework will expunge the need for failure, what frameworks do is focus on activity over outcomes more often than not. Celebrate failure for the learning it provides.
As you consider Agility in the organization know that there are foundational aspects of your operations that must change, from HR, Finance, Sales, Marketing, and Technology, everyone must be engaged in the journey, it’s not just a technology thing. This is what scaling is about, allowing people to make the necessary changes to enable Agility, not laying a rule-based structure over another rule-based structure, and hoping things will get better.
Implications of Self-Empowered Teams
We talk of teams being empowered, but in reality, most teams never reach any level of real empowerment because their focus is on activities over outcomes.
Activities that support the frameworks we implement in the name of Agile become the focus of our day-to-day life. The activity of building and having a backlog of ‘work’ is a metric we typically convey back to leadership on the ‘health’ of a team. So their focus is on creating a deep backlog instead of having a backlog that is filled with strategically aligned outcomes that deliver value.
If a team is truly empowered then they would know how their decisions of what to work align to outcomes that the organization seeks.
Unfortunately, in most organizations, the transparency and alignment of strategy to value is not well known or may not exist at all.
Empowerment is not just Leadership saying, you are empowered, it’s instead about laying a foundation of transparency about what they believe is the most important outcomes that teams can deliver and then providing them the runway to do that through experimentation and empiricism.
A truly empowered organization won’t look anything like the frameworks say it should, because empowerment implies a higher level of independence than the frameworks provide.
With great independence comes great responsibility for everyone involved in ‘Being Agile’.
Empowerment must build trust through the ability to show how you delivered value and that value then being positively leveraged by the organization to sustain and support growth.
Agile Planning in 3 SImple Questions
Should We Do It
Can We Do It
Will We Do It
Answer these three questions before you start on any large initiative
Asking Should we do it starts a conversation around whether this is strategically aligned with our goals and objectives.
Asking Can we do it then moves the conversation to whether or not it’s technically feasible, what types of architectural enablers might we have to invest to deliver on this idea?
Once we have answered the Can we do it then we need to move onto the important aspect that will drive the final decision do it — Cost.
Just because we CAN do something doesn’t mean we SHOULD. At one organization the business came to us with an awesome idea (no really it was) but when we told them that could take more than 20 sprints to accomplish (almost a year) the business said that it would be valuable to them if it was 4–6 sprints but not more than 20. This caused them to go back to the drawing board to refine their objective goals.
Once we evaluate the strategic alignment, technical feasibility, and the potential cost of initiatives, only then are we ready to pull the trigger to invest in this idea.
Asking the Will we do it, provides everyone an ability to confirm that this is the right decision and then make that investment decision transparent to the organization.
It may sound non-Agile in approach (it’s not Discovery is an important component) but before we invest our teams in large Initiatives we should take some time to assess whether that is a good idea to do it in the first place. Just because something can be done doesn’t mean it should.
Why Aligning Value and Strategy is Important
Value is often in the eye of the beholder and because we attach ourselves to the perception of that value we can’t often differentiate between what we want and what we need.
As leaders, we often follow a similar approach when deciding what projects we should take on for the w\organization. For instance, we may read about something interesting that another company is doing and think that we should be doing the same thing, this becomes your want.
Unfortunately what that other company is doing may not be what your organization either needs right now or worse is not even strategically aligned to its strategies.
All too often organizations have an annual planning cycle where individual leaders pitch their ideas for new projects and request funding. And all too often these projects are disjointed, competing with other projects seeking opposite outcomes, or are even duplicate efforts leveraging different technologies, all because their focus is more on wants over needs for their capability.
So how do we move from thinking in wants to acting on needs? It starts with transparency and alignment to the organizations' strategies.
How many people in your organization know and understand the strategies that are key to delivering value to your customers? How many more define their initiatives around those strategies? Unfortunately, the answer is very few.
To start you need to create a Portfolio Valuation scoring model that is tied to your strategies and then provides a scoring mechanism that is aligned to Objectives and Key Results. The key results form the basis of the value factors that will generate a score for each initiative.
By aligning the scoring engine to strategies and having the value factors aligned to metric outcomes, we can apply the scoring model across the organization holistically. This is key to moving from a wants to needs conversation in the organization.
Having implemented this model in several organizations what happens at the leader level is that they have a harder time justifying investments that they want if they have low scores associated with them. How do you convince leadership that it’s a good idea to invest a million dollars in a project with a value score of .5? The answer is it’s not easy.
At one organization that had been trying to make the case to invest in a new ERP system with no success, we were able to tell the story better when leadership saw that they were investing large sums of money into low-value returns. So the scoring model isn’t just to stop you from working on the wrong things, it also informs future investments to support fact-based decisions.
Value needs to be the driving focus of any organization as you have a limited amount of investment capital for software development. Adding useless features that don’t align to strategy and have low-value returns is a waste of money
Additionally building things you don’t need adds bloat to your tech stacks as this code still has to be maintained and supported long-term. The cost of any feature is never just related to its development cost.
Agile Your Way
My experience with Agile stretches back almost 20 years when a healthcare organization I worked for asked me to take on a new product development effort that was languishing. When meeting with the developers they asked me if I’d support them doing the project in Scrum. Not being familiar with it I did some reading and came back and said I’d do it.
And this was how many of us started in Agile, people taking the leap and then figuring it out. Funny thing, during this time there were no coaches.
Instead, we were forced to work with each other to figure out what our ‘Agile’ was going to look like. And here’s the thing, there is no ONE way to do Agile. You did what worked and if it worked then you were Agile enough and kept changing when needed.
Coaching came later and with it the industry that we have now. Lost in all of the talk involving frameworks has been the concept that each organization is different and what Agile will become for them needs to adjust or adapt to the organization and not vice versa.
Instead, Agile Transformations rely almost entirely on the implementation of specific frameworks and then telling the organization they have to adapt to what the framework expects. The frameworks assume that your organization perfectly fits into their framework and no company I’ve worked for yet has that been the case.
You have to apply the framework based upon the intended outcomes the framework seeks and not implement it ‘out of the box’ in my experience.
Don’t get me wrong I’ve been involved with many organizations where we have implemented something out of the box and it’s not that we can’t deliver value, but the inherent imbalance of where the organization is at and what the framework expects keeps us from reaching higher levels of matutity.
Another reality not talked about much, is that is possible to be successful in managing a transformation on your own. Two of the most successful Agile organizations I’ve worked in (not as a coach) were led by the people in the organization, we just started and got to work asking a simple question – Is what we are doing Agile? If not what needs to change?
Was it easy? No, but what change is? Could we have used some help? Sure, but we couldn’t afford a multi-million dollar transformation led by coaches.
It was these experiences in mind that I helped create the Agile Learning Journey, a complete package of E-learning content, developed based upon my years of experience in working in Agile.
Agile Learning Journey provides coaching for your leadership down to the teams that will be working in Agile but does so in a way that points you lays a foundation of knowledge that would have been helpful all those years ago when I started working in Agile.
In addition to the reach experience you will find in our learning modules, we also provide you with boot camp training material, templates, and a myriad of other support elements to help you launch your Transformation successfully.
We can help you move to an Agile operating model at a fraction of the cost of bringing on full-time coaches, who often have little of that real-world experience I’ve developed over the years.
This is an important distinction because coaches who haven’t been involved in working in Agile will in the end tell you how the framework is supposed to work, but have little real experience making it work.
This is where my experience brings life to our product. I’ve worked through the challenges of how to align change to action for people and organizations.
If you are interested in learning more please visit us at agileprocoaching.com or connect with me directly at michael@agileprocoaching.com.
Organizational Zones of Antagonism
Recently my family and I were watching a worldwide bio-diversity seminar online and during one of the segments on Lichen’s (yes it was fascinating) the presenter talked about how Lichens grow and they formed what she called Zones of Antagonism as they looked for more food which allowed them to grow bigger.
The Zone of Antagonism formed a barrier around their space and would ward off any encroachment from another competing Lichen organism for their food source.
This concept immediately got me thinking about how organizations often operate with zones of antagonism as well. We see and deal with them all of the time though we often refer to it as the politics of an organization.
People, due to the siloed design of their organizations' processes, often form what might look like zones of antagonism around their functional area. These manifest themselves in many ways but are often revealed when an organization goes through any type of change management, such as an Agile Transformation.
Change forms a threat to the status quo, to the power bases built up with the current structure of the organization. Power influences outcomes and outcomes drive behaviors. Tell me how someone is incented and we can tell you how you are likely to behave.
We reward success, but which also means that there is a loser. Much like the Lichen looking to compete for food, people often look to influence or consolidate power as much as they can when working within an organization. We have been taught that to move up in an organization implies high levels of authority, influence, and compensation, so these are the drivers for what we see when we pull on the levers of change.
What we as change agents might refer to as resistance might also be called zones of antagonism instead. It’s not that people are resisting as much as they are protecting against either something they know to be a real threat to their current state or something they fear due to a high level of unknowns.
As an Agile coach, we need to put ourselves in the place of the individuals we are coaching and ask if the organization has made clear the vision of why Agile is the way to go and what the organization and the people within it will get out of supporting the move to it?
If leadership for an organization has not made clear the game plan for engaging in change, Agile or otherwise, then people, much like Lichen will respond by establishing their zones of antagonism as a way to delay, thwart or even kill the transformation overall.
We know resistance to change is real, however before condemning the resistance seek to understand it first. It’s this step that starts the real work to remove the zones of antagonism in an organization that will cause the value you seek.
Too often as coaches, we are transactionally hired to come in and teach Scrum, SAFe, or any of the other myriad of frameworks used to ‘implement’ Agile.
The problem is that the frameworks won’t make you Agile, only the mindset of change combined with the vehicle (frameworks) can move you from simply going through the motions and ‘Doing Agile’ to the place we want to be of ‘Being Agile’, where operate in a new normal.
TAP2 Change - Building an Agile Organization via the Pillars of Transparency, Accountability and Predictability
I’ve been involved with Agile for almost 15 years in all manner of roles and organizations. Some of the Agile efforts I’ve been involved with could be counted as a success, some not so much.
The organizations that I’ve been involved with, which had successful transformations, had a few key behaviors they exhibited, which included:
1. A willingness to be vulnerable regarding what wasn’t right about how the organization. These organizations weren't afraid to discuss what wasn't working and make decisions about what needed to be done at the Leadership level.
2. Active engagement from the organization’s leadership and a willingness to experiment and fail along the way towards mature and effective agile processes.
3. An ability to provide people and teams the space to become self-organizing and empowered to define how best to work within in the context of being Agile.
As I've moved through the Agile experience I've identified a way to approach an 'Agile Transformation' from a different perspective. Too often our focus is only on the frameworks that have grown up to support the implementation of Agile, such as Scrum, Kanban, SAFe, xP and a myriad of others. These frameworks focus on how teams operate and are concerned mostly about the flow of work to teams. This is only part of the equation.
Based upon my experiences I've created a framework that is holistically focused on changing the entire organization not just the software development capability.
I call the approach TAP2 Change
TAP2 Change focuses on developing three key pillars necessary for a successful Agile transformation:
1. Transparency
2. Accountability
3. Predictability
Transparency –
This pillar is about defining many of the missing pieces of most Agile Transformations, most importantly identifying why the organization wants to move too Agile.
Agile shines a light on all of your organization’s inefficiencies and asks one simple question – What you are going to do about it?
Something we don’t tell organizations trying to be Agile is that Agile doesn’t fix anything, it’s not a framework, or a process, so it can't 'deliver' anything for you. What it is, is a mindset which asks you to challenge your current belief structures held within your organization and then start the process of re-envisioning your organization.
Transparency starts at the top where we challenge Leadership to:
1. Define a clear vision and strategy conveying to the organization why you want to do this and what you expect to have as an outcome as you transition to Agile. Tell people the important part of change - ‘What’s In It For Me’
2. Reassess how they view their value streams or develop them if they don’t exist. This will challenge long-held beliefs about what is valuable to the organization and will result in a brand new way of thinking about your business.
3. Redefine your products and capabilities within the context of your value streams. This again will challenge beliefs about where your organizational value resides.
4. Engage people from all levels of the organization as you build out your Agile Transformation strategy, ivory tower approaches need not apply. Agile is a ground game that needs input from everyone in the organization so it doesn’t appear that this is being something done to them but with them.
5. Completely change the way you look at how you finance your software development projects, moving from Project to Team-based funding.
Your Transparency Pillar will be the most difficult and will take the most time because if you can’t be transparent about what outcomes you are seeking and the ways that your organization must change to get them, then you will not realize the full value of going Agile.
Instead, you’ll be like the myriad of organizations who reach the state of Doing Agile and never move past this state or worse regress when leadership declares they are Agile and stops supporting it.
Accountability –
Accountability is an important element in any Agile Transformation however much of our efforts in rolling out Agile to the organization avoid organizational and team accountability.
When we talk about Accountability we are talking about several elements:
1. Organizational Accountability – Leadership is accountable for defining an Agile Transformation strategy and roadmap and ensuring that they both communicate and regularly update the organization on how they are doing. Leadership is also accountable for ensuring that they support the change and don’t simply fund the initiative and forget about their part in this significant culture change that they must lead.
2. Team Accountability – As Product Development teams begin operating in whatever framework that they will be using, they are accountable to the organization to engage positively and seek to continually grow in the maturity and capability of that framework. Too often Leadership views Agile as a way for software development teams to not be accountable for their work and show progress in delivering on important features and functionality. This is not the case, but how we view accountability is not about hitting fixed dates and scope but rather being accountable with respect to our Transparency so that Leadership is informed with facts about how we are progressing and can then more clearly understand the issues with attempting to create features in a highly complex environment.
Leadership is accountable to teams to be engaged in assessing what value we they are delivering and making fact based decisions on what is needed not what was wanted.
Predictability –
Predictability is ultimately what Leaders are looking for, they have to make commitments to customers and shareholders with respect to value that they expect to deliver. Not all organizations have the luxury to continually develop and deliver new features and enhancements such as Amazon or Google can, the reasons are many but they are real.
This pillar however, just as with the Accountability Pillar, is not about a team marching towards a fixed date/fixed scope effort. Rather Predictability is about understanding the capacity of individual teams and the entire organization and identifying the minimal amount of work that will deliver the most value in the shortest time.
We view Predictability not within the context of scope but with cadence, be it story points, # of stories, or whatever metric you use to identify how much work can be completed within a specified amount of time.
To ignore our need to show progress, even if the progress shows that we are hitting challenges, provides important fast feedback to Leadership so that they can make informed decisions and manage expectations of customers earlier than waterfall would ever allow.
You can build out one or more of the Pillars, but it is the strength of all three that will provide you with a strong foundation for building a successful Agile Transformation.
To learn more about our process you can reach me at michael@soundagile.com or go to www.soundagile.com
Also - Coming Soon - Look for my book - TAP2 Change Building an Agile Organization via the Pillars of Transparency, Accountability, and Predictability.