The good news is that this is actually a trivial task to push tweets from Gemini given that we have a nice plug-in system that allows us to consume key events such as “issue created”.

So we set about creating the Gemini Twitter Plug-in and within a couple of hours we had a working solution…

Twitter Plug-in Development

Create your plug-in class and implement the AbstractIssueListener class:

Creating a simple plug-in class

Next up, we’ll create a simple configuration file that contains the Twitter login credentials:

Configuration file stores Twitter Login Credentials

Because our plug-in class implements the AbstractIssueListener class we get all those nice event handlers that we simply leverage to push out issue tweets.  The IssueEventArgs object contains the user who caused the event (e.g. issue reporter) and the issue itself.  So now it is very easy to gather and tweet the information:

Events exposed by Gemini Plug-in Framework

We’ll leverage the excellent TweetSharp library for talking to the Twitter API.  Here’s how easy it is to post an update to Twitter:

TweetSharp talks to Twitter

And the final result?  See for yourself:

Final result: Project Issues in Twitter

You can actually view our live Gemini Twitter feed at http://twitter.com/issue_tracker

Twitter Plug-in Deployment

1. Grab the plug-in binaries from here.
2. Put the “.dll” files and “.config” file into your “Gemini\bin\plugins” folder.
3. Put your twitter login credentials into the “.config” file.

That’s it.

No related posts.

http://portal.acm.org/citation.cfm?doid=1718918.1718972

Abstract:

Issue tracking systems help organizations manage issue reporting, assignment, tracking, resolution, and archiving. Traditionally, it is the Software Engineering community that researches issue tracking systems, where software defects are reported and tracked as ‘bug reports’ within an archival database. Yet, as issue tracking is fundamentally a social process, it is important to understand the design and use of issue tracking systems from that perspective. Consequently, we conducted a qualitative study of issue tracking systems as used by small, collocated software development teams.

A key conclusion was that issue trackers are still used as a fundamental communication channel:

We found that an issue tracker is not just a database for tracking bugs, features, and inquiries, but also a focal point for communication and coordination for many stakeholders within and beyond the software team. Customers, project managers, quality assurance personnel, and programmers all contribute to the shared knowledge and persistent communication that exists within the issue tracking system. These results were all the more striking because in spite of teams being collocated–which afforded frequent, face-to-face communication–the issue tracker was still used as a fundamental communication channel. We articulate various real-world practices surrounding issue trackers and offer design considerations for future systems.

Take some time out and have a read of this study.

No related posts.

The lure of quick short cycles producing working software.  The attraction of managing just a couple of weeks of work with quick daily meetings and being seen as “agile”.

Sure, you have a certified Scrum Master and everyone involved signs up to the process and gets its.

But the problems arise when the software engineering side of things is not quite geared up for Scrum.

To quote Allen Kelly:

“You hit the Scrum wall when you adopt Scrum and everything goes well, then, after a few Sprints things don’t work any more – to use an English expression, they go pear shaped. You can’t keep your commitments, you can’t release software, your customers get annoyed and angry, it looks like Scrum is broken.

This is what happens when you adopt Scrum without technical practices such as Test Driven Development, continuous integration and refectoring. When teams adopt the Scrum process, they go faster, show progress, things look good… and then the quality becomes a problem. Now the team are fighting through quick sand.”

The underlying  problem is brilliantly framed by Ayende Rahien: processes such as Scrum actually ignore the actual building of the software.

So no amount of project management / scrum management tools will help that much if your software engineering is not up to the task!

No related posts.

The objectives for the this release:

1. Show My Work — issues assigned to you.
2. Add Comment — log comments against your issues.
3. Create Issue — log a new issue.

Moving forwards, the app will be expanded to include:

1. Changing Issue Status.
2. Logging Time.

We have deliberately taken a narrow yet focused approach on building iPhone functionality — it’s about getting your work on your mobile device and NOT “Gemini Lite”.

No related posts.

An enterprise-wide issue management platform should typically facilitate capture and tracking of defects, tasks, quality checks, support tickets, change and feature requests from multiple locations, departments and even multiple organizations.

Implementing an issue management platform goes well beyond the traditional Software Development team. Clients, vendors and other organizational departments also require project participation. During the implementation many organizations seek guidance around project structures, user access rights, metadata, and workflows. The rationale is that investing some time upfront to structure the implementation saves the “refactoring pain” that typically follows once the issue management  platform is in active use.

Problems are usually compounded when multiple applications and project repositories are deployed thus resulting in “multiple versions of the truth”. A single issue management platform for all users will yield a “single version of the truth” – no room for confusion is left if all users adopt the same project platform.

We could summarise the necessary steps as follows:

