Category Archives: Scrum

Making Agile Teams work in real life – The quest for Stable Feature Teams?

Estimated Reading Time: 5 minutes

Context

This post is inspired by ongoing discussions in the AgileSparks team based on our experience trying to help organizations make agile teams work in real life. It is heavily inspired or can even be called a revision of a post from a couple of years ago on the Lean/Kanban approach to teams.

If you look at the Agile Manifesto, you can find “The best architectures, requirements, and designs emerge from self-organizing teams”

Scrum, the most popular framework for implementing agile is quite clear about the topic (Quoting the Scrum Guide 2011)

“Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.”

The scaled agile frameworks popular today (SAFe, LeSS) also put high value on Scrum Feature Teams. All of this is with good reason.  As Al Shalloway writes Cross functional teams eliminate waste and manifest lean. I fully agree. So where’s the problem?

One of the big problems with cross-functional teams is that they require structure changes. Let’s assume though that we overcame this challenge. We get to the another big issue. As teams spend time together they gel and mature and get a chance to achieve higher performance levels (assuming we are doing the right things to nurture this performance and not kill it, but many have written about it before so let’s leave it aside for now). See for example Tuckman’s stages of group development model.

This is why Scrum recommends stable cross-functional teams. So, again, what’s the problem?

Well, if we have very high staff versatility meaning everyone on the team can do everything and all teams can deal with whatever is on the organizational backlog, we don’t have any problem. We can create stable cross-functional teams and they will just deal with whatever we throw their way (or whatever there is to pull from the backlog when they have capacity for it, if you want to look at it that way…). Very high staff versatility is a great idea. Extreme Programming calls it collective ownership. Others call it “Full Stack developers”. For some reason, I rarely see it in the trenches though. Maybe it is just the contexts I’m working with but the variety of technologies and specializations is such that there are very few “full stack developers” around. And as a networking/kernel specialist in my background I’m not sure I would have liked to spend lots of time coding mobile application UIs or SQL statements for that matter. So the reality we encounter is that of at least some variance of skills.

We can deal with this variability, right? We can simply build the teams in a balanced way that is tuned to what’s coming our way. Each team will take features of a certain “work mix”. Essentially this means we will have a product backlog for each “work mix”. The problem with that is that now we are dictating priorities based on the team structure. Let’s say we built a team that is Server-heavy (3 server guys 1 client) and a team that is Client-heavy (3 client guys 1 server). Both are cross-functional able to deliver end to end features but of a different nature. This constraints our capacity allocation to be 50% Server-heavy features and 50% Client-heavy features. Now what happens if we suddenly need to deal with a big need for features who require same amount of work in client and server? Yes we can force-feed teams this work and expect server guys to work on the client side and client guys to work on the server side, on both teams. Yes, this will be a good investment towards Collective Ownership and versatility. Hopefully it is something these guys will find interesting and useful individually. Hopefully they will feel it is a worthy cause. Hopefully the ramp-up time will not be too long. This picture becomes more complex the more skills we need to work on improving. This leads to many people finding it hard to create stable Scrum teams. They find it creates wastes.

Now, let’s pause for a second. In many cases this is just a symptom of fear of change. The difference between Stable Scrum Teams and Dynamic Scrum Teams can be dramatic from the perspective of management (especially those team/line managers managing people directly). In Dynamic Scrum Teams and surely when continuing to work without Scrum/Feature teams altogether people these team/line managers continue to “control” what is going on. They continue to “own” the people and move them around. They can continue to live in the illusion that their old style of management is the right style of management. The move to Stable Scrum Teams, even if it doesn’t change the formal organizational structure, leaves no room for doubt. The team/line managers are not in the loop of day to day work the same way anymore. They have to do things differently. They need to focus more on attending to the bigger picture, to the capabilities of their professional teams/lines (What Spotify call chapters/guilds and others call Community of Practice/Professionals). So one shouldn’t be surprised that they rationalize however they can the downsides of Stable Scrum Teams. (Thank you Chris Matts for sharing some thoughts about this topic of Staff Liquidity during our Feature Injection chat today).

