Share this page!

Allen Holub Profile picture
Twitter logo
10 Nov, 4 tweets, 1 min read
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
An MVP is a prototype, but it's one that you'll discard if it doesn't turn out to be viable. 4/4

• • •

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

Allen Holub Profile picture
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 Profile picture
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 Profile picture
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
Allen Holub Profile picture
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
Allen Holub Profile picture
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 Profile picture
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

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!

Like this author's thread?

Get email notifications when new thread is out from this Author!

Check out other threads from this Author!

Read all threads by @allenholub