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.
#ChooseYourWoW | #ContinuousImprovement | #Kaizen | #ProcessImprovement | Adoption | agile | Agile certification | agile transformation | Analogy | Architecture | architecture | book | Business Agility | Certification | Choose your WoW | CMMI | Coaching | Collaboration | Compliancy | Configuration management | Construction phase | Context | Continuous Improvement | COVID-19 | Culture | culture | DAD | DAD discussions | DAD roles | Data Management | database | DevOps | Discipline | disciplined agile delivery | Documentation | DW/BI | Enterprise Agile | Enterprise Architecture | Enterprise Awareness | Essence | estimation | Evolving DA | Experiment | Financial | GDD | Geographic Distribution | global development | Goal-Driven | goal-driven | goals | Governance | Guideline | Improvement | inception | Inception phase | Large Teams | layer | Lean | Lifecycle | lifecycle | Metrics | mindset | News | News and events | Non-Functional Requirements | non-functional requirements | Operations | Outsourcing | People | Philosophies | Planning | PMI | PMI and DA | Portfolio Management | Practices | Principle | Process | process improvement | Product Management | Product Owners | Program Management | Project Management | Promise | quality | Release Management | release management | Requirements | requirements | Reuse Engineering | Risk management | RUP | Scaling | scaling | scaling agile | Scrum | security | serial | Support | Surveys | Teams | Technical Debt | Terminology | Testing | testing | Toolkit | Transformation | velocity | Workflow | show all posts

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

Recent Posts

The Disciplined DevOps Layer

Would you like to get involved with the 20th Anniversary of Agile?

The Four Layers of the Disciplined Agile Tool Kit

The Disciplined Agile Foundation Layer

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

Comparing DAD to the Rational Unified Process (RUP) - Part 1

Last week I was discussing DAD with a new client and he asked me “Is DAD just an Agile version of RUP?”  In a word, no.  DAD is a toolkit composed of a hybrid of methods and practices as shown in the diagram.  It includes the best of Scrum, Extreme Programming (XP), Agile data and modeling, and yes, the Unified Process (UP).  DAD also includes additional content such as agile governance that is not present in any of these methods.  As the diagram indicates, probably the method that adds most to DAD is XP, not the UP.
The Rational Unified Process (RUP) started as a small manageable process framework targeted specifically for building software within the context of an iterative lifecycle.  However over time, Rational (and subsequently IBM) added additional guidance and artifacts to extend the applicability of RUP to all sorts of projects, such as package implementation, maintenance projects, technology specific guidance (J2EE, .Net etc.), systems engineering and may other project types.  It became unwieldy and hard to understand and apply successfully.  In fact it is frequently misused (with the Elaboration phase often being treated as a big requirements upfront (BRUF) phase as an example).  This misuse has been described by Julian Holmes as RINO (RUP in name only).  To be clear, RUP properly applied in the right circumstances can be very effective.  Unfortunately though, that often does not happen.  One of the issues with applying the RUP framework to different types of projects is that it is described as a “Use case-driven” approach.  Specifying requirements as use cases, and then creating component-based architecture from these use case realizations is fundamental to RUP.  This presents challenges for maintenance projects or package implementations where it may not make sense to produce use cases at all.

DAD does not prescribe a use case-driven approach, or insist that OOAD be rigorously applied to build out services/components.  A use case-driven approach is a potential practice to apply but there is a danger that this could lead to an exhaustive requirements specification which is not particularly agile.  We would prefer to use a user story-driven approach if that makes sense within the context of your project.  User stories might not be the right choice either.  Perhaps you are in a regulatory environment that demands a traditional software requirements specification (SRS).  The key point is that you will have to adapt to the situation that you find yourself in.  This is why we prioritize the team’s work with a work item list comprised of work items, rather than Scrum’s backlog comprised of user stories.  Using a work item list allows us the flexibility to put any type of work onto our backlog, extending the applicability of DAD to many types of projects beyond those for which RUP or Scrum would be ideally suited.