• Understand potential users, project types and the relationship between projects – “are we managing both Support and Development projects?”
• Identify business processes to be managed – “are we tracking Defects and Change Requests?”
• Determine data requirements for different business processes – “what data fields does the user fill in when logging Defects, and when raising Change Requests?”
• Plan for external participants requiring project participation – “which external entities need access to the platform to view, update and close tasks?”
• Adopt readily understood and consistent terminology – “should the platform state “Modules” or “Components” when describing elements of the application in question?”
• Design and implement now, tune later – “focus on rolling out the platform and optimize it later for additional benefits.”

Read our white paper and see how to plan and implement an issue management platform for your organization:

White paper: Implementing an Enterprise-wide Issue Management Platform

No related posts.

We have started off by open sourcing the Gemini Snagit screen capture integration:

http://gemini.codeplex.com

Also introduced is the Greenshot screen capture integration with Gemini:

http://geminigreenshot.codeplex.com

You can read more on Greenshot here: http://greenshot.sourceforge.net

For all such projects complimentary issue tracking will be provided at http://opensource.countersoft.net

Gemini Community Codeplex Homepage: http://gemini.codeplex.com

Codeplex Open Source Issue Tracking:  http://opensource.countersoft.net

No related posts.

As we promised just before the Summer, Gemini 3.6 sports a completely new User Interface — an even more appealing look-and-feel coupled with innovative yet intuitive, usability enhancements.

You can now see Gemini 3.6 Beta running in anger on our public Gemini Issue Tracker instance: http://gemini.countersoft.com

We use Gemini to manage Gemini — shouldn’t all Bug Tracking / Issue Tracking Vendors provide a public instance of their own Product?!  We do and have done so for a good few years.

Here are the download links:

http://countersoft.com/downloads/beta/CounterSoft_Gemini_v3_6_0_Beta2.zip

http://countersoft.com/downloads/beta/CounterSoft_Gemini_Scheduler_v3_6_0.exe

http://countersoft.com/downloads/beta/CounterSoft_Gemini_API_v3_6_0_Beta2.zip

http://countersoft.com/downloads/beta/CounterSoft_Gemini_API_TestHarness_v3_6_0_Beta2.zip

Here is a summary of “what’s new / fixed / improved”…

• Dynamic Issue Filters – ultra-fast, compact, dynamic issue filters like no other!
• Re-vamped Dashboards — Global, Project, User, and Issue Dashboards totally re-vamped to provide an even more crisp user experience.
• Movers & Shakers — quick summary info per project providing a handle on Project Activity.
• Quick Issues – bulk create issues specifying minimal data.
• Roadmap & Change Log – summarised metrics and charts provide insight into Issues addressed.
• Nested Versions – organize Versions in a Hierarchical fashion (great for SCRUM Sprint organization).
• Tables or Charts — decide whether you want see summary data in Tabular or Chart fashion.
• SCRUM Burndown Chart — display data based upon Hours Logged or Issues count.
• Inline Editing Everywhere – Users and Admins can inline edit data as they see it.
• Time Reporting – roll up time data at any level and see time logged by Time Types (e.g Billable).
• Mega Menus, Less Clicks – slick navigation experience provided by Mega-Menus.
• POP3 Mailbox Processing – now tracks and auto-emails external email submitters.
• HUGE speed tweaks — Gemini is now even faster, see http://performance.countersoft.com.
• Drillable Charts + PDF Export.
• 40+ Bug Fixes.

Existing users can upgrade from any previous Gemini release to Gemini 3.6 — drop us a note if you need assistance.

We’ll let the screen shots do most of the talking…

Existing users can upgrade from any previous Gemini release to Gemini 3.6 — drop us a note if you need assistance.

No related posts.

They huddle in a corner, hunched over the Gantt chart you just handed out, muttering darkly.  Only the occasional, quick glance in your direction betrays that you are the subject of their reproach.  You sigh and for a moment are tempted to bat for your corner, but in the end you realise that it’s best to ignore them.  A quick drink after work and they’ll come round.  Instead, you scan through the list of Change Requests, Outstanding Issues, Bug Fixes and the Financial Summary and prepare yourself for your next meeting.  This one ought not to be so bad, the Client might not like what you have to say either but at least they don’t see you as the enemy within.

Who would be a Project Manager?  There are times when it is akin to being a referee at a particularly fractious soccer match.  You have to keep both sides apart while making sure that they play the same game and abide by the rules that they want to wilfully ignore.  Sometimes it feels as if only you realise the fundamental difference; this is not a game, and if one side loses then nobody wins!

The classic portrayal of the gap between requirements and delivery.

