Agile In Regulated Software - Partnering

-

This may be generic advice, but it might not be a familiar concept for those in IT working within a large organization doing validated software:
Photo By: JD Hancock
Once you adopt the practices described in my previous blogs about regulated software, you will find that you aren’t working alone anymore. The tight feedback cycles allow you to regularly check-in with the business and involve them in building the software. Once this happens, priorities and features will change. Early on they will change often. Don’t discourage this as its a good sign things are moving in the right direction. The people talking to your customers are directly involved in building features your customers will use. This is exactly what you want because it be likely that you will produce a better product now. Now that you have left your IT bubble you must partner with your stakeholders rather than simply delivering to them on a regular basis. How do you effectively partner with the business and marketing? Here are the difficulties you will likely face:
  • Goals are different
  • The phases and corporate dialect are different
  • Time frames of when decisions are made is different
  • Required documentation will be different and address different goals
  • Stakeholders will feel comfortable giving verbal requirements, but you must to document them, get them formally approved and finally build them into working software
How do you partner with the business and still meet your commitments? Follow the practices I presented earlier and stick to the following principals:
  • Consistent focus on activities that add business value
  • Build trusted partnerships
  • Constant customer engagement
  • Continual process and practice improvement
  • Be collaborative and transparent
  • Work together: No heroes, lone wolves, or cowboys
  • Pay attention to the team and adapt as needed

Popular posts from this blog

How to start a product redesign - a playbook

-
Image
A few months back I was working on a large, ground-up redesign for a product I own. I had a little trouble getting started. I realized I needed a playbook to remind me of the basics. I am sharing my playbook for those who are having trouble and procrastinating getting started. Enjoy. Before you start At the highest level, in one paragraph, what is a representative user's goal and the problem you are solving for them?  If you can't answer this succinctly you have many, many features or you don't know your users well enough to continue.  Slow down, answer #1 for each feature set before you go to #2. What's working for them now? What's not? What you need to design for them Verify you are building all the tools they need. Show the process they will use to reach goal - give them a map or trail to follow. Indication of progress toward the user's goal - "You are here" Make sure you build in escape hatches because they find a better way....
Read more

Applying user centric design to your business plan

-
Image
Image by Lars Plougmann I got asked by an investor recently how we at Digital H2O do design. I liked the conciseness of my response and thought it was a good example of how to tie user centric design into a business plan. Here goes: Our design philosophy is best described as user centric design. Our goal is to only design and build features our current, or potential customers, find valuable and that substantially help our business continue to grow. We spend significant time listening to our customers’ needs throughout the sales process. We then form hypothesis what customers’ needs are and what they can accomplish in the application. While designing features we show mock-ups and prototypes to customers in order to get feedback and incrementally improve the design. After the product is built and released we continue to test our hypotheses about how customers will use features we have built. We utilize automated event tracking in the app to monitor u...
Read more

Your Inconsistent Design Makes Me Worry About Your Entire Product

-
Image
This is from a product I use daily. Who wrote this code and thought they were done? Who approved these two button styles next to one another? I have this vision of a developer choosing a library that made their development life easier. I picture this code going straight into production use without review. Next, I picture the designer who works there rolling their eyes, checking out, and heading to LinkedIn to see what other opportunities exist. I'm being unfairly harsh, but it makes me wonder what other sloppiness is happening inside this product.
Read more