Scaling Roles

I recently took a program level course on the Scaled Agile Framework (SAFe) and was introduced to 3 roles useful for scaling agile software development – the Release Train Engineer (RTE), the Product Manager (PM), and the Enterprise Architect (EA). Who are these people? And more importantly … what do they care about?

There are 9 SDLC areas represented in People First’s optimization challenge. A Strong(ER) score indicates that a person is a leader/mentor in that area. A Strong score indicates that a person is confident and competent in that area. A Neutral score simply indicates that a person is not strong in the area. This could be because they have not had an opportunity to develop skills in the area, or the area just does not interest them – which is perfectly acceptable. But it can also mean that they delegated the responsibility of caring to others (who care) because of the need to focus and specialize in 1 or 2 areas of the SDLC.

If an RTE were to take People First’s optimization challenge their score would most likely look like this – Strong(ER) in Development Process and Process Performance.

RTE

In comparison, an excellent team level agile/scrum master cares about Development Process and perhaps Process Performance too. Depending on their strengths in other areas of the SDLC their optimization challenge could look like this Scrum Master (actual score).

The RTE, in the context of their focused program level participation, will probably not score Strong in these other areas. They focus on keeping the train on the track and delegate cross-functional responsibilities to self-organized teams. See http://scaledagileframework.com/rte/ for more information about the RTE role.

If a PM were to take People First’s optimization challenge their score would most likely look like this – Strong(ER) in Business Value and Strong in System Value.

Program Manager

In comparison, an excellent team level PO master cares about Business Value and System Value too. Depending on their strengths in other areas of the SDLC their optimization challenge could look like this Product Owner (actual score).

Product Owner 'T'

The PM, in the context of their focused program level participation, will most likely not score Strong in these other areas. Their focus is on the features (content) and the Program Backlog and delegate cross-functional responsibilities to self-organized teams. See http://scaledagileframework.com/product-management/ for more information.

If an EA were to take People First’s optimization challenge their score would most likely look like this – Strong(ER) in Technical Architecture and Strong in Application Architecture.

Enterprise Architect

Epic Owner (EO) of the Architecture Epic, the EA makes sure the enterprise applications make consistent use/reuse of the most capable computer technologies possible. See http://scaledagileframework.com/enterprise-architect/ and http://scaledagileframework.com/architectural-epic/ for more information.

Who owns the Business Epic? A Business Architect is not a role introduced by SAFe but is a common role/title within large enterprises. If a Business Architect were to take People First’s optimization challenge their score would most likely look like this – Strong(ER) in Business Value and System Value.

See http://scaledagileframework.com/business-epic/ for more information.

 

 

 

 

 

 

 

Now You Can Do the Mushy Stuff Too

Jim Highsmith said, “At the core, I believe Agile Methodologists are really about ‘mushy’ stuff… about delivering good products to customers by operating in an environment that does more than talk about people as our most important asset but actually ‘acts’ as if people were the most important, and lose the word asset.”

This simple but profound idea is the motivation behind Process Second. Process Second is a software development process that focuses on UP essentials, manages development using Scrum, and gives teams the ability to achieve organizational goals by using their strengths. I started developing the process in January and most of the high-value stories are done!

ReleaseForecast

The project has a weekly release schedule so if you have a People First account – Now you can do the mushy stuff too.

Why Strengths?

Someone asked me why I am so persistent about strengths, “Why don’t you just give up?” And can People First Process Second be used without taking a strengths assessment. I am persistent about strengths – I won’t give up – because 1) my own strengths story and 2) the business case for using strengths in an organization. Of course you can use People First Process Second without taking a strengths assessment. But why would you?

Optimize It: Manage Iteration

Managing the iteration is a daily activity that begins when iteration planning completes, and ends when evaluation begins. It is the team’s responsibility to manage all aspects of the iteration’s internal activities. Transparency is the key to success. But it is inevitable that team members who are Strong or Strong(ER) in Development Process and Process Performance will be looked to for leadership when things get tough. And they almost always do.

Strengths at Work: Development Process, Process Performance

Daily Decisions

What Did We Do Yesterday?

