I was a double CS and Medieval-History major. One of my banes in the latter was learning Latin. The problem was that Latin was taught as a "dead language." (The prof in my giant Latin class made that very explicit in the first lecture.) 1/4
We were subjected to long boring lectures, then had to go off on our own and memorize/study. That's no way to learn anything. Learning comes from doing. Had we actually spoken Latin to each other *in class,* things would have been way easier. 2/4
All this applies to programming as well. Too often, we think we should learn on our own and then somehow apply that info effectively. We don't start really learning until we apply what we read, however. 3/4
IMO, the best way to learn, then, is in a #Mob, not sitting alone with a book. Build something. Learn as you do it (ideally from other people). Apply it immediately. 4/4
• • •
Missing some Tweet in this thread? You can try to
force a refresh
"Working software is the primary measure of progress" is an enabling constraint. Sometimes, managers use the phrase as a club to get people coding. Coding, however, is a necessary driver of creating software, but it's not the only thing you have to do. 1/5
Standing in front of a whiteboard and discussing design, creating and running tests, just staring out the window and thinking, are all necessary parts of the development process; but if you don't get that software into your customers hands, you've accomplished nothing. 2/5
Using working software (the result of the process) as your measure of progress, puts natural limits on the entire process, including the staring-out-the-window parts. It forces you to work small (thus the "constraint") enough to deliver frequently. 3/5
How do you split work into Initiatives and Epics, as required by Jira? Don't split it like that. The basic unit is the product. You move the product forward by capturing stories of the user's work, then modify the product to support that work. 1/4
"Intiatives" and "Epics" were made up by Atlassian. They do not, and never have, have any part in Agile thinking, and have nothing at all to do with story-based planning. 2/4
Stories desribe your user's work. They might be so nebulous that they're not ready to put onto your backlog, but those "Epics" have no place in anything except strategic planning. An "Epic" is not a bag of stories. It's a story so nebulous that you can't implement it. 3/4
I really don't understand the hate directed at Design Patterns (both the book and the practice). Design patterns are DISCOVERED, not invented. Gamma et al just cataloged patterns that they disovered by reading lots of code written by people who didn't know one another. 1/
They didn't invent those patterns. They just said: we looked at a lot of well-written code, and when we focused on certain problems, patterns started to emerge in the solutions. 2.
Criticising the GoF is really criticising the code of many hundreds of talented programmers working independently. Sure, the patterns aren't appropriate everywhere, and it's often best to start simple & refactor into a pattern, but they say that pretty clearly in the book. 3/3
This diagram has gottem me thinking about management structure. We all (at least /we/ all) agree that cross functional teams is best for development. However, that cross-functional, colaborative structure disappears up the organization, where VPs, etc., are not a team at all. 1/
So we have a situation where there's a collaborative executive team, collaborative execution teams, and everybody in the middle are separate individuals, often working at odds. I don't really see how that can work. In fact it doesn't work very well. 2/
We have a tension betwen any hierarchical structure, which is about giving orders and single people in control, and collaborative cross-functional teams. The only soln that makes sense to me is to go to collaborative cross-functional teams everywhere, even at mgmt levels. 3/
I was just thinking obout the old CMMI "maturity levels," which I now think of as rather ridiculous. 1/4
It's intereting to me that the very highest level (Optimizing: "organization is focused on continuous improvement and is built to pivot and respond to opportunity and change.") is where we *start* in the Agile world. 2/4
All the other levels involve a control hierachy telling everybody what to do and standardising across the organization. They are Agile anti-patterns. If you've standardized the entire org on Scrum or SAFe, you're at CMMI level 3, not even close to Agile (at level 5). 3/4
Was asked "Can Scrum Master be held responsible if development team is not delivering on time?" The whole notion of "delivering on time" flies in the face of basic Agile thinking. "On time" means that you're matching an estimate of a detailed up front plan. 1/5
Detailed up-front plans are the opposite of agile thinking. Teams learn as they work. The things they learn often "slow them down." If, for example, they learn that it's not worth building the thing they're working on, they'll stop working on it. 2/5
They won't deliver that thing at all, much less "on time." Do you really want to punish somebody for not wasting the company's money building something that nobody wants? 3/5