Allen Holub Profile picture
I help you build software better & build better software. https://t.co/9q9iaKe5kK. Get in touch; my DM is open.
Domingo Gallardo Profile picture Jonathan Escobar [EN profile] Profile picture Germain C Profile picture waitire colline Profile picture Mark Kilby Profile picture 6 added to My Authors
26 Oct
The reason for decisions to happen at the team level is agility plain and simple. This applies even to strategic decisions, which are best made collaboratively at the executive-team (they are a team) level with input from the rest of the org. 1/5
If a decision doesn't happen at the place the work is done, the entire process slows down, sometimes to a crawl. 2/5
That delay, in turns, vastly increases the odds of the decision being a wrong one, both because of the telephone/whispers problem but also because the feedback loop is no longer swift or short enough. 3/5
Read 5 tweets
24 Oct
The only way to garner respect is to respect other people. I've worked with shops, however, where "management" held the teams in contempt. They blamed the teams for management-induced problems. 1/4
They called them "lazy" and they rolled their eyes when they complained to each other about how teams wouldn't self organize (all the while being more than happy to punish the teams for truly self organizing). 2/4
Given that abuse, nobody respected management. This was a DarkAgile shop, as you'd expect. Respect is a key Agile value, and there wasn't any. It is literally management's job to create a culture of respect. These ppl weren't doing that. 3/4
Read 4 tweets
22 Oct
I've been thinking about this tweet from @michaelbolton. The difference is that, in a team that really understands inspect-and-adapt, observation, experience, and experimentation is happening during development. 1/ Image
@michaelbolton Also, a team that really has the customer's interests in mind will give the customer choices. if there's no observable difference after deploy, just deploy. 2/
@michaelbolton If you're fixing a longstanding problem, explain what's different as part of the UX. The change will probably be welcome. 3/
Read 7 tweets
15 Oct
The idea of "sales" is hard in an Agile world where the thing you're selling is changing all the time. The sales people, however, can work to increase sales by identifying places where the user community (not one "prospect," but the general community) needs improvement. 1/5
In other words, the sales folks are alies who are effectively collecting potential user stories for us. For that to work, however, you can't have them screaming for some feature just because a single client wants it. That behavior is amplified by a commission model. 2/5
It's actually money in their pockets if they can get you to make a single client happy. We need to change that to a model the rewards making the community as a whole happier, not single customers. 3/5
Read 5 tweets
14 Oct
It's a well kept secret that most programmers would program even if we didn't get paid for it. (Shhhh!). I think because of that, we sometimes lose track of the fact that we work for businesses, and that businesses in turn work for their customers. 1/4
That's where the money with which they pay us to have fun ultimately comes from—customers. If we don't make the people with the money happy (that is, the customers), the business will cease to exist (and no more fun for us). 2/4
So, it's our primary job to make those customers happy by providing something that THEY find valuable. Not "internal stakeholders." Not "business people." Not some Product Mgr that calls themselves a "customer." Actual customers. The ones with the money. 3/4
Read 5 tweets
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
11 Oct
"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
Read 6 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
14 Sep
This "where there is no responsibility there is laziness and lousy work to follow" is actively destructive. "Responsibility" is a way of leveraging guilt and assigning blame, & I hate the notion that the default state of a human being is "laziness" and "lousy work." 1/
So, let's dump that "responsibilty" thing (and it's cousin, "accountability") and replace it with something better. People do their best when they belive their work is meaninful. They do their best when they feel valued and appreciated. 2/
They do their best when they're actively helped and encuraged to improve, and thrive in an evironment where learning is central and experimentation is not punished. 3/
Read 4 tweets
14 Sep
Cost of Delay (money lost becuase something hasn't been delivered) is a big deal, often > cost of development. It's hard to determine, tho, involving lots of guesswork. Fortunately, in an agile world, we don't need to have to have a hard number. 1/6
We can assume that the more valueable something is to our customer, the higher the relative cost of delay. "Relative" is all we need. In waterfall (and SAFe) shops, you need complex formulae (e.g. WSJF) for CoD because the timeframes are so long & dev time is a factor. E.g 2/6
If you have a small thing with a high CoD, and a large thing with a low one, do the small thing first. The time added to the long thing won't impact its CoD all that much. However, in an agile (SAFe isn't agile) shop, we can make the units of work very short. 3/6
Read 6 tweets
14 Sep
Many companies are locked into long release cycles (once or maybe twice a year). Just stop, already. We're agile. Those long cycles made sense when we were distributing on on floppy disk. Takes a long time to churn out those disks. We don't do that any more. 1/4
In fact, I think we should get rid of the notion of a release altogether. We can even dispense with publically visible version numbers. If you haven't updated in the last couple days, you're out of date. 2/4
Yes, I know all the arguments surrounding authoritarian IT departments run by facsists who derive power from withholding necessary software from people who need it to get work done. That's not my problem. 3/4
Read 5 tweets
11 Sep
There's a notion floating around that one of the main jobs of a manager is to buffer/protect the team from the rest of the organization. Has anybody given a moment to think how bonkers that is? 1/5
I've never seen a job advert that says "we're an extremely fu***d up organization and there's nothing we can do to fix that, so one of your main jobs is to protect the people who are doing the work from the rest of us." 2/5
The jobs all call for people to control the out-of-control teams (which is just as bonkers). The adverts all effectively say "the teams of full of lazy unmotivated bozos with the attention spans of gnats and we need you to keep them on time and in budget" 3/5
Read 5 tweets
7 Sep
If you think that quality slows you down, I have a challenge for you. Start by measuring cycle time and throughput for all your teams. Then introduce practices that improve quality in half of them. 1/4
For example: add TDD, a zero-known-defects-at-release policy, regular feedback from customers during development to adjust the UX, &c. 2/4
Note, by the way, that a story is not done if you do a demo-style review at the end of your sprint and the customers need changes. That story goes back onto the backlog or back into the next sprint, and it doesn't count as a win in your throughput measurements. 3/4
Read 4 tweets
3 Sep
Okay. "Cargo cult" is no longer politically correct. I accept that. I do, however, need a replacement term. What do you call someone who goes through the motions, mimicing something they've seen but don't understand, expecting results to occur by magic?
I've lost track of the tweet, but somebody said that they will continue to use "cargo cult" until somebody in class objects. That's like saying that it's okay to use racist metaphors as long as there are no black folk in class. The metaphor itself perpetuates racism.
Not using a racist/colonialist metaphor is a principled stance that says good things about a person. Surely, we want to teach that principles are important.
Read 4 tweets
31 Aug
I'm thinking about backlog refinement today. First, what does "refinement" mean? IMO, "refinement" is the process of adding stories, removing stories, changing priority, etc. It is NOT adding details to stories. That's just premature up-front design. 1/4
Some PO sitting in front of Jira adding details to stories is NOT refining the backlog, they're designing the implementation. Backlog refinement is an ongoing process because you're constantly learning new things about the connections between stories (and their value). 2/4b
That is, given that you're always discovering new stories and learning new things about existing ones that impact their value, modify the backlog by adding/removing/moving stories as soon as you learn so that you don't forget. Refinement is a process, not a meeting. 3/4
Read 4 tweets
28 Aug
Companies that introduce a faux Agile—some rigid process that negates actual agility—don't do that through some mistake or misunderstanding. It's a conscious rejection of Agile principles and values in favor of the status quo. 1/4
Frameworks like Scrum or SAFe are not popular becuase the adopters were duped or stupid. It's a conscious decision to accept the familiar and reject the radical, and to some highly risky, changes required for true agility. 2/4
Put another way, faux Agile is a direct result of the fear of change. It's familar, thus conforting. Given that, perhaps the most important—and most necessary—Agile principle is courage. 3/4
Read 4 tweets
26 Aug
What returns the biggest bang for the buck in Agile? That comes from doing the things that many companies resist the most. Trust the teams to do their work—no more monitoring "productivity;" no more asking for permission. 1/4
Give the team full autonomy to meet strategic objectives, including control over how they do their work and the tools they use (and if that involves doing something other than Scrum and/or dumping Jira, fine). Support them when they need organizational changes. 2/4
Encourage and suport direct communcation with customers. Make them fully cross functional and give them control from idea to deployment. Create a culture of learning and psychological safety across the org. 3/4
Read 5 tweets