WIP stands for Work In Progress aka work that has entered the development process but is not yet finished and available to a customer or user.

Whether or not your workflow management tools include a kanban board with a workflow process via an actual low-tech office wall or having digital agile software board like the ones in Herogami, you want to avoid having too much WIP on your team.

As a project owner or scrum master, if you allocate or allow too much WIP in a sprint, you may create too much waste or risk in the form of lagging partially completed work, or excessive waiting. Furthermore, excessive WIP will also cause blockages in your project due to obscure and hidden activities which will arise totally unplanned.

Different teams may adopt tailored workflows that provide different workstations. All workflows have one trait in common: work states are progressive. There is always an initial state, a final state, and a series of intermediate states that measure the progress of activities at a scale ranging from one team to another.

To exemplify here are a couple of workflow examples at the extremes of what we usually see in Agile teams.

First example (don't laugh, we've seen it happening):

New → Open → In Progress → Code Review → Code Committed → QA Ready → QA In Progress → QA Passed [or] QA Failed → UAT Ready → UAT In Progress → UAT Passed [or] UAT Failed → Closed/Done

We see the above actually happening in many teams: a complex workflow is one the first symptoms of organizations adopting Agile whithout being trained on the fact that any major change in their internal processes should aim at keeping things simple, actually to the very bare minimum. This is a very basic rule of change management in organizations of any size, yet it is outside the scope of this post, we will definitely reserve a post on this in the future.

A more simplified (and possibly recommended) view of this workflow process would look like this:

To Do → Doing → Done

Of course the latter workflow may not be the best workflow either, most likely it is too simplistic and may not reflect the actual status of the activities a task, a story or an issue is going through. Say, for instance, that an issue needs validation before being considered completed or “done”. In this case, the perfect workflow looks like:

To Do → Doing → Testing → Done

The above is what you actually find a the default workflow in every new project in Herogami. Of course in Herogami this can be totally customized on your needs by editing stories and issues workflow, even on a project basis.

In either workflow solution, it is in everyone’s best interest to protect the project success by limiting the number or items being processed at every step of the workflow: you want place WIP limits.

Before your sprint starts, you must be able to determine - based on the story points and team size - what the typical limits should be as per the agile team roles and team members.

These can then be calculated and factored to represent the overall WIP limits for your board to prevent too much clutter. However as you can guess, the comprehensive example above or any type similar to it, would be the most difficult one to set limits to, since the stories would be scattered everywhere across multiple statuses.

Like any complex procedure, it is best to break it down into smaller parts. A simplified board should be used as your dashboard view to get a consistently general view of progress.  Once you’ve scaled down your board as much as possible the WIP limits will become easier to manage. A notable mention is the status “Blocked” which can be shown with a more specific indication of which workflow the block occurrence came from, i.e. Blocked in Dev, Blocked in QA, or Blocked in UAT. This will further allow for a quick response to the blockages.

The example given above assumes workflow management processes are happening simultaneously, but it would certainly be more appropriate to create some workflows in later sprints or specific milestone date if you knew, for example, that UAT was coming at a much later time. The key is to keep it simple.

Grumpy Herogami, Architect
29 Jul 2017 Read more

In July 2017 the free trial duration period for Herogami will change from three months to 30 days.

We are making this change because our data shows that a 90 days trial period is unnecessarily long. Most users either subscribe on day 1 of the trial or they subscribe a few days after the trial period has ended when they are prompted to subscribe when attempting to log in.

If you feel need more than 30 days to try out Herogami, or if you have any other questions regarding the trial period or all available upgrade options, please do not hesitate to write to our customer service team at support@venticentistudio.it and request an extension of your trial period.

We're happy to recap all relevant details on how Herogami subscriptions work.

You initially subscribe to Herogami with a free plan, so that it's easy for you to try our the app and check if it fits your team and workflow. The free plan provides a basic number of users and projects, it is a trial plan Herogami provides with no obligations whatsoever.
Once you're ready to jump in and bang hard on your projects, just upgrade from within the app, there's upgrade buttons more or less... everywhere :-)

