Sign up to save your podcasts
Or
Share Agile Thoughts
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Agile Thoughts
Agile Thoughts episodes
- 053 Scale the Good rather than the MistakesCONNECTVisit Agile Thoughts and register to receive free development, analysis, or leadership and management materials and learn to excel at developing software. I’ll also send information on my low cost email courses you can take via the internet.053 Scale the Good rather than the MistakesDhaval: There’s no industry today that is safe. In other words, the taxi industry you got taken over by Uber and left. The media industry has been taken over by napster and then later by all the streaming devices. So there is no company on the planet that can not be taken over by a small group of seven, eight people who are working in a startup trying to basically take your bread and butter. The way organizations have historically solved this problem is by hiring more people, having more talent, and then compartmentalizing it so when they look at how am I now going to cope with all of the threats that are coming at me, which is probably 100 start ups. You can’t tell which startup will take you over, but you know one of them will. So how do you compete with that? And the way people are choosing to do that is by trying to do whatever they’ve already been doing, but only faster. So if you look at the problem that the organizations have, they’ve tried to solve a typical competitive problem by trying to more put more people at the problem. In other words, we keep doing the stuff that you’ve already been doing only now do it faster, right? They don’t change the underlying system and that underlying system is a very tayloristic mindset of compartmentalizing people, compartmentalizing their function, and trying to compartmentalize even more whenever they want to try to increase throughput.When we talk about scaling, LeSS especially, it talks about descaling because it’s about going back to the basics of why you have this system that you have and that there must be a better way of doing what you’ve been doing without taking on the overhead.Bas: A lot of those startups that are disrupting the industry, they grow and they become the same big inefficient company. So why does that happen?It happened because they didn’t get out of that mindset. Even when they were a small group, somewhere in the back of their head is still a large scale development shoot [like a plant] to work that way. Luckily we’re not that way yet, but when they grow, they make the same mistakes. If you wait, they follow the same assumption, the effect of ending up with the same kind of organizations has more to do with the assumptions that they have about how work should be done. And if lots of people have the same assumptions, then even if they think it’s a bad idea, they automatically fall into the same traps over and over again.Dh11 min
- 013 Developer Intent and the Bible
In the pre-guttenberg days, printing the Bible was done by teams of monks with a lot of hand crafted labor—even the paper and ink had to be made. Many hands over one year were involved in the production of a single bible. Software development is the same way.
The post 013 Developer Intent and the Bible first appeared on Agile Thoughts.
4 min - 013 Developer Intent and the BibleCONNECT
Visit Agile Thoughts and register to receive free development, analysis, or leadership and management materials and learn to excel at developing software. I’ll also send information on my low cost email courses you can take via the internet.
013 Developer Intent and the BibleIn the pre-guttenberg days, printing the Bible was done by teams of monks with a lot of hand crafted labor—even the paper and ink had to be made. Many hands over one year were involved in the production of a single bible. Software development is the same way.IT shops range from having 4 to 100 developers working on the same application. With Applications, the source code can be years older, sometimes over ten years old. A developer who is asked to make a change needs to understand what is already there before making an alternation. The monks, although their job should have been easier as they were typically copying, had trouble because of the drift of an evolving language and the metaphorical nature of the bible–it wasn’t easy to know what the original meaning was. Some IT shops have developers create a document that is supposed to document what a program does, but everyone knows that those documents aren’t very accurate. At best they work as a 10,000 foot map. A huge value that micro tests bring is that the developer’s intent is “baked” into another program which tests the production program. The term “production program” refers to the program that is intended to be installed into production so it can be used by users. The test program is never put into production since users aren’t interested in executing micro tests. Having micro tests gives developers something the bearded and bald monks of the medieval times never had: an automated check that raises a flag when the production program deviates from some past developer’s intent. When a micro test fails, the developer then re-evaluates her recent program changes and looks closely at the both the test program and the production program to decide if the failing test needs an update or if her strategy is flawed. This is an advancement over the monks whose only recourse was to take a break, consult with others, and pray and ponder the matter. Micro test automation is an advancement over such medieval practices such as manual testing since they give developers feedback within minutes. Now let’s get busy and start creating them.Later in this series, we’ll fill you in on situations that developers face which complicate doing TDD. But before that, let’s get the players onto the field and find out Why Devs Don’t TDD.4 min - 012 An Example of doing TDD
TDD is a clever process. By writing your test before the code, you end up growing your test with the code.
The post 012 An Example of doing TDD first appeared on Agile Thoughts.
5 min - 012 An Example of doing TDDCONNECT
Visit Agile Thoughts and register to receive free development, analysis, or leadership and management materials and learn to excel at developing software. I’ll also send information on my low cost email courses you can take via the internet.
012 AN EXAMPLE OF DOING TDDTDD is a clever process. By writing your test before the code, you end up growing your test with the code.
So let’s throw away that untested code from last episode and start over. The first developer writes a test program to check that the program she will write, shows the word “aware.” The test program won’t execute until there exists a stub of the program—essentially an interface around an empty body that does nothing, so after a she writes the test she creates the stub, then executes the test. She observes the test program reports a failure.
Great! The automated test is now the nagging shrew “driving” the programmer to make it happy. The developer adds to the program the ability to produce the word “aware” and runs the test program. The test program communicates with the wanted program and declares that it passes the test. The developer publishes the program.
Later, another developer is asked to add the colon, which she does by adding a test that reports a failure. She then makes the wanted program have the colon. When she runs the test program, she executes all the tests and both pass. She publishes the code. The third developer doing the “ness” work doesn’t make the mistake of losing the colon because, as there is a test that explicitly checks for the colon, she doesn’t need to guess the intent of the programmers before her.
With Test Driven Development, before you can add more code to your program, your first order of business is to figure out how to test what you want to add. It’s a virtuous cycle!
Next episode we’ll discuss Developer Intent and how that could have made collaborative operations such as producing Bibles get to market faster and with fewer defects.
Attributions:
This podcast frequently uses sound effects from http://FreeSound.org and specifically used samples available via the Creative Commons license from the following members:
jay_rope, fennelliott, Timbre.
5 min - 052 Same Fun Dynamic at Scale
Bas Vodde, in the bay area. One of the founders of less.
Boss: How can we get the same fun dynamics of a single team but working with multiple teams?Because often they add so much stuff and bureaucracy and distance between the teams and the actual users, that it's no fun anymore.The post 052 Same Fun Dynamic at Scale first appeared on Agile Thoughts.
5 min - 052 Same Fun Dynamic at ScaleCONNECTVisit Agile Thoughts and register to receive free development, analysis, or leadership and management materials and learn to excel at developing software. I’ll also send information on my low cost email courses you can take via the internet.052 Same Fun DyNaMic at ScaleBas Vodde, in the bay area. One of t5 min
- 052 Same Fun Dymanic at ScaleCONNECTVisit Agile Thoughts and register to receive free development, analysis, or leadership and management materials and learn to excel at developing software. I’ll also send information on my low cost email courses you can take via the internet.052 Same Fun Dymanic at ScaleBas Vodde, in the bay area. One of the founders of LeSS.Boss: How can we get the same fun dy5 min
- 051 Why do people want Scaling?
Bas Vodde in the bay area, one of the founders of LeSS on “Why Scaling?”
The post 051 Why do people want Scaling? first appeared on Agile Thoughts.
3 min - 051 Why do people want Scaling?CONNECTVisit Agile Thoughts and register to receive free development, analysis, or leadership and management materials and learn to excel at developing software. I’ll also send information on my low cost email courses you can take via the internet.051 Why do people want Scaling3 min
About Agile Thoughts
From the publisher's feed
In the time it takes to receive a Starbucks coffee, Lancer Kind covers how to consistently release software with zero defects, and how to guide teams and organizations through changes necessary to do Continuous Delivery. The Mandarin edition is at (中文版):
http://agilenoir.biz/feed/podcast/敏捷理念