…..before this, did you really know what live was?

So, last night there was a thunderstorm and I did not sleep well at all.

But, the good news is that I started playing around with words in my head, because why wouldn’t I?

Maybe it’s a coincidence that I was reminded of this tweet only yesterday:

I love wordplay, be it rhyming, alliteration or portmanteaus. And it is the latter two that seemed to grab my attention. I started playing in my mind with words that began with ‘TR’ for no apparent reason. As I noted some of them down, I started to think about how these could actually be used as a mnemonic for successful software development projects.

For those of you who have stuck around for a while, you’ll know that I started working through Michael Bolton‘s (F)EW HICCUPPS mnemonic. I’m still short of CUPPS, I’ll get there eventually, I promise. (F)EW HIC can be found here.

So without further ado, I present my new alliterative portmanteau mnemonic:

TR-emonic

Maybe not as exciting as you may think an alliterative portmanteau mnemonic could be – and I might have used a lot of artistic license – but here we go!

• Treaty
  • We call this a charter. Check out Stephen Janaway’s Creating a Team Charter
• Traffic
  • We are looking at an end goal, we need to navigate through the traffic, roadbloacks and unforseen delays on the way
• Transpose / Translate
  • If we’re lucky enough to have requirements and specification, there is still a lot that is open to interpret and mould into a working application. I often come back to the definitions of verification (did we build the thing right) and validation (did we build the right thing)
• Trio / Trifecta / Triad
  • The Three Amigos

  • So, a Product Owner, a Developer, and a Tester walk into a bar sit down to talk about something that the system under development should do.  The Product Owner describes the user story.  The Developer and Tester ask questions (and make suggestions) until they think they can answer the basic question, “How will I know that this story has been accomplished?
    
    http://blog.gdinwiddie.com/2009/06/17/if-you-dont-automate-acceptance-tests/

• Tranche
  • Slice up our workload into bitesize pieces that we can digest within our sprint cycle
• Trim
  • There is always an element of refinement (not just in refinement meetings) and we need to be flexible enough to make changes as we go along to meet MVP
• Try / Trial
  • We need to be given the freedom to try things and fail. Accountability and creativity are a must
• Tribe

  • A tribe is a group of people connected to one another, connected to a leader, and connected to an idea.
    https://sivers.org/book/Tribes

  • The basic unit of a tribe is the team. In the words of Christine Comaford, author of Smart Tribes, you need to “create a team that acts as a team, one in which the members support one another and work together to achieve the results you need.” A team should have a defined mission and the people with the skills necessary to deliver.
    https://techbeacon.com/app-dev-testing/teams-tribes-creating-one-team-culture-devops

• Transferable
  • Skills, a codebase and documenatation that is transferable is vital, as are the people who work. We want to avoid single points of failure and stagnation
• Track
  • Tracking our work, our successes and failures are all important to learn and continuously improve. Examples of this are found in the Scrum Ceremonies
• Transparent / Traceabe
  • Accountability in development is so important, and for the wider business an understanding of the weird and wonderful world of Agile/Scrum/DevOps or “whatever those development teams call it” it is important to involve those who aren’t au fait with our terminonologies. Often we can use a kanban on a wall, or a software tool like JIRA, TFS or other tools are available
• Trade
  • We have to work with others, maybe a different team or department. Better communication and collaboration is beneficial to the business
• Transcend
  • If you ask one of your colleagues if they follow their job description (if they even have one) to the letter, I would hazard a guess that most would say that they often do other things. Maybe it’s engineer who is also involved in UX or MHFA. These are good things.
  • We also look to create T-shaped engineers
• Trip
  • I guess this could either fall under traffic or:
  • We stumble, we make mistakes, we learn from them and iterate
• Triage
  • Bugs. Whether or not you have a zero defects policy or some sort of bug handling process, software has bugs and they can be reported by customers, stakeholders and development teams. An efficient and effective triage process for these bugs should be detailed, outlined and carried out
• Transport
  • Software development explained with cars
  • 
• Train
  • A release plan is important, to add focus and bring the product to market as soon as possible and tighten the feedback loop from development to production. In SAFe they use the Agile Release Train
• Transmit
  • We should project and broadcast (definitely internally, if not externally) our plans
• Transform
  • 
  • Not just an excuse to include my favourite Transformer, Grimlock, but we should be looking to transform, innovate and iterate, ourselves as well as our products. Investing in our future is important
• Transact
  • As mentioned earlier, we should have an end goal, even if it’s just a major update or product increment. It’s very deflating to work years on end with no published product. We need closure
• Treasure
  • Rewards, be them a product release or targets being met, we should celebrate our victories.

Maybe too long as a mnemonic? But, the theme is there, more a heuristic? Let me know your thoughts.

Blog post title lyrics from: Can I kick it – by A Tribe Called Quest.

Find all the songs from my blog posts at this Spotify playlist.