Recently, I've been playing the role of 'customer' or 'sponsor' to a vendor and, at the same time, an internal development team. For the first time, I'm realizing that as an IT professional, I haven't spent much time thinking about what my user's experience is. What is it like for a person who knows a business very well to start, day one, with a development team? How do we, as IT professionals, ensure that our customer or sponsor has a good experience?
Both the vendor and the development team use SCRUM (albeit a bit differently) to develop software, and yet my experience with these two groups is so completely different. What makes it different? and why is one a much better experience for me than the other? I want to explore these topics and learn more about others in the industry tackle this issue (or do they at all)?
I also want to address the issues surrounding how Agile development impacts the people we are building the products for (the business, not the end users). Agile development is so widely praised in the IT community, but I wonder how it is for our customers? Is it really the best, and does it really bring about the best outcome, or do we just like it better? What Agile practices make the business experience* better?
* I've decided to use the term "business experience" to mean the experience of how software is built from the perspective of our sponsors/marketing departments/CEOs/Partners/etc. It is probably equivalent to the term User Experience, but different so that I can hopefully side-step the tricky pitfalls of UX
Friday, January 22, 2010
Intro
I work in an internal IT development group as a ?? [insert your term of choice here: Product Owner, Program Manager, Business Analyst]. Let's just say that I try to translate what "the business" and "the users" want into something that "the developers" can build.
Over the past couple of years my role has moved further away from the task of IT development and more in the direction of determining vision and setting strategy. Don't get me wrong, it sounds a lot fancier than it is, and most of my days are spent in discussion and syndication, not drafting strategy decks to be printed on card stock. So much of what I do is actually decided by (and implemented by) others that I'm in a constant state of negotiation.
Over the past couple of years my role has moved further away from the task of IT development and more in the direction of determining vision and setting strategy. Don't get me wrong, it sounds a lot fancier than it is, and most of my days are spent in discussion and syndication, not drafting strategy decks to be printed on card stock. So much of what I do is actually decided by (and implemented by) others that I'm in a constant state of negotiation.
Subscribe to:
Posts (Atom)