DAD is goal-driven, not artifact-driven.  It does not prescribe practices or specific artifacts.  Rather, it suggests alternative strategies than can be applied at certain parts of the lifecycle with the pros and cons for each, but which ones you choose is up to you.

In my next post I will describe which aspects of the Unified Process did make it into DAD and why.

Posted by Mark Lines on: August 25, 2012 02:45 PM | Permalink | Comments (0)

The DAD Role of Architecture Owner

As you can see from the above diagram, the DAD primary roles are similar to those of Scrum.  In Scrum, the product owner decides what will be built and in what order.  In DAD 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 DAD 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.  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 DAD 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, a DAD goal 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?

Why does DAD not have an explicit role for an Analyst?  This is a hot topic for those in this profession, and a subject that I have been asked to talk on, notably for the IIBA.  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 such as the Project Management Institute (PMI) and the International Institute of Business Analysts (IIBA) 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.  The IIBA is positioning the Business Analyst profession to be more strategic, identifying the need to have them present at the management table when key decisions are made regarding how the business and its architecture should evolve.  Our book on Disciplined Agile Delivery is about agile software development.  But not all business issues are solved by software.  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)

Product owner issues in the Transition phase of large agile projects

Captain Barbossa

Mainstream agile methods would suggest that we should have one product owner, being the “one” voice of the customer for matters related to release/iteration scope, priorities, and requirements clarification.

The reality that I see on most enterprise agile projects is that the product owner cannot possibly manage the work item list themselves.  In fact, they are often not the best person to do this prioritization.  I wish it were as easy as managing epics and user stories.

On my current project, we are in the process of taking ownership of a very large application built offshore.  In DAD, we would describe this as the Transition phase of the product as we deploy the solution to our stakeholders.  We will take over the build, deployment, support and enhancement going forward.  This is a team of 20+ with responsibilities spanning development, infrastructure, and devops.  Due to the complexity of the rollout we are doing it over a number of Transition iterations.

A simplistic view would suggest that the Program Manager is our product owner.  At the end of the day he may have ultimate responsibility, but he is not collocated, and deals with the larger issues of the project, such as vendor management, governance, funding, resourcing, and other related issues.  He delegates responsibility for the details to domain leads for the business, development, infrastructure and support.

My approach as the overall agile team lead is to treat the these traditional leads as product owners.  They each have their own work items and priorities such as:

Development team:

  • setting up VM images for development support of code
  • determining a source code management strategy for parallel streams of maintenance and enhancements
  • automation of continuous integration & deployment

Support team:

  • establishing a customer support strategy, with triage process, roles, on call schedules etc.

Infrastructure/DevOps team:

  • setting up automated jobs
  • performance tuning

Business:

  • change requests/stories
  • defects

All:

  • knowledge transfer between vendor and support team
  • satisfying stage gate acceptance criteria
  • documentation of procedures

For these work items, who is responsible for designating priorities, assigning to iterations, and iteration planning? The last question is the easiest to answer.  We let the team members doing the work do the task identification, estimating and assignment.  The other questions are a bit more tricky.  I don’t believe that any one person should determine the scope and prioriity of these diverse work items.  Rather, as team lead, I would prefer to let the team leads of infrastructure, customer support and development (traditionally might be PMs) to self-organize and advise me on their priorities and in which iteration their work items should be completed.  The summary of which is then reviewed with the Program Manager to assure alignment with the overall program’s goals.

Therefore what we are doing is co-managing the work item list with myself as facilitator.

This discussion shows some of the challenges in managing a DAD Transition iteration(s) using an agile approach.  I understand that the idea of having shared product ownership is not consist with methods such as Scrum.   However, in my world of large enterprise agile projects pragmatism trumps the agile “code”.  As Barbossa says in Pirates of the Caribbean, “the code is more what you call guidelines than actual rules“.

Posted by Mark Lines on: October 31, 2011 01:06 PM | Permalink | Comments (0)
ADVERTISEMENTS

"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."

- Howard Aiken