Project Management

Put Practices in Context: #NoBestPractices

From the Disciplined Agile Blog
by , , , , , , ,
#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 | Requirements | requirements | Reuse Engineering | Risk management | RUP | Scaling | scaling | scaling agile | Scrum | 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

Recent Posts

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

Disciplined Agile is a Hybrid

HONESTY



There is no such thing as a “best practice”, except perhaps from a marketing point of view.  All practices (and strategies) are contextual in nature.  In some situations a practice works incredibly well and it other situations a practice can be the kiss-of-death.  Two of the philosophies behind the Disciplined Agile (DA) toolkit are that choice is good and that you should understand the trade-offs of the options available to you.  In short, practices are contextual in nature and you should strive to adopt the ones that work best for the situation that you find yourself in.

Let’s work through an example.  A hot button for many software developers are strategies around cost estimation, typically used for budgeting and forecasting purposes.  In DAD initial estimation is addressed by the Develop Initial Release Plan process goal, the goal diagram for which is shown below.  As you can see with the Estimating Strategy factor there are several options available to you.  We’re not saying that these are all of the potential estimating options available, but we are saying that this is a fairly good representative range.  The arrow on the left-hand side of the strategies list indicates that the strategies towards the top of the list are generally more effective for initial planning than the strategies towards the bottom of the list.  Your mileage may vary of course.

Initial release planning

The following table summarizes the trade-offs involved with two of the estimating strategies, in the case formal point counting (such as function points) and an educated guess by an experienced individual.  One of the reasons why the DAD book is so thick is that much of it is tables like this communicating the trade-offs of the hundreds of practices and strategies encapsulated by the toolkit.  As you can see, there are advantages and disadvantages to both strategies.  You can also see that there are situations where each strategy potentially makes sense.  Although you may not like a given strategy, I personally abhor formal point counting, you should still respect the fact that the strategy is viable in certain situations (perhaps not yours).

 

Strategy Advantages Disadvantages Considerations
Formal point counting
  • Fulfills contractual obligations in some situations – for example, the US Government often requires function-point based estimates.
  • Provides a consistent way to compare projects and team productivity.
  • Often increases the political acceptability of the estimate due to the complexity of the effort to create it.
  • Greatly extends the Inception phase effort.
  • Provides a scientific façade over the estimation activity, even though estimation is often more of an art in practice.
  • Reduces team acceptance of the estimate because the estimate is typically produced by a professional estimator.
  • Historical data won’t exist for new technology platforms or development techniques, requiring you to guess the value of some complexity factors.
  • Provides a mechanism to compare the productivity of development teams, which can motivate them to over estimate and thereby decrease comparability and the value of your historical database.
  • Total cost of ownership (TCO) is very high as it motivates questionable specification practices, which in turn motivate change prevention and other poor behaviors by the development team.
  • Overly long estimation efforts in an effort to get the “right answer” often prove to be far more costly than the actual benefit provided.
  • Beware of misguided desires for “accurate” or “consistent” estimates which prove costly to produce in practice yet don’t improve the decision making ability of senior management to any great extent
Educated guess by experienced individual
  • Very quick and inexpensive way to get a reasonable estimate.
  • Requires that you have an experienced person involved with your project (if you don’t, then you should consider this a serious risk).
  • Explicitly reveals to stakeholders that estimating is often more art than science.
  • Some stakeholders may be uncomfortable with the fact that you’re guessing.
  • Beware of estimates by people who are inexperienced with the platform or domain or who do not know the abilities of team.

 

There are several reasons why DAD’s goal-driven approach is important:

  1. It makes your choices explicit.  If your team wants to truly own your process then it first needs to know what choices are available to it.
  2. It makes it clear that practices are contextual in nature.  No practice is perfect for all situations, every single one has advantages and disadvantages.  Are you choosing the ones that are most appropriate for your situation?
  3. You can have more coherent discussions of the trade-offs that you’re making.  We have endless religious battles in the IT industry around process-related topics.  This often happens because people choose to focus on the benefits of their favorite practices and to downplay the disadvantages (or worse yet are oblivious to them).  To help your team move to more effective practices it’s important to recognize the trade-offs involved with each, to then discuss them rationally, and then decide to adopt the strategy that is most viable given your situation.  Note that this doesn’t necessarily mean that you’re going to adopt the best practice from the start, but that instead you’ll adopt the best one that you can right now.  Later on, perhaps as the result of a retrospective, you’ll decide to make improvements to your approach (in the case of process factors where the strategies are ranked by effectiveness, your team may choose to adopt a strategy higher in the list).
  4. Improves the effectiveness of retrospectives.  During a retrospective it is fairly straightforward to identify potential problems that you’re facing, what isn’t as easy is identifying potential solutions.  You can improve retrospectives by having these process goal diagrams available to you to suggest potential strategies that you should considering adopting.
  5. You can avoid reinventing existing practices.  Many very smart and very experienced people have found ways to deal with the same challenges that you’re facing today.  Furthermore, many of them have shared these strategies publicly.  If you don’t know that these strategies exist you are at risk of wasting time reinventing them, time that could be better spent adding real value to your organization.
  6. It enables scaling.  Teams in different situation will make different process decisions.  Although teams at scale, perhaps they are large teams or geographically distributed, will follow many of the same practices as small co-located teams they will also adopt a few strategies that make sense for them given their situation.   DAD’s process goals provide the insight that teams need to understand how they can address the challenges associated with the scaling factors that they face.

For a more detailed discussion about the challenges around “best practices”, you may find the article Questioning Best Practices to be an interesting read.  The New Deal for Software Development provides some interesting insights as well.

Posted by Scott Ambler on: March 05, 2015 05:16 AM | Permalink

Comments (0)

Please login or join to subscribe to this item


Please Login/Register to leave a comment.

ADVERTISEMENTS

"Diplomacy is the art of saying 'Nice doggie' until you can find a rock."

- Will Rogers

ADVERTISEMENT

Sponsors