Executives expect Agile results, but too few executives and managers realize the organization change necessary to support Agile results. Agile without Lean is an executive landmine and Scrum without Agile requires human resource partners.
Where Lean involves the whole system focus on customer value, Agile further extends Lean DNA for results and this requires that human resources (HR) gain a Lean understanding as well as understand Agile methods. Many organizations who attempt Agile expect Agile results: fast design, zero defect, customer delight, motivated employees, all of that.
The Agile framework of choice is Scrum:
By early 2009, more organizations were using Agile processes than waterfall processes, and of those employing Agile 84%, were using Scrum.
The heart of Scrum must include collaboration, motivation, and people development. Scrum and HR have to work together.
Scrum has close alignment to human resource objectives, sadly, too many human resource business partners fail to realize Agile change is far beyond software development teams: Agile and Scrum, itself, are organization transformation.
Expectation that others change while executives and management remain the same gain little to no realized business results. DNA does not change. Transformation requires whole-system change from:
- Human resources,
- Information technology (IT),
- Product management, and
Those who look to lose weight, but expect results without diet, exercise, and lifestyle change of immediate results over incremental progress become the folly of those who lack maturity.
An organization can not change DNA, but an Agile transformation requires the entire organization to become Lean.
Scrum without HR
If your executives do not look Lean, talk Lean, act Lean, or learn Lean than you are left with further command and control of the latest fad.
Don’t stop smoking, don’t stop drinking, don’t change your diet, don’t go to gym, but where is the change?
An organization design for Scrum involvement reveals management need to understand different Scrum roles, titles, and responsibilities are. Too many organizations never modify job titles and instead ask teams to manage their work with additional role responsibility. This is a job sharing issue with grave switching costs.
The Scrum Team is mix of roles required for success. Some organizations will never adopt these job titles, but need to account for the role. Product Owner, for example, challenges both management and inhibits team success:
Where HR need to respond is in different job titles, different job families, and different job ladders.
The Scrum Master, and individual role that requires an individual title with the knowledge, ability, skill, and motivation to succeed.
The Development Team shares accountability. To succeed, all capability to design, develop, and assure every Sprint quality requirement.
Imagine, HR, if you will, the traditional QA manager and their QA development peer that continues to think of their resource, their utilization, and management of their work resource.
The Product Owner (PO) is, however, more often a role and responsibility taken from Product Management or, sadly, in software-focused, recovering waterfall shops, the business analyst role. Let confusion ensue.
Where Scrum adoption requires incremental improvement at the team level, the surrounding organization requires transformational change to support Scrum.
Human resources must get involved, must understand, and must own Agile transformation, from job titles, to compensation, to rewards, to recognition, and, ultimately sanction those unwilling or unable to see themselves in a Lean organization.
The PO role represents the customer.
The PO role is the most critical change for enterprise transformation.
Lean-Agile focus is to optimize flow. The root cause of customer disconnect, real or perceived, is that the product does not deliver customer value.
To articulate Agile principles in practice review some of the PO flow:
- Customer to PO:
- Articulate gap
- Choice one: close gap with end-user communication/training,
- Choice two: create new stories and work with team to prioritize/design
- PO to Development Team
- Create product backlog using voice of customer
- Estimate level of effort with delivery date range – based on sprints and daily performance progress towards both acceptance criteria (customer value) and their larger population of acceptance tests to include test-first practice to write tests before code development and to assure acceptance behaviors
- Development Team back to PO to evaluate customer acceptance
- PO to customer value
Product Owner is no Daredevil
What is a Product Owner, from Scrum Guide? To look at deeper guidance, with enterprise direction in mind, I save my sanity and avoid any argument, in this case, I refer many teams to Scaled Agile Framework, on the Product Owner:
The PO is the member of the Agile team who serves as the Customer proxy responsible for working with Product Management and other stakeholders—including other POs—to define and prioritize stories in the team backlog.
The PO has a significant role in quality control and is the only team member empowered to accept stories as done. … [t]his role has significant relationships and responsibilities outside the local team, including working with Product Management, who is responsible for the Program Backlog
There is further guidance within the above Scaled Agile Framework, Product Owner post for the enterprise to figure where people change management is and where enterprise transformation support is. The gap presents no confusion for any organization leadership, management, or human resource business partner.
The focus on customer value is a focus on user-centered design. The transformation from product management may prove huge.
The transformation from command and control management, again, huge.
The transformation that the PO knows customer need and customer priority … we need a transition plan and executive awareness.
So, as a customer proxy, the Agile team coordinates solutions to meet customer acceptance.
The development team may or may not need to talk direct to customer to better understand solution set – the Lean approach is to reduce the cost of delay, that includes information. Where is the PO?
If every iteration/sprint does not achieve fully shippable product there is fat in a system that needs Lean to be Agile and get Scrum.
Executives and managers that are not Lean, are bloat.
Agile transformation that adopt Scrum need HR support for team roles, collaboration, and communication focus that really disrupt management command and control.
Share this Post