The airplane blog

Stay updated on the latest trends of the agile world and discover new features of Herogami!

The airplane blog breeds Agile culture and spreads buzz on the coolest Kanban platform in town, right from the guys that envisioned it.

Try it now!
All Posts Agile Herogami Team

ABD On Tour is the new nationwide Italian initiative delivering workshops led by proven Agile professionals to companies and organizations looking to adopt an Agile twist.

Industry-leading coaches and speakers share their knowledge of the Agile domain at all levels, from project management practices to lean collaboration and coherent teamwork habits, all designed to make teams and organizations achieve results by improving transparency, lower stress and deliver verifiable output.

ABD On Tour sessions target professionals wanting to improve their knowledge and expertise of Agile and are hosted at the premises of major Italian companies and brands such as Lotto, Pagani (yes, the Zonda car maker!) and more.

Herogami was main sponsor of the January workshop focusing on Kanban, hosted at the H-FARM headquarters in Treviso, one of the leading Italian startup accelerators.

The event took place on a cozy Saturday morning in the beautiful contemporary buildings of H-CAMPUS, a H-FARM company bridging opportunities that modern digital technologies provide to students of all ages.

H-CAMPUS and H-International School programs are designed to promote an educational path where knowledge is gained through a hands-on approach, through direct contact wth the most advanced technology and through an innovative teaching methodology that aims to cultivate knowledgeable, sensitive, attentive, curious and well prepared students of all ages.

The workshop led by Gaetano Mazzanti from Agile42, the international company specializing in Agile mentoring. Gaetano, a proven Agile coach interfacing all levels in complex international organizations, delivered a great 360-degrees overview of the best Kanban practices. In a relaxed atmosphere and supported by an attentive audience, Gaetano shared the effectiveness of the pull Vs push teamwork approach, cards layouts tactics, story planning strategies, priority management threats as well as non-conventional KPI and charts to measure project progress and team efficiency.

All participants received a 12 months coupon to try out Herogami digital Kanban boards and granting access to all major features, such as:

- Projects portfolio management
- Project Kanban boards with multiple views
- Customizable workflows for stories and issues
- WIP limits at each step of the process
- Full team activity tracking in the Project Timeline
- Shared Wiki for recording meetings, retrospectives and more
- Project Calendar linked to dates in Kanban cards
- Automatic emails and smart comments notifications

A week or so from the event, we are already seeing the adoption of Herogami among participants: newly registered teams got up to speed in a snap and are now appreciating the ease of use of Herogami and its balanced ergonomics allowing teams to tailor Agile practices on their own methods. Herogami supports the process without forcing a specific process or mindset, providing the just-about-right foundation for teams to deliver successful projects.

Of course we’d love to see these new teams leverage the full potential of Herogami. Here’s a glimpse of our PRO and PREMIUM plans.

- Backlog creation via e-mails from stakeholders and guests, product owners should not spend their day typing on their laptops keyboards, there’s a world of interviews and meetings to attend!

- Linking stories and issues to your source code repositories and review committed files and comments from within Herogami.

- RESTful APIs to integrate external systems such as third-party ticketing systems, timesheet databases, reporting tools and more.

- Full download of the team activity log from a given sprint for retrospectives and other review sessions, have you ever wondered the average time your cards spend sitting in the leftmost column on your Kanban board before being put to work?

And, last but not least, extended cloud storage, first class support, customization of PrivateCloud instances, on-premises installations, training programs and more.

Acting as main sponsor, a tiny bunch from the Herogami Crew attended the event and, to say it out loud, it was just great! We definitely spend far too much time in our cloud made of servers and compilers: what a refreshing break getting our feet on the ground (actually on the shiny green soft lawn of H-CAMPUS!) for a day. Also, sharing interest and curiosity for all-Agile topics with Gaetano and all participants has been an extremely rewarding opportunity.

We wish the ABD On Tour initiative, Gaetano Mazzanti and Agile42 as well as H-CAMPUS the success they deserve, they are fast-lane players in the creation of a new global project management culture. A more human-centered project management culture Herogami and our thirteen-thousand registered customers from more than twenty countries are part of, already.

01 February 2018 Read more

Limiting WIP is an integral part of a well-designed Agile process. Increasing the workload of your team will not make your project delivery process any faster, unexpectedly filling your pipeline with a number of tasks proportional to your team velocity will.

A good measure of your peers ability to process and complete a task is to measure the time a given task goes through the columns of your kanban. Is it taking one day? Three days? More? Since Herogami tracks all events occurring on your cards on the project timeline, you can export the timeline and filter for relevant tasks and events, including timestamps.