Each Developer on the team discloses the tasks they worked on and/or completed yesterday.

What’s Are We Going to Do Today?

Each Developer on the team discloses the tasks they plan to work on today. Developers should take on tasks that put their unique strengths to work as much as possible. Occasionally, there will be tasks that no one on the team feels Strong about. When this happens, just do the task and get it over with. If this happens too frequently, it may be time to recruit another Developer to fill this gap.

What Are the Obstacles?

Each Developer on the team reports obstacles they are facing with specific task(s).

Update Status Boards

Truthfully, everybody on the team is NOT going to care about status boards and reports. Everybody doesn’t have to. But somebody does. That is why we have team members who are Strong in Process Performance and/or Development Process. Agile Master, if team members are sluggish about updating the boards (especially if it is electronic) offer your services. It isn’t their strength; it is yours.

Determine Adjustments

Remove obstacles as quickly as possible and keep a keen eye on the Burndown Chart. Way ahead? Consider adding a Spike or a related story. Way behind? Consider removing items or splitting items. This is a team decision best led by team members Strong(ER) in Process Performance; the Product Owner must be in agreement to all decisions made.

StrengthsFinders Themes at work: Achiever, Activator, Adaptability, Analytical, Arranger, Belief, Command, Competition, Consistency, Context, Developer, Empathy, Harmony, Learner, Maximizer, Positivity, Relator, Responsibility, Restorative, Self-Assurance, Strategic, Woo,

Product Owner; Somebody Has to Care

The Product Owner has to care; this is key to business and/or organizational success. The Product Owner has to care because if they don’t, there is no vision – no profound reason why the product should be developed. You know how the saying goes, “Where there is no vision, the people perish”. Therefore the Product Owner must first care about Business Value. Someone who cares about Business Value is motivated to develop products that create revenue in the support of business and/or organizational goals. In agile development all team members are encouraged to care about Business Value. However, the core responsibility of Business Value belongs to the Product Owner. Second, they should care about Process Performance. Someone who cares about Process Performance is motivated to execute project schedules on time and on budget. Third, they should care about System Value. Someone who cares about System Value is motivated to develop systems that accurately deliver requested business value. Of course a person who performs the Product Owner role may care about many other things than these. That is what makes them unique and able to perform other roles on a project.

ProductOwnerStrengthsBusiness Value

The Product Owner must be Strong or Strong(ER) to be able to develop and communicate a product vision that people will embrace.

Process Performance

The Product Owner should be Strong or Strong(ER). If you have a Product Owner who cares about Process Performance, you will have projects that don’t wrestle with gluttony and lust – two of the 7 sins of project management. It is OK if the Product Owner is not Strong if someone else on the team is Strong, and especially if the Agile Master is Strong(ER).

System Value

The Product Owner should be Strong. A Product Owner who can actually write requirements is very valuable. But even if someone else on the team is Strong or Strong(ER) and can fulfill these responsibilities, the Product Owner has to be able and willing to collaborate on writing/reviewing user stories and acceptance tests.

Agile Master; Somebody Has to Care

The Agile Master (aka Scrum Master) has to care; this is key to successful agile adoption. The Agile Master has to care because if they don’t, nobody else will. First, they must care about Development Process. Someone who cares about Development Process is motivated to make sure their team has everything they need to perform their roles with excellence. Second, they should care about Process Performance. Someone who cares about Process Performance is motivated to execute project schedules on time and on budget. Of course a person who performs the Agile Master role may care about many other things than these. That is what makes them unique and able to perform other roles on a project.

AgileMasterStrengthsDevelopment Process

The Agile Master must be Strong or Strong(ER) to be able to successfully lead/mentor a team in the use of agile principles and practices. If the Agile Master is not Strong, i.e. the team is just starting out, pair up with an Agile Coach. They will help them Get Strong(ER).

Process Performance

The Agile Master should be Strong or Strong(ER). People who care about being on time and on budget are more willing to lean/lead towards flexibility when it comes to trade-offs concerning schedules, resources, and features. It is OK if the Agile Master is not Strong if someone else on the team is Strong, and especially if the Product Owner is Strong(ER).