This past weekend, I had the opportunity to deliver a presentation at the Pittsburgh TechFest – A Noble Product Owner 2014. I truly enjoyed myself and I believe that everyone in attendance enjoyed it as well.
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.
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.
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).
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.
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.
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!
The project has a weekly release schedule so if you have a People First account – Now you can do the mushy stuff too.
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
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.
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,
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.
The Product Owner must be Strong or Strong(ER) to be able to develop and communicate a product vision that people will embrace.
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).
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.
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.
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).
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).
I have found that organizations pursue agile initiatives from two directions. Organizations want to be agile because they have software engineering problems to solve (e.g. staff turnover, buggy software, brittle software) or they want to be agile because they have business problems to solve (e.g. customer dissatisfaction, loss of revenue, loss of market share).
I have also found that no matter what direction you start, once you have one set of problems fixed, the other raises its ugly head begging for attention – even if you didn’t have recognizable issues before. An inescapable side effect of becoming agile in one area is that it creates and/or magnifies problems in the other.
I was recently talking to a friend who is helping to lead the agile adoption in their organization. They said that their organization is consistently executing 3 week sprints that include enough testing to produce potentially deployable increments. YEAH! They said that their organization is ‘priming the pump’, i.e. grooming the product backlog during sprints to prepare for the next sprint (or two). YEAH!
But, they also said that their organization is now struggling with a bloated backlog of requests and issues. BOO! Business problems have raised their head – What should we work on next? What features are important and which ones aren’t? Can you reject requests? How?
I rarely start an organization out with hierarchical requirements. A flat product backlog that supports feature grouping is usually sufficient to start an agile adoption. Yet, within most innovative organizations, there will come a time when a top-down requirements management strategy will become necessary. Frameworks like the one proposed by the Scaled Agile Framework (SAFe) were developed for just this purpose.