Paid subscription plans are designed around two concepts: the size of your team and the number of projects you manage. Remember that advertised prices do apply to entire teams and not single team members.

When you spend say 99 Euros on a plan that covers you up to 100 users, you're basically spending less then 1 (one!) Euro per team member per month.

We are able to provide these highly convenient pricing scheme thanks to a massively scalable and elastic infrastructure running on very efficient code that optimizes both CPUs usage as well as data storage.

Thanks to its ease of use and perfect balance in terms of smart features and sheer power, during the new 30-days trial your team will soon gain the right confidence to move a consistent part of their workflow on Herogami. Enjoy!

Grumpy Herogami, Architect
22 Jul 2017 Read more

Software projects fail for a number of countless factors. One of these is that requirements are incorrectly captured, not fully expressed, shared and understood by all actors involved in the project.

In this post, we review an ideal set of best practices to manage your requirements, expand them in user stories and make sure that every member of your team fully understands them.

Requirements are usually captured in work sessions where all project participants (or in less fortunate cases only key figures) gather in a meeting room with a large whiteboard, a few chairs and countless post-its.

From such meetings, you can generally expect a positive outcome: the overall requirements are first discussed and then dissected. Most likely, after a few hours, everyone leaving the room feels like the meeting was great and everyone is convinced just had a great start, paving the road to success.

The truth is that this meeting is simply the first step of a long series which, most often than not, will not end as expected. Let's see why.

Problem #1 is that, following the meeting, all requirements get transcribed in some long document that no one will really read carefully. The document will be too long and too bureaucratic. It will be plagued by version numbers, indexes and blank, unused spaces. Even worse, it won’t have pictures in it, it won’t be visual enough!

Often the definition of the requirement is in fact tasked to the project owner that being a managerial role may not have the graphics skills to represent an effective synthesis of the solution in a few key images. Most likely a wireframe will also lack.

The project owner therefore issues a super-verbose document where the requirement becomes a classy topic that no one will really read carefully. Or rather, if business users may also have the maturity to do so, the weak link reveals itself to the development team that somehow looks superficial to the written requirements, interprets them quickly, and puts the code on the job.

Problem #2 is that project owners rarely consider the opportunity to collect feedback from project actors in a proactive way, often relying on silence-consent: me the project owner I have sent you a beefy requirements document and since I cannot baby-sit you for you comments, if you do not send me a response within a number of days, I will just consider that the formulation of the requirement is accepted. And that's a big mistake.

Requirements, once transcribed, should be presented in a highly visual document, with images and diagrams and approval from all team members should be actively seek'd out.

The trick to effectively invite people to read your documents and provide feedback is to forget conventional approaches and write your specifications like you were writing a software manual. To do this you can use Herogami's wiki, we'll see that soon in part 2 of this long post.

James Albertson, Customer Support
16 Jul 2017 Read more

On Saturday, June 17, 2017 the new Herogami got pushed to cloud servers This update is not a simple facelift but rather a deep refinement of the application and service to get even closer to the initial design and intent of Herogami. 

Herogami is a project management platform dedicated to software developers. Its philosophy has always been to provide the set of features that make sense in the everyday life of a software development team and to support developers first, the actual folks that implement the d***n thing and not necessarily the managerial bean-counting side of the process. This translates into features that make sense to those who do the job and into tools that never get in the way with far-too-intricate configurations and fixed workflows.

A quick recap of what you'll will find in this release.

The Herogami application gets a complete redesign to increase the visibility of the essential UI elements and increase overall clarity. Less fuss and less frills. More emphasis on the important elements of the user interface like its menus and its commands. Defer to content is the guiding principle and content therefore gets all the space it deserves.

The new burndown chart in the project dashboard reports the trend of the current sprint. Both for stories and issues. We have worked to ensure quick access to the definition of sprint duration, which you can edit directly from the burndown chart.

