"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
I'll add that sometimes, progress does have to slow down so that you can think things through. That's fine. That's natural overhead in the process. Incorporate it into your planning. 4/5
But, if the overhead overtakes valuable work (creating "working software"), then you need to take a long hard look at how you're doing things. 5/5
I'll add: The underlying assumption is that "software" is *valuable* software. You need to take the phrase in the context of the rest of the Agile Manifesto. There's no value in just pushing random junk out the door. That's not progress.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Allen Holub

Allen Holub Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @allenholub

11 Oct
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
Read 4 tweets
24 Sep
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
Read 4 tweets
22 Sep
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
Read 4 tweets
21 Sep
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/
Read 5 tweets
18 Sep
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
Read 4 tweets
16 Sep
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
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!