Tweet

This Thread may be Removed Anytime!

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

More from @allenholub

Allen Holub

@allenholub

6 Dec

Sometimes, a skill is specialized enough that it doesn't make sense to fully integrate it into a team. Take Architect. You don’t need one on every team, and in fact, a single Architect for an entire product helps with coherence. The architect has two main jobs. 1/7

(1) Diffuse their knowledge out to the teams, assuring that everybody has architectural skills at whatever level makes sense for them. They teach. They work with individuals. They review the team’s work & make suggestions. 2/7

(2) They work with all the teams for a given product to assure system coherence. They say things like “this is good, but if we do it this way instead, it will work better with what team 2 is doing.” 3/7

Read 7 tweets

Allen Holub

@allenholub

3 Dec

IMO, the "Sprint" is one of Scrum's biggest flaws. Just dump it. When you're done with the current thing, metaphorically walk over to your backlog and pick the next-most-valuable thing to work on. There's a lot of waste in Scrum surrounding the packing of Sprints. 1/4

Getting rid of the Sprint gets rid of the waste. 2/4

That doesn't mean, by the way, that cadences aren't useful. Putting everything on the same cadence is not, however. 3/4

Read 4 tweets

Allen Holub

@allenholub

11 Nov

I keep hearing about people who want to track the progress of an Agile adoption. What are you going to track? Agile is about "responding to change over following a plan." Tracking towards a goal implies an up-front plan and a definite destination. 1/4

There is no destination to Agile, though. It's a process. You constantly improve. You never arrive. 2/4

The way to keep improving is with a continuous-improvement culture, which is evidenced by things like regular retrospectives that come up with concrete improvements that actually happen. That's not the only way, though. 3/4

Read 4 tweets

Allen Holub

@allenholub

10 Nov

I think it's worth distinguishing between a prototype and a mock up. The prototype is the first one. It's a test bed that engineers make changes to until they have the best results. The production versions are exact copies of the prototype. 1/4

I think of all software is a continuously evolving prototype. You never throw away prototypes. 2/4

A mock-up is not a real thing at all. It's something held together with duct tape and cardboard just to see if an Idea can work or not. You throw away mock ups. What people call "paper prototypes" are actually mock ups. 3/4

Read 4 tweets

Allen Holub

@allenholub

30 Oct

Often, people think they need documentation to assure continuity of knowledge in the face of rapid turnover. If that's you, then eliminate the need for so much documentation by fixing the rapid-turnover problem. Churn is not a fact of life. 1/4

Keep salaries current with what your competition will pay to hire people away. Provide a solid working environment full of relatedness/collaboration, autonomy/self-organization, mastery/learning, purpose. Create a psychologically safe environment. Trust. 2/4

Provide an ideal workplace where people want to be, and then don't require them to be there if they can't for some reason. Treat people as volunteers, not conscripts. 3/4

Read 4 tweets

Allen Holub

@allenholub

30 Oct

The Agile Manifesto says that it's better to get get things to work than it is to write "comprehensive" documentation. It doesn't say you should write no documentation at all. Don't document things that don't need to be documented. 1/4

More to the point, create things in such a way that they don't need to be documented. For example, arithmetically transparent, fully self documenting code, needs only a bit of architectural stuff (mostly diagrams, maps, & few pages of "why"). 2/4

Similarly, if your architecture closely maps closely to the Domain, you don't need to document the parts that just reflect the domain. If the code and architecture is done right, there's so little extra documentation that keeping it up to date is not difficult. 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?