Topic 48 - 50

tags: The Pragmatic Programmer

Topic 48. The Essence of Agility

Agile is an adjective: it’s how you do something. Agility is your style, not you.

Tip 83. Agile Is Not a Noun; Agile Is How You Do Things

We feel that many people have lost sight of the true meaning of agility, and we’d like to see folks return to the basics. Remember the values from the manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

• THERE CAN NEVER BE AN AGILE PROCESS

  The agility, both in the physical world and in software development, is all about responding to change, responding to the unknowns you encounter after you set out.

  These decisions are always contextual: they depend on who you are, the nature of your team, your application, your tooling, your company, your customer, the outside world.

• SO WHAT DO WE DO?

  No one can tell you what to do. But we think we can tell you something about the spirit with which you do it.

  So here’s our recipe for working in an agile way:

  1. Work out where you are.
  2. Make the smallest meaningful step towards where you want to be.
  3. Evaluate where you end up, and fix anything you broke.

  Repeat these steps until you’re done.

  Sometimes even the most trivial-seeming decision becomes important when you gather feedback.

  e.g.

  ​​​​// 1. Now my code needs to get the account owner.
  ​​​​let user = accountOwner(accountID);
  ​​​​
  ​​​​// 2. Hmmm... user is a useless name. I’ll make it owner.
  ​​​​let owner = accountOwner(accountID);
  ​​​​
  ​​​​// 3. The story says that I’m sending this person an email, so I need to find their email address. Maybe I don’t need the whole account owner at all.
  ​​​​let email = emailOfAccountOwner(accountID);
  

• AND THIS DRIVES DESIGN

  You make a change, and discover you don’t like it. Step 3 in our list says we have to be able to fix what we break. To make our feedback loop efficient, this fix has to be as painless as possible.

  If it isn’t, we’ll be tempted to shrug it off and leave it unfixed. (Topic 3, Software Entropy.)

  To make this whole agile thing work, we need to practice good design, because good design makes things easy to change. (Topic 8, The Essence of Good Design)

Topic 49. Pragmatic Teams

Tip 84. Maintain Small, Stable Teams

A pragmatic team is small, under 10-12 or so members. Members come and go rarely. Everyone knows everyone well, trusts each other, and depends on each other.

Let’s recast some of the previous sections in terms of teams.

• NO BROKEN WINDOWS (Topic 3, Software Entropy)

  Teams as a whole should not tolerate broken windows—those small imperfections that no one fixes. The team must take responsibility for the quality of the product.

• BOILED FROGS (Topic 4, Stone Soup and Boiled Frogs?)

  Encourage everyone to actively monitor the environment for changes.

  The team needn't reject changes out of hand—you simply need to be aware that they're happening. Otherwise, it'll be you in the hot water.

• SCHEDULE YOUR KNOWLEDGE PORTFOLIO (Topic 6, Your Knowledge Portfolio)

  If your team is serious about improvement and innovation, you need to schedule it.

  Trying to get things done "whenever there's a free moment" means they will never happen.

  Tip 85. Schedule It to Make It Happen

• COMMUNICATE TEAM PRESENCE (Topic 7, Communicate!)

  The team as an entity needs to communicate clearly with the rest of the world.

  “Generate a brand” helps teams communicate as one.

• DON'T REPEAT YOURSELVES (Topic 9, DRY—The Evils of Duplication)

  Good communication is key to avoiding duplicated work between members of a team.

• TEAM TRACER BULLETS (Topic 12, Tracer Bullets)

  We recommend developing individual features, however small and limited initially, that go end-to-end through the entire system.

  That means that you need all the skills to do that within the team: frontend, UI/UX, server, DBA, QA, etc., all comfortable and accustomed to working with each other.

  Tip 86. Organize Fully Functional Teams

  Build teams so you can build code end-to-end, incrementally and iteratively.

• AUTOMATION

  Automation is an essential component of every project team. Make sure the team has skills at tool building to construct and deploy the tools that automate the project development and production deployment.

• KNOW WHEN TO STOP ADDING PAINT (Topic 5, Good-Enough Software)

  Remember that teams are made up of individuals.
  Resist the temptation to add more paint.

Topic 50. Coconuts Don’t Cut It (me)

Do not fall into the cargo cult trap.

Cargo cult: People had imitated the form, but not the content.

• CONTEXT MATTERS

  • Don't fall into the trap of blindly following trends; consider whether a particular development method, framework, or testing technique is suitable for your specific context.
  • How do you know "what works"? You rely on that most fundamental of Pragmatic techniques: Try it.
  • The real secret to success lies in continually changing, growing, and pivoting over time.
  
  

  Tip 87. Do What Works, Not What’s Fashionable

• ONE SIZE FITS NO ONE WELL (Topic 48, The Essence of Agility)

  No one size fits all, and current methods are far from complete.

  For example, Scrum defines some project management practices, but Scrum by itself doesn’t provide enough guidance at the technical level for teams or at the portfolio/governance level for leadership.

  Don’t Be Like Them (the leading companies)!

• THE REAL GOAL

  The goal is to be in a position to deliver working software that gives the users some new capability at a moment’s notice.

  Note that being able to deliver on demand does not mean you are forced to deliver every minute of every day.

  You deliver when the users need it, when it makes business sense to do so.

  Tip 88. Deliver When Users Need It

  However, overly investing in any particular methodology can leave you blind to alternatives. You get used to it. Soon it becomes hard to see any other way.

  You’ve become calcified, and now you can’t adapt quickly anymore.

  Might as well be using coconuts.

  ---

  Decide how to organize the work / improve software development processes:

  • Scrum (project management and team collaboration) + eXtreme Programming (XP) (technical practices)
    • Scrum is an agile framework that focuses on iterative development and cross-functional teams. It emphasizes frequent communication, regular feedback, and the use of time-boxed iterations called sprints.
    • eXtreme Programming (XP) is also an agile methodology that emphasizes customer satisfaction, teamwork, and continuous improvement.
  • Kanban (visualizing and managing work) + Lean (waste reduction and efficiency)
    • Kanban is a Lean methodology that focuses on visualizing and managing work in progress.
    • Lean aims to eliminate waste and increase efficiency in the software development process.