This series of blogs is based on a talk entitled "Is Your Programmer a Better Business Analyst Than You Are" given by the author to the Kansas City IIBA user group meeting in April of 2015.
It's always been a problem for me that programming students have no clue about working with existing project requirements. I've never seen any teaching nor any methodology come from the Agile movement let alone any other technical cultural phenomenon. If no one is concerned that the project moves from the business analyst role to the programming role, that must mean that the project really starts with the programmer because that's where the project deliverables really begin. And so, programmers have reverse-engineered analysis and design skill sets to cope by themselves,
Of course, real world projects are the practical training ground for understanding how to work with project teams, but couldn't we make this a part of the skill set for a programmer before they get thrown into the war room?
Web programmers are used to this. They are a department of one. They gather information on understanding customers' needs, write copy, design layouts, put the code together, and deploy and maintain a site. As the web application world expands, this puts immense pressure on the technical web employee to know about any new development and keep up their own skills tied to the legacy apps they maintain.
Programmers I talk to have an implicit distrust of the project. They find a purpose but no real detail in it and muddle through the development as best as they can. In fact, most businesses without a solid project management process don't have much to work with. The management will throw stuff out into the market and claim that the market is crazy. The analysts are documenting whatever anyone says and then complaining that the users don't know what they want. Coders code whatever they think is right and try to make the project manager's deadlines.
And testers. Standing at the end of the line with a deadline rapidly approaching doesn't make anyone try to establish any standards knowing that they are holding up the deployment. They just try to find as many bugs as possible in the time they have.
The programming students I see have not been trained in business so it's reasonable they don't know how good goals can drive their behavior. A couple of questions have always intrigued me when working with a software project:
It's always been a problem for me that programming students have no clue about working with existing project requirements. I've never seen any teaching nor any methodology come from the Agile movement let alone any other technical cultural phenomenon. If no one is concerned that the project moves from the business analyst role to the programming role, that must mean that the project really starts with the programmer because that's where the project deliverables really begin. And so, programmers have reverse-engineered analysis and design skill sets to cope by themselves,
Of course, real world projects are the practical training ground for understanding how to work with project teams, but couldn't we make this a part of the skill set for a programmer before they get thrown into the war room?
Web programmers are used to this. They are a department of one. They gather information on understanding customers' needs, write copy, design layouts, put the code together, and deploy and maintain a site. As the web application world expands, this puts immense pressure on the technical web employee to know about any new development and keep up their own skills tied to the legacy apps they maintain.
Programmers I talk to have an implicit distrust of the project. They find a purpose but no real detail in it and muddle through the development as best as they can. In fact, most businesses without a solid project management process don't have much to work with. The management will throw stuff out into the market and claim that the market is crazy. The analysts are documenting whatever anyone says and then complaining that the users don't know what they want. Coders code whatever they think is right and try to make the project manager's deadlines.
And testers. Standing at the end of the line with a deadline rapidly approaching doesn't make anyone try to establish any standards knowing that they are holding up the deployment. They just try to find as many bugs as possible in the time they have.
The programming students I see have not been trained in business so it's reasonable they don't know how good goals can drive their behavior. A couple of questions have always intrigued me when working with a software project:
- What if all the people on the project have the same goal?
- What if they all had documents that built on the previous documents and were traceable back to the original value-driven goals?
- What if the project was measured on how it realized that goal?
A project proposal should be estimated on value. Not only just a return on investment but understanding what the priority is for the enterprise. Value for internal projects can be seen as basically two parts but more can be added if justified:
- The number of people in the company that will use the project in their processes
- The visibility of that project in the organizational chart of the business so that if that project fails, the level of management involved determines the severity ticket level.
Value for external projects is estimated the same way. There are the same two metrics involved:
- The number of people in the market that will find value in using the product/service.
- The amount of money that the market is willing to spend to get that product/service
The two measures are both based on quantity of value. The project then can look back to this value of opportunity and see how to organize the project pieces. For instance, business goals, the basic business driven goals that begin the requirements process, are based on what value the business gets. Requirements meetings should never ask the question "What do you want the project to do for you?" because it's not about the person. The better question is "What should the project do to produce the best value for the business?"
Then, the business can see that the customers have needs where they should adapt their product/service to achieve the best solution to a large market segment. The question for the strategists and enterprise analysts would be "What can I do to help our customers/employees solve their problems?"
Business analysts would then understand that the value perceived at the strategy level should be communicated downstream to the programmers clearly. That communication should be able to move directly into testing of that code because the target of the project development effort is to communicate business value to the technical staff. The analysts' question then is "How does what the customer/staff do right now help them get tasks done?"
The designers have the task of taking the current processes and possible new processes and shoehorning them into a fit with the business assets so that it improves the value. They have to think about improving life in general. The question for them is "How can we translate the requirements into code/real life? The trick is to make it look like it's simple.
The final stage in the value transition from idea to final service/product is that someone double-checks that the value has actually arrived. That's the job of the tester who assures that the quality will be there though verifying minor things throughout the project and validating that the expectations were met at the end. Their questions are "How can I guarantee quality?"and "How can I let everyone know how well they did?
In making the move to measuring by value, the chain of FUD will change to the chain of quality. But there are lots more questions that I've asked and I'll continue this series by taking on those questions. Here's a sample of some:
- How should scope be measured by value?
- How should scope be organized by value?
- What is the role of analysis?
- What does a programmer need requirements to look like?
- What are good business quality metrics for code?
- Is TDD dead or alive?
