The longer I stay in the software development business the more I am convinced of certain things. One thing that has hit home recently is this very interesting fact – on the whole, those in charge of software delivery are fundamentally ignorant of how software is made. I have written previously about how software development is a creative process, but what amazes me is that the people who staff and manage software development fail to see how much communication is necessary to software development.
Want a Quick Agile Win? Try Office Hours
When you are an Agile Coach you sometimes must resign yourself to the fact that it will usually take team members awhile to get it and victories can be few and far between. One thing that I can recommend for a quick win and something that has worked well for me on multiple occasions (when it could be implemented) is something that I called office hours. I can only assume that I am not the one who invented this, but it is something that I “discovered” independently to solve the issue of resources being pulled into unproductive meetings when I needed them to be on task for our stories.
Agile = Antifragile Part 2
I entered my previous post on the subject when I had just begun Taleb’s book Antifragile. As I continue my reading I have run into some very specific passages which lead me to theorize that the reason Agile development works so well is that it is a living, breathing example of what Taleb would call “Antifragile.” I am also coming to the conclusion that Taleb is a truly great contemporary thinker. As I examine my own career, I plan to take to heart many of his suggestions on creating one that is Antifragile.
While I am no in any way paid to sell this book, I encourage all Agile folks to highly consider adding this to their reading list.
Agile = Antifragile?
I am currently reading the book Antifragile: Things that Gain From Disorder by Nassim Nicholas Taleb. I loved two of his other books, The Black Swan: The Impact of the Highly Improbable and Fooled by Randomness: The Hidden Role of Chance in Life and in the Markets so I thought that I would give this one a go.
His central thesis is that there are systems that are not only robust, able to withstand randomness and chaos, but there are those that actually thrive on such events. He calls these “antifragile” as opposed to fragile systems.
Larry’s Top Ten Agile and Scrum Myths
I gave the Larry’s Top Ten Agile and Scrum Myths talk to the Java Users’ Group in Phoenix recently and people have asked me what the top 10 myths are. I have posted a copy of the powerpoint, but for quick reference, I have listed below.
- Myth #1 – Agile is a Framework/Methodology
- Myth#2 – Agile Means No Documentation
- Myth#3 – Agile is Less Disciplined / Easy
- Myth#4 – You Can Achieve Agility Without Organizational Change
- Myth#5 – Agile is Scrum
- Myth#6 – Scrum Will Lead to “Hyperperforming” Teams
- Myth #7 – You Must Get 100% of all Stories Complete or You’ve Failed
- Myth #8 – Scrum Master = Project Manager
- Myth #9 – We Can Do Scrum Without a Product Owner or Many P.O.s
- Myth #10 – With Scrum We Can Make Changes Whenever We Feel Like It
Now feel free to rip into these as you wish!
Larry’s Presentation to Java Users Group
Last night I had a wonderful experience presenting to the Phoenix Scrum Users Group on Larry’s Top Ten Agile and Scrum Myths. It was a very friendly audience and there were a great number of comments and questions from folks representing the whole Agile spectrum.
I have uploaded my PowerPoint file of the presentation for those who are interested.