Net Objectives Portal: Recent Episodes
None
This will be expanded, but here’s a start Understand the value stream is the workflow, not the people in the workflow, from concept to consumption of value. Attend to the entire value stream. If you don’t get cooperation of portfolio or product management, make the cost of this visible. Use Minimum Business Increments (MBIs) when enhancing existing products. Use MVPs for what they were intended for – discovering if you have new products. Don’t confuse the two. Create semi-autonomous teams that have all the skills required to create the MBIs. Do your PI planning by focusing on removing delays in workflow in the completion of MBIs. This lowers waste while lowering cost of delay. Use dependencies identified in PI planning to Improve your organization’s value creation structure
< Using the Intake Process to Educate Leadership ToC The assessment timeline for a development group of less than 125 people > Not all development groups are organized in the same fashion There are several patterns of flow through development groups. The factors that affect this are when: the number of applications that interact with each other the number of different development platforms (e.g., IOS, Android) have vertical applications riding on top of horizontal applications (e.g., MSCIT) the number of support groups for the applications the amount of dependency on shared services (e.g., Business Intelligence, documentation) Not attending to these organizational issues can make it difficult to achieve flow through the teams. An easy solution is to do a planning event that identifies dependencies 2 to 3 months out, such as SAFe does. While this will help, it creates challenges on its own: interruptions that occur will push stories out, resulting both in breaking the plan for managing dependencies and having the analysis work done on those pushed stories to be redone requirements will be stale towards the end of the program increment makes any pivoting more expensive removes focus because people are now thinking in terms of the program increment long range planning without the use of MBIs often spreads out the time that releasable items are built Parkinson’s law (work will fill the available time) comes into play To better understand the problem of the needs of these organizations, let’s look at a few of the most common. Mostly independent teams The first case to look at is when there are several development groups that are mostly independent. This is shown in the following figure. This structure is relatively easy to manage. This is a common structure for development organizations for less than 75 people. After that almost all organizations require some support group as shown in Figure 2. Independent development groups are easy to manage and can be planned on a per sprint basis. Big room planning is not needed, but often good for its social aspects. Also, because of the size of the organization it is often affordable. Simplest case typically found for development groups greater than 50 people For most organizations over 50 or so people in the development group, figure 2 is more common. This requires a bit more planning or the use of Kanban. Kanban at the application support to products can usually manage how to handle dependencies. But in order for this to work, MBIs must be used to sequence the work being requested so that the support teams know which are the most important to get done. Another practice to improve flow is to temporarily assign people from the application support teams to the teams that need them. Application and Platform Products As the cloud becomes more popular we’re seeing more and more often that applications share a common platform which may be a product in and of itself. Manufacturing Supply Chain IT Many companies have the challenge of multiple horizontal platforms that are products in their own right supporting multiple vertical applications that require them. A common example is Manufacturing Supply Chain IT. What’s Required to Solve these Differences There are two essential concepts required to solve these challenges: the use of MBIs so that cost of delay can be computed on releasable items use of organization wide OKRs so that MBIs can be sequenced based on consistent business value – allowing low level decisions to be tied back to high level business value an understanding of Flow so that teams can be organized to reduce hand offs, interruptions and delays in general Seeing how to manage flow can be accomplished through the A Simple Guide to See if a Change Will Be an Improvement later in this book. < Using the Intake Process to Educate Leadership ToC The assessment timeline for a development group of less than 125 people >
< Product Managers and Product Owners ToC Teams and Agile Coaches > The guardrails are our agreements with each other across the enterprise. Each role and phase, however, manifests these agreements in different ways. The following provides more detail on what the guardrails mean during implementation and integration. Promise: Create psychological safety Safety on a team is very important. People should be able to safely disagree with decisions even they are to abide by them after being made. Also, quality issues must be able to be safely pointed as. If estimation is being done people should be able to freely discuss their beliefs without fear of repurcusion. Safety often takes additional time to foster, but it results in better results as well as a much better work environment. Promise: Accelerate value realization When teams need to work together, they should focus on getting the most business value ready to be realized. Promise: Collaborate proactively Collaboration is key. One team cannot refuse to help another team if what the other team is working on is of more value to the organization. This helps teams look at the bigger picture. Promise: Make all work and workflow visible The work of the teams must be made visible so other teams can see both what is coming their way and how their work will affect others. Promise: Increase predictability Much of the waste created is from work being done across teams. Each team must attend to how its work affects others. Promise: Keep workloads within capacity Each team must include planned and expected requests from others. They should also respect the workload of other teams that they make requests to. Promise: Improve Continuously Teams are not just to improve themselves, but to help teams in the value stream they work in as well. < Product Managers and Product Owners ToC Teams and Agile Coaches >
This blog covers some of the ideas in the first session of our upcoming webinar series on Tuning SAFe. It's actually an adaptation of our Lean-Agile experience into the SAFe model so it will be useful for anyone attempting or doing Agile at scale. The first session, called 'Rationale of SAFe', discusses the four key elements of an Agile transformation.
Ken Pugh and Jim Trott talk about ATDD: who is involved and who leads the effort, what is involved in writing acceptance tests, how ATDD compares with regular "analysis" you have done in the past, how ATDD compares with TDD, and the language of Acceptance Tests.