Agile tactics are the tools that deliver specifications (at first) and a working product (in the end) in your projects. These are the techniques that help you collect and share information and push projects forward at every sprint. New product features are best delivered incrementally so we can learn from the feedback we collect from them as well.

There are a myriad of agile tactics. To list a few:

Daily scrums meetings

Test Driven Development

Continuous Integration

User Stories

Sprint Retrospectives

Backlog Refinement

Story Maps

Pair Programming

These are just some of the examples of the many agile tactics out there. Agile workflows are written in books for you to apply your best contribution that fit your team's personalities.

 And to make it more fun, these tactics evolve over time so:

1. Use the ones that work best in our situation

2. Try new ones to solve specific problems

3. Inspect and adapt.

The tactics are the least important aspect of agile. Lots of teams start with the tactics, without looking to where they spring from – the agile values, principles, and frameworks. That’s ok, sometimes practicing the tactics teaches us the value of the frameworks, which starts to teach us more about the values.

Now ask yourself: are you stuck in pure tactics without getting the real heart of agile? If so, go back to the core of Agile:

Customers, Teams, Collaboration, and Fast Feedback.

Look to improve the heart, and the mind and tactics will often follow A comprehensive platform like may help in the process, ya' never know.

Grumpy Herogami, Architect
12 Sep 2016 Read more

This is a true story, a case study reported from - drumroll - Adobe™, the global software vendor behind Photoshop®, Illustrator® and many quality applications used by millions everyday.

A bunch of Adobe teams started using Scrum in 2005 with the goal to get to releasable quality each four week sprint throughout the course of an 18 month release.

While Scrum felt much better to the team, which in itself constituted a perfectly valid reason to keep using it, managers in the organization asked the team for some hard data about any improvements or achievements deriving from Scrum practices.

That’s tough to get, since many of the things tracked prior to using scrum didn’t make sense to track anymore. One exception was the total number of open bugs at any given point in project. The team compared the bug count per release before and after the adoption of Scrum and saw and reduction of the 70% after adopting Agile processes. 70%!

On a constant, repeatable basis, the software development team was able to inject a new measure of quality into the code base as a result of the improved communication flow, better defined responsibilities and discrete planning through smaller, manageable sprints.

Software Developers felt a stronger sense of satisfaction in their work. Nobody wants to build a shoddy product – scrum tends to give teams permission to do the right thing even in the face of pressure to go faster.

Product Managers got more satisfied with the product quality and features and can provide better feedback on the actual features rather than just defects.

Executives get higher revenue at a lower cost.

Scrum is often described as an empirical framework, meaning that it provides transparency with frequent opportunities to inspect and adapt. Delivering working products and services early creates a cultural shift from predicting to testing hypotheses in the market. This shift to an empirical approach significantly reduces power imbalance between the managers and the teams. It creates a new mindset of “let’s try it out and see what we learn”, rather than a mindset of “I made this prediction, you’d better make it happen”.

Effective teams voice and work through differing opinions about how to get work done, but do so in a way that focuses on the problem to be solved, not the people solving the problem. Scrum tends to emphasize this approach, leading to higher engagement, team satisfaction, and better business results.

Alfred Dierk, Agile Coach
11 Jul 2016 Read more

It’s all about communication and collaboration. Here’s our guide to breaking it down and making it manageable. Go agile by considering the following 3 stages.


1. Identify your challenges

Maybe your teams are in different locations or working in different timezones. Perhaps you’re struggling with complex processes, or there’s too much “red tape” administrative tasks such as organizing confcalls or entering data into timesheets. The ability to be agile and adapt to issues is perhaps more relevant to web teams than to any other – we at Herogami have first hand experience on this, since our backup company Venticento Studio also provides bespoke software development and consulting. Having recently launched a website in China with a brand in the retail space, we’ve clearly noticed that when you’re building your organisation’s website, you’re developing the real one and only customer-facing front end.Your website is your shop front. But disparate teams, complex processes and unforeseen bugs are the unfortunate reality for all developers. We’ve witnessed this in enterprise organisations and smaller businesses alike. And this may lead to your front-end channel to go burst.