With this in mind, maybe you are saying, the hell with it, let’s do this change. It is all political change resistance. We need to strongly communicate the need for it, manage the change correctly, sell people on being “full stack developers” and have the patience to deal with the lower productivity while we are investing in our liquidity/versatility. And in many cases this will be the right approach.

Maybe you are talking the “Start with what you have” approach of starting with dynamic cross-functional teams that are created and dissolved on demand with the rationale that it is a smaller change but is still a step in the right direction. And in many cases this will be the right approach as well. A word of caution though – Remember your goal in the long haul though – make sure that you are investing in improving versatility along the way and building the capability for improving the stability of teams without reducing the business flexibility. Invest in management skills and style that is more and more oriented around the “Community of Practice” and “Capability Building” so that managers don’t associate that strongly the “daily allocation” responsibility with their identity as a manager.

And one more thing – Regardless of whether you go to Stable or Dynamic teams but especially if you go for Dynamic – let people finish something before they start something else. Don’t put people on too many teams. Ideally a person should work on one team. There are exceptions. But if you find people are working on too many teams they should either work as a “shared services” team and not as members of all these teams or you need to stop some projects/features and wait until people actually have the attention for them. The fact that the Capacity Allocation Excel can find a way to squeeze that project in with fragments of a Full-time-equivalent to be there supporting it just in the weeks they are needed is a surefire recipe for overloading the system and affecting motivation, quality, velocity and cycle times. Jim Benson’s new book “Why Limit WIP” has a great section (Eldred’s story from chapter 7 onwards if I’m not mistaken) about this BTW. I loved the introduction of Learned Helpness as a result of this situation.

 

PS Sorry for not providing a clear-cut best practice. But hopefully I gave you some ideas about how to choose the right approach to start with in your context…

 

 

 

 

Do Craig Larman’s Laws of Organizational Behavior really mean we always need to start with a structural change? What do they say about starting with Kanban?

Estimated Reading Time: 2 minutes

I’ve been following Craig Larman’s work for a while now. I find the books he wrote with Bas Vodde on scaling agile to be very insightful and actionable.

I recently discovered Craig’s “Laws of Organizational Behavior”:
1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.
2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.
3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.
4. Culture follows structure.

And as a practical advice Craig adds:
i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that’s why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture. i discovered that john seddon also observed this: “Attempting to change an organization’s culture is a folly, it always fails. Peoples’ behavior (the culture) is a product of the system; when you change the system peoples’ behavior changes.” “

So do these Laws mean we always need to start with structural change? With a move to Feature teams for example like Scrum prescribes?
I find the laws provide an interesting perspective about a typical challenge I see at my big enterprise clients. The structure is definitely providing a glass ceiling to improved performance. Sometimes the performance is at that glass ceiling but in many cases it is way below it.

At this point we have two choices (at least) – one is to do what Craig suggests and start with a structural change. In the cases where the organization is ripe for change that would typically be the right move. In many cases though the understanding of the need for a big change is missing. There is mistrust that the new language/approach/structure of agile/flow/feature teams will work and will address problems the organization cares about.

An alternative is to use an understanding-focused tool such as the Kanban Method to both improve the performance w/ the current structure but also to show its limits/glass ceiling. At some point the organization will have to decide whether the performance gains it got within the current structure is enough and whether it is stable/sticky within the current structure. If not, the leaders will now need to change the structure to break the glass ceiling and enable the next jump in performance.

I see this pattern a lot in the field in various sizes of organizations – Kanban used to show the way towards a real structural change towards an Agile structure of real feature teams. It typically drives a healthy leader-led change that eventually sticks.

Kanban FAQ: Should I FINISH what I’m working on or help the team READY new work items?

Estimated Reading Time: 3 minutes

Once people start to get “Stop Starting Start Finishing” thinking (Kanban) or the “Focus on the current sprint” thinking (Scrum) a frequent question that comes up is how to deal with people who are required for different activities throughout the work life cycle.

Some example scenarios:

“I’m a tester who both participates in ATDD spec. workshop (upstream) and exploratory testing (downstream). The developers are free to start a new story, should I help them with the ATDD thinking for a new card or focus on finishing the one I’m working on?”

flowtrumpswip

