I work as an SAP Solution Manager consultant and Testing Expert. Being a certified Professional Scrum Master always makes me want to help customers become more agile. "Fast, Safe, and Cost-effective", says Inventy. Long story short: this article is not focused on SAP but aims at giving you a general overview of the agile SCRUM framework! Have a look at SAP Activate methodology if you're interested in SAP-centric agile framework.
Agile software development is not for everyone.
Let me first get one thing straight: you have no need to be "agile" if you face little change and uncertainty in your project. The Agile Manifesto (Google it now!) provides fantastic ways to reduce costs and risks, and better meet customers' expectations, under the assumption of change. It is in the best interest of startups and small companies to "fail fast", because immediate customers' feedback help them uncover what people really need - not just what they said would be nice to have, unless you want to end up with months of delay due to wrong need assessment. A system optimized for reliability and reproducibility is more valuable when products have started to become interchangeable, or have been converted into a service you can buy.
"Let me get back to you in 24 months."
Agile software development is nothing more than breaking your next realease into small shorter cycles (usually, between 1 and 6 weeks), instead of delivering a single huge realease with features that may or may not convince your customer. A cycle (or "Sprint", or "iteration") is basically a mini implementation project that focuses on your new incremental functionality, and will be your next go-live release. Many SAP consultants prefer a longer Sprint length because it gives you a false sense of safety, and feels more like the Waterfall approach you are familiar with and need to get away from.
Because the team will have no time to waste in the process, work has to be performed in a highly collaborative manner. This means real-time communications, such as regular face-to-face interactions, rather than sending dozens (more likely hundreds) of emails a day; and a team that is composed of developers, analysts, consultants, domain leads and facilitators (interaction designers, sponsors, etc.). Please note that Scrum puts emphasis on shared responsibility: you fail as a group. More importantly, you succeed as a group, so you must secure quick wins as early as possible to motivate the team to keep going.
It is all about you.
The Agile Manifesto and the Scrum methodology are two different things: the first one will always be a prerequisite to the second. Scrum aims at facilitating agile development (SAP implementation), and enabling the creation of self-organizing agile teams. For example the Scrum Master certification that many people are looking for, should help you assuming the role of both a traditional project manager (centralization, coordination) and a facilitator (through guidance, and coaching). Project managers should not direct the team, but rather helping a team member to feel committed to the other team members.
Milestones for Agile-Scrum development projects.
* The Kickoff meeting (ie. half a day). This should be an introduction to the project requirements, with selected "user stories" to de decomposed into programmable tasks with the time estimates for completion. You should try to give visibility into who is the customer, what it is that you try to achieve, and why it is so important for your team to perform well.
* The Iteration meeting. The team members collectively decide the "Sprint backlog", which is a list of prioritized work to be done per sprint. Unlike the Kickoff meeting you want your people to get the details about what they are expected to do. Anyone should be welcome to add or remove tasks, which are then distributed among the team on a per voluntee basis. The ScrumMaster, if you hired one, will help build personal commitment to the team.
* The Daily meeting. Same time, same place, everyday. No one is allowed to sit, unless the doctor said so. Team members should individually answer to 3 simple questions: 1) What have I accomplished since the last meeting?; 2) What will I be working on next?; 3) What are the problems preventing me from achieving goals?. You want to be sure that everyone among the team moves towards the same Sprint goal, and changes priorities if it's been decided as such.
* The Retro meeting. At the end of each Sprint you should be presenting what the team has accomplished. You can also use such an occasion to gather the team, and evaluate what worked well, or what needs to be improved during the next Sprint.
(IBM - "Scrum. Sprint. Burndown.")
How is this useful to QA Testing?
Agile thinkers are convinced that testing (go with Solution Manager 7.2 Test Suite!) needs to be integrated throughout the entire iteration cycle, whereas traditional project managers consider it should be a phase at the end. Once again, there is nothing wrong with a separate testing phase when your project is something you know you can do with your eyes closed. But it is very dangerous to adopt formal methodologies, or even Lean thinking, if have no idea of what is just around the corner.
A sad truth is that rivalry is strong between quality testers and consultants. Because testing professionals are involved from the start, and have the same information about requirements and customers' needs at the same time, communication and collaboration are usually better among QA and consultants. They work towards a common goal, and are reinsured of this through daily meetings. Building self-organized teams also means that everyone's voices carry the same weight, but produce complementary work: testers are better at identifying alternatives, while consultants (analysts) deliver concrete results.
But optimization is the real thing here. Since there is no separate test phase, short development cycles and new releases all the time ask for the best on a daily basis. We know at least two efficient ways of planning and performing testing efforts efficiently: 1) exploratory testing (looking for bugs or missing features) at the beginning of each new sprint, or following any change to a product feature within the cycle; 2) automated testing (go with Solution Manager 7.2 CBTA!) throughout the project, meaning that you need to build scrips and test cases for every features.
- SAP Managed Tags:
1 Comment
