Manifesting Business Agility

A few years ago I put together this guide https://bit.ly/2Qxcjoo

Disciplined Agile Scrum Master workshop teaches basic Agile and has a variety of goals, each with a few decision points and each has a few options. So it's straightforward to grow your own team framework. But you can also just take defaults - there is an Agile (Scrum like) life cycle predefined.

A quick view is to decide on whether a cross-functional team is available (virtually always good if are) and whether you should do sprints or flow. Sprints are usually a good start for new teams, but not always.

But you should always add a little ATDD (at least level 0) https://bit.ly/3hDBfWZ

and expand on Scrum's empiricism by basing your approach on Lean and Flow so you can take a scientific approach.

Note that the choosing your way of working to start can be used to transcend whatever you start. Scrum forces you to stick with Scrum - not necessarily with what works. Not knowing how to choose your practices is, btw, one of the main causes of ScrumBut.

You'll find our old support pages useful as well
https://bit.ly/3gCj0zM

These are different:

• bashing is disparaging something with the intention of making it look bad
• criticism is expression of disapproval & involves judgement
• negative feedback is the reporting of a perceived deficiency

All of these are emotionally uncomfortable. Many automatically defend themselves by discussing the person giving the comments and not the issues. This is done by stating:

• the person giving the feedback doesn't understand what they are commenting on
• has bad motivations
• they are a "basher"

A better way to take feedback you don't like is:

• first note if you feel attacked, maybe that's not what's happening
• then, If you don’t think you have this problem, ask the person giving it why they think you do
• ask if there’s a solution to this perceived problem

Always discuss the issues, not the person giving the feedback. Neither party benefits otherwise.

Be aware that if you're tired of someone giving negative feedback but have never engaged with them about what they perceive to be a problem, they may be tired of you not attending to the problem.

Finally, remember “It is hard to get a man to understand something when his salary depends upon his not understanding it” – Upton Sinclair

You may be this person

In my earlier post I talked about the importance of decoupling budgeting and funding. Here are three common failures that occur when this doesn't happ:

1. Budgeted dollars are given to a group but not all people are allocated as needed
2. The development is funded but not the required release and support efforts
3. Something gets started but something its dependent upon is not funded

By funding MBIs, which specify the scope and people required, we get both the dollars and people we need - for the entire chunk of work being built.

Now consider these common budgeting challenges:

• Long time to get funded
• If I don’t use my funds (budget) I lose it
• If I don’t get started I might not ever get the funds
• Change of priorities – so if I jumped when I was at the top I’d have gotten my funds
• Not able to get started when I expected

Again, consider that we're not having budgets in the old sense but funding MBIs based on which ones are most important. This doesn't mean all of our problems are gone, however. We're still left withthat people are going to want to push their own areas.

I'll talk about this in my next post on the Disciplined Agile promises.

The essence of budgeting is to ensure we are allocating our funds to those endeavors that will manifest our vision and strategy. While our strategies may span years, it is important that our endeavors be Agile and enable us to shift as the world and our competitors change around us and as our own abilities and understandings change within our organization.

We need to think of strategy as our long term guide, budgeting as our short term guide of how much we are going to allocate to the different strategies and funding as the actual allocation of our funds. Doing this can be straightforward, but requires the right entity to be funded.

Funding should be done on a just-in-time basis and for items that include the construction, deployment and realization of value. It must include both the business needs and the development capabilities needed. 

Budgeting can be done in real time as well (Beyond Budgeting), but most executives will feel more comfortable budgeting on a quarterly basis. This entails aligning anticipated funding to longer term strategies. An annual budget adjusted quarterly works well if a longer term view is decided. We call it “Agile” budgeting since it is adjusted on a short time-frame based on changing conditions and understanding.

I hear Lean attached to most everything now. Lean budgets, Lean inside Scrum, and more. I remember a few years ago a website with Lean in the url offering Scrum training with no mention of Lean on the site (I looked).

In the Scrum community, Lean has undergone Arthur Schopenhauer's “All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident.” 

But just labeling it Lean doesn't make it so. At a first cut I'll suggest a quick guide for something to be lean. It must have all, or at least not contradict any, of the following concepts:

1. be based on systems thinking
2. incorporate just-in-time (thinking about removing delays)
3. encourage small batches
4. build quality in (e.g., test-first)
5. shorten feedback cycles
6. speed up delivery of value to the customer
7. enhance learning

Things can be Agile, (e.g., something that encourages quick feedback) without being Lean. Most things I see with the Lean moniker are Agile at best, and misleading about Lean at worst.