Project Management

Disciplined Agile

by , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes
Kashmir Birk
Klaus Boedker
Mike Griffiths

Recent Posts

Disciplined Agile: An Executive's Starting Point

Using Lean Agile Procurement (LAP) in complex procurement situations

Vendor Management in the Disciplined Agile Enterprise

Asset Management: What Types of Assets Might You Manage?

PMI and Disciplined Agile at Agile20Reflect

The Team Lead Role: Different Types of Teams Need Different Types of Leaders

We are often asked why Disciplined Agile (DA) has a team lead role instead of  Scrum master or project manager.  The answer is three-fold: different types of teams require different types of leaders, leadership responsibilities vary based on the type of team they are leading, and DA strives to be agnostic wherever possible.  Let's explore the implications of this strategy.  

Team lead is what is known as a meta role.  What we mean by this is that there are different types of team lead depending on the situation, as depicted in Figure 1.  Think of team lead as a place holder for a more specific type of lead.  So, a scrum master is a team lead of a Scrum team, a project leader is a team lead of a project team, a sales manager is a team lead of a sales team. At times, the team will choose to stick with the name “team lead” for the role due to their way of working best fitting that description. 

Figure 1. Types of team leads.

Disciplined Agile Team Lead Role

As I said above, there are three reasons for taking this approach with the team lead role:

  1. Different teams require different types of leads.  A Scrum team needs a scrum master, or better yet a senior scrum master, as team leader. Similarly, a project team needs a project manager or project leader.  A finance team or a sales team need a function manager such as a chief financial officer or a sales manager respectively as the team lead. Each type of team needs a team lead that is fit for purpose. Because all these teams (and many more) are part of Disciplined Agile, we cannot prescribe a single type of team lead.  
  2. Leadership responsibilities will vary across teams. The responsibilities of team leads will vary depending on the type of team they lead. For example, when leading a team a project manager takes on different responsibilities compared to a scrum master.  Similarly, a sales manager leading a team would have responsibilities around educating business leaders on the sales strategy that a project leader typically wouldn't have.   
  3. Being agnostic.  Let’s imagine for a moment that it made sense to have a single set of responsibilities for the team lead role. Which one should it be? Adopting the scrum master role would only fit Scrum teams. Similarly, adopting the project manager role would only fit project teams. In the end, either choice ends limiting the applicability of the Disciplined Agile tool kit. Remember that DA is a hybrid approach that opens your options by combining great ideas from a wide range of sources: some agile, some lean, and some traditional. Ultimately, leading teams appropriately to a better way of working.  

The end result is that you may see some DA teams with a senior scrum master as the team lead, some DA teams with a project leader as a team lead, some DA teams with a functional leader in the role of team lead, and some teams with someone who is simply the team lead. Just like your way of working (WoW) should be fit for purpose, so should your approach to roles and responsibilities.

Posted by Scott Ambler on: July 07, 2020 09:13 AM | Permalink | Comments (8)

The DAD Role of Architecture Owner

Disciplined Agile Delivery roles

As you can see from the above diagram, the primary roles of Disciplined Agile (DA) teams are similar to those of Scrum.  In Scrum, the product owner decides what will be built and in what order.  In DA we recognize that architecture is a key source of project risk and someone needs to be responsible for ensuring the team mitigates this risk.  As a result, DA explicitly includes Agile Modeling’s role of architecture owner. The architecture owner is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design.  The person in the role of team lead will often also be in the role of architecture owner, assuming they have the skills and capacity to fill both.  This isn’t always the case, particularly at scale, but it is very common for smaller agile teams.

The responsibilities of the architecture owner include:

  • Guiding the creation and evolution of the architecture of the solution that the team is working on.  Note that the architecture owner is not solely responsible for the architecture, but that they lead the technical discussions.
  • Mentoring and coaching other team members in architecture practices and issues.
  • Working closely with the Enterprise Architecture team, and often being a member of it, to understand and evolve the architectural direction and standards of your organization.
  • Ensuring that the team adheres to the architectural direction and standards of your organization.
  • Understanding existing enterprise assets such as frameworks, patterns, subsystems and ensuring that the team uses them where appropriate.
  • Ensuring that the solution will be easy to support by encouraging good design and refactoring to minimize technical debt.
  • Ensuring that the solution is integrated and tested on a regular basis, ideally via the practice of continuous integration(CI).
  • Having the final say regarding technical decisions, but they try to avoid dictating the architectural direction in favor of a collaborative, team-based approach. The architecture owner should work very closely with the team lead to identify and determine strategies to mitigate key project technical risks.
  • Leads the initial architecture envisioning effort at the beginning of the project and supports the initial requirements envisioning effort (particularly when it comes to understanding and evolving the non-functional requirements for the solution).

