A lot of the material in here needs to be moved to other files. All the agile and scrum stuff can go to methodologies and meeting stuff can go to communications.
In fact, pretty much all of it has to be moved. Workflow should be a lot more process based – we have larger and smaller workflows.
We also have publication workflows that are different from code and design work.
- how we work
- workflow & toolchains
- methodologies
- communications
- rituals
- remote work
- 6 Inspiring Employee Handbook Examples | Nasdaq
- Valve: Handbook For New Employees (pdf) | 2012
- Team Handbook | GitLab
- Zappos 2014 Culture Handbook
Zappos is well known for placing tremendous emphasis on cultural fit (so much so that they offer you $3,000 to leave after the first week).
Schneider had specific ideas about how to make a great company culture, ideas that Mullenweg shared. One major mistake Schneider had seen was how companies confused supporting roles, like legal, human resources, and information technology, with product creation roles like design and development. Product creators are the true talent of any corporation, especially one claiming to bet on innovation. The other roles don’t create products and should be there to serve those who do. A classic betrayal of this idea is when the IT department dictates to creatives what equipment they can use. If one group has to be inefficient, it should be the support group, not the creatives. If the supporting roles, including management, dominate, the quality of products can only suffer.
– The year without pants | Scott Berkun 2013 Ch4
The volunteer culture Automattic inherited from WordPress, where contributors were under no obligation to participate, defined a landscape that granted wide autonomy to employees. Schneider and Mullenweg went to great lengths to keep support roles, like legal, human resources, and even IT, from infringing on the autonomy of creative roles like engineering and design. The most striking expression of this is that management is seen as a support role. The company stays as flat as possible for this reason. Schneider described his philosophy in this way:
- Hire great people.
- Set good priorities.
- Remove distractions.
- Stay out of the way.
These freedoms at Automattic reminded me that the hardest part of work is what goes on between your ears and between you and your coworkers. The trends and gadgets that make up most conversations about the future of work miss the point. Instead of vice presidents seeing the problem as a lack of a tool or a secret method, they should realize they’re in the way more than they realize. Granting authority is more powerful than any software, device, or method. Instead of treating employees like children, which many executive staffs do, Schneider and Mullenweg explicitly desired an environment for autonomous adults—a place for people who know best what they need to do great work.
– The year without pants: WordPress.com and the future of work | Scott Berkun 2013 Ch8
There was, it appeared, a mysterious rite of initiation through which, in one way or another, almost every member of the team passed. The term that the old hands used for this rite — West invented the term, not the practice — was “signing up.” By signing up for the project you agreed to do whatever was necessary for success. You agreed to forsake, if necessary, family, hobbies, and friends — if you had any of these left (and you might not if you had signed up too many times before). From a manager’s point of view, the practical virtues of the ritual were manifold. Labor was no longer coerced. Labor volunteered. When you signed up you in effect declared, “I want to do this job and I’ll give it my heart and soul.” It cut another way. The vice president of engineering, Carl Carman, who knew the term, said much later on: “Sometimes I worry that I pushed too hard. I tried not to push any harder than I would on myself. That’s why, by the way, you have to go through the sign-up. To be sure you’re not conning anybody.”
– The Soul of a New Machine | Tracy Kidder
That does not detract from the fact that this is still a terrific story. I have read it several times and still quote from it after nearly thirty years of reading from it the first time. My favorite image is of the engineer who quit the project to become a farmer, so that the smallest unit of time he had to deal with was the season. My second favorite quote (which may not be original to this book, although this is the first time I ran into it) is that the management style on the project was the mushroom theory. That is, `Keep them in the dark and feed them shit’.
A true journalistic classic. Buy it and Read it! – Comment on Amazon Books
- T-shaped skills | Wikipedia
- What is a T Shaped Person? | Zion & Zion
- IDEO CEO Tim Brown: T-Shaped Stars | Chief Executive
- Revisiting ‘T-Shaped’ People | Only Dead Fish
- Strategy by Design | Fast Company
- “The hunt is on for the Renaissance Man of computing” | David Guest, The Independent 1991
The Valve Company handbook mentions that they prefer to hire “t-shaped” people; people who have deep knowledge and expertise in a few subjects, and basic knowledge and experience in many areas.
We calue “T-Shaped” people. That is, people who are both generalists (highly skilled at a broad set of valuable things – the top of the T) and also experts (among the best in their field within a narrow discipline – the vertical leg of the T).
This recipe is important for success at Valve. We often have to pass on people who are very strong generalists without expertise or vice versa. An expert who is too narrow has difficulty collaborating. A generalist who doesn’t go deep enough in a single area end up on the margins, not really contributing as an indvidual.
– Valve: Handbook For New Employees pg 46 | Valve Press 2012
The term was coined by IDEO’s CEO Tim Brown:
T-shaped people have two kinds of characteristics, hence the use of the letter “T” to describe them. The vertical stroke of the “T” is a depth of skill that allows them to contribute to the creative process. That can be from any number of different fields: an industrial designer, an architect, a social scientist, a business specialist or a mechanical engineer. The horizontal stroke of the “T” is the disposition for collaboration across disciplines. It is composed of two things. First, empathy. It’s important because it allows people to imagine the problem from another perspective–to stand in somebody else’s shoes. Second, they tend to get very enthusiastic about other people’s disciplines, to the point that they may actually start to practice them. Tshaped people have both depth and breadth in their skills.
– IDEO CEO Tim Brown: T-Shaped Stars | Chief Executive
I-shaped person is one who is a functional expert—their functional expertise being represented by the vertical stroke in the letter I. A T-shaped person is more. Much more—with the horizontal stroke of the T representing cross-functional awareness and understanding, in addition to the table stakes vertical stroke.
– What is a T Shaped Person? | Zion & Zion
T-shaped people tend to be self-starters, and work better within teams because they understand the larger context of their expertise in relation to everything else.
This is related to Olson’s “saturation job” because once you have mastered a single subject you have the skills to quickly gain proficiency in many other areas. That doesn’t mean it will be easy, there are no short cuts, mastering anything is a long process. But once you have mastered one thing you know a few things. First, you know you’ve already done it once so it’s possible to do it again. This isn’t so obvious when you are setting out to master something. There are any number of times when it feels hopeless. But once you’ve done it once you know not only it can be done but that it can be done by you.
In evolutionary terms – I shaped people are overly specialized for a very specific ecological niche, which means that they are vulnerable to environmental changes that eliminate the conditions that they evolved to exploit. The more specialized you are the more vulnerable you are to change.
- Programmer Interrupted | ninlabs research
- I Wasn’t Hiding From You, Boss. I Was Just Being Productive.
- Remote vs. in-office software teams: Which is better? | TechBeacon
- The Remote Manifesto | GitLab
- Flaws In Scrum And Agile | Panda Strike
- Remote: Office Not Required | Crown Business
- Rework | Crown Business
- The year without pants: WordPress.com and the future of work | Jossey-Bass
The general work flow at Automattic had seven steps:
- Pick a problem. A basic problem or idea for WordPress.com is chosen. It could be something like, “It’s too hard to print blog posts,” or, “Let users share from WordPress to Facebook.” There are always hundreds of ideas and dozens of opinions about which ideas are important. There’s no formal system for deciding, but many came from Mullenweg or as suggestions from the Happiness folks. After an idea is chosen, discussion begins on how it should work.
- Write a launch announcement and a support page. Most features are announced to the world after they go live on WordPress.com. But long before launch, a draft launch announcement is written. This sounds strange. How can you write an announcement for something that doesn’t exist? The point is that if you can’t imagine a compellingly simple explanation for customers, then you don’t really understand why the feature is worth building. Writing the announcement first is a forcing function. You’re forced to question if your idea is more exciting for you as the maker than it will be for your customer. If it is, rethink the idea or pick a different one.
- Consider what data will tell you it works. Since it’s a live service, learn from what users are doing. The plan for a new feature must consider how its positive or negative impact on customers can be measured. For example, if the goal is to improve the number of comments bloggers get from readers, we’d track how many comments visitors write each day before and after the change.
- Get to work. Designers design. Programmers program. Periodically someone checks the launch announcement to remind everyone of the goal. As more is learned about what’s possible, the announcement becomes more precise. Sometimes the feature pivots into something different and better.
- Launch. When the goal of the work has been met, the feature launches. It’s often smaller in scope than the initial idea, but that’s seen as a good thing. The code goes live, and there is much rejoicing.
- Learn. Data is captured instantly and discussed, often hourly, by the folks who did the work. Bugs are found and fixed. For larger features, several rounds of revisions are made to the design.
- Repeat.
– The Year Without Pants | Chap 6.
- basecamp/handbook | GitHub
Basecamp breaks work into cycles, and heartbeats:
We work in 6-week cycles at Basecamp. This fixed cadence serves to give us an internal sense of urgency, work as a scope hammer to keep projects from ballooning, and provide a regular interval to decide what we’re working on.
The idea is not that everything we ever decide to work on has to take six weeks or can be completed in that time. But rather that we think about how we can break big projects into smaller ones that can be done in that amount of time, and that we bundle smaller things into presentable scope of work that can be discussed.
On the product side, we’ve even formalized this further with the notion of Big Batch and Small Batch work. In Big Batch, we work on a single feature that’s likely to take the entire six weeks. In this mode, the six week limit works as a budget. If what we currently have in mind doesn’t fit within that, the first approach should be to judo the problem and scope hammer the domain. Most things we work on can fit within six weeks.
In Small Batch, we work on stuff that won’t take longer than 2 weeks at the maximum. So we can get more like 3-5 smaller things done in a single cycle.
– How We Work | Basecamp
It’s hard to keep up on what everyone is doing and what it means, if you just watch the stream of latest activity scrolling along in Basecamp. (It’s also a waste of time and source of stress to even try.) Instead, we have three chief mechanisms for keeping everyone in the loop about the work that’s going on.
First, there’s the daily question of What did you work on today?, which supplies the nitty gritty details, but as a personal narrative. They’re a great conversation starter if you see someone working on something you either care about or want to learn more about. Please do use them as such!
Second, there’s the weekly question of What will you be working on this week? which answers the nitty gritty at a slightly higher level. Well, at least the intentions of that!
Third, and finally, there is the team updates. They usually happen half-way through a cycle, at the end of a cycle, or when something new is launched. This is where the big presentation of work is done, and the main way for you to keep in the loop with what the company is focused on at a high, digestible level.
– How We Work | Basecamp
As most remote work companies they favor asynchronous communications.
It’s far better for everyone’s concentration and sanity if you collaborate as though most things will get an answer eventually, but not necessarily right this second. Your first choice of action should be to post a message, a todo, or a document about what you need to explain or need to know. Then others can read it on their schedule, when the natural lulls of the day allow it, rather than being interrupted right in their peak flow time.
Don’t take that as gospel, though. Some times you really DO need to tightly collaborate with someone for an extended period of time, and that’s fine. We have pings, hangouts, screensharing, or even in-person collaboration for when nothing else will do. (But most of the time something else will).
All that being said, you should still ensure that there is ample overlap with the people you work with most of the time. While most roadblocks can just as well be cleared in 15-30-60 minutes, they become real annoying if it’s a one-day turn-around every time.
– How We Work | Basecamp
Whether you work on the product development or not, your voice and observations can help determine what we should be working on. The way to exert this influence is through pitches.
Write-up your idea of a new feature, a change to a feature, or any other product development you think we should be considering as a fully considered post (the more specific, the better). This gives the whole company a chance to consider and respond to the idea, and then we’ll have the idea encapsulated in a post, available for reference at any time.
– How We Work | Basecamp
The company tries to minimize the need for everything to go through departents – because work get’s bogged down in organizational bottlenecks.
So, when possible work is broken into self-sufficient, independent teams. It’s not mentioned what the average size of teams are, or how they are structured.
- Conformity | Wikipedia
- Conformity Bias | The Human Condition
Mary Poppendieck warns that conformity bias works against some of the best ideas in a team (group) from emerging at all.
There are any number of factors that determine if people speak up in a group environment or keep their mouths shut. Factors include:
- age
- social status
- experience
- language skills
- gender
- culture
Many cultures socialise their societies to always conform, go with the flow and keep your opinions to yourself.
Stop Voting
- Explore multiple ideas, including outliers
- Pursue a variety of ideas with champions and volunteers
- Gradually narrow the ideas to those that will work
- Maintain multiple options as long as possible
– Mary Poppendieck | The Future of Software Engineering (presentation)
So it is important to create environments where all members of a team can contribute ideas without feeling that they are being watched or judged by what they say or not say.
Automattic’s project blogs where everyone simply adds on comments to an existing topic helps all team members contribute.
Team leaders need to solicite ideas before and after meetings and provide asynchronous channels for people to propose ideas. This is not to say that all ideas are equal – far from it. But it’s often hardest to get the ball rolling and propose something new in the first place.
So long as everyone in the team shows respect for each other’s ideas and are not immediately dismissive or derisive then everyone benifits. Even if something is a patently stupid idea, there are any number of reasons that it was proposed – perhaps the person wasn’t aware of information that was considered to be common knowledge by the rest of the group – if so, then it should be treated as an opportunity to teach and learn and improve the person’s knowledge and ensure that the group improves as a whole.
That’s that you should never start a sentence with “I can’t believe you never…” Because at some point in the past you “never” also, and everyone learns different things at different points in their lives in different contexts.
An iterative process is one that makes progress through successive refinement. A development team takes a first cut at a system, knowing it is incomplete or weak in some (perhaps many) areas. They then iteratively refine those areas until the product is satisfactory. With each iteration the software is improved through the addition of greater detail.
An incremental process is one in which software is built and delivered in pieces. Each piece, or increment, represents a complete subset of functionality. The increment may be either small or large, perhaps ranging from just a system’s login screen on the small end to a highly flexible set of data management screens. Each increment is fully coded and tested, and the common expectation is that the work of an iteration will not need to be revisited.
– Mike Cohn, User Stories Applied: For Agile Software Development Pearson Education, 2004.
Teams are made up of 2-8 people, with the average being closer to
4-6. In a Scopic organization, a Team is called a shop and is a
formal designation of a holon with an identity of it’s own. For this
reason shops must be registered (self-registered) that will
establish a unique identity, a bramble, and ruleset that will be used
to manage it. Teams are persistent, they can be created, but once
created they are part of the blockchain – so they can be disbanded,
suspended, disolved, fractured, absorbed, merged or even abandoned,
but they can not be unmade.
Shops can be legal entities in their own right, shops can own property, generate revenue, disperse funds, hire services, purchase goods. Shops, and the holons that own the shop are also accountable, legally, ethically and morally.
There are limits on shop sizes – they must conform to the human
scale group pattern
For larger issues or issues that contain many different moving parts,
you’ll be likely working in a team. This team will typically consist
of a backend developer, a frontend developer, a UX designer and a
product manager.
- Teams have a shared responsibility to ship the issue in the
planned release.
- If the team suspects that they might not be able to ship something in time, the team should escalate / inform others as soon as possible. A good start is informing your lead.
- It’s generally preferable to ship a smaller iteration of an issue, than ship something a release later.
- Consider starting a Slack channel for a new team, but remember to write all relevant information in the related issue(s). You don’t want to have to read up on two threads, rather than only one, and Slack channels are not open to the greater GitLab community.
In many respects, this article should be considered the last word on the subject – it is so well thought out and written that it should be required reading by all team members.
https://m.signalvnoise.com/is-group-chat-making-you-sweat-744659addf7d#.toilxdaah
Tasks that aren’t completed in a sprint and overflow into the next sprint.
In orgmode they are called tags, in GitLab they are called labels, on Twitter they’re called hashtags, but they all amount to the same thing.
Tags are useful in many different contexts, but they become a lot more useful when used consistently. GitLab breaks down tags into three groups; team, subject, and type.
Tags MUST be unique strings that are formally defined in the
Chenla topicspace.
| Class | Name | Color | Org Tags | Badge |
|---|---|---|---|---|
| Team | @Backend | #7F8C8D | :@backend: | |
| (brown) | @Frontend | #7F8C8D | :@frontend: | |
| @Operations | #7F8C8D | :@operations: | ||
| @Admin | #7F8C8D | :@admin: | ||
| Workflow | Plan/Todo | #FF0000 | * PLAN/* TODO | |
| (red-purple) | Next | #CC0033 | * NEXT | |
| Work | #8E44AD | * WORK | ||
| Done | #5843AD | * DONE | ||
| Issues | Bug | #69D100 | :BUG: | |
| (green) | Feature | #5CB85C | :FEATURE: | |
| Request | #44AD8E | :REQUEST: | ||
| Wish | #A8D695 | :WISH: | ||
| Moonshot | #A8D695 | :MOONSHOT: | ||
| Priority | Critical | #CC0033 | :CRITICAL: | |
| (red) | #P1 / High | #FF0000 | #A | |
| #P2 / Med | #F0AD4E | #B | ||
| #P3 / Low | #69D100 | #C | ||
| Release | Stub | #428BCA | :STUB: | |
| (blue) | Draft | #428BCA | :DRAFT: | |
| Release | #0033CC | :RELEASE: | ||
| Design | #0033CC | :DESIGN | ||
| Demo | #0033CC | :DEMO: | ||
| Status | Confirmed | #AD4363 | :CONFIRMED: | |
| Broken | #AD4363 | :BROKEN: | ||
| Discuss | #AD4363 | :DISCUSS: | ||
| Review | #AD4363 | :REVIEW: | ||
| Approved | #AD4363 | :APPROVED: | ||
| Testing | #AD4363 | :TESTING: |
Tags MUST adhere to the gracefully degrade pattern and
work both in monochrome plain text displays as well as in
graphical color displays.
| @place | .team/org/proj | #subject/type |
|---|---|---|
| @pnca | .backend | #A |
| @office | .frontend | #bug |
| @home | .infra | #feature |
| @hk | .kinto | #backlog |
| @bulma | #NEXT | |
| @hard | .moe | #WORK |
Colors SHOULD always be used to convey semantic, contextual meaning. Bootstrap uses the following:
<span class="label">Default</span>
<span class="label label-success">Success</span>
<span class="label label-warning">Warning</span>
<span class="label label-important">Important</span>
<span class="label label-info">Info</span>
<span class="label label-default">Default</span>Colors SHOULD use the following color-blind friendly color pallete for all gui widgets.
# The palette with grey:
"#999999" "#E69F00" "#56B4E9" "#009E73"
"#F0E442" "#0072B2" "#D55E00" "#CC79A7"
# The palette with black:
"#000000" "#E69F00" "#56B4E9" "#009E73"
"#F0E442" "#0072B2" "#D55E00" "#CC79A7"Places can be either a physical location, an organization or a machine name.
Should use
/* Teams ---------------------------------*/
.tag span.Backend,
.tag span.Frontend,
.tag span.UI,
.tag span.Infra { background: #5CB85C; }| Backend | Backend Team |  |
| Frontend | Frontend Team |  |
| Ops | Operations Team |  |
| UI | User Interface Team |  |
Workflow is used on the Kanban Board and in TODO items
| PLAN | backlog |
| NEXT | what will be worked on next |
| WORK | work in progress |
| DONE | completed work or closed issues |
| bug |  |
| feature |  |
| request |  |
| wish |  |
| moonshot |  |
Items that are marked with a priority are to be completed before other items. For this reason they are to be used sparingly – but when they are used they need to be taken seriously. Priorities should be discussed before being assigned.
- #A : Critical. Must be given priority over any other issue except other #A level priority issues.
- #B : Must. Must be finished within the current sprint, milestone or release.
- #C : Should. Takes priority over other non critical features, tasks or goals.
Used mostly for repo README files
| Made-By Chenla |
 | Licence |
 | Descriptive, prescripive, theory, history, background |
| Things that in principle can be built and deployed |
 | Projects build and deploy things |
 | Technical specifications & standards |
 | tl;dr |
 | pattern |
 | place |
 | event |
 | person |
 | concept |
 | material |
 | blob |
 | TOC |
 | README |
| Work |
 | Expression |
 | Manifestation |
 | Instance |
 | Stub; placeholder |
| Work-in-Progress |
 | Draft |
 | Request for Feedback and Comments |
 | Published/Released |
Badges for git Tags are used when the status has reached the draft. Stubs and WIP are to nebulous for revision numbers to be of any use. But a draft is approaching some kind of final form that people may reference and link to, so it makes sense to version everything thereafter.
Will dig these up – clean out the spam and get things restarted again.
Our irc server is http://irc.chenla.org
- #chenla
- general discussion
Will install Sticky Notes and the server will be: http://paste.chenla.org
I am a big believer in the power of physical kanban boards – I’ve tried a number of electronic ones and they just don’t have the emotive power of a punch of colored pieces of paper taped to a board!
However, we are a distributed project – so an idea I have at the moment is to set up a webcam with a motion sensor of the kanban board at the office at prekleap once an hour and keep a feed of the camera onm a web page.
We can then create a simple way of notifiying whoever is the person (KanBan Keeper?) to move things around as needed.
The idea is that during scrum meetings, everyone should have a feed of the board running next to their irc client so that we can make collective updates during meetings.
It might turn out to be a dumb idea – but I’d like to give it a try.
- Continuous delivery - Wikipedia
- Poka-yoke | Wikipedia
Continuous deployment means that every change is automatically deployed to production. Continuous delivery means that the team ensures every change can be deployed to production but may choose not to do it, usually due to business reasons. In order to do continuous deployment one must be doing continuous delivery.
– Continuous delivery - Wikipedia
- How release canaries can save your bacon | Google Cloud Platform Blog
- How release canaries can save your bacon | Hacker News
When you have continous releases, when you make a release, use it as a way of testing for bugs and if anything crops up then immediately rollback the release and then test.
Release database changes between release canarys.