Cult of Done

By -
I came across Bret Pettis' Cult of Done Manifesto several years ago and fell in love with it.

You need to check it out at that link and ponder the graphic he includes, but I'll give you his twelve points here:

The Cult of Done Manifesto
  1. There are three states of being. Not knowing, action and completion.
  2. Accept that everything is a draft. It helps to get it done.
  3. There is no editing stage.
  4. Pretending you know what you're doing is almost the same as knowing what you are doing, so just accept that you know what you're doing even if you don't and do it.
  5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
  6. The point of being done is not to finish but to get other things done.
  7. Once you're done you can throw it away.
  8. Laugh at perfection. It's boring and keeps you from being done.
  9. People without dirty hands are wrong. Doing something makes you right.
  10. Failure counts as done. So do mistakes.
  11. Destruction is a variant of done.
  12. If you have an idea and publish it on the internet, that counts as a ghost of done.
  13. Done is the engine of more.
These are consistent with Agile and Lean Startup principles.  When I came across this, I introduced it to the development teams I was working with at the time and we adopted the first point in our daily standups.

 Each team member succinctly began his report to the team by stating which state s/he was in at that point.  "Not knowing" was a way to ask others on the team for help.  "Action" indicated s/he was making progress on a story and expected to finish it soon.  "Completion" indicated s/he accomplished what s/he had set out to do the previous day and was ready to pull another story in or available to swarm on something with others to get it to Done.

It was a fun and non-threatening way to get developers to crystallize their thinking and summarize it for the team.  Too often, a developer provides a lengthy, too-detailed description of what s/he did the previous day and what s/he's planning to do that day.  The rest of the team tune him/her out and the PO or SM is left not really knowing if the team member is in good shape or is stuck on something.

Comments

Post a Comment

Popular posts from this blog

Severity, Priority, Impact and Likelihood - Managing Defects and Risks

By -
Defects and Risks are often dealt with in a subjective, emotional way.  That's unfortunate, because among all the things a software development team deals with, those are two that can be handled in a more constructive and empirical way. First, a couple definitions. Defect Severity: the degree of impact a defect has on system operation. A defect is something observed, so impact can be empirically quantified. Risk Severity: the degree to which a hypothetical event, should it occur, would impact system operation. A risk event is something that has not occurred, so impact must be estimated or extrapolated. The common element in both Risk Severity Assessment and Defect Severity is Impact on Revenue.  The FMEA framework that AKF recommends uses 1 = Low, 3 = Med, and 9 = High, to represent the exponential effect of a high impact risk or defect Impact on Revenue No payments being collected and/or payment data security compromised (Critical) Payment collection being de
Read more

Enterprise Agile Framework: The Entrepreneurial Operating System (EOS)

By -
Image
Brian Rabon introduced me to the Entrepreneurial Operating System (EOS) as the framework he uses to manage his company, The Braintrust Consulting Group (TBCG). EOS is the missing element in organizations that are having some success with Agile at the team level, but not succeeding with change at higher levels or outside software development. As Charlie Rudd points out in his post The Third Wave of Agile , there is broad consensus on the value of Agile practices at the team level, but all types and sizes of businesses are struggling to scale Agile and to increase agility across their organization.  I think EOS addresses those challenges. EOS is comprised of the EOS Model : Having a model like this in place allows teams to function optimally as self-organized units that share the vision and goals of the organization.  Teams are able to align themselves with the organization's objectives, and can see how their outcomes affect the organization's performance. The EO
Read more

Chatbot Code of Ethics

By -
A  NYTimes article  describes efforts by a consortium of the largest technology companies to create ethical standards for AI. A related article in MIT Technology Review is titled  AI Wants to Be Your Bro, Not Your Foe . Artificial Intelligence has reached a level of sophistication, and is on the brink of being so pervasive, that we can have these serious conversations. In my work developing AI-powered chatbots to assist with learning, I work within the bounds of these 7 precepts: Right View - our chatbots honor humanity, human dignity, and the human quest for knowledge, understanding and technological innovation Right Intention - our chatbots promote human progress in the areas of intellectual pursuits and personal ethical development Right Speech - our chatbots use encouraging, prudent, and situationally appropriate language Right Action - our chatbots perform with integrity toward the aforementioned right view and intention Right Live
Read more