< Using the Theory of Flow to Find Your Impediments     ToC     Improving your company’s culture >

Small development groups may either be stand alone or embedded in a larger group. True standalone groups in a larger organization rarely exist in that they usually have a need for shared services of the company and must also work with an ops organization that is also helping other groups. In these cases there is often a conflict on what priorities to guide shared services or ops with when they have insufficient capacity. There are three general situations for small groups therefore:

1. small (< 125 people) group representing the entire development organization
2. small group in a larger organization  that has its own funding but that both works with other groups in the organization and depends upon  shared services and ops
3. small group as above but shares its funding with other groups

I will present an assessment for the first situation and then add what you need to investigate for the second and third cases.

Assessment Timeline for Small Standalone Development Group

Let’s first review the items from an earlier chapter in this part The purpose of an assessment in visual form:

These, of course, are interrelated. The following schedule can be used to accomplish this:

Step 1: Prepare for the assessment.

The steps for preparing for an assessment include:

1. Identifying the key players in the transition to better methods
2. Identifying who is the driver behind this adoption
3. Identifying who has the budgetary control behind this adoption
4. Identifying the products/services done by the group (and it’s larger organization if it’s in one)
5. Understanding the roles and location of all of the teams involved (see The Net Objectives Value Stream Questionnaire for the particular information to get)
6. Have interviews with a few key players in all locations to get a sense of:

• the major challenges present
• the attitude of the different roles involved about the adoption
• the level of Lean and Agile experience at the leadership, management and team levels

7. Identify two teams to help you with the assessment:

• Core Transition Team. This team consists of 3-8 people (around 5 is ideal). This team should have some visibility into all of the main aspects of the client company. In particular DevOps, system architects, PMO, product management, development, testing/QA (if separate from dev). The purpose of this team is to:
  • learn the main concepts of the FLEX system to ensure its applicability
  • become evangelists for the approach

Qualities of team members:

• Should be on-board with the idea that we need an improved process
• Educate the people as we get trained
• They have unique perspectives that provide insights that we can’t gain any other way

• Extended Transition Team. This is the core team extended to include representatives from all teams and all roles. The purpose of this team is::Convey information about their company
  • To get insights into all teams in the group adopting the new approach
  • To bring up any concerns they have about the adoption
  • To provide information to their teams about the adoption
  • Learn the main concepts of the FLEX system to ensure its applicability
  • Become evangelists for the approach

These can be done off-site if need be. 

Step 2: Onsite Assessment

This schedule is a guide. Step 1 is used to set the specifics.

Note: Meetings in italics are when group is in a larger organization and the roles the meeting is with exists. 

1. 2 hour meeting  with the core team.

• • Ask each members view of what the situation is, what they want to accomplish and what their greatest concerns are
  • Present figure 1 without the red/blue text boxes and go through their value stream identifying their challenges and strengths. 

2. 1 hour meeting with product management/owners – or those who will be responsible for these roles. This meeting is to understand the current thinking these folks have and to see how product management is being done.
3. 4-6 one hour meetings. Meet with all “gemba” roles – 1 hour each (devs, testers, ops/shared services, architecture, other groups not well represented by the core teams). These are to provide insights to the consultant about what’s happening at the team level. Management often does not have a clear picture of this so it is important to meet with them directly.
4. 1 hour meeting with core team to review what was learned and to create a tentative road map.
5. 2 hour meeting with extended team to review what was learned and to present the tentative roadmap.
   • This is still primarily an group meeting, but others can attend if desired.
   • Present “value stream” created in core team meeting.
   • Answer questions.
   • Ask for objectives.
   • Review and modify the roadmap
6. 1 hour meeting with business partners outside of group. This is mostly to inform them about the new method the group will be using. It also is a preliminary enrollment for spreading Lean and Agile across the organization. It also is to provide some awareness of how the group will work with these other teams.
7. 1 hour meeting with PPMO that initiates the projects for this group and others, meet with them. On key purpose of this is to provide the PPMO with certainty that budgeting, finance and SOX compliance can be accomplished in the Agile space.
   • • Present flow model
     • Address PPMO concerns
       • mitigating risk
       • having a plan they can count on
       • knowing they will get value from their investments
       • having a resilient system so they can get some degree of predictability
       • Budgeting and SOX compliance
     • Provide insights on value of quarterly budgeting

8. 1 hour meeting with Executives (management and leadership). These folks will have similar concerns as the PPMO.
   • Provide explanation of what group is doing and why
   • can extend this meeting and to provide some Lean-Agile traing
9. Leave time open for topics that come up (2-4 hours)

< Using the Theory of Flow to Find Your Impediments     ToC     Improving your company’s culture >