Tweet

@michaelbolton

@michaelbolton

@michaelbolton

@michaelbolton

@michaelbolton

@michaelbolton

@michaelbolton

More from @allenholub

Allen Holub

@allenholub

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

Allen Holub

@allenholub

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

Allen Holub

@allenholub

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

Allen Holub

@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

Allen Holub

@allenholub

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

Allen Holub

@allenholub

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

Share this page!

Allen Holub

Try unrolling a thread yourself!

More from @allenholub

Allen Holub

Allen Holub

Allen Holub

Allen Holub

Allen Holub

Allen Holub

Did Thread Reader help you today?

Like this author's thread?