“I’m a developer who both analyzes new stories (you might call it backlog grooming if you’re a scrum team…) and develops them. I see our backlog of ready stories is running low – should I continue to work on my story or should I move to analyze some new ones?”

Stop Starting Start Finishing talks about finishing things and minimizing the waste of inventory. It seems to say always prefer to finish and not starting. Why would we even consider a different approach? And indeed on some rare teams it is reasonable to work in a pure “One piece flow” mode where we focus on one thing, finish it, and then move to the next. But this requires a very high level of collective ownership and collaborative concurrent engineering. This is seldom the starting point and rarely an early achievement of teams trying to set up a more healthy flow of work.

So in the majority of the teams the challenge is that in order to maintain healthy flow people are typically working on different things. And when the work process of these teams is such that it requires different members of the team to take part in the work in separate areas of the life cycle so they have to touch the work, leave it, and return to it, we have an issue. Maintaining healthy flow is now in conflict with Stop Starting Start Finishing because you would typically always have something to finish, so when are you going to move left on your board or go to work on things related to your next sprint?

One concept that might help is the “Lean Decision Filter” (see slide 16 from David J Anderson’s  Lean Kanban 2009 Keynote):

Lean Decision Filter

• Value trumps Flow – Expedite at the expense of flow to maximize value

• Flow trumps Waste Elimination – Increase WIP if required to maintain flow even though it will add waste

• Eliminate waste to improve efficiency – Do not pursue economy of scale 

So based on the filter what we can deduce is that if we need to start something new in order to maintain flow then this is what we should do even if it is a potential waste since we could have focused on finished something.

BTW In a lot of scrum teams this manifests as the heuristic to spend 10% of the team’s capacity on preparing for the next sprint.

A way to decrease the waste of context switching while maintaining flow is to use an ongoing cadence. For example hold specification workshops or backlog grooming sessions at a regular time each week. This minimizes the impact of the context switch since it provides some heads up for people instead of surprising them and pressuring them to move to something else (otherwise the rest of the team will be idle…).

Bottom line – one of the first steps to really getting Kanban/Scrum is to start thinking “Stop Starting Start Finishing”. But the Lean Decision Filter helps us apply the required common sense to real world situations where this seems to be in conflict with effective flow – which is actually what we are striving for.

Do you see this problem in other forms? Did you find other ways to rationalize the right thing to do? Do you have other tips/suggestions to people facing this problem? That’s what the comments are for…

 

Implementing the Kanban Method using Scrum (a.k.a Scrum with a Kanban spirit)

Estimated Reading Time: 9 minutes

Warning:

If my last postrattled your cage, let’s see how you like this one… This post is a thought experiment. This hasn’t been tried in the field, and might be the worst idea in the world. But at a minimum it might be a way to understand better Scrum and Kanban. Let me know what you think.

The Context

Let’s assume a client or stakeholder in the organization wants to go agile and Scrum has been dictated to us – something like “Hey – I heard Scrum is a good thing. I want one of that please. I don’t care about other kinds of approaches. I want Agile. Agile==Scrum. Give me Scrum. Scrum. Scrum. Scrum.” (only SLIGHT exaggeration of real life…) Let’s also say we like the Kanban Method of evolutionary change management towards Lean/Agile and we actually believe it is a better approach to change management in the discussed context. So basically it might be a nice idea to give the organization what it wants – Scrum, while giving the organization what it needs – an evolutionary approach to change management. Is that possible? Let’s try to use the Kanban Method thinking and principles while implementing them using Scrum practices and building blocks. Here we go, enjoy the ride…

Foundational Principles:

Start with what you do now

Well, Kanban says to start with your current way of doing things. Scrum is perceived as a revolution, so let’s see along the way whether we are able to minimize the changes to the current way of doing things.

Agree to pursue incremental, evolutionary change

This is actually quite easy to live with since Scrum is also an Inspect and Adapt framework that seeks to look for incremental evolutionary change using Scrum as a baseline.

Initially, respect current roles, responsibilities & job titles

Here comes a tough one. Scrum comes with roles, responsibilities and some might say even job titles. Let’s see how we deal with those. One way is to say forget it. I know you’ve read about Scrum Masters, Product Owners and the Scrum Team. But we believe there is no need to change roles & responsibilities up front not to say define new job titles in the organizational structure. This might work and is a reasonable approach but is quite a “cop out”. Lets try to go a bit deeper …

