CASE STUDies > agilE

agile management and coaching
enterprise software team

OVERVIEW

Client

- KinderCare Education
- Children's Creative Learning Centers
- Champions
- The Partners Group

Location

- Portland, OR

INDUSTRY

- Child-care education and services
- Financial / accounting
- Tuition subsidy

COMPANY PROFILE

- $1.6B company
- World's largest early childhood education company

TECHNOLOGIES

- Enterprise software
- ERP software (enterprise resource planning)
- Financial and accounting software

Product(s)

- Tuition subsidy financial software

Project / feature / deliverable

- Tuition Subsidy v1.0 (MVP)

duration / date

- 15 month release / 2015-2016

brief

NOTE: Don't feel like reading? Watch the video at the end of this page.

NOTE: If you are diving deep into my background, I highly recommend reading my KinderCare Education product and UX design case study first to better understand the larger context for the case study below.

BACKGROUND

This case study highlights my documentation and project management work for the Tuition Subsidy v1.0 MVP software product, especially the change management and tools integration work underpinning my higher-level product design and product management. While the separate case study highlighting my product management work probably better covers the umbrella of "product management" in praxis, this case study better showcases the documentation itself, and the deep integration between project-management and documentation software tools used on the project.

problem

The company had history of losing all the the talent and knowledge associated with its software products. Everyone who had ever originally designed or developed a software product at the company had left years earlier. This loss of mindshare had been a major force in the fragmented and decaying state of enterprise IT infrastructure and various legacy software products. Within the program, this weakness was acknowledged as a major risk, and executive leadership wanted a solution to prevent it from recurring.

Prior to my arrival, management of all software development had been limited to two tools. An antiquated bug tracking system was as far as the enterprise had ever gotten on its own. In an earlier iteration of this program, another program manager had introduced Smartsheets, an Excel-like, cloud-based solution designed for group collaboration. This tool is more geared towards general business work, not software development. But unfortunately, the original Smartsheets work had been inherited, re-purposed, and perpetuated with two successive program managers, without understanding the documents' origin or project needs that had changed in the meantime.

solution

I have been using documentation and publishing software on various projects since the beginning of my career. I used this experience to quickly land on the Confluence wiki from Atlassian as a primary tool. Confluence is a product I have used for years and found useful on other similar software-development projects. The decision made even more sense since the company had landed on Agile JIRA, another Atlassian software product, as its project-management tool. The tight integration between the tools offered numerous benefits.

As I began to conceptualize the product design of the new software, and a vision and framework emerged, it allowed me to structure and organize my documentation efforts. I configured both Confluence and our JIRA project to mirror the information architecture of the new software product. This uniformity made it easier for me to hold disparate roles and manage work in each area, since the information architecture of the application always provided the same guideposts. This structure also served as an educational tool for team members and stakeholders using Confluence or JIRA. By virtue of using either software tool, everyone was educating themselves by default on the new software product, its organization, and the logic behind it.

Bit by bit, over successive months, I developed the Confluence wiki and JIRA project. The wiki was primarily dedicated to product design and specifications, while JIRA was used to set up the same information in the form of release schedules, sprints, epics, and user stories. Although I was always thorough in documenting the software, I also took a lean approach, and tried to remain nimble and dynamic. There was full traceability with all project information using this approach, everything in Confluence linked to JIRA, and everything in JIRA linked to Confluence.

Challenges

This enterprise had no experience with best practices in modern software development or Agile. As such, this competent of the project could easily be grouped under an umbrella of change management. Putting these tools and processes in place was much more than taking my experience and expertise, and defining and implementing solutions. It required a great deal of communication and persuasion. Initially, the value of extra resources invested in this work, especially the documentation, was met with resistance and misunderstanding. Even when new processes and improvements took root, issues with cultural adoption straggled and lingered. On one hand, starting anew allowed for these fresh processes to be properly introduced and rooted. On the other hand, it was daunting to unblock this fresh work and create momentum.

The larger problem, though, was the sheer scope of work. Beyond the groundwork I describe, or the documentation and release management itself, the precursor to it all was abundant research, usability testing, relationship building, and many other foundational tasks. Once I had acquired key knowledge and data, I then had to cull, cut, process, edit, distill, and refine the information into discrete and intelligible chunks. These pieces eventually translated into the backlog, epics, and user stories in JIRA, and copious design artifacts and specifications in Confluence.

Outcome

The measure of success with this work is tied to a lot of other facets of the project, but obviously the resulting software product itself is the biggest testament to its success. We were able to deliver a v1.0 MVP software product using JIRA and Confluence as our tools.

Attitudes about the extra investment with these tools and their value changed with time. All of the stakeholders on the project had no prior Agile experience. While some of the engineers understood Agile conceptually, they had never seen it implemented as part of a cultural practice. Soon people were living a daily Agile practice instead of resisting it.

The documentation was particularly well regarded, and in my mind the most valuable resource. It provided a deep knowledge-base for all facets of the product, and served as hub for all our work. This impetus also drove regular UX reviews. Collectively, it all allowed us to build a software product with a collective, clear, cohesive vision.

TOP

PROCESS

note: select image for lightbox view

dive deep: RESEARCH, INTERVIEWS, WHITEBOARDING

Discovery set the foundation for all my work, but was particularly important to the work I did in JIRA and Confluence, as those tools allowed me to translate raw data and research into structured design specifications and development work. .

ARTIFACTS and REVIEWS

When conducting research and usability testing by myself or in group settings, we would cycle through iterations as many iterations of artifacts and reviews as necessary, until we felt concepts and ideas were ready to starting to morph into something close to final form. When people hear the terms wiki or documentation, it brings to mind copious editing and word-perfect content. But the approach with Confluence, especially at this stage, was very much fluid and dynamic. Sharing ideas, gaining traction, and gaining momentum were our first goals. Confluence is a wonderful tool because it takes ideas and artifacts that often get lost in emails or directories, and organizes them into a centralized knowledge base.

documentation and publishing

When i knew that the artifacts and specifications had matured and there was general consensus with pages and features, I would commit the information to the Confluence wiki and begin to share it with the larger team. The inclusion of engineering at this point also introduced helpful iterative improvements. At this stage, I the documentation did become more precise, and attention to detail took precedence, since the engineers based of their work on my specs.

agile management

The backlog generally grew at the same pace as the documentation. While JIRA offers areas to document user stories and acceptance criteria, I chose to keep information in JIRA intentionally abbreviated, and developed all specifications in linked Confluence pages. This minimalist approach in JIRA made it easier to segment product design and product management work, facilitating tasks like backlog grooming and release planning in JIRA.

full traceability

Because I was linking all information in JIRA and Confluence, there was always full traceability of all project information. The tight integration between these tools supported a more holistic approach that would not have been possible using other software tools.

TOP

deliverables

note: select image for lightbox gallery

Confluence wiki

This series of screenshots represents the spectrum of documentation for the Tuition Subsidy v1.0 software product in Confluence. Click through the gallery in sequential order to approximate the experience of navigating the wiki in sequential order using the bookmark tree in the left navigation drawer. By the end of the first release, there were over 300 pages of internal technical documentation.