The Cobbler’s Kids

The old saying about the cobbler’s kids that have no shoes is as true in concept now as it was a millenia ago. At Oasis Digital, where we find great solutions to increase the success of our customers, we have been so focused on those projects that we find ourselves lacking our marketing shoes. Our marketing efforts have been tertiary at best.

 

A few years ago we realized the need to develop our brand, a few months ago we started moving forward, and a few weeks ago we sat down and started the process with our team. I asked them to articulate what we are really good at, what they were proud of. The list was broad, and spoke to their understanding of the value they bring to our clients. Here is the list:

  • We don’t just build what the customer describes, we address needs in a well-thought out manner. We creatively solve problems, not just execute.Fists-shoes-216x300
  • What we build can last (longevity). and scale
  • Our teams communicate and collaborate
  • Challenges/problems are shared in the team
  • Our tech stack stays fresh
  • We teach about what we use
  • High quality, comprehensive design documents that hit the mark the first time.
  • Continuous learning/continuous improvement professionally
  • We can bridge the gap between techies and lay people
  • Our team can communicate effectively
  • Always look to improve, solve the problem with less code
  • We push for regular delivery, to finish items, not have long-standing open work items

This is the first bit, what we do well. The further question is how do we do these things. Very often, how you do things communicates your value to your customers. For example, people find our training very valuable because it is intensely workshop based, and taught by an actual practitioner of the craft, not a professional teacher.

  • We build high quality software
  • We empower our customers to prosper
  • We leave customers and projects better than we found them

We are a values based organization, so the “what” and the “how” are not the full answer. When you answer the “why” you find the values that motivate your work. The answer I came to was two-fold:

  • We love to solve problems
  • We love to help people

The wording will change over time but our core motivator is solving hard problems that have value. We really enjoy that process. Adding value, helping people and businesses to be successful, those are solid values that we believe will resonate with the right kinds of customers.

I love the powerful words pushed forward by the team. They are full of meaning and demonstrate the consistency through the team of our values.

love, empower, build, communicate, help, teach, improve, finish, learning, effective, collaborate

I cannot wait to have these ideas permeate our web presence and our marketing communications. If we can push this to conclusion I believe we will finally have a nice pair of shoes!

JIRA Case Study: Nested Workflows

Using custom issue types and multiple nested workflows to bring business management processes into a project without disrupting the core workflow.

Last month I had the pleasure of teaching a private JIRA Boot Camp at a national corporation on the East Coast. They had been using JIRA for a while, and had achieved a level of success in within their development team. They knew JIRA had the ability to play a larger role, but they were struggling to really integrate it into the business. They asked if I could come out and go through my normal curriculum but with an eye on their particular situation.

Working with the Director of IT, we decided to really push hard to complete the curriculum in two days and spend the third heavily focused on their internal challenges and their production environment. By the end of the day it was really clear this had been a wise choice. They were picking up the main curriculum very well, and they could see how to move development based items through the workflow. They were struggling with how to manage the business-related processes that precipitated and followed the software development process. Like most people, they understood JIRA could be so much more than an issue tracker, they just needed a little guidance to make it happen.

As we went through the workflow exercises in the curriculum, the problem crystallized. In their organization, initiatives would be proposed by various leaders of groups throughout the company. Those initiatives would go through an assessment, research, and approval process before any development occurred. They needed to track these initiatives so they knew what was coming, but kept mixing them into the development workflow. After we covered custom issue types, I approached the solution with them. They needed to nest a development workflow inside a workflow to track initiatives. This could be done with custom issue types and advanced workflow configuration.

First we white boarded the initiative workflow both before and after development occurred. The results are shown below.

Initiative-Workflow1

The process for the initiatives was fairly complex both before and after development. The entire development process was represented by a “development” status for the initiative. Important truth, the business process “around” development work is often far more complex than the development process itself.

After this we nailed down a straightforward workflow for the development process, represented in the next image. The essential process became crystal clear to them once we removed the distraction of the messy process surrounding it. I needed to coach them very little once the distractions were removed.

Development-Workflow2

The answer to the overall problem was to allow the original initiative to be created, researched and run through an approval process. This initiative then needed to be tied to the development work while it was being completed. Once this phase was completed, there was a well-defined business process that needed to be completed for the whole initiative.

The next challenge was how to implement this in JIRA. The first step was to define the two separate workflows and lay out the statuses and transitions of each. Even though there were some possibilities of sharing statuses between the workflows, we were very careful not to do so. I have learned to isolate workflows that have different purposes. I have written about this previously, here. Mixing the purpose of a workflow includes using a status from a different workflow that may share a name. If the meaning is different in any way then a status should not be shared.

We then created the custom issue types that would be used by each workflow. There were multiple custom issue types needed for each workflow. We created multiple custom issue types for each workflow, then negotiated the transition between the issue types and workflows in a way that fit the organization.

An initiative would ride through its process until it was approved. It was then transitioned to the development status. The initiative was then assigned a label and the development items were created and tagged with that label. The initiative was not allowed to transition out of development until all the items with that label were resolved. The development items then make their way through the process to completion, thus allowing the initiative to move forward to the review, field testing, and deployment stages in the first workflow.

Screenshot-2013-12-03-at-12.41.06-PM-e1386096862843

Another bonus of this approach was reporting. An agile board could be created for each initiative, allowing the stakeholder to monitor progress of his project. Another agile board could be created to track all the initiatives, another for initiatives by department, another for development tasks by developer.

The net result was that a very complex, opaque process made manageable and transparent by utilizing custom issue types, separate workflows and advanced workflow configuration to nest the two workflows together. Yet another example of how powerful JIRA is, and how strategic use of its flexibility can improve organizational efficiency.