Working at Disney a number of years ago was in so many ways transformative for me (not sure why I left) because it provided me with an opportunity to work with an organization that needed to get better at delivering software for our partners and we ended up choosing Agile as our path. Disney was the place where I had the opportunity to help build an Agile process from Requirements to Delivery and what we discovered was that we needed to develop an effective planning process that allowed us to build a solid backlog of work before we just started coding. I here that so often in organizations that are just starting to adopt Agile. I think a statement I heard recently is descriptive of organizations that just start coding - Shoot and Point.
Disney is a largely creative driven organization (Not surprising) and because of this we typically had a disconnect between our creative (UX) groups and the Product Delivery teams. The UX team primarily worked independently of the PD teams and as was the case when I arrived, UX would deliver a creative design that didn't align to our technical capabilities. This is a common issue in today's web development environment.
Our first 'Release' Planing went very poorly and after a round of retrospectives we came up with a format that at first pass you would say wasn't Agile (trust me we used that phrase a lot in the early days of our becoming Agile). But in the end this first step of Discovery ended up being what I believe is the most critical element of being able to go fast in Agile.
The basic process that we ended up with was as follows:
- Pre-Discovery - Sr level PD, PO, UX, Marketing and other Stakeholders would review a specific new feature that was being considered. The group would utilize several tools such as Mind Mapping to understand the scope, parameters and potential dependencies at a high level. If the feature work was approved then we went to the next phase.
- Discovery - Depending uponthe the size of the potential project Scrum teams and extended stakeholders would meet to go through a low-level review for that feature development. For many of our larger efforts it was not uncommon for us to sequester the teams into a room to work through the entire effort, UX to QA to Delivery.
- Process
- Kick off - Have your PM or PO along with the key stakeholder(s) of the effort describe WHY this feature is so important. We learned in our process development that it helped our PD teams to have an understanding as to why this feature was important to the organization. It helped them feel connected to the value that was being delivered and not simply code jockeys running a race.
- Competitive Review - Another great exercise was to have the entire team go out and find competitive features that we either did or didn't like and describe why. This helped the next phase of our Discovery process as we worked to define what our feature sets would ultimately look like
- UX and Story Development - This was the primary scope of our Agile workshops. Typically led by the UX lead for the project we would begin developing low-fi wireframes and discuss the issues, constraints and code complexity that the low-fi would entail. We discovered in this process that we could work through the types of issues that come much later in a typical product delivery effort.
- Outcomes -
- UX ended up with designs that they could utilize to develop prototypes that would be used in User testing prior to any significant development work being completed. This allowed changes to UX to be found at the very beginning of the PD process rather than at the end when refactoring consumes a much larger amount of time and leads to lower quality of code.
- PD ended up with a solid design at the beginning of the PD process which led to high quality code and higher levels test automation.
- QA ended upon with an ability to write higher quality acceptance criteria which lead to high quality in the delivery and higher levels of test automation (sensing a theme here?)
- User Story development was done during the Discovery phase and with it I was able to have a fairly accurate model to predict the number of stories at the beginning of the Discovery phase (typically between 100-120 higher level Epics, we strove for stories to be between 21-34 points in this phase as PD would start fairly quickly after the discovery phase 2-3 weeks) and how many that would translate into for a full project (typically 350 - 400). This provided me with input as to how many BDD acceptance criteria would come out of this as we used a marker to determine when a story should be broken down - More than 7 variables in the BDD would be an indication that it's time to think about breaking down the story and more than 14 tests in a single test scenario would also trigger the conversation of whether to add a scenario to a story or create a new story.
- Benefit - Keeping your BDD test automation in small increments makes it much easier to understand what broke, who probably broke it and what is needed to fix it.
- Outcomes -
- Process
I know this doesn't 'Sound' Agile (like the name of my company), but in my experience doing this small amount of work up front does provide teams the base to go really fast once the PD process begins.
I have used this process now for many years and when we do it right it's like writing a symphony, all of the moving pieces make beautiful music. When it isn't done right, then all you get is noise.
This process probably does work for larger and more complex organizations over small organizations, but really would you start building a house with no blueprints and no idea of what you wanted? If you had builders just show up and you told them I need a house to live in and I need it fast you will get that, but I doubt it will be anything that you want. And in reality it wouldn't be done fast as they probably wouldn't have the right materials scheduled to arrive at the right time. I have my roofing supplies but the foundation company can't some for a month, see what I am getting at?
Slow down a bit, understand what you want, how to get it and then go fast to get it.