You may be FrAgile if...

Moving to the Agile can be challenging.  It implies a behavioral change to the Agile mindset supported by the Agile Principles found in the Agile Manifesto. However,  many find themselves in the land of FrAgile (i.e., fake Agile), Scrumbut (i.e., we are doing Scrum but not some of the practices), Scrumfall (i.e., some elements of scrum within a waterfall lifecycle), and even Kantban (i.e., Kanban without respecting the queues). 

What is FrAgile? This is where there either isn't really a commitment to go Agile, there isn't an understanding of what "being Agile" means, there isn't the talent like an Agile Coach to help bring about that change, or an incremental deployment approach stalls along the way. And most importantly, frAgile is when Agile very quickly becomes brittle, lacking in vigor, and shatters once there is tension applied leading to a regression to past ways of working.    

When "Fragile" happens...

Some may ask, “why do I care if Agile is not quite right”.  When a form of Fragile is applied, you will not gain the business benefits of aligning better with customer value and the many other benefits Agile can bring. When you see that you are not gaining the business benefits of Agile, instead of blaming Agile, look to see how you have implemented Agile and whether you are really aligning with its values and principles. 

In honor of Jeff Foxworthy and his "You might be a Redneck if" routine, I thought I would adapt his saying to fit the Agile message of this article.  I present several areas which can be problematic if they are not in place and you are serious about Agile.  So without further ado, "You may be FrAgile if": 

• ...you do not want to hire or identify a Product Owner (or similar) who works with both the customers to gather requirements and Engineering team to describe the requirements in more detail.  The result is that there engineering will build what they think the customer wants and then you will wonder why the customer doesn't want it.  
• ...you continue to have the Project Manager or Functional Manager assign the work to the Team.  The result is that your team will not be self-organizing and you will wonder why your team members are not engaged.  
• ...you continue to collect your requirements upfront and lock them in for the remainder of the project.  The result is that you may build the wrong thing for the customer and you will wonder why the customers are not very excited about the release and few are buying or upgrading to it. 
• ...you do not want to have a healthy balance of test/QA minded folks on the team.  The result is that the testing activities will become the bottleneck or worse yet, the testing aspects will become watered down (i.e., skip testing steps), ergo releasing a product with low quality and subject to many defects.  
• ...you mechanically know how to do the Scrum and XP events and practices but can't remember any of the Agile values nor any of the 12 Agile principles.  

Let me know what you think about the results of "You may be FrAgile if".  If you believe there are other Fragile, Scrumbut, Scrumfall, Kantban, and other related Agile challenges that could be non-starters or significantly impact the ability to "be Agile", please feel free to share.     

Who makes the Best Product Owner?

In one of my recent articles entitled Who makes the best ScrumMaster?, I discussed the attributes needed to make an effective ScrumMaster and what traditional roles may play the ScrumMaster best. From the feedback, those who can best exemplify the attributes of a ScrumMaster made the best ScrumMaster and it did not appear to be strongly aligned with any particular traditional role.

In this article, the focus is the Product Owner role. Much like the ScrumMaster, the Product Owner role is very important to a successfully running Agile team. In fact as teams consider adopting Agile, who plays the Product Owner is critical to gaining the benefits of Agile due to the importance of identifying customer value and enacting the customer validation activities to ensure we are building something that the customer actually wants.

What are some important attributes of an effective Product Owner? A Product Owner recognizes what customers want and translates their needs into meaningful epics and user stories (aka, requirements). A Product Owner must intuitively adapt requirements (aka, user stories) when customer needs and market conditions change, to ensure what is built and delivered aligns with customer needs. This may sound obvious but the Product Owner must have the wherewithal to ensure that the organization in which the team works in will positively support and welcome change. A Product Owner must have the attributes to be a good voice-of-the-customer (VoC) and communicate the customer needs to the Team so they can build what the customer needs. It can be quite challenging to commit time to customers and team members.  Some attributes that an effective Product Owner must have include:

• Parsing customer and business problems and turn them into meaningful user stories  
• Working with sales and marketing to get their ideas into the backlog
• Establishing a directional Product Roadmap and Product Strategy
• Understanding the business marketplace
• Understanding and interacting with the customer domain 
• Establishing effective Customer validation (e.g., end-of-sprint reviews/demos, alphas, etc.) to ensure you are building a product the customer wants   
• Understanding that it takes a trusting environment where problems can be raised without fear of blame, retribution, or judgement, with an emphasis of healing, collaboration, and problem solving  
• Facilitating and influencing the work without coercion, assigning, or dictating

So the question arises, is there a traditional role that plays the Product Owner the best? Let’s examine a few of these roles.