2. Go all in

It’s not just the web devs you need on your side. If you don’t have a collective buy-in across teams, your collaboration will suffer, which means your work will as well.

Similarly, if you aren’t being agile across the entire lifecycle of your work, your team won’t be working to its full potential. Testing obviously plays a major role in web development, but the beauty of agile is that it’s about the mentality behind work processes more than the work itself.Agile practices are built around a specific set of values:

- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan

This is why agile isn’t just a change in working processes – when it’s effective, it’s a shift in culture. Collaboration and continuous improvement will improve efficiency across a whole organisation. It means you can bring different teams together (think web development, marketing, sales, the end user – you should be looking at your customers as another team to work with!).

3. Take a look at your tools

Are you using the best tools for the job? Are you using the same tools across departments? A lot of the businesses we work with fall into the trap of using tools because they’re used to them or because of vendor lock-in, not because they’re the best. Departments often use different tools that just don’t work together, and it becomes inefficient and costly. In web development, you have specific, unique requirements, but the best tools can be adapted to be used across all teams so cross-departmental work is as easy as work within a team. Herogami is the perfect example of a highly integrated Agile tool, providing not only task-oriented features but also empowering collaboration tools such as wikis, calendars and a document management platform. It’s a boost for collaboration with smoother processes and no more incompatibilities. Herogami was built with Agile and Kanban in mind and wins any comparison over other project management tools used by agile dev teams.

Better collaboration makes it easier to track projects across different teams. If your marketing team has feedback, your sales team needs to update pricing, or a customer encounters an error, effective collaboration is the key to avoiding delays. Herogami can handle it all.

Grumpy Herogami, Architect
20 May 2016 Read more

Herogami aims to cover all Agile and lean topics so that development teams can effectively plan, collaborate and release software. This is our mission, we strive to do our best when we release new features in Herogami.

On tuesday 5th March our dev team has released a new version of Herogami on our cloud servers. It meets the highest standard of the Agile semantics, yet it still feels naive and playful. Herogami is possibly the best tool to help team share knowledge and a collective experience which will help Agile practitioners in their duties.

We strive to offer cross-functional topics to support cross-functional teams and new ideas and concepts together to supporto multiple business and functional domains. Enter the new Stories and a dedicated view to illustrate task progress. It's called Kanban Expended and it is interactive, you can move stories around by draggin'n'dropping them around the fully customizable kanban board.

You can check task progress with a single click of your mouse and even update the story's tasks status in a breeze, directly on the card, without entering the actual story. We feel agility means speed of execution and are designing Herogami around this concept.

Innovation has just started, on your browser and your tablet, and there's many more rabbits waiting to be pulled out from our hat.

Simone Eckehard, Business developer
05 Mar 2016 Read more

We were sitting at an incredible event yesterday, standing in the second row at a conference on startups’ dynamics, eagerly listening to success stories made of hard work, some misfortune and bad times, incredibly motivated teams and dreamers’s dreams. Startups are like that, they’re fueled by the founders’ energy and the hard work of gaunt teams.

These are team where people often wear multiple hats at once: technical members may get involved in marketing activities, business-type people may be asked to test some code, designers are required to do marketing research.

By listening to founders' stories, we’ve noticed a trend that was only barely imaginable up to a couple of years ago and is a consolidate feeling today. Startups are experiments and as such they need to be started, treated, led and monitored. Which leads to an interesting conclusion: when you run an experiment you're just collecting data and evidence from a number of assumption which is exactly what the Lean Startup method is about. Guess what: the lean approach wins over the more traditional business approach everyday!

“Lean” happens when a minimum working/viable product is launched with minimum investment or even not built at all and the business plan and model are tracked and revised in very short cycles. And short mean even as low as a week, even less. There are no rules other then ones established by the change frequency of the effective (so-called actionable) metrics and the team ability to implement and manage change. The approach is in contrast with typical startup school-book business practices assuming you need to invest time and sweat in writing a five-years business plan which, guess what, it’ll never work out as you expected. What’s the point of writing one then?

Get a couple metrics such as the free-paid conversion factor, customer lifetime or plain and simple the amount of money you can cash-in each month and just stick to those. Even better, change them too but stick to effective ones.

