Another note from a user which we wanted to share with you…
Just this week we had a fundraising administrative group meeting where our people collected for a 4-day meeting.
One of my software developers attended the meeting and we were scheduled to do a 1.5 hour presentation in the last slot of the 3rd day at 3 PM.
At 11 AM that morning, while he was in the meeting, I created a Kerika project for our presentation. I added the cards and attached screen shots and links that I wanted to present.
I messaged him in the meeting to get him to add cards to the project for IT issues that had been discussed in the previous 2.5 days so that we could address them in our session.
While he added cards, I added more screen shots to his cards and we organized and combined the cards while being in separate rooms so that by the time 3 PM rolled around, I showed up for the meeting and we did our presentation together.
It was ‘very agile’ indeed.
It probably wasn’t as polished as a PowerPoint but it was a lot more relevant as we put it together so quickly.
While we presented the different topics, we swiped the cards through the ‘Active’ and into the ‘Done’ column.
As we neared the end of our time limit, we were then able to adjust on the fly the topics that we would present with the time we had left.
Of course, we didn’t finish but it allowed us to present the most meaningful information with the time we had.
One of our users wrote in last night with this great story, which we wanted to share with you…
I did a one hour webinar for the software company (Software AG) that we develop all of our software with as they were impressed with the way we were using their software development environment (NaturalOne).
I threw a little Kerika spice into my presentation as it has become such an important part of our development environment and I actually used it to prepare my presentation.
Instead of preparing the presentation by myself I used a Kerika project and had my software developers contribute cards and instructions in the areas that they specialized.
While I was doing a live presentation I was referring to the cards on my other monitor and swiping them to the ‘Done’ column as I completed them.
I know you like to hear stories about how people use your software and this worked very well for this presentation. It was recorded and I will send you a link to it once it is published. It might put you to sleep at night, except for the Kerika part.
Here at Kerika, we often get asked how we do Scrum as a distributed team.
Here’s the model we have evolved, which works for us mainly because we are the very essence of a distributed Agile team: we have people working together on the same product from locations that are 10,000 miles apart!
And this means that we are the most enthusiastic consumers of our products: we use Kerika to manage every part of our business and we only build what we would ourselves love to use.
Here’s the basic outline of our Scrum model:
Kerika’s model for 2-week Sprints
Each Sprint is 2 weeks long: that that works well for us; other folks might find that 3 weeks or 4 weeks i better. Pick what works for you.
Each Sprint begins with Sprint Planning, where the Scrum Team gets together with the Product Owner to decide which cards will be pull from our main Product Backlog into the Sprint Backlog.
Each Sprint is organized as a separate Scrum Board: this makes it really easy for us to concentrate upon needs to get delivered in that particular Sprint, without getting distracted by what was done in the past or what remains to be done.
And Kerika makes it really easy to pull cards (literally!) from the Backlog onto a Scrum Board, and then hide the Backlog from view so it doesn’t distract the Team while the Sprint is underway.
Half-way the Sprint, at the end of the first week, we do a gut-check: does the Sprint look like it is going reasonably well? We don’t ask if it is going perfectly: almost no Sprint does; what we are looking for is any indication that the Sprint is going to severely under-deliver in terms of the Team’s commitments to the Product Owner.
We could do these gut-checks every day during our Daily Standups, but in the first part of a Sprint cycle these can often give us false positives: it’s easy to tell early on if a Sprint is going to be disastrous, but it’s hard to tell for sure that it is actually going to end well. But about midway through the Sprint we start to have a more reliable sense for how things may turn out.
In keeping with the Scrum model, our goal is to complete a potentially shippable set of features and bug fixes with each Sprint, although this doesn’t necessarily mean that we will always ship what gets built after each Sprint. (More on that later.)
For each feature or bug, however large or small, we make sure that we have design and testing baked into the process:
An analysis document is prepared and attached to the card, either as a Google Doc or as Box document. (We had been using Kerika+Google exclusively for years, but have recently switched to Kerika+Box since we completed our Box integration.)
The document is often just a few paragraphs long, because we always take cards representing large features (or other big work items) and break them up into smaller cards, so that no card is likely to take more than a day’s work. Kerika makes it really easy to link cards together, so it’s easy to trace work across multiple cards.
For bugs, the attached document describes the expected behavior, the actual behavior, and the root cause analysis. Very frequently, screenshots showing the bugs are attached to the cards.
For new features, several documents may be attached, all quite small: there may be a high-level analysis document and a separate low-level design document.
For all features and bugs, we do test planning at the time we take on the work: for back-end (server) work we rely primarily on JUnit for writing automated tests; for front-end (UI) work we have found that automated testing is not very cost-effective, and instead rely more on manual testing. The key is to be as “test-driven” in our development as possible.
There are several benefits from doing formal planning, which some folks seem to view as being antithetical to an Agile model:
It helps find holes in the original requirements or UI design: good technical analysis finds all the edge cases that are overlooked when a new feature is being conceptualized.
It helps ensure that requirements are properly interpreted by the Team: the back-and-forth of analysis and reviewing the requirement helps ensure that the Product Owner and the Team are in synch on what needs to get done, which is especially important for new features, of course, but can also be important to understand the severity and priority of bugs.
It deliberately slows down the development pace to the “true” pace, by ensuring that time and effort for testing, especially the development of automated tests, is properly accounted for. Without this, it’s easy for a team to quickly hack new features, which is great at first but leads to unmaintainable and unstable code very soon.
At the end of the 2-week cycle, the Team prepares to end the Sprint…
We like to talk about Sprints as “buses”: a bus comes by on a regular schedule, and if you are ready and waiting at the bus stop, you can get on the bus.
But if you are not ready when the bus comes along, you are going to have to wait for the next bus, which thankfully does come by on a regular 2-week schedule.
This metaphor helps the Team understand that Sprints are time-boxed, not feature-boxed: in other words, at the end of every 2 weeks a Sprint will end, regardless of whether a feature is complete or not. If the feature is complete, it catches the bus; otherwise it will have to wait for the next bus.
And here’s where the Kerika team differs from many other Scrum teams, particularly those that don’t consume their own products:
At the end of each Sprint, we do the normal Sprint Retrospective and Show & Tell for the Product Owner.
But, we also then take the output of the Sprint and deploy it to our test environment.
Our test environment is the one we actually use on a daily basis: we don’t use the production environment as often, preferring to risk all of our work by taking the latest/greatest version of the software on the test environment.
This forces us to use our newest software for real: for actual business use, which is a much higher bar to pass than any ordinary testing or QA, because actual business use places a higher premium on usability than regular QA can achieve.
(And, in fact, there have been instances where we have built features that passed testing, but were rejected by the team as unusable and never released.)
This is illustrated above: the version of Kerika that’s built in Sprint 1 is used by the team to work on Sprint 2.
This is where the rubber meets the road: the Kerika Team has to build Sprint 2, while using what was built in the previous Sprint. If it isn’t good enough, it gets rejected.
At the end of Sprint 2, we will release the output of Sprint 1 to production. By this time it will have been used in a real sense by the Kerika Team for at least 2 weeks, post regular QA, and we will have a high confidence that the new features and bug fixes are solid and truly usable.
We could summarize our model by saying that our production releases effectively lag our Sprint output by one Sprint, which gives us the change to “eat our own dogfood” before we offer it to anyone else.
“Done” is where you want to get to: it’s a special column that’s always to the right edge of every Task Board and Scrum Board.
(You can always chose to hide the Done column, of course, just like you can hide every other column on the board.)
Marking a card as “Done” is simply a quick way of moving it to the Done column, which can be handy when you have a very elaborate workflow — and we have seen folks whose boards have up to 20 columns!
In the near future when we add Work-In-Progress (WIP) Limits for Task Boards and Scrum Boards, the Done column, of course, will not be subject to WIP.
We are also planning on adding more metrics to help Project Leaders and Account Owners understand how well their projects are going, and these will naturally make use of the Done count.
(The fifth in a series of blog posts on how you can make use of the status indicators on cards, in Task Boards and Scrum Boards.)
In our last post we talked about how to use the “On Hold” flag; today, let’s take a look at “Is Blocked”
Setting status
“Is blocked” sounds similar to “On hold”, but it should be used in a different context: Blocked is a red flag to the team — it indicates that you are unable to proceed with a task, and you need help.
The essential difference between Blocked and On Hold is that:
You, or perhaps your boss, chose to put something On Hold.
You were forced to mark something as Blocked.
For teams working in a Kanban or Scrum model, the highest priority for a Project Leader should be to unblock cards.
Unblocking cards (and hence, people) is the most useful thing that a Project Leader can do to help move work smoothly.
This is why “Is blocked” is shown in red on a card, so that you can literally raise a red flag!
In an ideal world, you would simply pick up a task, get it done, and move on to the next one.
In the real world, you must often put aside something you are working on, in order to work on some more urgent and probably unexpected.
This is when you can mark cards as being “On hold”: it’s an easy way to let the rest of the team know that you are not currently working on something, even though it’s assigned to you.
From the Project Leader’s perspective, having too many items “On hold” is a warning sign: it’s often an early indicator that people on the team are starting to thrash between tasks.
If you see that anyone on your team has several items “On hold”, it might be a good idea to check in on them and see what’s happening: why they are picking up so many items and leaving them unfinished.
In an ideal world, cards would only move from left to right: starting off on the left-most column, e.g. the Backlog in a Scrum Board, and moving in stages to the Done column.
In the real world, however, work can sometimes need rework, and that’s what the “Needs rework” status indicator can be used for.
The amount of rework that’s needed will vary widely, depending upon the project and the team:
If someone new has just joined a well-established team, that person may need some time to understand exactly what’s expected of them at each stage of the project’s workflow: they may, for example, be too quick to move a card from “Planning” to “In Development”, without realizing what’s expected of a card that’s fit to exit the Planning stage.
This new person may find that her work gets pushed back to the left, marked as “Needs rework”.
It’s imperative that whoever pushes back work as “Needs rework” also provides some precise description of what rework is needed.
This is most often done using chat, but sometimes a marked up document, screenshot or other materials may be more useful, particularly if the task is complex.
But, simply marking a card as “Needs rework”, without providing a good explanation, is never a good idea: it will generate ill-will within the team, discourage the new person, and simply result in more work for everyone.
Some times of work will always require a lot of rework: e.g. design.
Mockups of new products or features, or copy for new advertising, will go through a lot of rework before it is considered ready to move along a workflow.
This is quite normal, which brings up another critical point: good Project Leaders will ensure that there is no stigma attached to cards being marked as “Needs rework”.
If people are made to feel, however subtly, that their work is of poor quality because many of their cards are frequently marked as “Needs rework”, this will have a very bad effect on individual and team morale.
It’s really incumbent on the Project Leaders to ensure that people understand that “Needs rework” is simply a status indicator, not a judgment of someone’s abilities!
This status is easy to understand: “Needs review” means just that — a card needs to be reviewed by someone before it can move further along on its way to Done.
There are many common scenarios where this is useful:
Perhaps a supervisor needs to review your work before it can progress further.
Perhaps an expert, e.g. a security expert, needs to review your work before it goes further.
Perhaps you are simply seeking comment from others on a draft idea…
Marking a card as “Ready for Review” can be done alongside a workflow that involves more formal review steps.
Here, for example, is a software project that has “Code Review” as a stage in the workflow:
Review as part of a workflow
This image is from one of our projects, and as you can see (if you squint hard enough) we have a “Code Review” column on the board that’s part of our Sprint workflow.
We use the “Ready for review” status flag at all stages of our workflow: for example, after a developer has done some technical planning for a new feature, she may mark the card as “Ready for review” and leave it in the Planning column.
A more senior developer may then pick up that card, provide her review comments — as chat, notes in the card’s details, or even an attachment (if the comments are extensive) — and attach them to the card before taking off the “Ready for review” flag.
The “Ready for review” flag can be used in both push and pull models of project management.
(The first in a series of blog posts on how you can make use of the status indicators on cards, in Task Boards and Scrum Boards.)
Kerika makes it really easy to flag cards on a board, if you need to alert your team members; here’s an example:
Examples of status flags on cards
There are several statuses that you can report on cards (in addition to “Normal”, the default setting), and we will try to provide some advice in these blog posts on how best to use them.
First up: “Ready to Pull”
Setting status
Ready to Pull is great if your team works in a “pull” environment, rather than a “push” environment. Here’s the easiest way to differentiate between the two:
In a “push” environment, work gets pushed onto people — quite literally. For example, Project Leaders (or even Team Members) decide that a particular card should be handled by a particular person, and they assign that card to that person: in other words, they push that work onto people.
In a “pull” environment, people only assign work to themselves: as they get freed up from whatever they are working on, they look at the board and pick up whatever task is waiting to be pulled (i.e. done) — in other words, they pick up a card that is marked as “Ready to Pull”.
There are advantages and disadvantages to both models, and it’s really a question of how your team prefers to work.
Particularly in organizations that are still transitioning from traditional (Waterfall-style) project management, the push model can be the easiest way to adopt a tool like Kerika: it helps retain the traditional role of a Project Leader as someone who is responsible for the assignment of work among the team.
This is definitely the easiest pathway for organizations that are still in the process of transitioning to a Lean or Agile model — a process that can take months in most cases.
There are, however, some disadvantages to the push model:
It can delay the organization’s cultural transformation to Lean/Agile: people feel less empowered, and can be more passive if they wait for work to get pushed to them by others.
A less empowered team is often slower to take the initiative.
Someone who has had work pushed onto them may feel less ownership of the outcome.
It provides a misleading picture of what’s actually getting done: this, in our experience, is the biggest shortcoming of the pull model!
When work gets pushed onto people, you can find that individuals have 10 or more items currently assigned to them. There’s no way they could be working on all 10 items at the same time, so one of the biggest advantages of Kerika — providing an accurate, real-time view of what’s getting done, and by whom — is somewhat negated.
The pull model is truer to the spirit of Kanban: it allows people to work at their own (true) pace, and empowers them to pick up new work as they get freed up — or blocked.
The Kerika team itself has transitioned from push to pull: with push we never had a true sense of what’s getting done; with pull, we do!
There are disadvantages to the pull model:
It requires more training and cultural change up-front: even for a team that generally feels empowered, it is a big shift in thinking and process to move from push to pull.
It can require a more complex workflow: for example, here’s a partial (!) view of the workflow that we adopted as part of transitioning to Pull, to make it work within our constraints:
Understanding the Pull Model
Pull is best implemented in conjunction with Work-In-Progress (WIP) Limits, which is a feature that we will be adding shortly to Kerika.
So, how should you use “Ready to Pull” as a status indicator?
If you are working in a push model, there’s nothing to do: you don’t need this feature.
If you are working in a pull model, whenever a user is done with a piece of work, she should mark it as “Ready to Pull”, and then take her name off the card.This will clearly signal the rest of the team that the work item is ready to be taken on by someone else.
On LinkedIn’s Scrum Alliance group someone recently posed this question:
Which is more effective agile software project management tool MS Project or a agile software project management tool for implementing scrum?
Here’s my response:
I started using MS Project around 1989 — must have been close to v1.0, I imagine — and even back then, when it was a relatively simple tool, it never delivered enough utility to warrant the immense hassle of trying to keep it updated so that it actually reflected the reality of a fast-moving project.
The phrase that came to mind often was “I have to feed the beast again“, i.e. I have to spend hours each day trying to map all the real-time changes that were happening in the real-world to the fake world modeled in MS Project.
The MS Project world wasn’t fake because I was incompetent: it was fake because it was always instantly out-of-date.
And as MS Project has gotten larded with more bells and whistles, it has never been able to address its fundamental shortcoming: it is a theoretical model of what you would like your project to be, rather than a practical/actual reflection of what your project is.
So, even back in the 1980s, before people were talking about Agile and Scrum, we were all actually living in an Agile/Scrum world; we just didn’t have that realization, and we didn’t have the appropriate tools to deal with a fast-changing project environment.
At Kerika, we live and breathe in a distributed Agile world: our team is spread out between Seattle and India, which means we never have any overlapping time, but by using Kerika scrum boards we are in perfect synch with each other.
We know exactly what everyone else is up to, and we are able to process, on average, 10-12 cards per week, per person, on a sustained basis.
Kerika also has a whiteboard capability so we are able to do brainstorming and design work.
Is MS Project useful for anything at all? Yes, if your project…
a) Is considered immutable from the very start.
An example would be a government contract which is negotiated up-front in painful detail, and your success is defined only in terms of whether you delivered exactly what was specified, not whether the final product was useful. (Business-as-usual for most Federal contracts.)
b) Every aspect of the technology has been prototyped, tested, and proven already, so uncertainties are minimized.
This is an interesting use-case of mixing Scrum and Waterfall that’s not explored very often, where you use Agile to do your R&D and figure out workable solutions to your biggest uncertainties, and then use Waterfall to build the final version.
This website uses cookies to improve your experience. We'll assume you're OK with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