By carefully analyzing the exported timeline in a spreadsheet you can easily gather the average number of tasks being processed at every step of your process. This gives you and your team a good measure of the maximum number of tasks that can sit at each step, aka your WIP limit.

To make sure your team complies with its velocity and avoid overallocation that would clog the process, make WIP limits explicits in Herogami.

Enter the Stories Statuses menu and edit a stage of the process, say the DOING stage that hosts tasks currently in development, and enter a number in the Limit WIP field. Say that you’ve established that your team can only process 5 tasks at any given time. Enter 5.

From then on, Herogami will mark the DOING column red whenever the WIP limit is passed, flagging the whole team that the maximum number of tasks to be carried over has passed your team’s ability to work them through.

Since Herogami provides dedicated workflow for stories and issues, limiting WIP in a story state will not affect issues. Act accordingly on issues statuses if you need so.

23 January 2018 Read more

What’s the best way to manage a project? Like with most things, the answer is: it depends as each project has requirements. This is where knowledge of project management methodologies comes in hand as it can help project managers figure out the best approach. To this end, we put together an article about the most popular project management methodologies. But first…

What’s a project management methodology?

Briefly, a project management methodology is a systematic approach to designing, executing and delivering a project. Project management methodology is a clearly defined combination of related practices, methods, and processes which determine how to best manage workload. It is a model for planning and achieving task goals.

Project management methodologies guide the team through all the phases of a project, with guidance on processes and tasks. These start with help in planning, initiation and implementation, all the way to closure. By providing clear guidance with in-depth descriptions for every step, project management methodologies help teams reduce risks and avoid failure.

Top 5 project management methodologies

While there are over 17+ project management methodologies, the ones listed below are the most popular.

Waterfall project management

The waterfall project management methodology is a sequential process. According to it, progress is seen as result flowing from previous steps. This project management methodology was first outlined in the 1950s. Still, the first use of the official “waterfall” name wasn’t until 1976 in a paper written by Bell and Thayer.

The initial waterfall model has 6 main stages:

1. Outlining and documenting requirements

2. Analysis

3. Design & conception

4. Development

5. Testing/Quality assurance

6. Maintenance

As soon as each step is completed, reviewed and verified, project managers can move forward to the next step. Since waterfall implies a sequence of steps, you cannot go back to a previous step without starting all over from the beginning. This leaves little room for change, so outcomes and a very detailed plan need to be established early on then followed closely.

One of the strong points in waterfall project management methodology is that is stresses rigorous documentation – for example requirements or design document, along with source code. This way, project knowledge can be easily passed on to new team members – in case anyone leaves the project before completion.

Also, because it moves forward in a linear way, projects planned using waterfall are easy to understand and its phases are pretty much self-explanatory. It’s also easy to identify project milestones as moving forward always implies completing a step.

On the downside, in waterfall, you cannot go back to an earlier step to make changes. Also, if the initial requirements are faulty, the result is pretty much doomed, too. Additionally, waterfall leaves little room for changing or evolving needs. If client needs and demands change, projects will take longer and more money to complete. Also, testing or quality assurance take place only further down the line, which makes it harder to detect bugs and predict their overall impact.

Waterfall project management is recommended for projects with fixed scope and requirements or for fixed and stable projects with little change. Also, once the requirements are established, projects that run on waterfall don’t need extensive client presence.

Agile project management

Agile project management came about as a response to rapidly changing demands in software development. Since waterfall doesn’t do a good job accommodating changes, agile stepped in to address these constantly changing needs.

Compared to waterfall, which is linear, agile project management takes an iterative approach to managing tasks and processes. It stems from Toyota’s lean manufacturing approach in the 1940s. Agile focuses on ongoing improvement through continuous releases. Also, it incorporates feedback from previous versions in every new iteration. Speed, team input and delivering high-quality work are all key characteristics of agile project management.

Agile project management grew on software developers quickly as it helps reduce waste and it increases transparency. Also, with continuous releases, agile pushes teams to collaborate and to innovate faster.

Agile project management is based on four core values:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

Besides the 4 core values, Agile also uses a list of 12 principles on matters of collaboration and self-organization. All these are covered in the Agile manifesto.

Agile has won praise because it allows for faster development while reducing waste of resources. Also, it has increased flexibility and is more adaptive to change, making it easier to focus efforts on a specific goal. Agile also allows for quick detection of issues and potential bugs, thus optimizing the development process. It also allows for increased collaboration and feedback and it puts customer needs at the forefront.

Scrum project management

There is a lot of confusion between Scrum and Agile. While Agile refers to a set of methods and principles, Scrum is a framework used to implement Agile methodology

