When you are working with a large board and a large team, it’s often useful to see just those cards that are assigned to some people.
For example, you might want to just see those cards that are assigned to you, so that you can focus on getting your stuff done and not get distracted by everything else that’s going on.
With our newest release of Kerika, we have made this both possible and easy.
One quick menu choice, within our new Filter dialog, will make it possible for you to filter your view of a Task Board or Scrum Board to just see the items assigned to you:
Just my items
If you are a Project Leader, you might want to filter your view of a board even further, and Kerika makes that easy:
Filter by People
This view is particularly handy if you are trying to deal with staffing issues: for example, if one person has called in sick, you can first filter your view to show just the items assigned to that person, and then add more cards to your view to see how busy someone else on the team is, if you are thinking of offloading the sick person’s work to someone else.
Here’s another way that Kerika makes it easy to manage really large Task Boards and Scrum Boards: you can use the new Filter dialog to show just those cards that are flagged as having a particular status — for example, you could view just the Critical items, or just the Needs Rework items:
Kerika has several flags you can use to identify the state of the cards on your board:
Card status
Ready to Pull: this means the card is ready to be picked by someone within the team, in accordance with the project’s workflow.
In Progress: this signals the card is being actively worked on by someone; it helps call out which cards are active, among several that may be assigned to the same person.
Needs Rework: this calls out the need for a “do-over” of some part of the work — e.g. if a design fails review, or work was not done as expected on a particular card.
On Hold: this indicates that the person assigned to that card has put it aside temporarily, usually because the person got diverted by some other work (which presumably is now marked as “In Progress”).
Is Blocked: not good; it means that the person who has been assigned that work is not able to progress as they would like to, due to forces beyond their control. Time for the Project Leaders to intervene!
Critical: hopefully this gets used sparingly…
Use Kerika’s new Filter by Status capability for your project status review meetings: it’s easy to see which cards are going well, and which ones need help.
A new tutorial video that shows you how you can customize the layout of any Task Board and Scrum Board, and — more importantly — switch any board from being a Task Board to being a Scrum Board, or back.
Only Kerika lets you have several Backlogs within the same Account, and easily pull cards from different Backlogs into the same Scrum Board if you want to combine work items from several Backlogs into the same Sprint.
We have had both tags and color coding of cards on Task Boards and Scrum Boards for a very long time, but, unfortunately, these operated independently of each other.
There’s no good reason for them to have been separate aspects of working with cards other than simple history: we added color coding many months after we added tags.
Originally we expected color coding to be used in a limited way only: to highlight a few cards on a crowded board that needed special attention.
We had a limited set of 7 light pastels that were chosen to be “color-safe”, i.e. appropriate for use by color-blind people.
Over time, however, we found that people were using color coding a lot more than we had anticipated, and that in fact they were using colors as an alternative to regular tags.
And that was true for the Kerika team as well: we have a “bug” tag that we use to track all work related to defects, but some of us also like to use the red color to highlight cards related to bugs.
And while we could readily agree on the symbolic meaning of a few colors, e.g. Red as indicating something critical or broken, we couldn’t agree on the names or meanings of all the colors.
So, this obviously wasn’t a sustainable path for us: if colors and labels were simply alternative ways of managing your view of a large board, and for collating work across multiple boards, then clearly colors and tags needed to come together as a single concept.
And that’s what we have done with our latest release: colors and tags are now the same thing — all colors have names, all tags can have colors.
Here’s what your Kerika boards will look like, with the new way of showing tags:
New tags styling
A couple of points to note:
All your old tags are preserved with this change, so you don’t have to go back and fiddle with any of your old boards.
We will show more than one tag on a card at a time; this will make it easier to visually scan a large board.
The dialog for managing your board’s tags has also been updated, to reflect the new merger of tags and colors:
Tags dialog
When you add a new tag, you have to use a different label from the ones you are currently using: as before, duplicate tags are not allowed.
And the same goes for colors: when you add a new tag, you can’t use a color that is already associated with a label, which means tags have unique colors.
One unique benefit we have added, along with this merger of tags and colors, is the ability to merge tags together.
Let’s say you had been using a tag called “bug” (if you are working on a software project). Some of your colleagues have been using a different tag called “defect”.
You decide that these two tags really reflect the same underlying concept — they are both being used to highlight problems with your software project — so it makes sense to merge these two tags together.
There used to be no easy way of doing this in the past, but now there is:
You can merge tags by renaming one of them, e.g. renaming “bug” to “defect” will cause the system the ask if you want to merge “bug” and “defect” together to be same tag.
You can also merge tags by recoloring on of them, e.g. by changing the color of the “bug” tag to be the same color as the “defect” tag will cause the system to ask if you want to merge these two tags.
A new tutorial video that shows you how Kerika’s powerful Filter feature lets you customize your view of any Task Board or Scrum Board: just see those cards that are assigned to you, or create more custom views of a board by selecting cards based upon their status, tags, or the people assigned to work on them.
You can even hide entire columns on the board if you like :-)
A new tutorial video on how to use Work-In-Progress (WIP) Limits on your Kerika Task Boards and Scrum Boards — even if you are not strictly following the Kanban model.
For a while now, our Kerika+Box users have had a very nifty feature that allowed them to create a new Box Note from within Kerika itself, and have that note automatically attached to the Task Board or Scrum Board card that they were working on.
Adding new Box Note to card
(Which meant, naturally, that this new Box Note was also automatically shared with everyone on that particular board’s project team!)
And since this was a very handy integration with Box, we added it to our Whiteboards and canvases as well:
Adding Box Note to canvas
We added this because Google Docs had equivalent functionality: Google enabled us to create a new Google Doc from within a Kerika+Google board and have that new Google Doc attached to the card the user was working on.
The trouble was, Box’s Content API didn’t really have an official way of doing this, so we came up with a workaround that worked fine for the longest time — so long, in fact, that we forgot that it was even ever implemented as a workaround…
Unfortunately, that broke a few days ago. Box did an update to their platform that stopped our workaround from working any more, which means that, at least for now, we will have to stop offering this feature for our Kerika+Box users.
Hopefully we will be able to get Box to give us official support for this feature, so Kerika+Box remains at least as good as Kerika+Google :-)
We are sometimes asked how people can move projects from one account to another, either because someone has left their organization, or simply because they want to consolidate ownership of all project assets within a single account owner.
We plan to make this process simpler in the future, but for now here is a simple workaround that can help you achieve the end-goal.
Step 1: Add User B to User A’s project as a Team Member.
This is the simplest option: once User B has been added as a Team Member on User A’s project, she can then copy and paste the entire project over from User A’s account into her own.
Step 2: Copy User A’s Project
Normally, your Home Page shows a consolidated list of all the projects you are working on, regardless of who owns them.
Home Page
But, you can filter your view of the Home Page to just show those projects owned by a certain user, like this:
Filtering your Home Page
Using this filtering option can make it easier to find just those projects that are owned by a particular user, like this:
Viewing a particular account
Now, User B can select one of User A’s project (that she has access to), and do a Copy using the Copy button that appears at the top of the list of projects:
Copying a project
Step 3: Paste the Project
Once User B has copied the project into her Kerika Clipboard (which, by the way, exists on the server and not on her browser itself, so you don’t have to worry about your browser crashing in the middle of this operation), a Paste button will appear when she then returns to view her own account:
Paste option
Step 4: Get rid of the old Project
Once the Paste operation has finished (it can take a minute or two, depending upon how big the board is that that is being copied and pasted, and in particular how many files are attached to that board), it would be a good idea for User A to get rid of her original project, so that there is no longer any confusion about which version is the active one.
Deleting a project is simple: just select something that you own, and you will see a “Move to Trash” button appear at the top of the list of projects:
Deleting a project
(Since Kerika offers a Trash/Recycle Bin feature, deleting is actually a “move to Trash” operation: if you delete a project by mistake, you can always restore it from your Home Page’s Trash.)
Developing Agile Procurement for more flexible contracts with vendors.
On Holacracy
Goal: empower employees to organize themselves.
There are no managers.
Washington State is first government anywhere to practice holacracy.
Washington State is also the first organization anywhere with a represented workforce (i.e. with employee unions) to practice holacracy.
Doing an A/B test of holacracy vs. hierarchical organization, in cooperation with Harvard Business School.
Hypothesis of A/B test: self-organizing teams will produce better employee outcomes.
Measure for a year and see what the results are.
Looking for three categories of metrics:
Are employees more engaged, with better retention?
Are there better customer outcomes, where “customers” are other agencies?
To what extent is an organization practicing holacracy more able to achieve larger organizational objectives
Instead of managers, there are roles that are assigned certain accountabilities.
Holacracy and Agile have things in common:
Bias towards action
Be iterative
Don’t make up all these demons that might show; see if they actually appear
Holacracy and Agile are different:
Holacracy isn’t about getting buy-in on your ideas from the team.
The Scrum roles, e.g. Product Owner, Scrum Master can be added as holacracy roles in a particular circle.
Quotes
“The reality is, a lot of the cloud providers can provide better security solutions than we can afford internally.”
“For us, cloud is actually one of the strategies for increasing security for the state.”
“The interesting question is, how do you do oversight and QA — really project management QA, not just traditional software QA — in an agile context?”
“One of the metrics for Agile QA: is the business engaged?” (Not just steering committees like before, but do we really have engaged product owners.)
“The contracts and procurement shop in state government practice what they call XP — Extreme Procurement”
“Washington is the only state to practice Agile Procurement and Agile Contracting”
“Downside of holacracy: everyone loves to tell me that I am not the boss of them”
“No government has ever practiced holacracy before.”
“Holacracy has never been practiced with a represented workforce before. (One with employee unions.)”
“I have been practicing holocracy for a few months, and I feel like I have a different set of lenses through which I look at work.”
“When I talk to people who are not practicing holacracy, I see evil spirits around them, like bureaucracy, office politics, inefficient meetings…”
“We develop these habits to compensate for the deficiencies of a hierarchical organization, instead of trying to change it, and this is after thousands of years of evolution.”
“The team has to want it: you need opt-in for holacracy to work.”
“Imagine trying to play soccer with a hierarchical organization, where the team is run by managers who are responsible for different sections of the field.”
“Because I am the manager, you need to always pass the ball to me. Ridiculous as that seems, that’s how hierarchical organizations work.”
“90% of my time is spent on crap that runs government work, and that’s because of the authority of my position.”
“As a manager I don’t have a passion for a lot of things, but other people might, so I want to give them the authority to take them on.”
“Healthy habits in a dysfunctional system become unhealthy habits in a functional system.”
“In holacracy, you quickly learn what makes for a valid objection.”
“The type of people who would not respond well to holacracy are managers that derive their self-worth on span of control.”
“There’s a category of employees who have no interest in being self-directed: they just want to be told what to do.”
