AgileDesignLeadership

I'm currently the Product Design Manager at Schawk Digital Solutions. My most important activity is user experience evangelism. I've worked in application development since the mid-90s in a variety of roles, from business analyst to team manager to project manager. Today I divide my time among functional design, experience design, and product planning. I've been increasingly interested in Agile methods, and received ScrumMaster? training in 2007. I'm considering Scrum Product Owner training in the next 6 months.

I'm part of the team that designs and develops SDS's enterprise digital asset and process management Web application. The design team was introduced into an organization whose test team had just mandated IEEE 830-style specs managed in one of the big software packages. We've since evolved through functional use cases, to use cases plus throw-away visuals, to an almost entirely visual spec of activity diagrams, interaction diagrams, and wireframes. In practice we have a fairly clear line between design and engineering self-directed collaboration with casual documentation if any, and spec formalization done independently after the approach is understood. That overhead frustrates us but for now it's a necessary part of our regulated industries strategy.

I can contribute an open and curious mind, appreciation for and willingness to learn from others, and passion for software and the happiness of those who create it and those who use it. As an analyst, I have some facilitation skills and am not afraid to use them (have markers, will travel).

I'm interested in

• collaboration patterns
  • XP offers one model that seems, however useful it might be, applicable to only a narrow subset of project types and organizational contexts.
• exploring Agile roles
  • Some would say people like me should either beef up our technical skills or move over to product and not concern ourselves with technology.
• product backlog and product planning, especially for large, complex applications
• decomposition and coordination dimensions - simplification strategies for developing complex applications
  • What does simplicity look like in large enterprise app dev efforts? I'm thinking of complex applications that combine multiple technologies, integrate proprietary code and COTS, have multiple subsystems and internal interfaces, and serve a mix of user classes. Are there "Simple Design and Test" approaches to complex products? The "Scrum of Scrums" seems not quite adequate to the problem.
• software products that delight, invisible software - Agile methods might produce adequate software, in part because placing empirical observation rather than analysis at the core means a larger number of people can achieve satisfactory results. But what if "adequate" or "satisfactory" isn't "good enough"? What if you have to surprise and excite, not merely enable?
• does success require the "lone genius," or software decathletes - people who can perform at a very high level across all the disciplines and competencies required to create software? How can you successfully integrate specialists if you need them? How broad does a T-shaped person's crossbar need to be to contribute successfully to an Agile team?

Some of the other challenges we've faced are:

• How can you get time to invest in architectural changes, especially front-end? What if the application stack doesn't enable you to fulfill business or user needs? How can you organize and execute a restructuring effort?
• Handling known extensibility? On the product side we often know that there is a required enhancement path for a feature, but we are intentionally implementing the feature incrementally. We've tried two approaches.
  • Communicate the whole feature and work with engineering to plan the implementation increments. Our engineers designing infrastructure like this big picture approach, but some programmers have not been able to find their way into complex features.
  • Chunk the implementation, communicate only the current chunk, and include extensibility or enhancement path requirements. Some of our programmers like this better, but they seem surprised by and resist subsequent changes.
• As we've developed our experience design practice and pushed toward more real-time collaboration, there is a lot more overt friction in the process. All this turbulence feels a little like passing through the sound barrier. Have others experienced this and how have they survived it?