One of the key reasons for having this role in DA is that the architecture owner, like the product owner, has a say in work items that are added and prioritized in the work item list (backlog in Scrum parlance).  While business value is certainly a prime determinant of priorities, completing work related to mitigating technical risks is also important.  Additionally, in DA the aim is to deliver consumable solutions, not just working software.  As such, sometimes it is necessary to add work items that are technical in nature, for example related to error logging/monitoring.  Or perhaps work items need to be added to improve the continuous integration and deployment processes.

We have found that the concept of having both product and architecture owners ensures that the solution addresses both functional and quality requirements such as usability and supportability adequately.  In fact, on my current project, I worked with the product and architecture owners to negotiate their priorities such that the iteration underway includes not only a selection of high priority stories, but also a set of technical work items related to hardening the solution in preparation for entering the Transition phase of delivering the solution to the stakeholders.  Without a specific role of architecture owner, it can be difficult to escalate important technical work into the work item list.  As a result it is often done subversively without the knowledge of the product owner which is not a healthy practice, or worse it never gets done resulting in a poor quality solution.

Scott has written a good article that describes the architecture owner role in more depth.  You can view it here.

Posted by Mark Lines on: May 28, 2012 08:41 PM | Permalink | Comments (0)

No role in DAD for an Analyst?

Whiteboard modeling

Why does DAD not have an explicit role for an Analyst?  Without question classically trained analysts bring much needed soft skills and a structured approach to requirements elicitation and negotiation which may not be present in the other roles such as a product owner or a developer.  However, having these skills alone is not enough in an agile and lean world.

Unfortunately, professional organizations tend to encourage us to seek specialization and certifications over being cross-functional team members, which will be far more effective and valuable in the future.  This is not to say that these organizations do not deliver value in developing and maintaining standards of professional conduct and capability.  Attaining certifications (that require some degree of commitment and experience beyond a 2-day workshop) demonstrate commitment to a professional specialty.  This is admirable but I would suggest that this base of knowledge is just the start of being an effective team member on an agile project.  We should look outside our area of specialty to learn all we can about other aspects of software development.

It is my belief that in the near future, analysts will need to be competent testers if they intend to prosper in their profession.  An increasingly important skill is the ability to write requirements as executable tests.  My advice to analysts is to learn as much as you can about agile testing and seek opportunities to write your requirements as tests wherever possible.

For Business Analysts that are not interested in moving more toward the testing end of the spectrum there is another way to go.  Analysts can be good Product Owners, representing the customer on the project and by managing the scope and priorities.  In this role they can use their elicitation and facilitation skills to gain a clear understanding of what the customer needs (vs. wants).

Another potential career path is for the BA to move more into the area of traditional management consulting.  Often it is the business process that needs to be fixed, and this is where traditional Business Analysis skills will always be needed.

In my opinion, one career path for analysts is going the way of the dinosaur though.  And unfortunately this career path is often the status quo.  Traditional projects expect Business Analysts to document business processes and requirements in batch up-front in a linear, waterfall fashion.  They then must obtain sign-offs before actually proceeding with implementing any of the requirements.  Subsequent changes to those requirements are discouraged, unless through a formal, time consuming and wasteful Change Request process.  This model clearly is flawed, and eventually most companies will change their approach.  High ceremony and bureaucratic organizations such as government will be the slowest to adapt, but private companies in a competitive environment will adapt their requirements capture approach to a more agile alternative or risk being left behind by their competitors that will be more “agile” in adapting both their business processes and the solutions that support them.

Posted by Mark Lines on: February 13, 2012 10:54 AM | Permalink | Comments (0)
ADVERTISEMENTS

"Smoking is one of the leading causes of statistics."

- Fletcher Knebel