We’ve all seen the cartoon about the difference between what the Customer wanted and what they got and we all know who has to manage the gap. What the team on both sides of the requirements/delivery divide should acknowledge is that this situation does not exist only as a comic creation, it exists as inevitable outcome of the fact that requirements evolve from abstract needs but Software Developers can only build still life.  If this was honestly stated by all parties right from the outset then the first question that would be asked is who is going to make sure that we all walk away from this with a satisfactory outcome in the bag?  The notion of the Project Manager as the Client’s mole or the Supplier’s secret salesperson would evaporate.

One of the most irritating debates would also get put to bed; namely why the Client should pay for Project Management.  The client should pay because the Project Manager serves the project, not the Client nor his or her direct employer, who only employs Project Managers because they have long experience and understand the necessity of Project Management.  A Project Manager is a necessary part of the cost of delivery.

Fortunately we live in a world where the value of a good Project Manager can be proved beyond doubt, provided he or she tracks everything related to the “infamous gap“; issues, changing requirements, moving time lines etc., and stays on top of it.  Our Project Manager can walk into a meeting with the Client or Delivery Team, and the data at their command rams home their value to either side.  Wait a minute, either side?  Maybe Project Managers are the enemy within after all.

No related posts.

• Dynamic filters that responded to selected Projects; select two or more Projects and watch the Components list auto-magically update.
• Jump quickly to fields you want to filter on without having to scroll around.
• Clutter-free; having multiple list boxes one after the other really isn’t pleasing to the eye.  Less is more?

So here’s a first-look at the new Issues Filter:

When you click on a filter item like Projects, you get a popup list to help you select your desired items:

Projects are organized by their label and when you change your Projects list, other filter options like Components load dynamically the appropriate items:

The Components are organized by Project Name and then by their hierarchy.  Nice, easy, intuitive user experience!

Finally, other filter items are more intelligent and they only show items for the selected Projects:

Irrelevant items are removed and the the item list is unified across the selected Projects.

Try it out now @ http://beta.countersoft.com and share your feedback with us.

No related posts.

The issue is one of risk and who takes it. With a fixed price project the risk is deemed to be the supplier’s, with T&M it is the customer who takes the risk. This ‘risk’ is presumed to be the risk of overrun, in other words if the project is not completed on time the cost of resources to continue working on it will be borne by one party or the other.

In the fixed price scenario, the supplier is in theory happy to accept the risk because it is the supplier who names the price and sets the timeline. If the project comes in early then the supplier makes a super profit because the engagement was profitable even if it was only on time and the supplier is usually allowed to add a mark-up to the project for accepting fixed price risk in the first place.  Everybody is happy unless the project comes in so late that it eats into the supplier’s contingency and extra margin, but if that should happen it is the supplier’s fault anyway for getting it so wrong in the first place. Or is it?

In reality the supplier rarely sets the price or the timeline. Customers don’t just sit back and accept the estimates they are given, they negotiate and they usually negotiate the fixed price risk factor away. Suppliers need the business and recognise that if they don’t do it their competitors will, so they take the risk of a fixed price project scoped out to meet exact deadlines. However, if they fail to meet those deadlines they do not passively accept the cost of the overrun either. Even if it is entirely their fault, suppliers will do their utmost to stay in business and running unprofitable projects is not a good way to remain solvent. They will under-deliver on what was promised, scale back on resources allocated to the project, either by using less or cheaper labour, and they will hit back with that dreaded weapon, the Change Request. When the arguments start over the Change Requests then nobody wins.

If we look at what was intended rather than the means of getting and paying for it we might be able to see a way out of the problem. Customers want good, reliable software that addresses a need that they have. However suppliers cannot give customers what they want; they can only give them what they ask for.  Customers, not being experts in the software development business frequently don’t know how to ask for what they want. Sometimes they do not even know if it is possible to get it. If you know that there is a gap between what the customer asks for and what they want, and you have enough experience to know that they rarely like what they are given first time, then the solution is to show them what they are going to get, early.

Project Managers should try to minimize the size of the gap by making sure that as far as possible the customer sees what they are going to get as soon as possible, in small chunks. The sooner the “what you want” vs “what you get” battle is fought, the sooner the “risk” vs “pricing” issue gets resolved and the more likely the project is to succeed.

We call this “Minding the Gap” and we learnt to do this because the reality in large projects is that there is rarely only one gap. The need to “Manage the Gap” is just as great as the need to recognise it in the first place. Even Agile / SCRUM projects can fail if you fail to properly “Manage the Gap”.

Every issue represents a potential chasm for funds and resources to pour into and that is why Issue Tracking tools like Gemini can be extremely beneficial to all parties concerned.

No related posts.