In Scrum, teams work in iterative cycles called sprints. The product owner, the person in charge of creating the product outlines the product vision statement, product roadmap and the project backlog. Along with the development team, the product owner plans what will be delivered at the end of each sprint.

Once a new sprint begins, teams hold short, daily meetings. Here, each tells about what they’re working on and if they have encountered challenges. At the end of each sprint, there is a sprint review that demos the completed work. Next are sprint retrospectives where the team evaluates their way of working and discusses potential problems.

In Scrum, progress needs to be transparent and easily measurable. To this end, teams use six documents to outline requirements and track progress. These are:

1. Project vision statement: a document that outlines the main goals of the project

2. Project roadmap: a high-level overview or project requirements, along with a timeframe and milestones for delivery.

3. Project backlog: this is a list of all the tasks that need to be completed, ordered by priority.

4. Release plan: A high-level timeline for releases

5. Sprint backlog: A list of goals and task associated with the current sprints.

Implementing Scrum can be easily done with spreadsheets or post-its. That can work well for small teams that share a location. For remote or distributed teams, project managers need proper tools to make ensure transparency. Herogami allow project managers to run projects in Scrum effectively.

PRINCE2 project management

PRINCE2 stands for PRojects IN Controlled Environments. It is a process-based method for managing projects. Initially used by the UK government, the first framework for PRINCE was developed in the 1980s. After its approach was reviewed and updated in 1996, PRINCE2 became popular across a variety of industries, both in the UK and internationally.

As a project management methodology, PRINCE2 has 5 key features:

1. Focus on business justification

2. Defined organisation structure for the project management team

3. Product-based planning approach

4. Emphasis on dividing the project into manageable and controllable stages

5. Flexibility that can be applied at a level appropriate to the project.

Since it is a process-based approach, PRINCE2 is governed by principles that control the entire process from start to finish. These make sure that each stage is clearly structured and that there are no loose ends when completing a project. The 6 rules of PRINCE2 are:

1. All processes must have a clear business justification. They need to serve a clear need, a realistic customer and defined benefits.

2. Project teams should learn at every stage. Every step provides lessons that are recorded and that can be used to improve in the future.

3. Clearly defined roles and responsibilities. Every team member should know what they and their mates are responsible for.

4. Planning is done in stages. Tasks are splitted into individual phases, with specific milestones and checkups to confirm that everything is on track and according to requirements.

5. Project boards manage by exception. Generally, once the requirements are set, project managers have the authority to manage a project without additional input from senior management. However, if issues come up, they can be considered an exception and involve senior management.

6. Teams need to constantly keep an eye on quality, checking against requirements

In PRINCE2 there are also 7 stages: starting up, directing, initiating a project, controlling a stage, managing project delivery, managing stage boundaries and closing the project. Additionally, there are 5 roles: the customer, the user (can sometimes be the same as the customer), the supplier, the project manager, the team manager and the administrator.

Compared to previous project management methodologies, PRINCE2 requires experience in order to be implemented. What’s more, there are also available courses that allow project managers to get certification with this methodology.

Kanban project management

Kanban project management was conceived by a Toyota engineer back in 1953. Compared to other project management methodologies, it focuses more on visualizing the workflow in order to balance demand and spot potential bottlenecks.

In Kanban, work is divided into specific stages and steps. Each team member does his/her work then passes the task forward for the next stage to be completed. Kanban is somehow similar to a factory floor where a piece of metal goes through a series of steps to be turned into a finished part.

Kanban requires project managers to define each stage of the workflow. Also, project managers need a system to get a task from one stage to the other. While this sounds easier for physical goods, for knowledge work is can be something like cards – virtual or real. As work on the task progresses, the card is moved to different lists.

Kanban focuses on managing output and efficiency. By doing one thing at a time, it allows project managers to estimate better the workload a specific team member can deliver. Additionally, Kanban is pretty flexible, with only four guiding principles:

1. Cards (Kanban translates to “visual card”): Each task has a card with all the relevant information needed to complete the tas

2. Cap on work in progress: To avoid burnout, project managers need to limit how many cards are in play at once

3. Continuous Flow: Prioritize according to importance and make sure there always is a workload

4. Constant improvement: Analyze the flow to determine efficiency and what can be improved

Compared to other project management methodologies, Kanban is a bit more laid back. With no sprints, assigned roles or specific milestones, team members can focus freely on the task at hand. Also, meetings are defined according to team needs, instead of regular process meetings.

