This was reinforced in a recent episode of .NET Rocks! (Is Agile Dead at CodeMash). A panel member (sorry, I don't remember which one) polled the audience. First, he asked how many people were part of the "business". Result: one or two people. Then, he asked how many people were part of "I.T." The result was most of the audience. He immediately said that this was wrong -- that everyone is part of the business. That's why we (as developers) exist.
As another example, we can look at the Principles behind the Agile Manifesto. Specifically, "Business people and developers must work together daily throughout the project."
Forming a Partnership
So, how do we go about forming this partnership? Previously, I mentioned that I really didn't know. But it turns out, I did. I just needed to look at my experiences in a bit of a different way. I mentioned how I have worked in an environment where the development teams and business areas had very good relationships. But even if we don't have this particular environment, we can work towards it.
Note: I'm approaching this from the standpoint of a corporate developer -- a developer who is building applications to help the company get work done. You will need to modify these ideas just a bit if you work for a software company or build products for people who don't work for your company.
Watch: Learn How the Business Works Today
The first step is to see how your users do their day-to-day work. Start by spending a day with one of your users. Watch everything that he or she does. Your job at this stage is to simply see how the folks in the business area get their job done.
Keep your mouth shut. Think of yourself as a wildlife photographer -- you record what takes place in front of you, but you're not allowed to intervene. If you see someone fumbling with a process or a piece of software, make a note of it, but let him fumble. You're not there to give advice; you are there to see how things are done.
Take notes, but don't immediately start thinking about how you would change things. As developers and problem solvers, we have a tendency to let our brains run wild. But this distraction can keep us from making some important observations. So, just keep watching.
Listen: Learn How the Business Wants to Work
The next step is to talk to your users. Ask them what they think would make their jobs easier. Find out how they want to work. This is still part of the observation stage. Don't immediately start trying to solve problems; just keep collecting information. The key is to listen to how they would change things. Periodically review your notes with the people you are talking to. This will ensure that you are collecting the correct information and has the added bonus of giving the users confidence that you are really there to listen and help.
If you're dealing with front-line workers, also talk with their management team. Ask the managers what they think works well and what doesn't work well. You may find out that the management team would like the front-line workers to focus on different priorities -- maybe there are short-term goals that change from time to time. If you can, try to sit in on one of their team meetings. This will give you better feel for what is important to them.
As before, don't let your brain start problem solving. You're still collecting information.
Analyze: Review What You Learned
After you've collected your information, it's time to start analyzing. Now is time to let your brain run wild. Think about the software that is being used (or not used). Review the stumbling blocks the users may have had (for example, did they have trouble finding a particular function?). Think about the processes that were not automated that could be. Maybe you noticed that someone took data from an email attachment and re-keyed it into a different system.
At this stage, don't be afraid to follow up with anyone that you've talked to out in the business area. Often, after you start analysis, you find out that you don't have all of the information that you need. You can use some quick follow-up questions to fill in the gaps.
Contribute: Take Your Plan to the Business
Now that you've had a chance to come up with some suggestions, it's time to take them to the business. Start by grouping your solutions into "quick wins", short-term, and long-term time frames. Once you have this, go back to talk to the folks in the business area.
Hopefully you have a couple of "quick wins" to start with. These are items that would be easy to implement from a technological standpoint (with minimal cost and resources) and would add good value to the business area. This is where you start to build trust. The quick wins show that you understand the business and that you are able to help.
If you "missed" on the quick wins, don't get discouraged. If the business area did not like your ideas, it's your chance to gather some more information. Ask some clarification questions and listen. Figure out what you misunderstood and work toward correcting that.
If the "quick wins" are a hit, then give brief descriptions of your short-term and long-term solutions. This is an opportunity to plant some ideas for future projects.
Continue: Constant Interaction
Congratulations, if you've gotten this far, then you are well on your way toward a good partnership. Now you need to make sure that you continue this relationship. If you start implementing some of the solutions, stay in constant contact with the business area throughout the process. Give them prototypes and get feedback as you go. Back to the principle we mentioned earlier: "Business people and developers must work together daily throughout the process".
Benefits of a Partnership
Ultimately, the business benefits from this relationship. As a developer, you are more in tune with how the folks in the business area think. Your software will naturally head in the direction that the business needs. In addition, the folks in the business area will trust your judgment. Once they see that you are all working toward the same goal (the improvement of the business), then they are more likely to accept your suggestions.
A partnership is about building on the strengths of both members. The business area has operational experience -- they know what work needs to be done. The development area has technical experience -- they know how to automate processes and build working software solutions. Working together, the entire business benefits.
Getting Buy-In
One of the issues you may face is getting buy-in from your management team. It may sound like you will be spending a lot of time "not developing" as you are doing "partnership" work. But this really isn't the case. Plan on spending one day a month in the field -- this really isn't all that much. The rest of the time is touching base from a few minutes to an hour at a time. You might spend a bit more time getting things started, but it will just become a natural part of your work after that.
"Agile" is a very popular term to use. Many development teams claim to be Agile, but often they are only using a couple of buzzwords and work in "sprints". But ultimately, Agile is about getting working (and useful) software into the hands of your users as efficiently as possible. If you don't understand how the business works, then this becomes very difficult. (Note: this is part of the discussion of "Is Agile Dead" from the .NET Rocks! episode mentioned above.)
Wrap Up
I have been fortunate enough to work in a very productive environment where I was able to form strong partnerships with my users. In that position, my management team understood the importance of these relationships. I was able to respond quickly to my users' requests (since I understood what direction they were headed), and I was also able to make relevant suggestions to improve the process.
Just remember:
- Watch
- Listen
- Analyze
- Contribute
- Continue
Happy Coding!
Really good tips.
ReplyDelete