Scrum Team

At least the Scrum Team is quite core to how scrum works so we can probably say that we will define Scrum Teams that will not make any change to existing organizational structure. If we want to play strictly to “start with what you have” we can map Scrum Teams to the current functional teams whatever size they currently are and whatever skills (or lack of cross-functional skills) they currently have. A major alternative here is to start with “Managers Scrum”. See “Managers Kanban”for the general idea. Applied to Scrum this means leaving the individuals/actual teams alone for the moment. Just create a “Scrum Team” that is comprised of the managers of the relevant functional teams. These managers will run Scrum together for a while until they learn the ropes and are able to go sell and deploy Scrum with their teams, or alternatively decide that different teams might be needed before deploying Scrum fully… I will probably elaborate on this approach in a separate post. Let me know if it interests you to push it up the priority rank…

Product Owner

I would ask the organization who decides priorities or align priorities amongst multiple stakeholders at the moment, teach the “Product Owner” role and responsibilities and start with the people currently involved in the prioritization and backlog grooming activities wearing the “Product Ownership” hat. If needed, they will do it as a team. It is far from being the strong Product Owner that Scrum advocates, but we will evolve in a direction that deals with product ownership issues if we see that there’s a problem and that the Product Owner is the right solution. Some in the Kanban community have a strong case against the Scrum Product Owner. I have to say I’m on the fence on that one.

Scrum Master

Oh the Scrum Master… Well recently even in pure Scrum implementations we (AgileSparks) talk about the Scrum Master being a management style that should be undertaken by the individual leading the team (yes yes we believe that even self-organizing teams should have a leader that enables this self-organization). So I find it quite plausible here to talk about Scrum Master being a very good description of the coaching style of management that teams need in order to gel and perform better and better over time. And then I say we don’t need to define any specific role like that but the people leading the teams should be inspired. For sure we don’t define Scrum Masters as a position in the HR system. What we might do is find a great coach/practitioner candidate and ask him to play the “Scrum Master”/”Kanban Practitioner” role for the organizational unit (several teams)

Encourage acts of leadership at all levels

This is quite orthogonal to the actual flow framework we are using. But since Scrum is notoriously exclusive of managers (at least the perception is that it is…) lets make sure that managers understand they need to lead their teams to better and better performance, better and better alignment with what users/customers value. Of course Scrum Teams should show leadership by self-organizing to perform better and better. Those leading teams should show leadership by investing energy in team building and performance, decentralizing control while ensuring alignment with the organizational initiatives and values.

Visualize Work

First actual step is decide which teams comprise the flow of work and visualize the work flowing in and out of those teams using Kanban Boards and work in the teams using the same Kanban Boards or Scrum Task Boards if someone finds a very good reason to do that. Note in this step there aren’t any sprints or ceremonies yet.

We will use a Product Backlog with Product Backlog Items to visualize the “incoming”/”future” work. A Release Backlog can be used to visualize the subset of that work that is targeted for the current release. Work already in progress or done in this release will also be in the Release Backlog but with a status indication of the work state. Based on this information we can understand how far along in the Release Backlog we are and how the Release is doing. A Release level Cumulative Flow Diagram or Burnup can also help us visualize Project/Release state and help us feel safe and aware of what is going on.

Manage Flow

Now that we have the flow visualized we need to manage the work with the concept of flow. Here Scrum gives us some clear guidance that is helpful.

Iterations