Business Analyst as Product Owner?

What does a traditional Business Analyst (BA) do? A BA is someone who analyzes business needs, works with stakeholders in order to understand their needs, and to recommend solutions that meets these needs. At a deeper level, a BA focuses on eliciting, documenting, and managing requirements. They also act as a liaison between business and technical groups. It is because of the work a Business Analyst already does and in particular their focus on requirements and their liaison role between the business and technical groups that makes them a good candidate for the Product Owner role. A traditional BA would have to gain the experience in working in an Agile manner including the continuous requirements elicitation process (per the sprint cadence) and applying iterative customer validation so skills and experience in these areas would have to be built.

Product Manager as Product Owner?

What does a traditional Product Manager (PM) do? A PM examines the market, the competition, and customer needs and establishes the product direction that is considered valuable to the market and the customers therein. A good PM focuses on the financial considerations including the return on investment (ROI). In addition, the PM is involved in the requirements gathering and management process. It is because of the work a Product Manager already does particularly their focus on what is considered valuable by the customer that makes them a good candidate for the Product Owner role. A traditional PM may not have the experience in working in an Agile manner including a continuous requirements gathering process (per the sprint cadence) and applying iterative customer validation so skills and experience in these areas would have to be built.

Project Manager as Product Owner?

What does a traditional Project Manager (PjM) do? The primary responsibility of a Project Manager is to plan and execute a project from the beginning to closure. A PjM focuses on the project costs, schedule, and scope. A PjM may also help build the project objectives, help manage the requirements management process, manage project risks, issues, and dependencies. While there are some attributes a PjM brings that can help in the Product Owner role, there is very little direct customer focus which is a big part of the Product Owner role so this experience would have to be gained. A PjM may have to unlearn some "assigning work" and "driving the work" as this can inhibit the team's ability to become self-organizing.

Technical Manager as Product Owner?

I have found that some Technical Managers (TM) provide aspects of product ownership to their work. The Technical Manager may get input from Product Managers, Sales, and Marketing and then crafts them into meaningful customer needs.  While there are some attributes a TM brings that can help in the Product Owner role such as crafting a product or service direction, there may be little direct customer focus which is a big part of the Product Owner role. This experience would have to be gained. In addition, a TM will need to break from the "team are my direct reports" mindset and "assigning the work" as this can inhibit the ability for the team to become self-organizing.

Other Roles as Product Owner?
There are other roles that may be considered.  A select example are those in the marketing space (e.g., Market Researcher), service space (e.g., Service Consultant), user or customer experience space (e.g., UX Designer), and entrepreneurs. These are roles that understand the market, customers, and the continuous feedback from the customer.  As organizations have various roles in this capacity, it is worth investigating those current roles that are customer facing and understand how to translate feedback and strategy into user stories. 

Summary

IMHO, those who have played either a Business Analyst or Product Manager can become an effective Product Owner. However, anyone who has played a role where they work with customers to collect their needs and then work with teams to build products or solutions that meet those needs can evolve into an effective Product Owner. I would suggest that anyone who becomes a Product Owner (or is interested in doing so) should consider taking Agile Product Owner education, reading related books, and/or gaining guidance in this area through an Agile Coach in order to help them better understand this role and the activities they will need to perform in order to play this role effectively.

Who makes the Best ScrumMaster?

As teams consider adopting Agile, one of the most important decisions they can make is who will be the ScrumMaster. Because the ScrumMaster is the promoter of Agile values and principals as well as the coach for ensuring the Scrum is being practiced effectively, it is critical that this role be filled with someone who is dedicated to implementing the Agile mindset.

A good ScrumMaster must have the ability to be an effective Servant-Leader. If is important to understand that a servant-leader takes a facilitative approach and does not apply command-and-control. Some key attributes include:

• Building a trusting environment where problems can be raised without fear of blame, retribution, or being judged, with an emphasis of healing and problem solving.
• Facilitating getting the work done without coercion, assigning, or dictating the work.
• Ensuring the implementation of healthy Agile Scrum practices and values are followed on the project.
• Removing roadblocks or find the right level of personnel to remove the roadblock.

In the book “Practicing Servant-Leadership" by Larry Spears and Michele Lawrence, they share attributes for servant leadership. Some attributes include: listening, empathy, healing, awareness, persuasion, and foresight. Anyone who becomes a ScrumMaster should consider taking ScrumMaster training to help them understand their role and the activities they will facilitate. So the question arises, is there a traditional project role that plays the ScrumMaster the best?