New dashboard for the current sprint and your backlog. The dashboard highlight and summarize the trend of activities in the current sprint and the composition of the backlog, with particular regards to project priorities. Both dashboards include numerous graphic elements for immediate understanding of the progress of your projects.

New calendar widget in the project dashboard. The new widget highlights the beginning and end of stories and issues, as well as the start and end of sprints and other scheduled events.

Numerous bug fixes and general system performance enhancements. Each release is a very important opportunity to improve the quality of the software and even on this occasion we have not missed the option of making improvements.

The Tasks section is removed. Most of our users requested that Herogami adheres to Agile practices where stories and issues capture planned activities in projects, making other entities such as tasks or to-do's basically irrelevant. Hence the removal. Please contact customer service to get the link to the section and migrate Task in Stories or Issues, accordingly.

We look forward to know what our users think of the new update. Do you like what you see? Please let un know your thoughts by dropping a line at support@venticentostudio.it.

Matt Nowson, Sysadmin
17 Jun 2017 Read more

A few hours left before Herogami gets the planned update we've been worked on for months. Tweets and alerts have been posted so that you, customers, partners and friends, get all your stuff in order before we actually pull the trigger of the many update scripts. Ok there's going to be a few minutes of downtime and speaking of update scripts, actually we're talking lots and lots of scripts here, since the Herogami infrastructure is nothing short of a candyland of servers and contemporary cloud services!

For your convenience here's a a quick recap on what's coming. Nothing new if you've followed the blog and announcements posted inside Herogami but we thought it'd be cool to make sure you are aligned.

New public website, reflecting our commitment to the software development community and the joy of writing software. It's gonna celebrate an act of creation and having fun doing it with others through Agile collaboration.

New layout of the Herogami application that clears out the workspace and truly introduces a new design principle: defer to content. Which translates into focusing on the essential and hide the frills.

Revised project dashboard and a dedicated dashboard to the current sprint which includes the burndown and more charts. All dashboards in fact include numerous graphic elements for immediate understanding of the progress of your projects.

New calendar widget in the project dashboard. The new widget highlights the beginning and end of stories and issues, as well as the start and end of sprints and other scheduled events.

Bug fixes and general system performance enhancements. Releasing software is an opportunity to improve it. We did not miss on that.

We simplified the application by removing the Tasks Section to better adhere to Agile practices. If you're used to Tasks please note that the section will still be available although hidden, contact customer service to get the link to the section and migrate Task in Stories or Issues, accordingly.

See you soon on the new, updated Herogami. Pssss: every version of Herogami has a codename which is either funny, clever or both and will be revealed in the next post, with the new Herogami up and running  :-)

Grumpy Herogami, Architect
16 Jun 2017 Read more

Friday, June 16, 2017 we plan to release an important update of Herogami.

Herogami's public site gets a major facelift. Herogami is a platform dedicated to software developers. Software professionals are a weird species: we take pleasure in our work and enjoy playing with complex architectures and conceptual problems. The new public website celebrates the craft and the importance of doing great work together.

The Herogami application gets a complete redesign to increase the visibility of the essential UI elements and increase overall clarity. Less fuss and less frills. More emphasis on the important elements of the user interface like its menus and its commands. Defer to content is the guiding principle and content therefore gets all the space it deserves.

The new burndown chart in the project dashboard reports the trend of the current sprint. Both for stories and issues. We have worked to ensure quick access to the definition of sprint duration, which you can edit directly from the burndown chart.

New dashboard for the current sprint and your backlog. The dashboard highlight and summarize the trend of activities in the current sprint and the composition of the backlog, with particular regards to project priorities. Both dashboards include numerous graphic elements for immediate understanding of the progress of your projects.

New calendar widget in the project dashboard. The new widget highlights the beginning and end of stories and issues, as well as the start and end of sprints and other scheduled events.