We will work in Iterations of 1-4w (Also called Sprints although that is a horrible name. Sprinting should mean short-term acceleration to deal with a special situation. Iteration pace should be sustainable). Let’s assume a cadence of 2w here as that is a reasonable iteration length that many times use successfully and also allows a good frequency of flow management activities. So every 2w we will have a “Business Day” in which we hold :

  • Iteration Demo – review the completed work of the last iteration and get product-level feedback on it with relevant stakeholders. The completed iteration should be available as an increment of Potentially Shippable Product which means all items completed are working tested software and the relevant build is a candidate for shipping after no more than a short (few days) hardening.
  • Iteration Retrospective – review and adjust our processes based on the last iteration
  • Iteration Planning – based on what’s next on the product backlog,  product-level feedback from the Demo and process-level feedback and decisions from the Retrospective, We pull backlog items into the next Iteration. Pull = We take in the right amount of items to have an effective iteration. Not too few to avoid being bored. Not too many to avoid too much multi-tasking and context switches and the danger of not completing anything. Another meaning of Pull is that the team working on the iteration does this planning and makes those decisions. It is important to have a couple of more product backlog items queued up in case we are able to accomplish more than the amount we pulled. The purpose of the planning to is to establish this focused “Iteration Backlog”/Forecast and verify everyone on the team and in product ownership on the same page regarding what the relevant product backlog items mean, the priorities between them, how they will be demonstrated in the Demo, and the level of quality/functionality expected to say they are done (Definition of Done / Acceptance Criteria).
