Posts tagged "agile"

Deliver: Agile Execution aligned to Innovation

Previously, I spoke about “Discover, Define and Deliver” as the 3 Steps to Innovation upon Adobe technology. When describing this “3D Methodology” to customers, I find it’s easiest to start with that which is most familiar – Deliver – and then work back towards the value of Define and Deliver. When all is done, when the observations and insights have sparked an idea for innovation, and the innovation has been distilled into concrete requirements and designs, the Deliver phase is about bringing it all to life. It’s about breathing life into a design, lifting it from paper concept to production code. Deliver is primarily about writing code, pushing it through Quality Assurance and into production.

Deliver is agile…

Wherever possible, the team at Adobe advocates Agile development – and more specifically we advocate Scrum as our methodology of choice. This is indeed consistent with many of the product engineering teams within Adobe, as we more broadly embrace agile and Scrum within Adobe.

Formerly, I was an advocate of XP (Extreme Programming), but laterally, as more of the industry appears to embrace Scrum, as more of our customers embrace Scrum, and with more training and accreditation around the Scrum process, the differences between XP and Scrum are too trivial to matter. That previous link to Mike Cohn’s article highlights “Scrum doesn’t prescribe any engineering practices; XP does” … that being said, we very much advocate and encourage the practices of XP, whether it be coding standards, pair programming, unit-testing and test-driven development, continuous integration, and our teams are continually pushing the state of the art by contributing to tooling to support them, whether that be FlexUnit, FlexPMD, FlexPMD plug-ins, integration with Hudson, etc.

Prototype and Test == Release Early and Often

Throughout the 3D methodology, we strive to create the right environment for innovation. One particular trait of innovation is the ability to prototype and test; one particular trait of agile is release early and often. I think there’s a relationship between the 2 that is interesting.

Tom Kelley of IDEO talks about prototyping as “the shorthand of innovation”. I’d highly recommend reading that article, itself an excerpt from what we consider to be Adobe Technical Services required reading, “The Art of Innovation”. But within Innovation thinking, the importance of getting a working prototype in the hands of users, as a means of creating the opportunity to observe and feedback into the design, is very much established thinking. The team over at IDEO are tremendous at leveraging prototypes in their product design process; there’s a definite opportunity to embrace this kind of thinking and approach in the software product design process.

Within Adobe Technical Services, we will often prototype INCREDIBLY early in the process — oftentimes before we’ve even really undertaken a concise requirements gathering exercise. Prototypes are often deliverables from our Discovery phase, opportunities to explore hunches and insights, to play what-if with customers, or indeed even ourselves, and to stretch our own thinking about how some of the business needs, user goals and technology opportunities could come together in imaginative ways. We create incredibly high-fidelity prototypes, very quickly, either with Flash, with Flex or increasingly with Flash Catalyst…however, these vision prototypes really only take us on a “happy path” through the application. This kind of vision prototyping differentiates us from many others that we work with, and so I plan on talking about this in much more detail over another series of entries.

However, if you consider the agile process of delivering functionality in discrete time-boxes (what XP calls iterations, and Scrum calls sprints), then you recognize that each sprint affords us an opportunity to spin out a prototype that we can test. It takes courage on the part of the customer and the team, to challenge our own assertions mid-flight and to be prepared to course-correct upon learnings. But agile methods embrace change during development; and so the very engineering methodology that empowers us to prototype and test regularly through the development cycle, similarly empowers us to embrace the learnings straight back into the product design, during the manufacture of the design itself (which is in essence, the Deliver phase).

Deliver doesn’t have to be agile…but it helps…

We don’t always follow agile within Delivery, but ad-hoc is never an acceptable alternative. Oftentimes we will lead the delivery phase of projects with an Adobe team, but more likely we will be working alongside our customer’s development team or our ecosystem of Adobe partners. Agile approaches – stories as currency of requirements, feature-driven development and sprints of functionality prioritized according to business value – have proven to be a tremendous means of achieving technology and business domain knowledge transfer; I’d be interested if you have found the same also?

Summary

So when we get into the Deliver phase, we’re really in the midst of a software engineering lifecycle…there’s ongoing user-experience design for sure, but really the bulk of the experience is locked and loaded, in the backlog and ready for implementation. We definitely find that agile methods are conducive to innovation methods in the product design and manufacture, and so advocate them wherever possible. We definitely find that the engineering methods popularised by XP, and more widely embraced by the agile community, are as relevant to development with Adobe technologies as any other, and whereever possible we are contributing to and pushing the state of the art on the tooling to support agile engineering.

