The MetaScrum is the meeting where all decisions product are made and/or heard by representative decision makers from all areas of the company. Typically this is a weekly meeting run by the Master Product Owner and supported by the CEO. The agenda includes a charter of meeting rules, objective, current sprint status update and upcoming sprint plan. Depending on the company culture, more items may be included that impact the product release cycles. One of the most important rules to enforce is that all priority order changes must be made in the meeting and supported until the next meeting. These meetings can be critical to helping the product management and development teams focus on getting things.
I will be posting links to sample formats and documentation.
Thursday, March 29, 2012
Monday, March 26, 2012
Implementing new user experience design
When it comes to agile requirements, user experience and creative design implementation often becomes a challenge especially for large organizations. I have many different approaches to recommend but I will share one way that was wild successful for me.
Assume the user experience flow will require refinement after the screens have been developed and after real end users have used the system in their physical environment. The key is to partner closely with your customers at any given time in your planning, development and release lifecycles.
Below is a phased approached. Make sure you have thoughtfully identified minimum task completion, don't try to solve the experience for everything in your roadmap. If you listen to your market, they will adopt new feature flows and experience changes if you always do the right thing.
Phase1 (Mockup, Design, style guide and slices)
-------------------------
- Basic look and feel design and core user conventions. Conduct story mapping and identify only what tasks are necessary.
- Usability testing and feedback sessions with clients, user groups and CMIO panel
- Upload designs to central repository for review by all SMEs and front end architect. Time box feedback and move on.
- Work with product analysts or BAs to finalize user stories
- Requirements ready for development
Phase 2 ( In Development)
-------------------------
- Implement Design using artifacts provided by Creative
- Creative available for questions
Phase 3 (Beta Feedback and Refinements)
-------------------------
- Review implementation by development, make recommendations and refinements
- Beta Test Case feedback from client and product owner
Saturday, March 24, 2012
Helpful Tips - Scrum Feature Teams
Scrum feature teams make up vertical slices of areas of expertise to form cross-functional teams. Feature teams can help a company scale by allowing team to take ownership of active projects in-flight that must be released in parallel.
Please note, unless your architecture is stable and modules are completely stand alone, be mindful of how many major features are being releasing in a given sprint. I recommend the team limit the number of active projects and never start a new project until the current one is 'shelf ready'
Helpful Tips for Choosing Feature Team Members
* There must be a Lead Product Owner or Master Product Owner that oversees all the inputs and outputs
Per each feature team:
1. One Product Owner. Each feature team should consist of only one product owner. I will start another discussion on this topic when the same resources are responsible for projects belonging to different product owners.
2. One ScrumMaster. An experience ScrumMaster is recommended to teach both the product owner and the team to work through sprint goals.
3. The Team. Try to keep the team size limited to three to four developers and no less than one IT QA staff per feature team.
1. Make it very clear to all team members that no one is the boss, it is a horizontal org chart with everyone answering to the client. Everyone is a subject matter expert of their team function. Each person is held accountable for their role and responsibility during the sprint.
2. If teachers are limited, train development first. Developers appreciate Scrum if you point out that requirements and priorities do not change after the sprint is locked and committed to by the feature team. Check out Jeff's article on shock therapy - http://scrum.jeffsutherland.com/2012/01/scrum-shock-therapy-how-to-change-teams.html
3. Train Product Owners on how to write a user story and break it down into manageable parts. Provide high level training on the Scrum Framework, don't reinvent the wheel, use material provided by your Scrum Certified Professional or what is available on the Scrum Alliance.
4. VERY IMPORTANT - When the team completes estimations and goals can be selected, make sure there is a face to face meeting in which the sprint goals are clearly defined and committed to. The ScrumMaster only locks the sprint goals when the expression on every team members face shows comprehension.
5. Define a Sprint Activity Calendar and Checklist per each role. This is most helpful when there are old waterfall mindsets on the team.
6. Let the feature team members attempt to follow the checklist according to their role, make the ScrumMaster responsible for ensuring all members complete a full set of checklists by the end of the sprint.
7. The Scrum Coach or Scrum of Scrum Masters must conduct one on ones with each team member on a daily or weekly basis.
8. RETROSPECTIVE IS KEY. Inspect and adapt. Train on what is most important, not on everything under the sun, or shall I say 'under the Scrum'.
Please note, unless your architecture is stable and modules are completely stand alone, be mindful of how many major features are being releasing in a given sprint. I recommend the team limit the number of active projects and never start a new project until the current one is 'shelf ready'
Helpful Tips for Choosing Feature Team Members
* There must be a Lead Product Owner or Master Product Owner that oversees all the inputs and outputs
Per each feature team:
1. One Product Owner. Each feature team should consist of only one product owner. I will start another discussion on this topic when the same resources are responsible for projects belonging to different product owners.
2. One ScrumMaster. An experience ScrumMaster is recommended to teach both the product owner and the team to work through sprint goals.
3. The Team. Try to keep the team size limited to three to four developers and no less than one IT QA staff per feature team.
Helpful Tips for Training your Feature Teams
For members new to Scrum1. Make it very clear to all team members that no one is the boss, it is a horizontal org chart with everyone answering to the client. Everyone is a subject matter expert of their team function. Each person is held accountable for their role and responsibility during the sprint.
2. If teachers are limited, train development first. Developers appreciate Scrum if you point out that requirements and priorities do not change after the sprint is locked and committed to by the feature team. Check out Jeff's article on shock therapy - http://scrum.jeffsutherland.com/2012/01/scrum-shock-therapy-how-to-change-teams.html
3. Train Product Owners on how to write a user story and break it down into manageable parts. Provide high level training on the Scrum Framework, don't reinvent the wheel, use material provided by your Scrum Certified Professional or what is available on the Scrum Alliance.
4. VERY IMPORTANT - When the team completes estimations and goals can be selected, make sure there is a face to face meeting in which the sprint goals are clearly defined and committed to. The ScrumMaster only locks the sprint goals when the expression on every team members face shows comprehension.
5. Define a Sprint Activity Calendar and Checklist per each role. This is most helpful when there are old waterfall mindsets on the team.
6. Let the feature team members attempt to follow the checklist according to their role, make the ScrumMaster responsible for ensuring all members complete a full set of checklists by the end of the sprint.
7. The Scrum Coach or Scrum of Scrum Masters must conduct one on ones with each team member on a daily or weekly basis.
8. RETROSPECTIVE IS KEY. Inspect and adapt. Train on what is most important, not on everything under the sun, or shall I say 'under the Scrum'.
KISS - Keep It Simple Silly
Every meeting room used for sprint planning by product management and development should have a laminated poster that says 'Keep It Simple Silly'. This advise is timeless when it becomes obvious that the teams are over complicating the software design.
Subscribe to:
Posts (Atom)