Every day of the iteration we will hold a short (10-15min) “Daily Scrum” standup meeting in which we manage the flow within the Iteration. In this meeting the Team and Product Ownership meet in front of their visibility board (Kanban / Taskboard). They talk about flow since last meeting (What I did last day, what cards I moved), expected flow until the next meeting (What I intend to work on today, cards I’m about to Pull/Complete) and mainly impediments. Impediments can be work item specific or flow problems (bored waiting for devs to deliver something, seeing too many defects in what was delivered feeling uneffective, etc.) Impediments can be solved quickly in this meeting or taken offline by identifying an owner that will deal with them until the next meeting. Items with impediments/blockers can be marked using a special indication on the visibility board. Systemic Flow impediments can also be marked (e.g. mark the interface lane between Dev & Test with a red post-it saying “Nothing ready for testing 23/9”.

Implement Feedback Loops

Note that since we implemented Scrum ceremonies we are already deep into Kanban Method’s “Implement Feedback Loops”. The Iteration ceremonies provide feedback loops about Product and Process. The “Daily Scrum” provides a tactical feedback loop. Some teams learn to use the “Daily Scrum” to have a tight light-weight process feedback loop as well and add “Kaizen Moments” as necessary when dealing with what appear to be systemic impediments.

 

Make process policies explicit

We also made some of the process policies explicit by setting the “Definition of Done” of items to be declared Done at the end of the iteration.

Now’s the time to make more of our current policies explicit. Use your current de-facto ways of operating. You will have a chance to change/improve them in your process adaptation feedback loops:

  • What is the level of readiness of a product backlog item before the team is ready to pull it?
  • Any definitions for the interfaces between roles in the team?
  • Any other clear policies governing the work of the team, relations to product ownership, etc.? Estimation policies? Defect Fixing? Release Criteria?
The Iteration ceremonies we defined are also explicit process policies. They answer questions like how do we replenish the system, how do we deliver, etc.

Limit Work in Progress

Now after we have a flow system working, it is time to apply the real pressure. We need to constrain the system to guide it towards better flow. In Kanban we do this by limiting Work in Progress. Applied to Scrum this translates to constraining ourselves to work just on items pulled into the Iteration. We will not start working on any other item unless the Iteration is safely done. This sounds trivial, but when there are several people with different specialties on the team it is not trivial at all. It drives people to collaborate. It drives different pains/inefficiencies to the surface and requires us to deal with them.

Note that the Iteration focus is not the ideal way to limit WIP. It is not that clear and explicit and it is harder to go on a diet that tightens the WIP limit from iteration to iteration since the Iteration focus is based on velocity which might not improve so fast even if our focus is improving. Also note that in order for the Iteration Forecast/Backlog to be effective WIP limits we need to plan carefully our capacity and capabilities for the whole iteration to avoid taking on too much (and not challenging ourselves to focus) or too little (and straining our focus to an unrealistic and unhelpful level).

We can always later apply classic Kanban per-lane WIP limits of course. And since many people that want Scrum don’t really understand that the Sprint Forecast/Backlog is a way to constrain and guide improvement we can just skip to the easier and clearer approach of per-lane WIP limits. This will also make it easier to get across the end of sprint inefficiency.

Improve Collaboratively using Models

A remaining but important feedback loop is the Ops Review which is a data-driven feedback mechanism that increases accountability to improvement results and accelerates improvement activity. We will add this routine later on typically. There is nothing like that in Scrum but there is nothing saying it shouldn’t be done. Just add it on top of Scrum when the organization is mature enough for it. (I would say after a few months of managing flow and limiting WIP so the systems are stable, clear problems have been solved using Retrospectives, and it is time to seek more pervasive improvement opportunities. )

At this point we try to decentralize the improvement activity to the teams/people. We give them different models to use like Variability / Positive Deviants / Queuing Theory / Principles of Flow / etc. and expect them to suggest and execute improvement experiments and share successful conclusions for reuse by other teams.

 

Conclusions

I hope this article conveys the message that the Kanban Method can be applied using Scrum as the process framework. This can be useful in case Scrum is chosen by the organization due to various reasons but we believe an evolutionary guided change approach is a good fit for the context or we would like to complement Scrum with the useful change management ideas in the Kanban Method.

I’ve yet to try this in the field but the biggest risk I see in this approach is that Scrum IS focused on flow at the team level and there’s the danger of localized focus when using it as the main process framework. I also have an hypothesis that starting with “Manager’s Scrum” looking at the end to end flow rather than work at the team level this might be overcome.

I’d love to hear what others think. Does this makes sense? What would you do differently?

 

Making promises you can keep WITHOUT Scrum Sprint Commitment using Classes of Service

Estimated Reading Time: 3 minutes

How can we make promises we can keep without a commitment to the sprint content?

So I convinced you that the Scrum Sprint Commitment is not such a great idea. I convinced you it is mainly there for learning. You want to move to a commitment to try to meet the forecast instead of committing to deliver the whole forecast. But your Product Owner has a real problem with this. He understands all this learning rationale but his stakeholders want to know whether he can promise then a certain delivery on a certain date. So can we make promises without the Sprint Commitment?

Making promises to deliver certain backlog items in this sprint

Sometimes a Scrum team is expected to deliver certain backlog items for a specific sprint. Examples can be stuff other teams need to consume, a fixed date commitment to clients, a regulatory requirement etc. Such backlog items have a very high cost of delay so we want to really make sure when we promise to deliver them we deliver them. One way to make sure that is to put them at the top of the Sprint Backlog. If the team is working down the Sprint Backlog by priority (as they should) there is a higher chance they will deliver these backlog items.

But I believe we should be more explicit. We should have a clearer signal that these are special fixed-date items and clearer policies for what to do to make our promises around them. In Kanban teams use classes of service for this purpose. I recommend Scrum Teams in such a context simply do the same. Mark these items with a special color in the Backlog. Establish policies such as “If they are in danger we make whatever effort needed to deliver. Sustainable Pace will be put on hold”. Visualizing that these items are different will earn them a different class of service by the team. It also means that normal items without this fixed-date commitment might be put aside to make the extra effort to deliver those, even at the price of overall throughput. These items might call for deeper estimation and planning up front than normal items.

One key point is to make sure that these fixed-date items are not the majority of items in the Sprint Backlog, otherwise they cannot rely on preferential service. If you have a case of your whole work being fixed-date driven you need to be extra careful with planning and consider taking a time-buffer to protect against the inherent variability in sprint results.

With time the Scrum Team and Product Owner will learn about their ability to deliver these items and might be able to make promises earlier before the Sprint Planning, knowing that the price will only be the effect on other normal items in the sprint.

 

Making promises to deliver on a bigger project across several sprints

I won’t go deeply into this aspect in this post. Normal Agile Release Planning using history of throughput/velocity and setting hard commitments and soft commitments is the way to make promises you can keep. This means that within each sprint there will be a certain level of hard commitment related to the overall project hard commitment. If that level of commitment is already a stretch for the team then you have a dangerous project in which you cannot really expect to have safe-to-fail thinking or improvement, rather a tight focus on meeting commitment. Sometimes we have those projects. If you are always doing these kinds of projects time to look in the mirror and have a discussion about whether you are really trying to set up the organization for opportunities to improve/learn or just constantly meet commitments without any slack for improvement.