Three years ago I wrote an article that describes the changes in our Agile software development processes from 2008 to 2012. Three more years have passed by and our processes were not set in stone. Here I want to provide you with 90 months of changes in our product development practices, company culture, structure and engineering practices. Hope you will find it interesting and learn from our mistakes.
Read the article: Agile Software Development Process: 90 Months of Evolution
... no matter if it's agile, Scrum, Kanban, SAFe, lean, XP or some mix of these methodologies.
Project managers want to track progress in any software development project, small or large. Sometimes they want to track progress not only in one, but in many projects at a time, and they want to be able to do this fast and conveniently. A timeline is a a visual management tool that helps accomplish this. Let's take a closer look in which way.
Regardless of the software development methodology used, projects are meant to be completed. Always. However, at times project managers feel tied to by-the-book canons of Kanban (which is viewed by many as the best visual management system there is, but allows no time-boxing), or of Scrum (which has time-boxed iterations and releases but falls short with the visual part). What if a project manager wants to get the best both of Kanban, as a visual board, and of Scrum? Obviously, if projects have deadlines, one can not live by the classical pull and flow formula of Kanban only.
For progress tracking, Scrum allows only one visual report, called the burn down chart. When we want to keep an eye only on one project, such a report would probably be enough:
However, if many projects need a watchful eye of this one person, squeezing many burn down charts on one screen will not make the job any easier. Imagine how hard it would be to make sense of those charts arranged in a grid-like fashion. A project manager will likely want to see how projects correlate with each other, as it might be that the timing in one project affects the other projects. In this case, it would be sensible to drift away from the prescribed tool set of Scrum, and venture into the unknown land, fearlessly mixing sense of time (Scrum) with a neat visual representation (Kanban). That's how this stylized mix looks as a timeline view for 2 projects (click to enlarge):
Work items in several projects on a timeline in Targetprocess 3
Such a visualization will fit a dozen projects into one screen, showing a project manager how all of them correlate with each other. This timeline has something more in store, than merely registering projects' health in terms of time. Unlike in the burn down chart, one will be able to zoom in on any work item in any project and see what's going on. This timeline bears a certain resemblance to Kanban board, because bugs, user stories and features are presented as cards stretched over time. At the same time, as in Scrum, the forecast will update depending on velocity (if one needs it done that way), and the timeline will show the latest status. If a project manager is in charge of several teams, that do several projects, this timeline will show when one can expect these projects to be completed:
A teams/projects timeline in Targetprocess3
A yet another snapshot of tracking progress with timeline. Here we have Features and User Stories (as in Scrum):
User Stories inside Features on a timeline in Targetprocess 3
When someone pledges allegiance to Scrum, timelines offer a way to track progress with many iterations. Same for many releases, as opposed to clicking through single release and iteration plans one by one.
Tracking progress/status for several iterations on a timeline in Targetprocess 3
As we can see, it pays off when we forget about practices that seem to be rigidly prescribed by a methodology. A methodology is nothing, unless it works for our purposes, and helps us do the work better and faster. These timelines can not be, scholastically, classified as belonging solely to Scrum as a method, or to Kanban. While classical Scrum only offers burn down charts for progress tracking, this is not enough when people work with many projects and want to keep their hand on the pulse of all of them. Classical Kanban, in its turn, allows no time tracking as a methodology (and as a visual board). I'm not even sure if what they call "Scrumban" would accommodate this representation with timelines. Frankly, I don't care how it's called. I only care if it works for project managers or product owners, or any other folks in charge of projects, and helps them do their work well. And I wish that people were more of a freethinkers, unpinning themselves from the methodology labels.
Care to take a look where one can afford being a freethinker and still work as a project manager? With no strings attached to Kanban, or Scrum, sticking only to common sense and convenience of work? It's here.
Related articles:
How Visualize: Board, List or Timeline?
Why Visualize?
A couple months ago in the article Kanban as Multiban? I questioned the applicability of simple Kanban boards for managing complex software development projects, and suggested the concept of Multiban. This short word inherits the practice of visual project management with boards taking the baton from Kanban, and looks like a good coin term for this innovative concept to me. "Ban" stands for "board" in Japanese, Kanban is a "signboard", and Multiban is a Japanese-English mix which means "many boards". In this article I will tell more about the use of "many boards" for visual project management, showing how Multiban differs from Kanban, and when it's better to use Multiban instead of Kanban. Shortly, a Kanban will work well for a small company with only so much of work items, and with a straightforward development process. For a larger organization with many teams and many projects, a traditional Kanban board will not be enough. If you want to get the best of all the project Big Data in your organization, it's time to consider Multiban. It doesn't matter if your development process is Kanban, or Scrum, or any other lean or agile or whichever process. The Multiban covers everything.
There are 2 basic entities that Kanban and Multiban have in common: a card and a board. Let's look in to the differences.
How a card in Kanban is different from a card in Multiban?
A Kanban card can be pinned only to one board. No matter if the Kanban board is a physical or an electronic one, the card is tied to it and can't live anywhere else. Besides, a Kanban card usually signifies work items only. Now take a look at the list of Multiban cards:
Pretty impressive, huh? Apart from being impressive this diversity of cards powers the very ability to visualize project work in many different ways. Here's another crucial point of difference: one and the same Multiban card can live on many boards. If cards are available only for work items, as in Kanban, one can visualize how work streams through development states, pretty much as in material production. Software development, however, dictates the need to take many ad hoc factors into account. Big IT projects in a large enterprise company can be anything, but straightforward, unlike a car assembly line. If someone wants to control this complexity, without too much extra effort and time, a set of various cards visualized on many boards looks like a must-have gear .
How a board in Kanban is different from a board in Multiban?
With Kanban, a board is just one board to which the cards are pinned. With Multiban, a board is a slate of switchable data axes (or lanes), with custom intersections. This slate can also be converted to a list view, or a timeline view, or a card details view. Actually, it's for that reason that one and the same Multiban card lives on many boards. With switchable lanes, it can appear in various contexts. A Multiban tool has the switcher of those axes and perspectives (see the full list of available combinations) that allows to set up any board as a custom 2D data grid in no time:
Next, given that we deal with one digital screen, the single option of using board as a pinboard will not be enough. If all you have is a visualization with a board and cards only, this will pose a limit on the versatility of visualizations. What if you need to see work items and other entities as a list? Or as a timeline? Or what if you want to zoom in on just one entity? With Multiban, the electronic slate can be tweaked. It's now rather not a board, but a flat white space that turns into a list, or a timeline, or a board with cards. Check the purple arrows on that screen. They highlight the 3 basic switchers that are used to set up any board.
This image gives an excellent summary of the Multiban approach:
The "see data" stage is where you configure a custom visualization of any data entered to your project management tool that supports Multiban. You will want to ask yourself: "How do I need to see this?" instead of "What will this board allow me to see?" All those many boards are available, waiting to be picked by you.
Too many cards, too many boards... Do I need this?
It might seem that it's so easy to get lost in this versatility of cards and boards. Sometimes, freedom of choice is more intimidating than no choice at all. It does take some time to get used to the switchability of everything in Multiban. Too many cards can be sorted, filtered, paginated, zoomed in or out. Too many boards can be stored in folders, as in a file management system. It might seem an overkill to use Multiban if you're happy with a simple Kanban board for one project, with < 100 cards, and with a straightforward development process. But, for example, a fixed Kanban board will not be able to showcase a portfolio of projects like that:
If you want to learn more on when and how it's best to work with Multiban, check out these use cases... or look into the peephole in the fence on the right.
Related article:
Kanban as Multiban?
Earlier this year I published the 3 Checkpoints for Your Agile Project Management Tool blog post. As a reminder, the 3 checkpoints are these:
I'm making this reference to give a clearer idea of what my today's post is about. The very first bullet — process first, tool next — deserves a closer look. What happens in the phase which goes between "process first" and "tool next'? A diagnostics check of the development process. We need to be aware of any peculiarities of the real development process to select a tool that would be capable to replicate it. So, what are the things to note about the process that one would definitely need in the tool?
First, you need to break down your development process into these 3 parts:
This high-level representation will work as a good reference framework to cover all the essential details of the process that needs to be replicated in the project management tool. I've compiled a list of questions that would help stakeholders check if a tool is capable to mirror the process. Let's go over each of those 3 major checkpoints.
Work
1. Which work items are you using? How is work broken down in your development process? How many levels of hierarchy do you need for your work items? Just for the sake of example, the hierarchy can look as follows:
Idea (Issue) -> Epic -> Product->Project->Feature-> User Story->Task
A special attention should be paid to the levels of hierarchy, and to the ability of work items to be linked together, which brings us to the next question.
2. Which dependencies do we have between our work items? Do we need to replicate any other dependencies in the tool, apart from the hierarchical breakdown?
3. What is our definition of done for a project or for a work item? Do we need to have a certain scope completed, or is our project tied with the time elapsed? Do we need multiple final states for work items (e.g. Done and Resolved)?
People
1. How are people organized into teams? Do we have cross-functional teams? Functional teams? Project teams? Departments? No teams at all?
2. Is development process the same for each team? Do we sometimes need to assign several teams to an Epic or to a User Story?
3. Does anyone need to be aware of how work progresses, even if they are not assigned to this team or to this project? Customers? Executives?
Plan
1. How do we do backlog management? Where are the backlog items coming from? How do we groom the backlog?
2. Projects/Releases/Iterations: Do we have cross-project (or cross-team) releases? Parallel iterations or releases? Do we break down projects into phases (e.g. UX, prototyping, functional design, delivery)?
3. Which reports do we use? This one is very important. Be sure to check if the tool has all the reports that you need.
The reason I give this list here is that sometimes people overlook some essential components of their development process as they commit to a project management tool. I'm not claiming that each and every possible question is covered in the list above, but the 3 checkpoints framework will help to get a more complete idea of the points to note about your development process when choosing an agile project management tool.