Numerous bug fixes and general system performance enhancements. Each release is a very important opportunity to improve the quality of the software and even on this occasion we have not missed the option of making improvements.

The Tasks section is removed. Most of our users requested that Herogami adheres to Agile practices where stories and issues capture planned activities in projects, making other entities such as tasks or to-do's basically irrelevant. Hence the removal. We don't miss them but for customers that we're used to Tasks, the section will still be available although hidden: please contact customer service to get the link to the section and migrate Task in Stories or Issues, accordingly.

In the latest months, our team has performed all the tests required to avoid regressions and ensure a quick and smooth transition to the new platform. We look forward to knowing what Herogami users think.

Stay tuned for important updates, then, in the next couple of days. We hope you will enjoy them as much as we are already doing. Herogami has always been faithful to the vision of providing powerful yet very easy to use software that does not require complex configuration and administration tasks like many of competing products.

Herogami's guiding design principle is there's no time to read he f***ing manual. We have made every effort to guarantee our customers that Herogami reflects this vision in the next coming update and in the years to come.

Grumpy Herogami, Architect
14 Jun 2017 Read more

For many project owners and scrum masters, the sprint review (aka the demonstration and review of a sprint outcome) is one of the few chances they have to see their direct reports functioning with their Agile team and to witness the outcome of their work.

One of the most interesting side-effects of sprint reviews is that they act as the monitor of the health of an agile team: positive or critical dynamics and interactions among team members can often be revealed by observing this session. Hence, sprint reviews can truly act as thermometers of Agile teams and optimal interactions.

Healthy Agile teams dynamics revolve around three fundamental fulcrums of smart collaboration, here at Herogami and when consulting for customers we happily run a joke around the C letter and call them the Three C Vitamins of Agile collaboration. Here they are:

The first C stands for Connection between members. One can observe if the team is moving as one unit and just how well the members of the team are interacting with each other. Is one role or person particularly quieter than another? Does the relationship between developers and testers feel collaborative or contentious? Many of the best sprint reviews I participated in have a celebratory feel to them. The team collectively feels they are working on something meaningful and making significant progress towards the product vision. Hopefully, you sense this vibe.

The second C stands for Conversation around the product. The conversations in a sprint review should revolve around the product backlog and specifically around the value users should be receiving by finishing items in the backlog. This happens best when the team focuses on the acceptance criteria while they are demonstrating delivered value. The acceptance criteria is often the “script” for the demo. Otherwise, the demonstration tends to wander, making acceptance of the user story as complete quite challenging. Healthy conversation from the product owner about what’s on the horizon for their product is also a good sign.

The third C stands for Completion. Similarly, I have experienced some painful sprint reviews when the team is obviously not ready to demonstrate a completed story. For a story to be done, it should be in a state of potentially releasing it into production today should the product owner deem it ready. If this is not the case, something is amiss.

If, as a project owner or team member, you feel that one of the above “C’s” is not properly shaped in your team, take a deep breath and prepare to change something. Here’s a few hints, given the vast array   want to consider 

1. Make sure you have enough seniority in your Scrum master. The scrum master doesn’t have to be a technical genius but should be someone who understands which roles need to be filled in the team and how to find help for any impediments team members may encounter. They are not there to tell the team how to do their jobs, but to help them with whatever the team members need to make sure the job gets done.

2. Be consistent. Either Scrum or not Scrum at all. Don’t scrum haphazardly. Most teams approach Agile by tailoring practices to their habits. This works so-so. Even if you don’t feel like “scrum” is being done exactly right, continuing to push through the process builds confidence across the team. 

3. Do not skip Daily Stand Up Meetings (or let people sit). The Stand-ups ritual are there for a reason, the stand-up should always start with an energetic, “Yay-team!” attitude. Turn all phones off, this is really important if sales and marketing people are involved in the meeting