Actionable metrics stand in contrast with so-called vanity metrics, and as you pay attention you’ll notice there’s plenty of the latter flying around. Number of visitors, who cares? You need paying customers, forget visitors! Nationality… who gives a d***! Payments take place in your own currency. Platform or operating system of the visiting browser. Forget that, you need to support them all anyway.

The idea of running a startup like a constant experiment is well described in Eric Ries “The Lean Startup” book and if you want to run your team and your software using contemporary standards you should read it even if you’re not involved in the business side of things, it is becoming part of the Lean and Agile culture, the theory / method / approach is well described in the book and it is so sensible that it has in fact been adopted by most contemporary startup initiatives.

Here at Venticento we feel there’s an amazing potential for importing lean practices into project management. Monitoring the efficiency of the software or product development process has always been a “desirable outcome” of project management, yet rarely achieved. Measuring the throughput of software development team is not an easy task because it involves people and people are not cogs: a living and breathing human being is the amazing connection between the cold and sharp logic of code and the fuzziness of complex requirements. As such, the software developer stands in the middle of a constant mess and tries to makes sense of foggy business requirements and harmonize them in terms of data structures, algorithms and architecture.

Agile proves useful when this constant mess is reduced and governed by adopting a common language for developers and non-developers to share the path, to talk about requirements and specifications and to review progress in short cycles, empowering communications and feedback.

Given the messy process, the unstable scaffolding of a set of interdependent requirements, the constant moving targets and short deadlines, how can you then measure the efficiency of a software developer? On which basis? The line of codes he/she writes? The number of bugs? The ability to cope with stress? Bullocks, these are all vanity metrics. We feel there is just one way to do it and it is surprisingly close to the Lean approach: using actionable metrics and these are called story points, issues rates and velocity.

Story points measure the complexity of a story, aka how difficult it is to implement it. It’s just a ranking system nothing more: take three stories, assign one point to the simplest and ten points to the hardest, all others fall in between. That’s it. Any developer can guess story points in a minute. Herogami makes it amazingly simple to review stories given the ability to group stories using attributes such as context, components, environments, different views and plenty of filters. Enter the Planner View and you’ll also get a at-a-glance perspective of all the tasks associated with them, isn’t is a great way to express their complexity?

Issue rates. I write code, my pal sitting close to me too. But guess what, when he does he writes more bugs than me. We know it because we track issues and run post-release analysis. Actually my friend has an average of 2 issues per story in the last three milestones. If you track it, you know it. Herogami does.

Velocity. This is hard and in fact nobody measures it. It falls very close to the border line of vanity metrics, in fact. Basically is the number or stories a developer or a team completes in a given time frame or sprint. It can be measured too also taking into account the number of issues an story points. Measuring velocity requires a lot of post-release analysis but it can be done and in fact we are actively working on Herogami to provide an automated report for it.

We add another metric to our set. This is not in the books, it is called Awareness and it measures the ability of predicting the effort required for a given task. Activities in Herogami such as tasks, requirements and issues have attributes that record and track the effort associated with them. In particular, two fields which are super simple to use: the expected effort and the actual effort. The former is entered at the start of each sprint, the latter when the activity is completed. By periodically extracting a report listing any gap between expected and actual effort we’re able to measure the team members' Awareness and add some contingency percentage accordingly.

Story points, issue rates, velocity and awareness: effective, actionable metrics for Lean and Agile software development teams. Available today at

Grumpy Herogami, Architect
02 Dec 2015 Read more

Here at Venticento Software Design Studio, the Herogami team is actively involved in projects for customers whose profile spans from small startups to large multinational corporations. We support people and teams in adopting the best Agile practices and grow our list of case studies at constant rate. This grants us a priviledged, unique perspective on the adoption of Agile and evidence of the various approaches. Bringing teams onto Agile practices is not a five-minutes task, there are many reasons that Agile fails, here are the most common flaws we saw in companies attempts to implement Agile as a reliable development process.

1. Ineffective SCRUM Master or Agile coach

