Anytime there's been a failure on a project in iterative and waterfall methods, the first thing you see is finger pointing. Either as a CYA maneuver or as a means, they think, of root cause analysis
Both sides can point to pieces of paper that tell them they are right. Which is cool because they can use that paper to wipe off their lathered faces.
Remember that one of the Agile goals is to generate useful code, not create documentation. Despite what may appear to be a stand that goes against my vocational goals (BAs control the documentation in Waterfall and Iterative projects), I think a pile of paper is counterproductive. M-Gates be damned.
I've more important stuff to do than write stuff that no one reads. So do you.
Unless, and this is important, you have regulatory requirements (HIPPA, SOX, FDA, etc) or the customer wants documentation (in which case, you find out what they want and chances are it's usually a user manual or Admin manual which I can whip up in less than a week- usually).
The only place I've worked where the business actually read Use Cases (instead of looking at my color flow charts) was at a pretty big company. The managers there knew a multi-million dollar application which touched pretty much every server or mainframe in the house probably required them to read the Use Cases. And they provided superb feedback (at least to me). But the developers weren't reading the use cases.; And Because our company didn't allow us (the BAs and there were a lot of us) to talk to the developers, you wouldn't believe what the issues list looked like.
Just before everything blew up, we had a meeting. We were going to make this Agile stuff work, damn it. All we need is a new template.
A template for what, I asked
For requirements!
You think a template is going to clean up the process?
Yes!
No, templates only help standardize the results of requirements gathering...we have a governance issue.
Sit down, Scot.
I gave them all the reasons we weren't Agile.
We are MODIFIED Agile
Obviously, no one in my company had read the Agile Manifesto. Agile, by definition, adjusts to change and issues. There's no such thing as 'Modified Agile,' because all Agile projects are modified (Teams are self organizing, remember?).
But the finger pointing stopped, by gosh. One day the champion came over to our area and asked us all to get our stuff and leave. We piled all the stuff in our manager's trunk- he had no idea what was going on. A week later we all found out that our company hadn't been paid for five months before they hired me. I can guess the reason. But the finger pointing stopped, by golly!
I won't tell you an Agile Project can't fail. They have and they will continue to for a variety of reasons- scalability comes immediately to mind as does risk management and lack of buy-in.
But done with a little bit of care and a committed business unit, Agile eliminates the finger pointing.
God I hate finger pointing. Let's just figure out what went wrong and fix it. Anyone can make a mistake.
No matter how many SMEs (Subject Matter Experts), Stakeholders and champions you think you have on your team, it won't work unless the business frees the application owner or designate to spend a significant amount of time on the project (say 25-50% depending on how well communication works). This person needs to be able to:
I thought so.
Assign a decision maker to the development team and back them up when the need arises.
- The Business tells the DevTeam it should have been able to deliver what it wanted or needed in time to make <fill in the blank here>.
- The DevTeam tells the business in a slow, methodical manner that when one keeps adding more and more features and more and more complexity, one needs to either add additional developers or stretch the final release to a more reasonable time.
Both sides can point to pieces of paper that tell them they are right. Which is cool because they can use that paper to wipe off their lathered faces.
Remember that one of the Agile goals is to generate useful code, not create documentation. Despite what may appear to be a stand that goes against my vocational goals (BAs control the documentation in Waterfall and Iterative projects), I think a pile of paper is counterproductive. M-Gates be damned.
I've more important stuff to do than write stuff that no one reads. So do you.
Unless, and this is important, you have regulatory requirements (HIPPA, SOX, FDA, etc) or the customer wants documentation (in which case, you find out what they want and chances are it's usually a user manual or Admin manual which I can whip up in less than a week- usually).
The only place I've worked where the business actually read Use Cases (instead of looking at my color flow charts) was at a pretty big company. The managers there knew a multi-million dollar application which touched pretty much every server or mainframe in the house probably required them to read the Use Cases. And they provided superb feedback (at least to me). But the developers weren't reading the use cases.; And Because our company didn't allow us (the BAs and there were a lot of us) to talk to the developers, you wouldn't believe what the issues list looked like.
Just before everything blew up, we had a meeting. We were going to make this Agile stuff work, damn it. All we need is a new template.
A template for what, I asked
For requirements!
You think a template is going to clean up the process?
Yes!
No, templates only help standardize the results of requirements gathering...we have a governance issue.
Sit down, Scot.
I gave them all the reasons we weren't Agile.
We are MODIFIED Agile
Obviously, no one in my company had read the Agile Manifesto. Agile, by definition, adjusts to change and issues. There's no such thing as 'Modified Agile,' because all Agile projects are modified (Teams are self organizing, remember?).
But the finger pointing stopped, by gosh. One day the champion came over to our area and asked us all to get our stuff and leave. We piled all the stuff in our manager's trunk- he had no idea what was going on. A week later we all found out that our company hadn't been paid for five months before they hired me. I can guess the reason. But the finger pointing stopped, by golly!
I won't tell you an Agile Project can't fail. They have and they will continue to for a variety of reasons- scalability comes immediately to mind as does risk management and lack of buy-in.
But done with a little bit of care and a committed business unit, Agile eliminates the finger pointing.
God I hate finger pointing. Let's just figure out what went wrong and fix it. Anyone can make a mistake.
No matter how many SMEs (Subject Matter Experts), Stakeholders and champions you think you have on your team, it won't work unless the business frees the application owner or designate to spend a significant amount of time on the project (say 25-50% depending on how well communication works). This person needs to be able to:
- Make decisions for the business.
- Negotiate sprint features lists with me (the Business Analyst).
- Help me develop the road map.
- Coordinate Change Management with me or assist in coordinating with the business' own Change Management Team.
- Attend as many Scrum/Stand Up Meetings as possible.
- Perform the same Alpha tests that I do on a new build in production.
- Cheer lead for the end users to play with the application and get feedback.
- Co-Plan each UAT (User Acceptance Test) round with me so we're actually testing requirements.
- Let me help them create User Stories and tests. Agile is test-driven and the developer needs to know when s/he is done. So do I, so I can test boundaries and functionality.
- And stay on top of everything like the Project Manager and me.
I thought so.
Assign a decision maker to the development team and back them up when the need arises.
Powered by ScribeFire.
Posts