4. Never skip sprint reviews. If attending daily stand ups and weekly sprint planning is important to empower the execution phase,  retrospectives should not be negotiable. Attendance and engagement is most important for consistency. To make sure your team members start leaning into the practice of reviewing their work together, you may consider shortening the length of your Sprints from two-three weeks to four-five days, at least at the beginning of the project.

Teams moving to an Agile approach often complain about the number of meetings they must now attend. Planning sessions, daily stand-ups, sprint reviews, retrospectives, and product backlog grooming are now populating their calendar and they wonder when they will actually have time to work. Worry about this later, straighten your C’s first.

Grumpy Herogami, Architect
18 May 2017 Read more

A rather common misstep for Agile “beginners” it to lead sprint reviews by relying on team members’ personal opinions and bias when discussing what went well, and what not, at the end of each sprint. Sprint reviews can become completely irrelevant experiences when teams do not stick to data and actual facts, in particular in the context of Kaizen, aka when trying to assess what can be done better. 

Project progress and continuos improvement or Kaizen do not need your opinions and feelings: they need facts and hard data. As scrum master, you want to drive your sprint reviews skipping opinions and leveraging instead data and actual facts. 


Here's a recipe for the perfect sprint review by using Herogami.

1. Powerpoint Herogami Lighboxes

At sprint completion you want to visually summarize the sprint content in a very compact fashion. The typical Kanban column-split view may not be space-efficient, to avoid wasting projector space select View / Lightbox in your Issues or Stories View menu. In case there’s too many cards to see at once, group them to minify the cards.

2. Demonstrate the actual working product

Show the working product increment to the Product Owner and everyone else who is interested. The meeting should feature a live demonstration, not a report.

3. Visualize “done” with Herogami colored cards

After the demonstration, the Product Owner declares which items he now considers done. For example, a software item that is merely “code complete” is considered not done, because untested software isn’t shippable. Incomplete items are returned to the Backlog as candidates for future Sprints. In the Lightbox view, Herogami automatically mark any “in-progress” item with a color tag to support a better visual understanding of this process.

4. Leverage Herogami’s Wiki as the project blog

Create a new wiki type for your project and call it “project blog” and regularly enter comments and notes about the project progress, team feelings or contingencies. Review the project blog with your peers and stakeholders to recall specific episodes.

5. Record every sprint review in the Herogami Wiki

Herogami already provides a built-in wiki type called “sprint review”. Create a wiki article and set its type accordingly. Having the sprint review report in Herogami will help you keep a history of your projects’ reviews close to their planning.

As a final note, please remember that sprint review meetings are appropriate not only for team members to attend but also for external stakeholders and even end users. It is possibly the best opportunity to inspect and adapt the product as it grows from its embryo and progressively refine everyone’s understanding of the requirements. 

New products, particularly software products, may be hard to visualize on written documents and drawings. The majority of the end users need to be able to see a piece of functioning software to discover what they actually want. At your next sprint review meeting make sure you bring them on board.

Grumpy Herogami, Architect
28 Mar 2017 Read more

According to a paper from Ken H. Judy published in 2007 by Simon & Schuster analyzing data from the US Bureau of Labor Statistics (BLS), in 2007 women represented 46% of the overall US workforce but only 30% of Information Technology (IT) workers and less than 25% of software developers. In the same years, those numbers were to cut in half in Europe and went down to tiny fractions in the rest of the world.

But things have started to change most recently and there’s some good news around the corner. With software-related technologies becoming more pervasive and mainstream, the number of girls and women involved in software development activities has significantly increased in the last 3-5 years and the trend is growing fast. 

Brand new initiatives devoted to women in tech such as Girls Who Code and Women Who Code are raising awareness on the increasing female presence in software development teams at all levels. We are now seeing a growing number of women covering management positions as well as in project management and software development roles.

Software development is an attractive career for women that can provide a flexible working schedule, gratifying and creative solo tasks as well as team-oriented activities. It’s a career path that can take you to very technical, interesting and specialized paths as well as more generic duties such as project coordination and people management.

