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?
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).