Project Manager as ScrumMaster?
The seemingly obvious traditional role to play a ScrumMaster is the Project Manager. However, from my experience, there are pros with having a Project Manager become the ScrumMaster. On the positive side, the Project Manager has experience in being part of the team, so they may already have a trusting relationship with the team. Some Project Managers have built facilitative skills to lead work in a non-directive yet influential manner. And many already have the skills and the insight into an organization to appropriately remove roadblocks. On the negative side, Project Managers typically do not have technical experience into the product and cannot materially participate in technical discussions or provide meaningful technical insight. Also, some Project Managers had success utilizing command-and-control attributes and the more traditional Project Management practices which will not work well (and can be destructive) in an Agile environment. It can also be hard for some Project Managers to eliminate the traditional Project Management mindset of detailed project planning.

Functional Manager as ScrumMaster?
Quite possibly the most problematic role to play the ScrumMaster is someone who is a Functional Manager (aka, line manager, technical manager, etc.). Anyone playing a role where they have successfully directed people must make concerted efforts in removing their command-and-control behavior. On the positive side, they may have some technical experience into the product so can provide meaningful technical insight. They may already have the skills and the insight into appropriately navigating the organization and the ability to remove roadblocks. On the negative side, because they have been a manager of a team, so they may have issues with the team trusting them as a peer since they have been used to being judged by managers. A Functional Manager may have been successfully utilizing command-and-control attributes. However, this will not work well (and can be destructive) in an Agile environment. They must strive to remove their directive attributes and instead build facilitative skills. They must not assign work but instead enable and support team to become self-empowered. These are significant challenges.

Technical Lead as ScrumMaster?
Quite possibly one of the better traditional roles to play the ScrumMaster is someone who is a Technical Lead (QA Lead, Development Lead, etc.). By “lead”, I do not mean a manager or someone who has direct reports, but instead someone who is considered a lead by his peers. This person has a balance of leadership skills while wanting to get the work done. They typically have no interest in directing people. On the positive side, they have technical experience into the product and their specific field (development, QA, technical writing, etc.) so can appropriately aid the work (without direction or coercion and provide meaningful insight). They have experience at being part of the team, so may already have a trusting relationship with the rest of their peers. Because a lead does not have functional management responsibilities, they typically had to build their facilitative skills to lead work in a non-directive yet influential manner. On the negative side, they may not yet have the skills or the insight into an organization to appropriately remove external facing roadblocks.

Ultimately, the best answer to the question of what role best plays the ScrumMaster is not really a particular role, but instead which person best exemplifies the combination of the attributes of servant leadership, understands the Agile values and principles, embraces continuous learning, has a grasp of the technical aspects of the product under development, and can help remove roadblocks. In your organization, are there traditional roles that more often play the ScrumMaster role or best align with the servant leader attributes? If so, what is that role?  If not a role what attributes best exemplify a ScrumMaster in your organization?

----------------------------------------------------------------------------------------------------
PS - if you liked this article, consider reading "Who makes the Best Product Owner".

Robust Agile Organization - Core Roles and Beyond!

To establish to a fully robust Agile enterprise, it is important for everyone to play a role in Agile. I have found that being successful from an Agile perspective requires "core" roles and but must include the "across the enterprise" roles to ensure success.  Let's focus on each of these areas.

Core   

The core roles provide the nucleus for building customer value.  This starts with the Development Team. I prefer to use the term Agile Team (or something similar) since I want to ensure folks understand that it is not just development-centric but includes other key cross-functional roles and disciplines.  This cross-functional team is made up of around 7-9 members who can architect, design, develop, build, technically write, and test. This is commonly made up of developers (who can architect, design, and code, but preferably some who can do all three), QA/testers (who can build and execute tests), UX, DB, tech writers, and CM/build talent. The key is to ensure you have all of the roles you need to build an idea with sufficient skills to get the job done. You may also need a Product Architect which is a role that may not be considered full-time because they can support more than one team related to an idea.  However, it should be committed to the team(s).  This person ensures that the architectural related decisions are established and discussed with the team.

The servant leader for the team is the Scrum Master. The Scrum Master educates the team on Agile processes and practices, and helps them apply those practices. The Scrum Master takes the responsibility of a team coach ensuring the team stays true to the Agile values and principles as articulated in the Agile Manifesto including applying self-organization around the work. The Scrum Master helps the Agile Team and Product Owner remove roadblocks. This role also facilitates the Sprint Planning session, Daily Stand-ups, Retrospectives, and the Agile Release Planning session. Learn more about the Scrum Master in the Who makes the Best Scrum Master article.