Like Scrum, Kanban is great for teams that don’t need a lot of management and are self-motivated. It can also help project managers focus on efficiency, thus saving resources. If project managers are careful not to overload, projects can be completed in time and within budget. However, Kanban works best where skills are evenly distributed, sometimes overlapping in a team. If one team member has a specific in-demand skill, that can hold up the project.

12 October 2017 Read more

Herogami is silver sponsor of the Agile Business Day conference to be held in Venice, Italy, on 16th September 2017.

The event is a boost and a must for any Agile practitioner in the country. More than 400 participants and 50 nationwide-level speakers will 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 in business-related contexts.

For the second year in a row, 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 unique opportunities to teams and companies that start experiencing the most commonly Agile tactics for visually communicating content and progress in Agile projects. Herogami does not require complex setup, it is easy to use and provide a complete set of tracking, collaboration and sharing features.

Agile Business Day 2017 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

15 September 2017 Read more

A quick recap from part 1 (you can read the entire post here). This post aims at clarifying the role and responsibilities of a project owner with regards to projects requirements, which are not to be confused with user stories. The latter is in fact a representation of those requirements that intermediate the communication between business stakeholders and the development team.

With these premises, let’s go back to our initial goal: given a set of requirements capture in one or more meetings and interviews (well detailed in part 1), let’s make sure that your development team deliver exactly what your stakeholders ask for.

We have designed an ideal workflow to manage the complete lifecycle of your requirements.

1. Capture the real pain (aka do not believe your users’ first version)

The goal is to understand the real pain experienced by users which your project is aiming to solve and this can be achieved by, well, not believing what they say they want in first place. Business users will not be nearly pragmatic enough to define a requirement with all details, in most cases they will report a set of daily manual activities which lead to some general rule that has a plethora of exceptions. The most appreciated soft-skill of a good project owner and/or analyst is to understand where the real pain of your business stakeholders sit and to derive from that the real general requirement.

An example? The business user asks for a new form to manage all the expense of the company. The truth is that they are managing them already (most likely with a lot of manual labor) and they want to automate the approval process. Actually, they’d love a system that, once approved, let them forget of all that paperwork forever! The process and therefore the requirement are different from what the user initially asks for, so the result that is being asked of the team will also be different.

2. Explode users' requirements in stories

Your users' requirements are then broken into many functional blocks, often interdependent, through an amplification activity. The team breaks each requirement into many discrete and manageable user stories. At this stage, effort can probably not be evaluated in detailed metrics such as man-hours, yet a pretty well-spread alternative is to assign stories an index of complexity such as story points, pomodoros or some other arbitrary effort indicators. Herogami supports story points as well as pomodoros, but also color-coding and other user-definable attributes.

3. Translate stories into tasks for techies

This is the easy part. It's about getting your development team in the cafeteria or some meeting room and discussing the details of the implementation. Try not to dive too much into details, leave something for other rounds as well: Agile tactics include shared responsibility and each developer is responsible for its area, therefore you as a project manager can avoid the risk of falling into micro-management traps.

The goal of this phase is to derive, for each story, the tasks that developers need to complete. Having a clear set of tasks for your stories helps your developers understanding problems before they occur. It also helps to properly estimate the duration of activities, so as to avoid any form of guessing. Every story in Herogami has an internal kanban for tasks and they are super quick to enter.

4. Define effort estimates and contingencies from information or technical debt

With the tasks defined it is easy to indicate the effort required by the various stories. The sum of the effect, net of parallel activities, will provide a release date for the first test or the sprint review. Sounds simple, right?

The point is, most likely, that your requirement is not entirely complete, so you have to handle an information debt that will surely result in additional unplanned effort. Here are no rules, the sensitivity of each professional varies but the rule is to add a good 20-30% contingent effort to cover the risk. In Herogami you can enter effort in man-hours or pomodoros, and due dates for stories and issues are clearly displayed on the shared project calendar.

5. Run stories in one or more sprints keeping an eye on WIP limits

Stories can be put into work by relocating them from the backlog to the current sprint. Developers will move the cards while performing tasks, and Herogami will provide a proper project and sprint status through dashboards and burndown charts. This is a fantastic tool to understand the trend of the sprint and it is very complicated to handle it manually. Fortunately, Herogami updates the current sprint burndown chart whenever an activity is performed on a story or issue, in a completely automatic and transparent way. Make sure you configure Herogami’s WIP limit at every step of your workflow to avoid overloading your developers. 

We’ll see two more points in the upcoming part three of this post and drive some conclusions on effective strategies to manage your business requirements and user stories with Herogami. Stay tuned!

 

30 July 2017 Read more

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.

29 July 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!

22 July 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.

16 July 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.

17 June 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  :-)

16 June 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.

14 June 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.

18 May 2017 Read more