This podcast is part of a series, The 10 most important things I have learned from 20 years in Agile (June 3, 2019)
In this series, Al Shalloway shares some of the most important insights he’s had over this time and how they relate to each other.
This episode is about Focusing on the Work, Not the Framework. Continue reading “10 Lessons from 20 Years in Agile: Focus on the Work, Not the Framework”
This podcast is part of a series, The 10 most important things I have learned from 20 years in Agile (June 3, 2019)
In this series, Al Shalloway shares some of the most important insights he’s had over this time and how they relate to each other.
This episode is about Flexible Concrete. Continue reading “10 Lessons from 20 Years in Agile: Flexible Concrete”
An intermediary practice is a practice that works indirectly on what you are trying to achieve. Before discussing examples and the risks of intermediary patterns, let’s look at some of the things needed to achieve flow (realizing value without delay):
By working directly on these, here is what you would have. Continue reading “Intermediary Practices vs. Practices That Work Directly on Flow”
In my earlier post I discussed the relationship between visualization and reorganization & discussed how orgs should not limit themselves to visualization but should reorganize after visualization as appropriate. But in some situations reorganization is often not a real possibility.
Consider when vertical applications drive horizontal support systems & at scale. In a financial company one might have verticals for – banking, credit cards, signature programs, loans. These feed horizontals such as – payment processing, transactions across accounts, client account setup and maintenance …
In a situation like this, splitting up the horizontals into trains to work with the verticals won’t necessarily work well – either when you run them as separate trains or as part of the vertical train. Running the horizontals as separate programs doesn’t solve the problem either as they are each pulled in multiple directions.
In these cases, it is often best to create visibility on the work to be done by using Minimum Business Increments as the guide for what to work on across the organization.
n is often not a real possibility. Consider when vertical applications drive horizontal support systems & at scale. In a financial company one might have verticals for – banking, credit cards, signature programs, loans. These feed horizontals such as – payment processing, transactions across accounts, client account setup and maintenance … In a situation like this, splitting up the horizontals into trains to work with the verticals won’t necessarily work well – either when you run them as separate trains or as part of the vertical train. Running the horizontals as separate programs doesn’t solve the problem either as they are each pulled in multiple directions. In these cases, it is often best to create visibility on the work to be done by using Minimum Business Increments as the guide for what to work on across the organization.
This blog is an excerpt from my upcoming book –Achieving Business Agility at All Scales
I see a need for a new service and wonder how many people would be interested. As many people know, we’ve been on the front edge of XP, Scrum, Kanban, Lean, SAFe, technical Agile and more. We, of course, do assessments and Lean-Agile Transformations. In the course of these proposals I have noticed that many companies don’t have experience selecting who will work best for them Continue reading “Want an experienced person helping you with Lean and Agile proposals?”
Alignment is critical for Agile. The more you have the more autonomy people can have. It’s what teamwork is really about. At the team level people align around the team’s backlog. But what do people align around at scale?
I like Don Reinertsen suggestion “There is more value created with overall alignment than with local excellence.” Continue reading “What are you aligning around?”
Many Agile folks think of tools as a necessary evil. But they have a definite purpose and done well are essential.
Any Lean-Agile approach should start with getting an understanding of where the company is. Mapping the value streams of an organization is usually a good start. Identifying challenges in workflow and team structure is another. Only then should an adoption of a new workflow or company re-structuring take place. While it is often tempting to take solutions off the shelf it must be kept in mind that no one-size-fits all. Continue reading “The purpose of tools in mid to large scale transformations”
This blog is written specifically written for those whose technology groups can readily be thought of as being composed of groups that are 40-75 in size, regardless of the current or anticipated level of SAFe adoption.
By learning Agile Product Management before shifting to a SAFe-like program increment planning event, groups can shorten the program increment being planned to 2-4 sprints instead of the normal 5-7. This results in savings from not having to refine 2-3 sprints. It also results in quicker realization of value by having a shorter release horizon. This more than makes up for the investment required to do this. Just as important, the additional focus enables easier management of proper work-in-process levels and results in teams being more efficient. If you are just learning to adopt SAFe, this is a great way to start. If you are already using SAFe, this can be a method of shortening the program increment and getting to be both more effective and efficient. If you don’t want to use SAFe, product management with some Lean-Agile coaching can be used instead.
Focus on the work, not the framework
Learning Agile Product Management will encourage people to adopt a supportive framework. It doesn’t always work the other way around.
The goal is to speed up the delivery date of your first release and continue improving after it.
Agile Product Management – The Key to Effective Agile
The intent of Agile Product Management is to identify the most valuable work to be done, focus on just that work, prepare it for the teams to work on and guide them in building the functionality needed in thin slices. This creates quick feedback, the ability to pivot & faster value realization. The goal is business agility–the quick realization of value predictably, sustainable &w/high quality. Product management creates clarity on what is most valuable for the organization to build while providing teams guidance in its implementation. By discovering & removing unnecessary scope & provding this slices of work, teams become focused on true value delivery while becoming more efficient. This enables dramatically shorter times from start to initial value delivery.
Many people are looking to improve their ability to deliver value by becoming Agile. When considering such an adoption, it is useful to consider the following current and additional costs.
Obviously, these costs must be offset by gains. In our view, these gains should be met before the end of the next program increment.
The trick to getting a return requires focusing on the actual Agile work required, not the framework that surrounds it:
The key is the focus on business agility – the quick realization of business value predictably, sustainably and with high quality. This can be readily done by guiding work through the use of minimum business increments (MBIs) to create a focus on the smallest pieces of work that will realize the greatest value. Having smaller pieces enables shorter program increments. Smaller is also easier to manage as reflected in Eli Goldratt’s (creater of Theory of Constraints) observation – “Often reducing batch size is all it takes to bring a system back into control.”
Using smaller batches and shortening the length of the increment has several advantages. First, it reduces the amount of planning required. Second, it enables the group to pivot based on the feedback learned in the shorter increment. But perhaps most importantly, it focuses the group on delivering quickly. While SAFe suggests to “develop on cadence and release on demand” most planning events tend to define releases. By focusing on the implementation of minimum business increments (MBIs), even if a release is held to the end of the program increment, it is more likely more value will be created even if unexpected delays occur. See more here.
Of course, an investment in training and coaching must be made. But it should not take more than a few days. The core skills are to:
The two key elements here are the use of MBIs and Acceptance Test-Driven Development (ATDD). ATDD is mostly a collaborative method for product owners, developers and testers to define scope and clear requirements. Automation does not need to be included in ATDD although it can be a first step towards that. Unless you have an unlimited budget of time and money, it is best to focus on actual Agile skills. Midisze companies are usually better off improving their skills and creating or modifying a framework that suits their work instead of investing in a framework and then trying to figure out how to do Agile.
A planning event is about collaboration and dependency management in order to maximize the teams to work together to maximize business value. A focus on finishing MBIs, not merely getting everything done by the end of the increment must be manifested by all teams.
See Running Effective Planning Events for more.
Learning how to do Agile Product Management with ATDD improves both what you are working on and how you are working on it. By mixing ATDD into the blend, teams get great clarity on scope and acceptance criteria setting up further gains by enabling automating testing. I am not claiming that Net Objectives does anything magical here. Anyone who can effectively train and coach in product management, ATDD and team-agility can do what we do. Just make sure that’s who you engage with. The trick is in getting training and coaching before the planning. You can get more details about a framework (if you are using one) while you are doing the work.