Equally important is the role of Product Owner (PO), the driver of customer value. This Agile role should be played by someone within each product team that is customer facing to ensure everyone understands customer needs. This is often played by the Product Manager, Business Analyst, or someone who provides the business perspective and engages with customers to ensure the Agile Team is building something that is of value to the customer. Identifying the right customers for validation is the job of the Product Owner. To scale this PO role, the lead PO may introduce Product Owner Proxies (POP) who may be architectures, lead developers, or functional managers (the latter role may now have much less to do). The POP takes direction from the lead PO via the Product Owner Scrum of Scrum sessions to ensure all POs and POPs are on the same page. Then it is important to bring the customer into the picture to validate that what the team is building is something that the customer actually wants.  Learn more about the PO in the Who makes the Best PO article.

The final core role that is often forgotten in many Agile environments is the Customer.  The customer is core to determining what is value.  With the customer, you are not really enacting Agile. The customer is where many of the ideas of value come from.  The customer provides the valuable feedback along the way that validates (or adapts) what is considered value.  The customer may be in the form of multiple personas depending on their motivations and pain points. 

Across the Enterprise (aka, Beyond) 

If this is your first foray into the Agile space or you want advance in your state of Agile, it is important to have an Agile Coach who possesses deep Agile deployment knowledge to ensure teams are implementing Agile effectively. It has been established that training will only provide initial knowledge but team members can easily revert back to old traditional habits. The Agile Coach understands both the short-term and long-term pitfalls of adopting Agile, that Agile is a culture shift and will take time, and can help the team move to Agile is a more effective and efficient manner.

We then turn to management. Middle Management must play their role where they gently back away from command-and-control and act more as servant-leaders where they trust their teams, help them remove roadblocks, and support the Agile practices. They must realize that their direct reports are now on Agile Teams so they cannot be assigned any additional work. They may attend the End-of-Sprint Review (aka, demo) to gain a more genuine sense of progress (seeing actual working functionality) vs. getting a status report. Often times middle management have less to do in an Agile world and may consider changing their roles to either more of a Resource Management or Product Owner Proxy.  Learn more about Agile and middle management by visiting the Agile and Middle Management article.

Executives/Senior Management needs to play a leadership role as Agile champion. They must support Agile and understand that its primary intent is to build customer value which can ultimately mean more revenue for the company. They must also understand that they must get the Agile teams to feel ownership of their work and this requires leadership and not command-and-control style managers. They may need to adjust their staff if it already laden with too much command-and-control. They may also attend the End-of-Sprint Review (aka, demo) to gain a more genuine sense of progress (seeing actual working functionality).  Learn more about Agile and the Executive role by visiting the Agile Executives Playbook article.

Then we bring in roles like Sales and Marketing, Finance, and HR. These roles should adapt toward the same concepts of agile leadership, self-organizing teams, collaboration, streamlining and eliminating waste. Sales and Marketing are involved with bringing a product to market. They need to help the Product Owner with requirements input and clarification to ensure we are building something the customer needs. They need to understand that the Product Backlog and Release Goals are owned by the Product Owner, they must funnel requirements to the Product Owner, and avoid making commitments without the Product Owner in agreement.

Finance needs to be flexible in understanding that they can still manage to cost because it is the scope that is the important variable.  Finance and Portfolio should adapt to a continuous budgeting approach where ideas are continuously added to an enterprise kanban prioritized by value instead of fixing the work at the beginning of an annual budgeting process. You can learn more in the book Beyond Budgeting. 

If performance objectives are part of the organizational processes, then it is important for HR to establish a performance process that allows for team goals. This is because as part of the Agile mindset, it is important to establish that it is the team’s responsibility to ensure the release is a success and not specific to individuals.  HR can also help the enterprise move from an annual performance review to continuous review and feedback. Learn more about this in the Agile is creating a new horizon for HR article. 

If an idea or product is made up of more than one Agile Team (e.g., for a team of twenty you would want to break them into three teams of around 7), then there may be a need for an Agile Project Manager (APM) to help manage the dependencies and risks across teams, remove roadblocks, and ensure they work in a concert.  They may support a Scrum of Scrums (SoS) or similar.  The APM also handles the interaction with the business governance of the organization.  If your organization is large, you will need an Agile Portfolio Management Leader or team.  This leader focuses on providing visibility to the highest value work so that the organization (and teams therein) are building the highest value work to the customer.

Ultimately everyone within the organization should be focused on understanding and delivering customer value every step of the way. Getting to that value oriented mindset is critical to the success of Agile. It takes teamwork to get there and that team is the entire organization.

----------------------------------------------------------------

You can see a presentation that covers many of these roles at: http://www.boston-spin.org/slides/boston_spin_slides_2010_09.pdf