I facilitated an Open Space event at APLN-Richmond last night. (Open Space is great. Recommended.) Steve led a session that started with the idea: Scrum is inadequate when it comes to requirements gathering. What should we do?
My first response to him (offline) was that Scrum does not try to directly address requirements gathering (not my favorite phrase for that area of work), nor indeed any of the engineering practices. Scrum allows the team, in its situation, to use the engineering practices that are available, that they know best, and that fit best. Scrum most definitely does say: start with good engineering practices and improve them.
But first, is this topic appropriate for an Agile Business blog?
Should business people care?
My answer: Yes. Definitely...Yes.
Why?
To me Agile is about collaboration. We want an intermixing of the Business people and the Technical people. In fact, it would be ideal if every person were both a business person and a technical person.
More specifically, Agile in a way mixes up the work in such a way that all the larger engineering practices must be done together, as a collaboration that includes business and technical skills. I am thinking business value-story-testing-coding here (with Test Driven Development).
And even if some engineering practices are done solely by technical people, they are done in the open, and immediately the business people care.
If the engineering practices can be improved, the business people will see the benefits immediately. If I were a business person on a project, I would care whether the team has constantly improved its the engineering practices. The work will go faster, the quality will be better.
For some, though, this will seem counter-intuitive. To them, all engineering practices belong to the technical people only. That's how the word is defined for them. Business people don't do "engineering".
Of course, this is consistent with the waterfall-like notion that "I gave you the basic idea, now go off and do it. And don't bother me until you're done". Do doubt many of you have heard one or another version of that.
We have found that that approach doesn't work. Or not very well. Many reasons; perhaps the leading, irreducible reason being that there is too much change happening.
It also turns out that engineering practices, for a team, are somewhat different that civil engineering (which my niece does). Software is work done by and with people. Yes, some machines and technology are involved, but the real action is with the people. And almost magical. So, it is engineering where the main creative tools are....people. Umm? (So, are people skills engineering practices? And what are people skills anyway? If I study 'em, can I get a certificate in that?)
The two bits of magic
To me, building products has two main bits of magic. You start with the business value idea, and somehow that must get into code. This communication or transformation must somehow happen. As if by magic. All else is Type II muda (necessary waste).
The second bit of magic is taking working code and surrounding it with all the things necessary to release the business value. Since the release of business value itself (eg, delivery of customer satisfaction) is really key, perhaps it is better to say, "placing the code in a complete environment where it can help release business value."
Those engineering practices are part and parcel of making this magic happen.
Who must do what now?
In an earlier post I suggested that the techies must learn about business value, and understand a lot more about it. Now I have said that the business guys have to learn about software engineering.
But the responsibilities are greater than that. The biz dudes need to explain business value in a way that the geeks can understand. And the IT professionals must explain engineering practices to the suits without looking down their noses, like they were talking to a person who doesn't know what a kilobit is. Neither one is a dark art.
A final reason to care
You should care if you care about the delivery of business value, and about the success of the project.
My first response to him (offline) was that Scrum does not try to directly address requirements gathering (not my favorite phrase for that area of work), nor indeed any of the engineering practices. Scrum allows the team, in its situation, to use the engineering practices that are available, that they know best, and that fit best. Scrum most definitely does say: start with good engineering practices and improve them.
But first, is this topic appropriate for an Agile Business blog?
Should business people care?
My answer: Yes. Definitely...Yes.
Why?
To me Agile is about collaboration. We want an intermixing of the Business people and the Technical people. In fact, it would be ideal if every person were both a business person and a technical person.
More specifically, Agile in a way mixes up the work in such a way that all the larger engineering practices must be done together, as a collaboration that includes business and technical skills. I am thinking business value-story-testing-coding here (with Test Driven Development).
And even if some engineering practices are done solely by technical people, they are done in the open, and immediately the business people care.
If the engineering practices can be improved, the business people will see the benefits immediately. If I were a business person on a project, I would care whether the team has constantly improved its the engineering practices. The work will go faster, the quality will be better.
For some, though, this will seem counter-intuitive. To them, all engineering practices belong to the technical people only. That's how the word is defined for them. Business people don't do "engineering".
Of course, this is consistent with the waterfall-like notion that "I gave you the basic idea, now go off and do it. And don't bother me until you're done". Do doubt many of you have heard one or another version of that.
We have found that that approach doesn't work. Or not very well. Many reasons; perhaps the leading, irreducible reason being that there is too much change happening.
It also turns out that engineering practices, for a team, are somewhat different that civil engineering (which my niece does). Software is work done by and with people. Yes, some machines and technology are involved, but the real action is with the people. And almost magical. So, it is engineering where the main creative tools are....people. Umm? (So, are people skills engineering practices? And what are people skills anyway? If I study 'em, can I get a certificate in that?)
The two bits of magic
To me, building products has two main bits of magic. You start with the business value idea, and somehow that must get into code. This communication or transformation must somehow happen. As if by magic. All else is Type II muda (necessary waste).
The second bit of magic is taking working code and surrounding it with all the things necessary to release the business value. Since the release of business value itself (eg, delivery of customer satisfaction) is really key, perhaps it is better to say, "placing the code in a complete environment where it can help release business value."
Those engineering practices are part and parcel of making this magic happen.
Who must do what now?
In an earlier post I suggested that the techies must learn about business value, and understand a lot more about it. Now I have said that the business guys have to learn about software engineering.
But the responsibilities are greater than that. The biz dudes need to explain business value in a way that the geeks can understand. And the IT professionals must explain engineering practices to the suits without looking down their noses, like they were talking to a person who doesn't know what a kilobit is. Neither one is a dark art.
A final reason to care
You should care if you care about the delivery of business value, and about the success of the project.
No comments:
Post a Comment