Agile in a non-Agile Environment
I’m into my second month at my new job. I remain amazed at the amount of documentation that is being generated. Being a Microsoft shop, almost everything finds its way into Sharepoint. I’m not against Sharepoint per-se, but I do find it very opaque, i.e. hard to find stuff.
Its like having a lot of interesting papers on my desk, but they are all inside sealed envelopes. I can open the envelopes, but when I’m done with it, it goes back in the envelope. Sometimes there are other envelopes inside the envelopes. As I said, very opaque, and very non-agile. Contrast with what I am used to, which is a Wiki. Totally searchable, easy to find what people have been editing. More like a nice folder with happy little index tabs.
Sharepoint rant over, moving on…
The Business Analysts (BAs) had a slow start, with the result that we started developing our product before they had really written any requirement documents about it. The result is that they are playing catch-up, and documenting what we have provided, and asking all of the questions that we should have asked while we developed it.
We do not have a single customer, or product champion. This means that the questions are difficult for anyone to answer effectively. It also means that the team is pulled in several directions:
- software architect tries to get us to do multi-tier and service-based and ultra secure at the expense of usability
- managers care mostly that it is done on time
- business analysts care about “checking off” features
- there is very little optimization of features, i.e. everything is equal priority
The result is that we have a fairly well architected, feature-full product that is hastily put together. Features are surface deep, i.e. we are not “done” to the level that an Agile team would normally consider “done”. Usability is low, and the product lacks perceived integrity.
Even given all of that, I remain optimistic. We have a solid team, and every day we work more closely together. As I understand more about the environment, I am able to make small adjustments to improve it. We have a lot of time left to deliver, and upper management expects that it will be very much a v1.0 product.
Steve,
With a bit of experience with SharePoint, success is improved with Information Architecture. In the absence of IA, the ontological aspects get lost in the “emergence” of data.
Oil & Gas, electric utilities, and aerospace are common environments where emergenece needs to be throttled with IA to the benefit of the overall system.
Even with IA, we plan for several iterations of the operational system to allow the user community to “evolve” there understanding of what they want.
No matter what approach – other than intentional dumb ones – deploying knowledge management systems is very sporty buisiness – IME.
I’m surprised your employer doesn’t give you a ration of —- for this but admire your willingness to post.
Curious: why are the BAs documenting what is already built, especially if you are agile? Why not just have them focus on the upcoming stuff?
Nice blog. I’d like to also reenforce Glen’s comment. MOSS can be tough, for sure, but the IA is all the difference, and those sealed envelopes are often very useful. It is, I guess, a bit of a tradeoff. Permissions vs. total transparency.
Still, yes, I think there is a better way as well.
Best,
Josh
@Josh, thanks for your comments on this post and others. The BAs document what has been built because we have an independent QA group that must signoff on the functionality. The documents are for them, so they know what to test. They will not test without the documents. I will change that eventually, but I’m still waiting on a good opportunity.