Given the high demand for software developers these days and the investment every software company devotes to growing and keeping their tech staff, software-related career paths have proven to be an incredible opportunity for women in third-world countries to fight discrimination of gender and gain respect of their families and communities through recognition of their professional abilities and economic independence. This is clearly evident in countries such as India, Pakistan and middle-east nations where a growing number of women are taking active roles in tech companies.

Paired with the increasing presence of women in software development, we of course observe a growing presence of women in Agile development teams and Agile leadership roles such as product owners, Agile mentors and groups coordinators.

Agile Alliance has published the video report of their amazing 2016 Women in Agile conference and it’s just amazing to see and listen to passionate speeches on what are effectively engineering practices, check it out at:


Held by women for women, the conference offers a truly refreshing perspective from the quite usual gathering of Agile and Scrum geeks!

Women can play a major role in helping Agile teams achieve results while keeping a happy pace because of inherent qualities they can bring to the highly competitive sector of software development:

- Resilience to stressful situations

- Networking and relationship building

- Problem solving and practical attitude

- Natural creativity and design thinking 

- Collaboration over negotiation

We therefore encourage women to believe in theirselves and continue to bring diversity to software development by getting involved in Agile teams, share their experience, skills and contacts, and encourage other women to connect and get more exposure to the opportunities the Agile world has to offer.

Keep it up, girls!

The Herogami crew wishes a happy Women’s Day to all girls and women that make happiness bloom all around them!

Grumpy Herogami, Architect
08 Mar 2017 Read more

If you’re new to Herogami, just getting your feet wet using the tool, and are wondering what productivity tricks there are in the software that can make you a more efficient worker, then this post is for you. We’ve collected 4 of the best tips and tricks so you can turbocharge the way you work in Herogami. Read on!

Remember to mark the current sprint as starred

Enter a project and select menu More / Sprints to list all planned sprints for the project. You’ll notice that, by rolling the mouse over the leftmost column a blue star symbol will lighten up. Clic on the star to make that sprint current and have it as the default option for all your filters and data entry panel.

The current sprint is also summarized in the project dashboard, it is therefore a good practice to set sprints as current as your projects progress.

Share information on the Project Wiki

Teams, nowadays, have an amazing choice of tools to share information on projects and their functional or technical aspects, escaping the e-mail attachment plague that has characterized pre-cloud ages. We see companies using Google Drive, Dropbox, iCloud and file storage services of various sorts.

But sometimes you want to keep the information very close to the project campfire of Herogami and the Wiki provides an amazing tool for this task. Entering posts in the Herogami Wiki is a breeze with the stylized input frame which, by the way, also accepts images flowing along body text.

Wiki posts can be easily categorized with no limits whatsoever on the number of categories or types. Say you create a support category to record first and second-level support practices or and getting on-board category to collect information for future developers what the project is about and how its mechanics work. 

Documents in separate tool are work too but, being so close to your actual planning tasks, for information like this there is no better place than the Herogami Wiki.

Enter effort to improve sprint reviews

Herogami provides a hefty set of fields to estimate and track effort. When editing stories and issues you’ll notice that section Effort Estimates and Tracking lists a fields for estimation of effort and dates and for tracking the actual effort / dates reached at completion.

The estimate fields contains previsional data, while actual fields are reserved for ex post input. When starting a sprint, make sure you enter the estimate effort and dates, then fill the actual devoted effort and reached dates when closing the item. Your team has the option of downloading such data using the Export feature found at the bottom of all Kanban boards and review consistently any gaps between estimate and actual efforts and date to improve the outcome of future planning activities. 

Notify team members of your comments with @email

You may need to clarify the content of a story or report that an issue is hard to reproduce. The quickest way to keep track of every aspect of your work is to enter a comment into the Notes section of issues and stories. Herogami will record all your comment and even offer the option to share your comment with one or more of your peers on the project.

