About mgm technology partners

mgm is a medium sized software solution company that defines its success by its contribution to the success of its clients’ businesses. Founded in 1994, mgm is based in Munich, with about 300 employees throughout Europe.

Alexander Weiss has been with the company since its migration from Bugzilla to JIRA in 2005 – he championed the adoption internally after using JIRA at a customer site. mgm technology partners uses JIRA, GreenHopper, Confluence and recently brought in FishEye. After reading Alexander’s two-part blog series (Part I, Part II), which highlights how JIRA can be used for projects other than just bug tracking, I reached out to him to learn more about mgm’s experiences with Atlassian tools.

Setting Up

mgm works closely with customers on many aspects of their projects. One of the unique aspects of their business is how they use Atlassian products to get customers involved at most every step of the project and decision making process. Everyone gets a JIRA login – JIRA replaces email for project communication because it serves as a more direct and central tool for discussion, and makes historical information easy to find. They have a single instance of JIRA with about 70 projects running currently, and about 800 active JIRA users (employees and customers). Projects range from two month stints with only a handful of people, to several years long involving dozens of people on both the internal and customer side of JIRA.

Project leaders set up a project-specific JIRA dashboard, so customers have a place to find the most up-to-date information about their project – without having to wait on an update from someone else.

Avoiding Backlog Creep

The mgm development team uses GreenHopper to set up and prioritize project work. They’ve found this helpful in the same way that our own DevOps teams have: showing a customer the prioritized project backlog as it evolves maintains realistic expectations.

Our experiences showed that in software maintenance and enhancement projects – especially in large projects – there is less overhead and more benefits for everybody involved if customers aren’t locked out of the JIRA processes…Furthermore, the customer gets a completely different attachment to ‘his’ project if he is able to see all ongoing activities and if he can generate an actual project state by himself. We have realized that the customer feels much more satisfied and more responsible for his assigned lifecycle parts once he experiences the whole power of process transparency. He also becomes more sensitive for interference factors and usually starts to avoid ‘creeping requirements’ once he realizes the consequences of adding just another “simple” request… although sometimes the exception proves the rules.

Getting on the Same Page

Customers and developers need to understand details and expectations up front, so requirements must be communicated clearly and stored in a central, searchable place. mgm uses JIRA to ensure that requirements are stated in a consistent, relevant way so developers have everything they need when they start work.

The responsibility to verbalize requirements usually remains with us. But the customer can be involved at any time to contribute details and he can (and should) be an active part during the elaboration phase and deliver his input and expertise through comments to the respective tickets.

Another very important point in requirement management is the used terminology. It is very important to always talk (and to write) the customers’ domain specific language. Use only terms that can be understood by the customer! We find it very helpful to maintain a glossary of all domain specific words and terms together with the customer.

Get the Customer Working

Once the wheels of the project are in motion, customers are able to create new issues for requirements, change requests, and bugs – but it doesn’t stop there. Having the customers approve a bug fix or even execute a selected manual test engages them at a deep level, giving the customer a sense of pride and involvement with the project. This has been a huge key to success for many of mgm’s projects.

In our experience the advantages obtained through direct participation of customers in JIRA exceed the disadvantages of for example the increased efforts necessary for JIRA configuration. A well informed customer who is directly involved in his project feels much more comfortable even if something goes wrong or the progress of the project gets stuck. Transparency is the magical keyword.

Final Thoughts

Alexander gives great examples and lessons learned from using JIRA for organization-wide project management for several years. Whether you sell software, give it away, or provide it for internal operations, connecting with other teams and getting your end users involved in a project – even from a high level – helps set proper expectations and keeps everyone on the same page. People make software, and better software comes from better connections between all the people involved.