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

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

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.

28 March 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:

www.agilealliance.org/resources/videos/women-in-agile-the-changing-face-of-agile

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!

08 March 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.

01 March 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.

26 September 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

17 September 2016 Read more

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 Herogami.com may help in the process, ya' never know.

12 September 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.

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

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.

05 March 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 Herogami.com.

02 December 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.

10 November 2015 Read more