For big product launches, design is absolutely imperative to have done well. Hopefully, where you are working, you have a product management team, product owner, or marketing team that knows exactly how the product, system, or website needs to look like and they have a pretty darn solid way of showing it: wireframes, or design specs, etc.
Hopefully, even, they may have these design requirements all spec’d out even before you begin looking at it or creating stories! But often, they don’t. So how does design fit into Scrum when developers are demanding to have wireframes and sometimes, even, the whole daggum thing designed-out before they can begin work (I think this can be unrealistic).
I like to start with an “Iteration Zero (0),” a design iteration that takes into account time to wireframe, speak with stakeholders and involve a development lead to give some insight into how the system architecture may or may not be able to handle some of the design requirements.
The developer must be able to take something from the design meetings and the design specs/wireframes/design requirements must be just good enough for the developers to start work on. This has to be a healthy balance between what is needed by the developers and what can be fleshed out by the product owner and designers.
With my current client, we’ve found that if we take a test driven development approach (building out test cases and use cases) we can easily fill in the design aspects as we create modules or stacks of the whole. Woah there, it’s looking iterative and agile! So what we have here is a piecemeal development process that starts with the conversation with the product owner and designers (who also build test cases), and chunk out the whole development into design stacks that can be consumed by development.
Bottom line? Design needs to be just as iterative as any other agile process. There needs to be frequent inspection and adaption of the system as it’s built out. For a more detailed look at this check out this link here: [Agile Design].
[ImgSrc Dilbert.com]
It sound like a very innovative approach to the definition and development of requirements. A more formal and traditional approach can be very slow and not actually deliver what the client wants. I would love learn more about agile methods can you recommend some further reading?
Agile Adoption Patterns: A Roadmap to Organizational Success by Amr Elssamadisy
Agile and Iterative Development: A Manager’s Guide by Craig Larman
Agile Estimating and Planning by Mike Cohn
Agile Project Management: Creating Innovative Products by Jim Highsmith
Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen
Agile Software Development by Alistair Cockburn
Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
Becoming Agile: …in an imperfect world by Greg Smith and Dr. Ahmed Sidky
The Business Value of Agile Software Methods: Maximizing Roi with Just-In-Time Processes and Documentation by David F. Rico, Hasan H. Sayani, and Saya Sone
Collaboration Explained by Jean Tabaka
Crystal Clear: A Human-Powered Methodology for Small Teams by Alistair Cockburn
Encyclopedia of Software Engineering edited by Phillip A. Laplante
Extreme Programming Explained: Embrace Change by Kent Beck
Fearless Change by Linda Rising and Mary Lynn Manns
Innovation Games: Creating Breakthrough Products Through Collaborative Play by Luke Hohmann
Lean Software Development – An Agile Toolkit for Software Development Managers by Mary and Tom Poppendieck
Lean Solutions by Jim Womack and Dan Jones
Lean Thinking by Jim Womack and Dan Jones
Managing Agile Projects by Sanjiv Augustine
Managing the Design Factory by Donald G. Reinertsen
Planning Extreme Programming by Kent Beck and Martin Fowler
Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum by Craig Larman and Bas Vodde
The Software Project Manager’s Bridge to Agility by Michele Sliger and Stacia Broderick
User Stories Applied by Mike Cohn
Thanks for the reading list, better get busy.
No problem! Hope it helps!