Agile is an iterative process that takes time to master as a team. Agile works well when the equivalent of the project manager (no fuss here! call it owner, call it master but you know who we're talking about, ritgh?) understands how the pieces are supposed to fit together and what software to use to manage your Agile process. The person running your Agile team needs to understand product management, development, design and more, and know the Agile process well enough to identify deficiencies in the quality and number of user stories. Finding the right person is tough.

2. Stand-ups are too frequent and useless

If you are doing a daily stand-up, have they become meaningless and rote? We prefer having stand-ups a max of twice per week. The rest can be handled via IM and your Agile tool of choice, Herogami with its shared and highly visibile wirkflow rocks at this.

3. Sprint planning sessions are mistaken for design meetings

Marathon sprint planning sessions should not happen, sprint sessions should last one-two hours and no design/specs issues should be addressed. A sprint planning meeting is not where features should be argued and designed, nor the backlog extensively groomed. Prior to sprint planning, there should be some reasonably fleshed-out user stories. Clarify questions in advance or raise an issue if specs are not well defined but do not waste sprint planning time.

4. QA not involved

Agile works best when a dedicated QA person is embedded within the team. If the QA person isn't present in stand-ups and sprint planning, he/she will not be able to run tests properly nor to plan for them. Every single Agile project where QA is not involved will fail miserably. The speed of development in Agile is fast, codes needs to be tested iteratively and continuously, there is no testing phase as such, testing is continuous and constant.

Alfred Dierk, Agile Coach
10 Nov 2015 Read more

The actual term "A3" derives from the paper size used for the report, which is the metric equivalent to 11" x 17" (or B-sized) paper. Toyota actually uses several styles of A3 reports--for solving problems, for reporting project status, and for proposing policy changes--each having its own "storyline."

The term A3 Thinking was coined in English by a guy called Al Ward. In Japanese it is simply referred to as "A san" where "san" is the pronunciation for the Japanese number three.

There are a variety of uses of the A3 template in Toyota. Three uses that are most common are:

1) Structuring thinking and telling a concise PDCA story.
2) Generating discussion with supervisors or other departments for feedback.
3) Mentoring in terms of problem solving skills development.

There are others but these are probably the most common starting points.

Here at the Herogami Labs the team is currently experimenting with the Lean A3 Template chart to see if some of its logic and benefits may be brought into software. It is an attempt to expand the scope of on-line collaboration not only on the aftermath of creativity (aka stories or requirements) but on the actual creative process that generates them: complex problem solving.

The results so far are encouraging, we've developed a few prototypes which are going to be perfected of course before becoming parts of Herogami but they told us a lot, first and foremost is that the process does not encourage sparks but rather an iterative collaboration domain based on four phases:

- Analyze &: Plan: gain a deep understanding of the problem, set goals, identify the root cause.
- Take action: implement the plan and stick to it.
- Gather feedback: establish and analyze metrics to see if the plan actually worked.
- Adjust: take necessary actions to optimize the initial plan.

The whole concept assumes and favours some sort of metrics and that's where we're currently investigating. The dramatic rational is that in a Lean environment a plan is not such. It's a morphing / evolving entity. The question is: can you cope with an ever changing plan while developing bespoke software?

Grumpy Herogami, Architect
15 Oct 2015 Read more

Developing software is expensive, it’s complex and overall it’s a very unreliable and fuzzy process. Engineers do not speak the language of users, key users don’t get to see daily progress because dev teams hide it behind non user-friendly platform (Jira anyone?), when questions are raised answers are lost in e-mails and cc’s, eventually the whole burden falls on the shoulders of project owners which start running around in nonsense meetings and time wasting activities.

In order to succeed you need to gather all stakeholders, from key users to analysts, from team leaders to testers, around a single comprehensive platform that avoids tool fragmentation and ensures that information is consistent throughout all points of views.

Most teams nowadays use at least three different systems to manage projects:

- A shared document platform like Google Drive. First issue: it captures content but not progress.
- A progress tracking system. Second issue: informal systems like Trello do not capture content and specs, complex ones like Jira leave non-developers out of the loop, they’re too complex.
- A shared calendar tool, which by the way, also contains thousands of other shared, unrelated items such as company events, birthdays, you name it.
- E-mails to talk to key users and business stakeholders.