When entering a note, hit the @ character on your keyboard to open a popup menu listing all your team mates. Select one or more names to have their name entered like @email in your note, Herogami will immediately send the note all selected peers.

Grumpy Herogami, Architect
01 Mar 2017 Read more

Under the right conditions Scrum can be a tremendous success story, but it often requires hard work to get there. For new Scrum teams it means learning to fundamentally work very differently than they are used to, such as relying on a lot more collaboration, making and delivering on shared commitments and building a high degree of trust. For existing Scrum teams it means constantly renewing the team commitment to each other, the cause, and to the Scrum framework.

This includes the rather painful practice of revisiting the fundamentals and ensuring any deviations from accepted processes or practices were for the right reasons and had the right results. To have a chance at achieving high performance a new-to-Scrum team will not only need to just change their processes, but fundamentally change the culture and behavior of the team and all of the supporting roles (that includes their leadership).

Meanwhile, a mature or well-established team should never assume they are high performance; they should always be checking (and rechecking) that they are still living the Agile values. Needless to say this can become an extremely complex challenge! To be absolutely clear, I’m not proposing there is a single formula or recipe that works, but I do believe certain criteria can dramatically improve your Scrum team’s chances of success. To that end here are 10 tips (plus a bonus) that may help you focus your efforts towards building a successful Scrum team and experience.

One of aspects of a successful Scrum-driven project is having the right number or team members and well defined roles.

Currently the Scrum Guide recommends that Scrum teams will work best with three to nine people, not including the Scrum Master and Product Owner.  Enter your project dashboard, scroll down to Team Member and clic on the Add button to start adding people to your project. If you run out of users, Herogami provides you with a shortcut to create a new user and have it allocated immediately to the project team.

Herogami provides you with four team roles on your project, all with different privileges, roles and visibility on the project content.

Owner: that’s the product owner (and often the Scrum Master too) which controls the project

Developer: a developer consumes stories or issues and creates them as well

Tester: you can identify a given member as a tester too

Guest: this user will only see public content of the project, aka every single item on Herogami, from stories to issues, from documents to wiki articles and even calendar events can be marked as private. As such, only the team members see them, therefore they are invisible to guests.

Having issues marked as private and being therefore invisibile to guest members provides lots of advantages. First and foremost you give your team the ability to track every critical aspect of the project, every complex story and especially complex or blocking issues on Herogami without guests knowing about it.

In a scenario where the development team invites a few people from the customer’s staff and register them as guests, the benefits are obvious: the team handles the most internal issues by keeping them private and let their customer focus on highly visibile ones.

Grumpy Herogami, Architect
26 Sep 2016 Read more

400 participants and 50 nationwide-level speakers get together in one of the most beautiful event venues in the world, the University of Ca' Foscari in the heart of Venice, to explore benefits of Agile methodologies across all businesses.

We are crazily excited to announce that Herogami is sponsoring the initiative!

The Agile ecosystem in Italy is facing a momentum of significant growth, organizations and businesses at all levels are progressively realizing the benefits of contemporary lean methodologies and continuous improvement processes.

Herogami offers a unique opportunities to teams and companies that start experiencing the most  commonly used tactics for visually communicating content and progress of Agile projects. Herogami  does not require complex setup, it is easy to use and provide a complete set of tracking, collaboration and sharing tools.

Agile Business Day 2016 explores the business benefits and challenges posed in adopting Agile methodologies in businesses and companies, in non-profit organizations and in the public-sector. The focus of the conference revolves around the theme of innovative organizations and how to engage the best people in the organization to increase the rate of innovation and ensure both quality and economic sustainability.

Agile Business Day is a unique opportunity to share ideas and best practices and is not reserved to limited to industry experts or Agile professionals: Agile newcomers are definitely most welcome too!

Checkout the event website at http://www.agilebusinessday.com or follow the live streaming video on YouTube at https://youtu.be/9blsprjxWRU

Grumpy Herogami, Architect
17 Sep 2016 Read more