Will Treinen, founder and CEO of Treinen Associates gave a presentation at the 2014 IPMA Forum describing his experiences in building an “Agile PMO” to handle the extraordinary growth of his consulting business (600% in the past year!).
Will relied upon Kerika to create the perfect collaboration environment for his distributed teams of project managers, business analysts and business development staff:
Will Treinen, founder and CEO of Treinen Associates gave a presentation at the 2014 IPMA Forum describing his experiences in building an “Agile PMO” to handle the extraordinary growth of his consulting business (600% in the past year!).
Will relied upon Kerika to create the perfect collaboration environment for his distributed teams of project managers, business analysts and business development staff:
In a recent post on the Scrum Alliance forum at LinkedIn, a member asked this question:
How do teams handle defects that have been found after a user story has been accepted and released to Production?
My first thought was to just log a defect against the user story, but that screws up reporting as it removes the Accepted status. Executives do not want to see that. I am thinking we should just create a new user story and slate it for the next Sprint. ?
My answer:
Defects are bound to be found after a story has been accepted and released to production; that’s just a very normal part of software development, so it makes sense to add them to the Product Backlog to prioritize for a future Sprint.
There isn’t any need to take the “Accepted” status off a story that was already considered done within an older Sprint: “Accepted” doesn’t mean “super-excellent and done for all time”; it just means it was considered good enough by the Product Owner at the conclusion of the Sprint, and therefore accepted.
To “un-accept” stories post facto would not just screw up your reporting; it would start to create an unhealthy dynamic between the Scrum team and the Product Owner, where the Product Owner starts to believe he can reject stories post facto.
For Scrum to work well as a process, you need to get everyone to buy into the core idea that stuff gets done in iterations; new stuff gets done in new iterations; old stuff gets improved in future iterations.
On a more tactical level, Kerika lets you link together individual cards or even entire Scrum Boards, because every board, every card, every canvas has a unique URL that you can reference anywhere in the system to create dynamic links between stories and boards.
So, if we find a bug in a previously accepted story, we create a new card for that and simply reference the old card in the new card’s details. Here’s a video that shows how that’s easy with Kerika.
In a recent post on the Scrum Alliance forum at LinkedIn, a member asked this question:
How do teams handle defects that have been found after a user story has been accepted and released to Production?
My first thought was to just log a defect against the user story, but that screws up reporting as it removes the Accepted status. Executives do not want to see that. I am thinking we should just create a new user story and slate it for the next Sprint. ?
My answer:
Defects are bound to be found after a story has been accepted and released to production; that’s just a very normal part of software development, so it makes sense to add them to the Product Backlog to prioritize for a future Sprint.
There isn’t any need to take the “Accepted” status off a story that was already considered done within an older Sprint: “Accepted” doesn’t mean “super-excellent and done for all time”; it just means it was considered good enough by the Product Owner at the conclusion of the Sprint, and therefore accepted.
To “un-accept” stories post facto would not just screw up your reporting; it would start to create an unhealthy dynamic between the Scrum team and the Product Owner, where the Product Owner starts to believe he can reject stories post facto.
For Scrum to work well as a process, you need to get everyone to buy into the core idea that stuff gets done in iterations; new stuff gets done in new iterations; old stuff gets improved in future iterations.
On a more tactical level, Kerika lets you link together individual cards or even entire Scrum Boards, because every board, every card, every canvas has a unique URL that you can reference anywhere in the system to create dynamic links between stories and boards.
So, if we find a bug in a previously accepted story, we create a new card for that and simply reference the old card in the new card’s details. Here’s a video that shows how that’s easy with Kerika.
Something that we have learned in the course of making Kerika the best designed tool for work management: don’t rush to implement all of your bright ideas!
When we observe a usability problem, we tend to get riled up rather quickly because we take such pride in our work.
The result is a bunch of really good ideas about how to fix the problem.
And to improve the fix.
And to make the fix even better.
(You can probably see where this is going…)
It’s really easy to over-fix a usability problem, by applying too many fixes, too fast.
Here’s another approach you can try:
We have found this is a good remedy to the more common problem of over-designing a solution: rather than build an unnecessarily complex change, or one that creates its own usability problem — often by making a subtle change in the UI metaphors that the user has already learned by mastering other parts of the product.
Another question answered on LinkedIn’s Scale Agile group: The team is facing a high Technical debt before adopting Scrum. Now, they want to fix this. How could they include this in the Sprint?
If you already have a lot of technical debt, I would recommend that the first few Sprints do nothing but clear the most expensive debt.
The trick is to persuade the Product Owner that this is necessary, because it means deferring any delivery of “real features” while the debt is paid down.
Note that I say “paid down” rather than “paid off”: in my experience, there is rarely an opportunity to completely pay off technical debt and have a clean Product Backlog with nothing in it but nice user stories that deliver tons of end-user functionality.
At Kerika, we have found that we accumulate some debt almost continuously, and that this is unavoidable even though we are using Scrum.
Purists might argue that a true Scrum model eliminates technical debt, but this is unrealistic when you are dealing with a fast moving market and are focused on rapidly improving your product.
Periodically, we devote an entire Sprint to paying down technical debt. We did one fairly recently because we are in the process of adding some substantial new functionality: Kerika will now become the first Scrum/Kanban/Scrumban tool that has full integration with both Google Drive and Box for sharing project files within distributed team ;-)
Because this was a major platform enhancement, we took a 3-week Sprint to pay down our technical debt by clearing a bunch of bugs and server exceptions that individually were never going to make it to the top of the Product Backlog.
The Kerika tool makes it really easy to tag items, so it was easy for us to find all the bugs that were in our (rather large) Product Backlog and we cleared nearly 50 items.
Actually, this was our second debt payoff Sprint this year: in April, the Heartbleed scare prompted us to do a full internal review of our security processes, which morphed into a full review/overhaul of our QA and other software development infrastructure/process stuff, and we spent an entire Sprint to significantly clean up a bunch of stuff that had been moldering a while.
For what it’s worth, we generally do an all-hands-on-deck Sprint to pay down debt: we don’t try to sneak in any new product features because I find that it sends a confusing message to the team about the importance of paying down the debt.
I said earlier that often the big challenge is convincing the Product Owner of the need to devote a Sprint or two to pay down debt; in our case that’s relatively easy because I am the founder/CEO and buy into the idea ;-) but I do believe that if you are going to pay down debt, you need to do it with serious intent and get everyone focused on that, which means the Sprint is all about debt, not new goodies.
Hi folks!
I recently offered my thoughts to the Scrum Alliance group on LinkedIn, on the discussion thread on whether
Kanban is a better way to manage support/maintenance work than scrum. I thought you might find it interesting:
Kanban is generally a better model for support/maintenance: these tasks tend to trickle in, so trying to handle them with a conventional Product Backlog is often awkward.
Support/maintenance tasks are also usually unrelated to each other: one bug fix may have nothing to do with another.
This makes for a different metaphor than Scrum/Product Backlog where there is some presumption that user stories and tasks, while perhaps independent, are at least part of a larger product or release theme.
If you did support/maintenance tasks in a Sprint, that Sprint would have no overarching theme which I strongly believe is essential for success with Scrum teams.
And if any team doing support/maintenance with Scrum will quickly realize their Sprints are unlike those of other teams that are doing product development with Scrum.
I would view your questions about swimlanes as arising from a misfitting metaphor: instead of using swimlanes, you would be better off using tags, and then filtering your board as needed to see all support/maintenance tasks related to a particular subsystem or process or person. E.g. “show me all the tasks related to the database schema”.
We use our own product (Kerika) of course, and we do all of our new product development with Scrum Board, and support/maintenance with Kanban boards since Kerika lets you easily have both kinds of boards.
We use multiple tags on each card on both the Kanban and Scrum Boards, so we can filter and search, e.g. “show everything related to our Google Drive integration”.
These filtered views are much more effective and flexible than trying to organize your board with swimlanes, because each card can have multiple tags, whereas with swimlanes a card would be in only one swimlane at any time.
Also, this arrangement gives us flexibility to move from Kanban to Scrum and back: for example, if a support/maintenance card that originally landed on a Kanban board is later deemed to be significant enough to handle as part of product development, we can just cut-and-paste that card from the Kanban board to the Scum Board, and Kerika brings along all the content, history, attachments, chat, etc.
(Finally!) we are updating our blog and website to use a “responsive” design, which will make it easier to view on mobile devices.
Note: this doesn’t affect the Kerika application itself, only this blog and the kerika.com website.
This work had been pending a long time, but it kept getting pushed off while we devoted all our time to the Box integration.
Now that Kerika+Box is almost done, we are ready to update the website as well: a nice new format that works well on mobile devices — we used custom Bootstrap code for this — as well as new content that helps users understand that there is now a Kerika+Google product and a Kerika+Box product!
Our website updates tend to be in the same release cycle as our software updates, so we probably do fewer website updates than some other companies.
That’s because we use git for managing all the software assets: not just the code for the Kerika application, but also the website pages.
When we expect to do a lot of website updates, we put all those changes in a separate git branch, but that’s rare, since website updates are generally tied to software updates.
Updating the look-and-feel of this blog was much easier: we just switched from a custom WordPress template that we had built about a while ago — that was nice, but unfortunately not responsive — to the standard Twenty Fourteen template that comes with WordPress.
A few tweaks, and it works!