We are constantly blown away by the incredible variety of uses that Method Grid is put to. In this post, we talk about one such example: how Method Grid is used to host an agile sprint board and other related tools (such as prioritisation matrices).
At the heart of most use cases is the capture of structured service methodologies, operating procedures and training libraries – essentially the capture of your corporate playbook. What we are increasingly seeing, however, is the mix of such structured grids with more agile-based tools (such as agile sprint boards) and facilitation frameworks. A number of power users indeed link the two i.e. an overarching grid maps out their methodology and elements within this grid link off to second-level tools – which are in effect separate grids.
Here at Method Grid, we certainly harness the platform for both structured IP (where the grid columns equate to “stages” in a process/method) and such agile sprint boards (and other agile-based working tools).
In this short video, Dom describes such a use case – bringing to life how Method Grid supports both the prioritisation of our future software development and the visual supervision of our fortnightly working sprints: where a grid is used as an active scrumban board (scrum + kanban = scrumban).
Agile Sprint Board | Why might this be relevant to you?
As per the original Agile Manifesto, harnessing the power of Method Grid for such tools is specifically relevant if you are involved in product/software development and/or some form of service delivery that excels when improvement is delivered incrementally. That is, at the heart of what you do lie such principles as:
- you give the highest priority to satisfying your end-customer through the early and continuous delivery of value-adding products/services;
- you build projects around motivated individuals and give them the environment and support they need, and trust them to get the job done;
- you believe the most efficient and effective method of conveying information within a development team is face-to-face conversation (as facilitated by solutions such as Method Grid!);
- for software developers, working software is your primary measure of progress!
Agile Tools in Method Grid | Some practical “top tips”
We, of course, take our “own medicine” with respect to building out our company – harnessing the power of the platform. Initially, we used it – per its core purpose – for capturing our operating playbook – staff induction grids, sales enablement, training libraries etc. Increasingly, however, we saw the potential for grids to help the team supervise a host of more agile-based processes such as software roadmap prioritisation and the use of an agile sprint board for various operational matters: software development, bug resolution, marketing campaign management etc. Where we once used Method Grid for structured knowledge capture and Trello for such active task management, we now do it all on the one platform.
What have we learned as a result of this journey?
What practical “top tips” can we pass on?
Here are a few to consider:
- First Off. Just get going! The beauty of any agile-type approach is the short-term, iterative learning cycle it induces. It doesn’t matter if you get the framework/grid design slightly wrong to start – it is easy to change all aspects of a grid’s appearance in Method Grid. So, just get started with your best first effort at a grid presentation and at the end of your agile cycle/sprint just ask the team “how can we improve?” across all aspects of your operation – including tool design.
- For a (software-based) agile sprint board, a simple set of column headings might be “User stories/resources”, “Not started”, “Started”, “Blocked”, “Ready for Testing”, “Fully Tested”, “Deployed”.
- For a (software-based) agile sprint board, we often use the Y-axis rows, “themes” in Method Grid parlance, to capture the different types of “User Story” contained within a discrete release. For example, in a recent release to allow users to configure label legend colors, one theme/row was titled: “As a user, I want to configure label legends at the account level”, another: “As a user, I want to configure label legends at the individual grid level” etc.
- For a (software-based) agile sprint board, the constituent elements allow for such a “user story” to be broken down into manageable functional units. The power of Method Grid is that an array of information can be captured in these (board-movable) elements – text fields (e.g. updating key discussions), checklists, document links (e.g. to key design artefacts) etc. We have a standard template for such an element – but often find ourselves adding to this within a specific element (i.e. there is no constraint).
- Color-labelling really helps bring the visualisation aspect (a key principle of kanban-type agile) to life. Again, we don’t see any fixed recipe here – every sprint might need different aspects to be accentuated. As such, our label legends tend to evolve also; albeit we often make use of such color labels to denote who “has current control” of an element, what is urgent etc.