The planning approach at Praqma
Very often developers are engaged in multiple projects. So as an individual you’ll often have more than one milestone to work on in parallel. Learn how we have organized ourselves with issues and milestones in a Kanban style approach with frequent Office Hour sessions.
Any process that involves people, is dependent on all people following the process. It’s like the choreography of a dance; It looks beautiful and easy when everyone has rehearsed it together for hundreds of hours.
This post describes the steps of everyday agile planning, when everyone is involved in more than one project, distributed across multiple sites, working different timezones, having different levels of experience and even sometimes take vacations.
So learn the steps, put those hours in, start rehearsing!
|Tasks||GitHub Issues||Used for both briefings (≈epics) and tasks|
|Kanban||Waffle.io||Used to provide a Kanban view to the issues and to combine more milestones onto the same board|
|Meta discussions||Slack||Used for parallel discussions derived or reflected off an issue, but not strictly related to it|
|Office hours||Google Hangouts||Used for status meetings on milestone start and end|
|Copy - in progress||Google Documents||Used for all copy that’s in progress|
|Documentation||MarkDown||Always version controlled in Git|
Tasks are kept in GitHub repositories using GitHub issues. Each task is described in the repository it is to be implemented in.
Some of our repositories don’t even store any version controlled files, we use them solely for agile task management. An example is our
marcom repository used by our marketing and communication team.
The agile process is kept in check through the use of labels on issues and by organizing the issues in different milestones. That’s it.
The labels we use are organized in groups.
For convenience, labels within the same group use the same color tone.
|Size 1 - small||A task than can be carried out quickly, like in an hour or two but never more than that.|
|Size 2 - medium||Can be finished in somewhere between 2 and 4 hours.|
|Size 3 - large||It’s more than half a day’s work - it’s approaching a full day’s work.|
|Size 4 - too large||If it’s more than a full days work, then it’s too big.|
All time-boxes are set by the people who should work on the issue.
Some issues doesn’t have any fixed time-box at all - consequently they can never become workable. It’s all the issues where we’re debating and discussing stuff - until we’re ready to get started. These issues go to a special milestone called Briefings
When a briefing issue is settled it is closed, it will be spawned out into several issues for implementation - each will get its own time-boxes.
We all know that it can be really difficult to guess how long time a task is going to take, before we’ve actually done it. Let’s just agree that estimates doesn’t make much sense. So let’s call them time-boxes. This is not just a twist of words - they are actually different. Here’s how;
You should not exceed the time-box. If you know the term spike from Scrum it’s kind the same. You can say that we only do spikes! It’s an important difference, because you should see your T-shirt sizes as mini deadlines - just like the milestones in the greater scope.
So when time is up, you will deliver something. Now you may argue “But what if I haven’t got anything to deliver?” well, the thing is, you do. Even if you cant finish the goal of the task, you are clearly the victim of something that surprised you. Reporting on what that is important - and it should be delivered. Like; 10 minutes bore your time is up, you must fold, and go to the issue and write a small summary of what happened - your log will be used to create a new issue with a new time-box, which you have better chance to complete, since now you know more. Or maybe we know enough to say, that “then we don’t want this issue” and then you reporting will be used as the cause.
In any event, the task will be closed, when the time-box is up! For no other reason than time is up!
At least not if the time you set aside for it is already spent. Think of it like this. When you put a T-shirt size on an issue it’s locked. You don’t burn 12 hours on a T-shirt size small. Never!
An you don’t just go and close the case and create another one exactly like it. Simply because they are not the same case. You’ve learned something - which will be taken into account - so make an effort out of actually describing the new situation.
|Prio 1 - must have||A condition that must be satisfied in the final solution for the solution to be considered a success.|
|Prio 2 - should have||A condition that should be included in the solution if it is possible. A critical condition indeed but not discriminating for success if left out.|
|Prio 3 - could have||A condition that could be included if time and resources permit. It is considered desirable but not strictly necessary for success.|
|Prio 4 - won’t have||A condition that is deemed not currently relevant and will not be implemented.|
Priorities are set by the product owners - often in the role as Benevolent Dictator, or one of their trusted lieutenants. At the end of the day, the priorities on tasks determine where the company or team is burning their resources - it’s gotta be right.
Normally a case will have to be worked on and delivered before it can be closed, but sometimes you have cases that are either duplicates of other issues or just plain simply a suggested change, that you don’t want.
If a task is to be closed without work, it must have either the
Prio 4 - won't have label or the
Status - duplicate label described in the next section.
|Status - duplicate||Used to indicate that a case is being closed, as the issue is covered further in a duplicate case.|
|Status - in progress||Used to indicate that the person assigned to the task is currently working on it - and nothing else!|
|Status - up next||Used to indicate that this issue next in line, to be included in a workable milestone. NOTE: Implies that the issue is currently on the backlog.|
Status - in progress label is also the one that is used to visualize the bottleneck in the waffle board, which we use for KanBan style visualization.
|Action - Awaiting feedback||Needs another set of eyes|
|Action - Needs grooming||Needs to be prepared to enter into a workable milestone|
An action label is a blocker - an action is required before the task can be worked on again.
An action label is always used in combination with assigning the task to a person: The one who’s gonna do the action.
When the person has performed the action, he or she will unassign themselves from the task again - leaving it unassigned for others to pick up. Sometimes is should be assigned back to a specific person, but in that case, that would be remarked in the comments of the task.
Green action labels should be attended immediately.
Go to github.com/issues/assigned and check if you have any issues with green on them - if you do, attend to it immediately - somebody is blocked by you!
Milestones are the only objects we control that have dates attached to them.
A milestone defines a delivery, and the delivery is tied to a date. A milestone is essentially a container of workable items. You can put as much as you want into a milestone, but if anything goes out of skew and behave different than planned - then it’s not the date that changes. The variable is the amount of work that gets done from the milestone. And that’s the only variable.
Consider milestones are like traditional deadlines in the publishing world; If you plan a magazine to be released, and there are articles or pictures that don’t meet the deadline, then you will release the magazine without them - but the magazine will be issued on time - always.
There are typically four milestones that exist in each project, that are special:
They are special for the same reason - they don’t have any due dates attached to them.
The backlog contains tasks that it’s safe to ignore for the time being - they are not currently in scope. Until they pop up in a milestone that actually has a due date attached - just leave’em.
The workable milestone is used to indicate work that is groomed and ready for work. Work here is up for grabs, anybody who’s bored or wanna give a helping hand, can prove themselves useful and chip in. It’s important that only groomed work are put to the workable milestone, it’s also worth remembering, that there isn’t any deadline attached to the milestone, so if it’s work that’s required at a certain date, you should take it to a real milestone.
The Briefing milestone holds all the issues that are not workable - the er size 0 in that sense. But we need them to discuss and clarify. When a discussion on a briefing issues comes to a conclusion, it will spawn off new workable issues with their own time-box sizes. In other words; a briefing issue will never become workable itself.
The runway is anything that’s required for take-off. If there are any blockers, they go here. The term “Runway” is referring to an airfield - like in an airfield - the runway should always be clear. If something ends up on the runway it takes precedence over anything else. If a task has you name on it, and it’s on the runway, then it’s your next task.
Check github.com/issues?q=is:open+milestone:runway+user:praqma like the runway in an airfield - it should be clear. If it’s not - and especially if your name is on something poppin’ up here - then you’re busy!
When a new issue is created, it typically doesn’t belong to a milestone, it doesn’t have a T-shirt size and it may not even have a priority. You can think of issues with no milestone as equivalents to the unread mails in your mailbox.
It’s the Product Owner who owns the issues with no milestones attached. But remeber that the Product Owner may have delegated the responsiblity to a Benevolent Dictator or some trusted Lieutenant - so it could actually be you who manages the “inbox”
If this responsibility is on you, then you need to to establish a routine where you have an eye on new issues with no milestones popping up in your issue system.
Hopefully the majority of them can go to the backlog, and you can revisit them together with you team when it’s time to form new milestones. But sometimes issues needs to go straight to the Runway milestone or even one of the existing milestones in progress - which would then probably ruin your plan for that milestone, so be careful with that.
Check github.com/issues?q=is:open+no:milestone+user:praqma this should be cleared - at least in relation to every office hour hangout.
The office hours are held as Google hangouts, everyone involved in the domain participates. The goal is to make sure that the work that lies ahead for the upcoming week (or so) looks right, that we didn’t drop anything, that the amount of work - based on workers’ own T-shirt sizes - looks realistic.
During office hours we go through the backlog, pick the tasks that should have focus, define milestones they can fit into and set a realistic, short delivery date for them.
As each developer often take part in more than just one domain or milestone, we try to minimize the number of milestones running in parallel within each domain.
To control task across multiple repositories, we use naming conventions. It’s important that we use the same names for milestones that are supposed to be the same. And with that in mind remember that milestones are deadlines So it makes really good sense to name the milestones after the date they are due or the period the cover. To balance readability and searchability we recommend
An alternative approach could be:
But this has some ambiguity build in: Is the deadline on a Friday? or on e Monday? Surely it’s not on a Sunday - Is it?
A milestone represents a delivery. Our milestones are both relatively short and relatively small. We’re trying to encourage that deliveries are small. Once every week on a fixed reoccurring time and date, each domain has its weekly office hour meeting.
Each individual milestone also ends with a short office hour meeting, where we run a retrospective: “How was the milestone? Did the T-shirt sizes and priorities seem right?”. If there are any issues left in the milestone that haven’t been finished, we will briefly touch on each one of them: “What happened? Why wasn’t it closed?”” and then we’ll clear them out of the milestone; Either to the backlog, but sometimes we just mark them “Priority 4 - Won’t have” and then close them.
When the milestone is emptied of open cases, we close it.
Meetings are expensive, because more people are burning time on the same event at the same time. So having efficient meetings is efficient. So before the office hours, everyone should prepare themselves.
The preparation falls on two different roles, the assignees and the product owner (…or whoever the responsibility may be delegated to).
Assignee is anyone who has one or more tasks in the milestone assigned to them - open or closed, it doesn’t matter.
The Product Owner is the person who sets the priorities. Sometimes it may not be the actual product owner, but then it’s a person who can act on behalf of the Product Owner - make decisions about priorities - that’s the key ability that’s required.
Assignees - Quickly skim through the cases. Did you actually deliver some of them but forgot to close? Do it now! Does any of your tasks have green action labels on them? Aargh, you should have attended them already - do it now! If there are tasks in the milestone that are still open and need a meaningful comment, now is a good time.
Product Owners - An hour before the office hour, poke the assignees and remind them that you expect them to be prepared for the meeting, as described above (- “Come on! is that really necessary?” - “Yes!” ). If you haven’t had time to keep an eye out on new issues without at milestone - do it now!
Being able to work efficiently is highly dependent on the quality of the individual tasks. In the weekly office hours we spend time on picking items for the upcoming milestones. But we also take time to discuss different implementation and design options and help each other with realistic estimates.
A lot of these professional discussions take place in tasks categorized as “briefings” - They are size 0; Not even a T-shirt!. This means we discuss issues, but we don’t work on them. At some point in time, we’re ready to hammer out specific tasks that will actually implement the goal described in a briefing.
Developers do that on initiative from the Product Owner. They describe the task, maybe the design or implementation, and they give it a realistic T-shirt size.
If a task is assigned to a specific person, then no one else can work it. So it’s not very efficient to preassign all cases to named persons. Therefore - in general - we do not assign tasks to specific persons, instead people grab the tasks when they are ready for it.
This approach is recommended on workable items on milestones, but it’s required for tasks that are on the backlog.
The only exception to this, is when we use the green labels, they are combined with assigning the task to a specific person - the person who needs to perform an action.
Waffle.io is visualizing a Kanban-style overlay on top of the GitHub issues - with all the filtering capabilities you could dream of. That’s neat! But waffle.io also provides another important feature; It allows us to combine issues from more repositories onto the same board. So people are capable of designing their personal view of what’s cooking - for them.
This flow is automated using Git, GitHub, GHI, Waffle.io, Jenkins and a handful of plugins - read more in the post about the praqmatic flow
Interested in how we deal with estimates? Read “Stopping development divination - replacing task estimates“
Do you work on any hobby coding projects in your free time? Practice code katas? We all wish we could, but making time for learning away from work isn’t possible for everyone. So, who should pay for learning time?
A write-up on learning away from work
Consultants are valued for their expertise and the fact that they’re outsiders. In this post I’ll argue that the single most valuable skill a consultant can bring to the table is to break the mental barriers in the client’s organization.
Overcoming mental barriers to help your clients succeed
In the past we had all kinds of software specialists: requirements specialists, build specialists, configuration management specialists, and test specialists. Those days are over. We are now in the age of the Full Stack Developer.
Eficode Praqma - The Knowledge Company
Slack is great, but it gets really rowdy as your team grows. I’ve compiled a list of useful settings and features to keep you from drowning in Slacktivity.
Essential Slack settings to shield your sanity
Developers still suffer task estimates, despite knowing they’re just fudging numbers. Here’s how we escaped the crystal balls and horoscopes.
We're not psychic, so why do we bother predicting the future?
We do things that seem crazy from the perspective of traditional IT consultancies. We are not crazy, but just in case you think we are, let me explain why we do things differently.
Breaking the rules of consulting
Developers love writing code because they get to invent things. But someone else has to use the code, operate it and even pay for it.
No developer is an island
We all complain about Legacy Code. We are limited by the leftovers from previous developers. But are we not guilty ourselves of leaving Legacy Code behind?
Leave no legacy code behind
The life of a consultant has drawn me back, but perhaps surprisingly, this time it’s not a return to my one-person firm.
High hopes this will be my most fun job yet
This is the bloody but ultimately edifying tale about “The Bonnie Situation”; I use this story as a metaphor for what consultancy is all about - solving problems. You’ll be introduced to Mr. Wolf - ‘Winston’ for those on first name terms - and you will see why we consider him a role model for any consultant.
A bloody yet edifying story about consultancy
Hear about upcoming events in Scandinavia, latest tech blogs, and training in the field of Continuous Delivery and DevOps