We have created a new tutorial video on how Notifications work in Kerika. It is based upon our new user interface, which hasn’t been released yet, so some of the menu options shown on the top-right of Kerika boards will look a little unfamiliar :-)
Category Archives: Technology
Moving projects from one Account to another
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.
But, you can filter your view of the Home Page to just show those projects owned by a certain user, like this:
Using this filtering option can make it easier to find just those projects that are owned by a particular user, like this:
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:
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:
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:
(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.)
Lean Government & Holacracy: the Video
Here’s an hour-long video of Michael DeAngelo‘s presentation on Lean Government & Holacracy in Washington State:
Highlights from his talk:
On the Office of the CIO
- Roughly 4,000 IT professionals in Washington State.
- About 80 agencies run their own IT teams.
- Office of CIO sets strategy and provides oversight.
- Transform government through technology and culture.
- Created the small business hub: business.wa.gov
- Run as a Scrum project, with 1-week Sprints.
- Adopted customer-driven design.
- Successful example of using Lean Startup methodology.
- Driving the use of Software-as-a-Service (SaaS).
- Practice and “open office” style.
On Lean Government
- Started in Washington State with Governor Christine Gregoire.
- All agencies are required to have a Lean focus.
- Challenge: how to be an “employer of choice” for IT professionals, given stiff competition from Amazon, Microsoft, etc.
- Several agencies have an active Agile/Scrum practice, but this is still in pockets within state government.
- Office of the CIO
- Department of Licensing
- Department of Labor & Industries
- Impediments to adopting Agile:
- Having the right tools
- Having the right sort of contracts
- Agencies adopting Agile are largely implementing this in a software development context.
- Developing the Agile QA Scorecard.
- 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.”
Lean & Agile Government in Washington State
Michael DeAngelo, Deputy CIO for the State of Washington (and a long-time user of Kerika :-) gave a talk on Lean & Agile Government in Washington State, at the Beyond Agile meetup in Kirkland last week.
Here are his slides:
We will shortly be uploading another presentation, on Agile QA, as well an edited video of his entire talk.
Deleting canvases attached to cards
You can attach as many canvases as you like to cards on Task Boards or Scrum Boards, and if you don’t need them anymore, you can delete the canvases.
Here’s how you add a canvas to a card:
By default, the new canvas is simply called “Canvas”, but like with any other attachments on a card, you can easily rename it by clicking on the pencil icon that appears to the right when you hover your mouse over it:
Clicking on the “x” button at the far end will let you delete a canvas that you no longer need:
If the canvas is empty — which means that there is nothing visible on the canvas, and nothing in the canvas’ Trash either — you see a simple confirmation message asking if you are sure you want to delete it:
But, if the canvas is not empty, you see a Restore option instead:
If it seems puzzling why a canvas that appears empty isn’t really empty, make sure you open the canvas and take a look at the Trash: there may be items there that you had previously removed from the canvas:
In this example, above, the canvas looks empty but isn’t really: there are items in the Trash.
In situations like this, Kerika is careful to avoid losing all your work: until you empty the Trash on a canvas, the canvas isn’t considered to be truly empty, and until a canvas is truly empty, it cannot be removed from a card.
So, in this example, you see the Restore option rather than the Delete option:
Lean Government
Michael DeAngelo, Deputy CIO for Washington State and long-time Kerika user, will be speaking on “Lean Government” in Kirkland on June 24: how the Office of the CIO has been pioneering the adoption of Kanban, Scrum and “holocracy” within the state. Check it out at http://www.meetup.com/BeyondAgile/events/222991832/
3 shades of grey are plenty
Some techies in Seattle may like up to 50 shades of grey, but at Kerika we try to stick with just three:
This is easier said than done: there’s a lot of grey in the Kerika user interface, and as we add new features or tweak old ones, it’s easy to slip and introduce new shades of grey.
So, periodically, we need to take digital color meter and examine the Kerika UI in detail, pixel-by-pixel, to look for stray shades of grey.
Limiting the palette of grey to just 3 shades is an example of how constraints can help designers.
Simplifying the use of Tags with Scrum Boards
Kerika’s Scrum Boards look a lot like regular Task Boards (which you can use for Kanban-style) work; the main difference is that each Scrum Board can share a backlog with other Scrum Board.
(And switching between a Task Board and a Scrum Board takes just one mouse click!)
We were doing some fairly complicated bookkeeping when people added tags to their Scrum Boards, and we decided it was getting messy both for the system and probably the users as well.
So, we are simplifying tags for Scrum Boards:
- Every Scrum Board is connected to a shared Backlog. (And, if there was no backlog to connect to, Kerika will automatically start a new backlog for you.)
- Cards on the Backlog may use a certain taxonomy for their tags, while each Scrum Board could add to this taxonomy, e.g. by adding a new tag that makes sense for a particular Scrum cycle (Sprint).
- Now, whenever you add a new tag to a Scrum Board, this will automatically get added to the Backlog’s taxonomy as well, and to all the Scrum Boards that share that Backlog.
The effect of all this is to ensure consistency of your tags taxonomy across all Scrum Boards that share the same Backlog: this will make it easier to pull cards from that Backlog into any Scrum Board and know that you will automatically get all the right tags set up for you by the system.
Yes, there is a “Kerika Blue”
We try to be consistent in our use of colors and shades throughout the application, although it is easy to slip up from version to version, particularly since we do so many releases a year.
One recent diversion we corrected was in the use of the color blue: we have a specific shade we call Kerika Blue (#0099CC) which is used to indicate the concept of “new”:
Kerika Blue is more muted than the regular blue that you might find elsewhere: we generally try to keep our color scheme muted, so that the decoration of the Kerika app doesn’t compete with your data — after all, your data are far more important to you than anything we do in terms of decorating your screen ;-)
Security within a Virtual Private Network
All of Kerika’s servers, which run on Amazon Web Services (AWS), operate within a Virtual Private Network (VPN), so they can be configured to only listen on local ports, e.g. ports like 10.0.0.1, etc.
This means that they cannot be accessed directly from the Internet: instead, all connections are routed through an Elastic Load Balancer (ELB), which is a special kind of AWS server that handles connections from all users.
The ELB is very secure: it implements SSL 2.0, and when vulnerabilities like Heartbleed and POODLE are discovered, it is relatively easy for us, with Amazon’s help, to quickly ensure that the the ELBs are patched. Patching the ELBs quickly gives us breathing room to patch all the other servers involved, particularly if vulnerabilities are found at the platform level itself.
But, running a VPN isn’t enough: while it blocks people outside the Kerika server environment from directly accessing our database, there is still — at least a theoretical possibility — that an attacker can find his way inside the VPN, and then try to connect to our database server on a local port.
To avoid this scenario, we use SSL within the VPN as well, so that the connections from the load balancers to the database servers are also authenticated and encrypted.