April 18, 2020 2 min to read

What I learned from Allen Holub

An opinionated guy on Agile

Allen Holub is an Agile coach. He wrote Holub on Patterns

I went through some of his materials and here is what stuck with me:

• in agile there are no deadlines there are only priorities - not when this will get done but rather what function do you need next
• if you have a deadline i.e. tradeshow then you start work and adjust based on velocity. If velocity is low as in you project you won’t make it on time then you either bring in more resources or you reduce scope. It’s not possible to say at the start that you will hit the mark. You only have 2 dimensions to play with
  1. scope
  2. resources
• no timesheets because you don’t work based on deadline you work based on priorities
• QA is baked into the process, it’s not a separate layer that gets done after
• anything that’s not providing customer value is a waste of time - time sheets / expense reports. This is admin tuff. Client isn’t paying for admin work he’s paying for software so work on the software.
• reduce friction by eliminating everything that is in the way of putting value into the hands of customers
• no PMs the team manages itself
• overall architecture CTO role is big picture view. It’s about “we’re already doing x here, if you do it the same way it will fit better”
• agile = flexible it’s not the bible. We’re agile means we’re flexible it doesn’t mean ‘agile says you should do x’. If someone is cargo cult’ing agile it means they don’t understand agile. Agile requires using your brain instead of getting a cookie cutter process. It’s not for dumb people.
• it is CEOs job to manage the culture of the organization if he can’t do it you should step in
• everything in agile depends on people being trusted to do their job
• if you trust people to do their work you don’t need managers
• you don’t need someone to sign off if the employee wants to go to a conference, they can determine if the conference is worthwhile for them

Agile Process

1. ask the customer what they need
2. break off a small chunk
3. build it
4. give it to them
5. get feedback
6. go to 2

• people don’t know what they need until you give it to them so requirements gathering doesn’t work well
• if no one will read the documentation don’t write it - it’s a waste. This applies to all paperwork to customers
• collaborate with customers don’t negotiate with them. Customers ask for hard things because they don’t know what’s hard not because they want to make your life difficult so suggest easier solutions. “That’s a really hard problem but if we make this change it will be way easier/faster/cheaper” - go back and forth.
• if I have to argue to do my job well the process will never work, you must support eachother
• high quality meals/cafeterias this is just a way to get you to work overtime
• you have to come in everyday rested and ready to do good work if you’re not rested you can’t do good work