Most of the knowledge that we have to share in the Deliver phase comes from the tools, methods and best-practices particular to the technologies we are using, rather than the process or methodology we are using. Many of my colleagues are sharing this information in their own blogs and articles, and I’ll seek to reference them more in future entries.

However, as we push back into the Define phase, where a user-experience moves from concept to idea and to implementation, where we ensure that user-experience designs are satisfied by business and functional requirements and vice versa, where the real collaboration and magic happens between designers and developers, then I think we have a little more insight to share.

And so that’s where I’ll go next, with a similar overview of the kind of challenges we address in our Define phase. I’d love to hear what challenges you’re facing, how and whether you’ve addressed them, so that you might steer the direction of dialogue. By releasing these thoughts early and often, I have the opportunity to evolve them to meet consumer needs…!

3 Steps to Innovation with Adobe Experience Design and Technology

Through a series of posts, I’d like to share ever increasing detail in how the technical services organization within Adobe – comprising user-experience designers and technologists from technical sales and solutions engineers to consultants – consistently approaches the ideation and implementation of solutions upon Adobe technology. Each solution that we innovate follows 3 steps, which we call our “3D Methodology” – Discover, Define and Deliver. Over a series of entries, I’d like to elaborate on each of these steps, as a prelude to sharing more deeply some of the best-practices that have emerged for us from repeated application of our approach.

When I describe “Discover, Define, Deliver” to customers and partners, I find it easiest to describe it from the back to the front…and so this is how I’ll introduce each phase over the coming days:

Deliver: Agile Execution aligned to Innovation

When all is done, when the observations and insights have sparked an idea for innovation, and the innovation has been distilled into concrete requirements and designs, the Deliver phase is about bringing it all to life. It’s about breathing life into a design, lifting it from paper concept to production code.

I’ll talk more about agile development, the adoption of Scrum, and the traits of innovation methods that I believe align with traits of agile software development methods.

Define: where Requirements inform the Design, and the Design informs the Requirements

The industry has long accepted the fate-sealing that occurs when a project commences development/delivery before requirements have been adequately specified. In the 3D methodology, the Define phase commences when we feel we have gained enough insight and observations about user-needs, technology opportunities and strategic business drivers, to have a solution set of opportunities that can be elaborated with the customer into a set of business requirements.

I’ll talk more about design-led innovation, about how we bring together user-experience design methods with agile software development, and resolve tensions that so many of our customers and partners seem to face when bringing design and development teams together. In other cases, we find that there is tremendous lip-service paid to the design process … it’s something we feel strongly about, and dialogue we look forward to entering into in this forum.

Discover: gaining the Insights for Innovation

If Define and Deliver answer the question “how do we build things right’, then Discover answers the question “how do we build the right thing”. In our discovery process, we very much embrace innovation techniques and user-centered design methods that uncover the critical insights that ignite the spark and uncover the soul of an application. In the discovery phase, it is our goal to construct a portfolio of ideas to inform the very requirements that we collect with our customer to gather. These insights come from observation of the very individuals for whom our solutions will be in service.

I very much look forward to sharing our thinking and approach, the tools that we use, the assets that we create, the workshops that we facilitate and the philosophies that guide us in truly stepping back and challenging not just the solution, but the problem itself.

The 3D Playbook

We’ve captured this methodology as a series of individual plays in our “3D Playbook”, a social platform for capturing best-practices in how to set up for success. Should a project wish to, each phase of discover, define and deliver can be followed “by the book”, giving project teams clear guidance on the sequence of workshops, activities and deliverables. Alternatively, a project can be less prescriptive, but embrace the best-practices and philosophies that the plays are there to support, cognizant of the consequences of the plays that are being passed over.

I very much look forward to dipping into our playbook, and sharing with you our approach, the tools we use, the techniques we apply, and the lessons and learnings that we try to pass from one team to another at each stage in the innovation lifecycle.

Summary

We fundamentally believe that solutions delivered upon Adobe technology can establish the state of the art, can set the bar, where the technology is a medium and a means to an end, rather than simply the end itself. If Adobe technology is necessary but not sufficient, then sufficiency comes from the introduction of Innovation, and Innovation is Design-led.

Innovation doesn’t happen “by the numbers”. However, the environments that must be created, the individuals that must be engaged, and the insights that must be gained, can be sequenced and repeated. The practices can be repeated, and the best of these practices can become best-practices. Discover can yield insights for innovation, Define can bring the design and engineering disciplines seamlessly together and Delivery can assure a consistent execution with engineering best-practice.

I’m very much looking forward to sharing in this thinking, and entering into broader dialogue with our customers, partners and community about where we can share more, and what we can learn from the successful implementations that you are each responsible for delivering.

What else can we share ? What do you have to share with us ? Where do we begin ?