Books, websites and consultants are telling us to move to some form of Agile- and, once the consultants get a hold of it, it's going to morph- which it has. Since when is Scrum a method? It's a meeting and project management tool. ARGH!
Now, the Agile Manifesto says two things that I've never seen:
...the guy or gal the Agile Book Writers either ignored, blew off on a simple process flow diagram or forgot existed. Bad move, Scrum Master/Project Manager/Team Lead.
If you really have top developers who can pull requirements from users, you still need the BA to introduce them, set up the meeting, attend the meeting to translate the jargon on both sides and provide a written record of what happened to eliminate the finger pointing later.
If you don't have top developers and are heading smaller teams with your best and brightest, who's getting your requirements? You're wasting time and resources if you grab the requirements in a demonstration or from comments/issues generated from your sandbox environment. Oh yeah- the stakeholders and the end users loose faith in your DevTeam because they didn't get it right the first time (Agile takes a while to settle into everyone's mind). Once you've lost faith, you've lost the project.
Scrum or Stand Up Meetings
I learned this system at Pathfinder Development under the tuteladge of CTO Dietrich Kappe.
We're assuming a two week sprint schedule here. The BA is working one sprint or iteration ahead of the current development work.
Each day, the team meets in a Scrum or Stand-up meeting. Only the DevTeam and Design Team participate. The Business Team provides support and listens for status changes. Each DevTeam member answers these three questions:
Requirements Gathering
The first couple of days, the BA generates a proposed list of Features and Issues (Fixes) for a sprint. The BA gets preliminary approval from the business team, architect or lead developer and the project manager.
The BA then meets with Subject Matter Experts, end users and stakeholders to gather enough detail to write preliminary User Stories for the list. After they're written, the BA returns to make sure the stories and tests are accurate. Once the BA has preliminary approval, the BA writes a more detailed specification. It may include data maps, wireframes, interfaces, flow charts, step action tables- in short, everything the Developer should need to code the item.
The BA then presents the stories and specifications to the Stakeholder (to verify accuracy and need) and to the Architect/Lead Developer. This check helps the BA and the DevTeam Lead to:
The current sprint ends. The Agile Manifesto says Agile Projects are test-driven. The developer does the usual boundry and smash tests. Guess who does the Alpha testing? Me. I use the minimal tests in the User Stories to create scenario-driven Test Cases (and usually test scripts since 99 times out of 100 I'm going to add the script to User Acceptance Testing later). This is sort of the reason I usually handle issues management. We don't want the client/customer to see really ugly stuff.
One- three days are scheduled to allow the Developers to read the new User Stories and Specifications, ask questions and begin deciding how complex each item may be. The BA either answers the questions or properly routes them to the Business Team.
The entire team meets for a review session of the most recently completed sprint. The BA records Best Practices, Suggestions and Proposals for Change.
The Kick-Off Meeting
The new sprint starts with a Kick-Off Meeting. Each proposed Feature or Issue is brought to the table and the DevTeam can ask the Business Team or the BA questions. The DevTeam then assigns a complexity rating on each item. Ballpark hourly estimates are awarded to each complexity level and then everyone can see if all the items can be done in the time allocated. If it can, great, the developers start coding and the BA starts the next sprint's proposed list.
If not, the BA and the Project Manager negotiate with the Business Team about additions and deletions to the list. A proposed list is given to the DevTeam. If accepted, great, we're off. If rejected, we re-negotiate.
Change Management and Scope Creep
Any changes made or requested during the sprint has to go through this process, at least informally, because the DevTeam is responsible for each item on the list. Idf the business team wants something new, something old has to go off the list. If the DevTeam is having a problem with an item, after root cause determination and proposed mitigation planning, the Business Team needs to make a decision on continuing or stopping development on that item.
Demonstrations and Communication
I've worked mostly 'distributed' Agile projects. I was with the DevTeam in our offices and the client/customer was somewhere else with the Project Manager. This sort of made me Assistant-Associate-Deputy-Vice Project Manager, doing what the PM needed done.
Typically, if we had a test environment, I create an e-mail list of all appropriate folks to tell them a. what's been changed and b. what the user should expect.
If there was no test environment (usually very early in the project), one of the developers will run a demonstration and let the demo meeting attendees play with the software.
I got all the issues, suggestions and complaints. I loved this part since Agile allows us requirement gatherers to ignore the bane of all BAs, IAs and Project Managers: Hidden Requirements. There are non by definition since the end user is playing with the actual product. That means we can change on a dime and make UAT Test Cases and Scripting easy.
Governance
1. The project needs to support the business. Gee-Whiz Stuff can either be pushed into the backlog or eliminated.
2. The business controls the functionality, prioritization and resource allocation.
3. The DevTeam designs, adapts or creates new business processes, researches technology and presents code to the business.
4. The DevTeam Leadership describes expected or potential outcomes from a decision as well as providing the business with options and a recommendation. The business is responsible for the decision (see #2).
5. Like any other project type, software development is controlled by time, resources and scope. If anything changes within a sprint, a release or an implementation, the business makes the decision.
Now, the Agile Manifesto says two things that I've never seen:
- Business People and Developers must work together daily throughout the project.
- Face-to-face discussion is the best communication tool we have.
- Item: Business people seem to have overflowing plates and are too busy to allocate a fraction of time to a development project every day.
- Item: We're lucky if we get a user to a demo or five minute play session in the sandbox environment much less regular face-to face meetings.
- Item: When was the last time you saw a member of the business team actually write a User Story? A Specification? Comment on an existing Story or Spec? Thought so. The only good thing about a Waterfall Shop is the Stakeholder actually reads the Stories and Specifications. Badly, inaccurately, but they read 'em.
- Item: And who's had the business team member actually empowered to make real decisions? Not in a consultant-client governance project and certainly not in an organization that is, necessarily, a waterfall shop moving to Agile.
...the guy or gal the Agile Book Writers either ignored, blew off on a simple process flow diagram or forgot existed. Bad move, Scrum Master/Project Manager/Team Lead.
If you really have top developers who can pull requirements from users, you still need the BA to introduce them, set up the meeting, attend the meeting to translate the jargon on both sides and provide a written record of what happened to eliminate the finger pointing later.
If you don't have top developers and are heading smaller teams with your best and brightest, who's getting your requirements? You're wasting time and resources if you grab the requirements in a demonstration or from comments/issues generated from your sandbox environment. Oh yeah- the stakeholders and the end users loose faith in your DevTeam because they didn't get it right the first time (Agile takes a while to settle into everyone's mind). Once you've lost faith, you've lost the project.
Scrum or Stand Up Meetings
I learned this system at Pathfinder Development under the tuteladge of CTO Dietrich Kappe.
We're assuming a two week sprint schedule here. The BA is working one sprint or iteration ahead of the current development work.
Each day, the team meets in a Scrum or Stand-up meeting. Only the DevTeam and Design Team participate. The Business Team provides support and listens for status changes. Each DevTeam member answers these three questions:
- What did you do yesterday?
- What problems did you face?
- What are you going to do today?
Requirements Gathering
The first couple of days, the BA generates a proposed list of Features and Issues (Fixes) for a sprint. The BA gets preliminary approval from the business team, architect or lead developer and the project manager.
The BA then meets with Subject Matter Experts, end users and stakeholders to gather enough detail to write preliminary User Stories for the list. After they're written, the BA returns to make sure the stories and tests are accurate. Once the BA has preliminary approval, the BA writes a more detailed specification. It may include data maps, wireframes, interfaces, flow charts, step action tables- in short, everything the Developer should need to code the item.
The BA then presents the stories and specifications to the Stakeholder (to verify accuracy and need) and to the Architect/Lead Developer. This check helps the BA and the DevTeam Lead to:
- Make certain each item is technically do-able.
- Make a preliminary judgment on whether the item can be done within a single sprint or needs to be split into components.
- Confirm dependencies.
The current sprint ends. The Agile Manifesto says Agile Projects are test-driven. The developer does the usual boundry and smash tests. Guess who does the Alpha testing? Me. I use the minimal tests in the User Stories to create scenario-driven Test Cases (and usually test scripts since 99 times out of 100 I'm going to add the script to User Acceptance Testing later). This is sort of the reason I usually handle issues management. We don't want the client/customer to see really ugly stuff.
One- three days are scheduled to allow the Developers to read the new User Stories and Specifications, ask questions and begin deciding how complex each item may be. The BA either answers the questions or properly routes them to the Business Team.
The entire team meets for a review session of the most recently completed sprint. The BA records Best Practices, Suggestions and Proposals for Change.
The Kick-Off Meeting
The new sprint starts with a Kick-Off Meeting. Each proposed Feature or Issue is brought to the table and the DevTeam can ask the Business Team or the BA questions. The DevTeam then assigns a complexity rating on each item. Ballpark hourly estimates are awarded to each complexity level and then everyone can see if all the items can be done in the time allocated. If it can, great, the developers start coding and the BA starts the next sprint's proposed list.
If not, the BA and the Project Manager negotiate with the Business Team about additions and deletions to the list. A proposed list is given to the DevTeam. If accepted, great, we're off. If rejected, we re-negotiate.
Change Management and Scope Creep
Any changes made or requested during the sprint has to go through this process, at least informally, because the DevTeam is responsible for each item on the list. Idf the business team wants something new, something old has to go off the list. If the DevTeam is having a problem with an item, after root cause determination and proposed mitigation planning, the Business Team needs to make a decision on continuing or stopping development on that item.
Demonstrations and Communication
I've worked mostly 'distributed' Agile projects. I was with the DevTeam in our offices and the client/customer was somewhere else with the Project Manager. This sort of made me Assistant-Associate-Deputy-Vice Project Manager, doing what the PM needed done.
Typically, if we had a test environment, I create an e-mail list of all appropriate folks to tell them a. what's been changed and b. what the user should expect.
If there was no test environment (usually very early in the project), one of the developers will run a demonstration and let the demo meeting attendees play with the software.
I got all the issues, suggestions and complaints. I loved this part since Agile allows us requirement gatherers to ignore the bane of all BAs, IAs and Project Managers: Hidden Requirements. There are non by definition since the end user is playing with the actual product. That means we can change on a dime and make UAT Test Cases and Scripting easy.
Governance
1. The project needs to support the business. Gee-Whiz Stuff can either be pushed into the backlog or eliminated.
2. The business controls the functionality, prioritization and resource allocation.
3. The DevTeam designs, adapts or creates new business processes, researches technology and presents code to the business.
4. The DevTeam Leadership describes expected or potential outcomes from a decision as well as providing the business with options and a recommendation. The business is responsible for the decision (see #2).
5. Like any other project type, software development is controlled by time, resources and scope. If anything changes within a sprint, a release or an implementation, the business makes the decision.
Powered by ScribeFire.
Posts
No comments:
Post a Comment