arborint wrote:I agree with onion that there needs to be some structure to the entire process when you have actual businesses involved.
I'm not quite sure what you are saying here. I don't think you are suggesting that agile is unstructured. Structure to me means planning and something methodical. Obviously structure is a good thing, we just need the right kind of structure and the right amount.
This is mainly because the non-technical parts of the business need to be able to think about the project with some kind of familiar reference.
Absolutely but I don't think the concept of an iterative, adaptive workflow is particularly technical. The practise of programming, data and user interaction is complex; it is these things that we have to communicate analogously. But to understand agile all you really need to know are a couple of truths about the nature of software development (the client doesn't even need to understand why these are the case, just accept them) and then you can explain how agile works to cope with the implications of these truths. I certainly feel that I could explain the reasons why agile is better than the waterfall methodology to my parents and they would understand. It's just business.
However, I really agree with Ollie that it is important to focus on what is important and what is actually known
Sure, we try to find out what is known but very often people know very little. We develop software based on assumptions. We assume that x interface will speed things up that y employ understands z term and there are so many of these you can't possibly go round asking everybody and testing whether they are true or not, you just have to implement them and observe the result: inspect and adapt. It gets rid of a lot of analysis, discussion and politics.
as you work through the entire process. I think it is actually easier than you might think. I tend to winnow it down by finding the things that 1) every agrees on, and 2) people will take responsibility for the decision.
That's probably a good approach considering how reluctant people are to stick their heads out. If that are willing it's got to be a safe bet.
Projects are often a bunch of people/depts dumb ideas assembled together into what looks like a coherent whole. We always find the truth later.
Yes, this way nobody is responsible if it should fail. This indicates a negative corporate culture though, one that expects to fail, one that prefers damage limitation over working to ensuring success, one where employees compete to achieve rather than work together.
(It is interesting that this is often because the business rules of the company are actually broken, but are made to work by some human system specific to that business they have implemented to work around the broken rules.)
What do you mean by this?
In answer to onion's comment that his clients would not be able to answer the question "what is most important" -- that's why they hired you. You need to listen to what they are saying, not necessarily what they say.
It is your responsibility as much as it is the client's. Neither of you can do it alone. But the beatify of agile is that you don't have to get it right first time, there's lots of opportunity for correction so you don't have to come into the business like an arrogant management consultant and attempt to find all the worms under the stones and really nail things down in specs you just have to use a bit of intuition.
I think one of the most important things is to listen for the Ubiquitous Language of the group. Then you can use terms that are understood, define terms that are not defined, and find new terms when there is disagreement within the group. If you can talk really about then you can do it well.
I might be missing something but I would say this is a side point to our discussion. I definitely agree though. Good terminology can save so much time and prevent many misunderstandings.
And I want to emphasize the "really" in some of these Agile ideas. There is a different in thinking you know something and really understanding it. There is a difference between talking about the project and really communicating project ideas.
If you can get real business people together and write user stories with them you'll quickly find out what is known and what isn't.
I just did a project the last couple weeks. I only did back-end work. The communication was mainly between the designer and the client. It did not go that smoothly (at least from my POV) because the designer did not focus first on: the known stuff, the common stuff and the basic stuff.
Can you tell us more? What did he miss? What was the project?
And they implemented some things early in the process that the client said they wanted, even though it was obvious they would be problematic or not work.
I would be interested to know what those things were.