In exchange for this mess, you still end up not having fundamental progress metrics because the above tools will not give you dashboards, forecasting metrics and readability at the end-user level. What you get is a pletora of different systems and users accounts. Ah, and credit card bills.

Successful projects and teams go centric. They pick a single tool that does tracking, plannig and reporting in a single, optimized environment with less clutter and less distractions.

Here’s a quick list of the features making Herogami the leader of comprehensive Agile platforms available today.

- Requirements and stories tracking, with multiple views (four more than Trello, three more than Jira!).
- Issues and defect tracking, on kanban boards, lists or tables, with custom sorting.
- To-do’s and reminders, also on hierarchical levels.
- Pervasive backlog for all entities and clear metrics on backlog debt.
- Shared project calendar, optionally highlightning milestones, stories, issues and more.
- Integrated document manager with previews.
- Wiki for every project, for specs, meetings, and knowledge base.
- Fully configurable workflow for stories and issues.
- No-nonsense graphs, eventuallt a dashboard that makes sense.
- Up-to-date project timeline to follow activities.

In Herogami projects happen like magic and, well, they simply cost you and your team less stress and money.

Michele Florian, Senior Developer
08 Mar 2016 Read more

People, not numbers and graphs, create successful projects. The major purpose of project management is to align and motivate people and to support their decision-making. It is people's creative insights and performance that will ultimately lead to project success, not a number or a graph. So keep your people on the same page, but make sure they're happy and have room to breathe.

Project management is a way of thinking and behaving, rather than just a way of analyzing and presenting data. Managing a project effectively means thinking before acting, identifying and dealing with potential problems before they occur, and constantly monitoring to determine whether your actions are achieving their desired results.

Stay away from automated graphs and number crunching platforms, conditions change and numbers will not work out results the way you expect. It will never happen. Provide and share content instead, organize it in sprints, motivate people in meetings or videocalls, do it face to face and use a tool to share information and monitor progress. Do not pretend you can predict stuff with a tool, you wont' 90% of the time.

Attempting to control all aspects of a project assures the greatest chance of success, but you will never succeed at controlling everything. That's okay. Project plans represent your current thought, at any given time, about how the goals of the project will be achieved. Herogami is not about micro-management and control. No Gantts here or crap like that. It's about people, collaboration, sharing. Monitoring progress happens as a result of that.

In Herogami it happens like magic.

Grumpy Herogami, Architect
10 Aug 2016 Read more

You may walk into a frantic two-guys development shop or in a large bank's IT department with thousands of employees staring at their monitors and you'll see the same stuff all over places: post-it notes layed out on a board, indicating a project's progress. Agile and Kanban guarantee short, rapid developments and teams can switch gears in between sprints. Standups encourage transparency and allow managers to spot delays and other issues in near real-time. Cross-functional teams encourages teamwork. Heavy emphasis is placed on providing value to the user. Agile practices simply boost software development to the next level.

James Albertson, Customer Support
14 Mar 2016 Read more

Herogami got rid of moving parts, at last! Servers have been up and running for more than a year with no maintenance whatsoever apart from a couple upgrades, the beta period went super smooth and very few issues were traced and chased, meaning we entered the beta window with a stable software platform.

Since we're about to remove the beta flag from Herogami and start rolling in proper production mode, server got a major boost in terms of both physical as well as logical resources. Got a bunch of megafast solid state drives powering databases and appservers I/O. More memory and network bandwidth got added to improve response time and a general more efficient use of the overall system.

We're sure you'll notice: Herogami is now just freakin' fast!

Matt Nowson, Sysadmin
02 Feb 2016 Read more

In the next month Herogami will go down for a few days for some maintenance of its cloud infrastructure. This should take place towards the end of the month, we're currently testing the upgrade procedures but the overhaul will be a major one and cannot tell at this stage nor the date nor the duration of the upgrade. We'll do our best to limit service interruption but please be aware that we are still running in beta and some minor inconveniences may be expected.

Matt Nowson, Sysadmin
16 Sep 2015 Read more