Scrum and Documentation.(use cases/ test cases). ?

I know I was suppose to write few posts totally focused on practical aspects of user stories. But I thought to write this post first, because last week I had an interesting discussion at office which could be really useful to other agile practitioners as well.
We were talking further about agile testing. Especially with Scrum. We do have a separate well focused QA team managed by an experienced QA lead. In our model, the QA department is independent from any projects and they directly report to the Project Director. So how does this model work with SCRUM? I find sometimes its bit contradicting with concepts. We know Scrum has cross functional teams and each developer is responsible about their Quality. However, there can be testers too working in scrum team full time, they will be team members within the scrum team and coordinate with the scrum master. But if the QA department runs separately how do we do that? We had 2 options. Running 2 scrum teams for same project, you can call it scale up scrum, one for QA and one for Development, then have scrum of scrum everyday to synchronize with 2 teams. The 2nd option was for QA team to give permanent QA resources to each scrum team and they will apart from the QA department. In that case it would be an organizational change as well as we will be losing the concept of the power of an independent QA team who certify the delivery before delivering to the end customer.We thought of maintaining the same independent QA team and still to run Scrum ( if you don’t like me calling scrum for this method.. sure .. you can call it something different.:). ) But then the biggest problem is that how the QA team members get the knowledge of the product? Because, in a Scrum team the documentation is very less. We don’t create lengthy specifications and pass them over the wall. Then how does my independent QA team get this knowledge from the development team who participate the Product backlog planning meetings and sprint planning meetings.The following are the points we discussed;
1. One QA member of the QA dept participate the product backlog meetings as well as sprint planning meetings.
At the product backlog planning meeting, the assigned QA member with the team will decide which user stories will need use cases. Further, we discuss about using some very light weighted use case only when required. You can find a good article on some light weighted use cases for Scrum in http://breathingtech.com/2009/writing-use-cases-for-agile-scrum-projects/

2. Once the product backlog planning is over , the QA team member who participated the product backlog meeting will educate the QA dept head about the scope of work in QA dept with regard to the project.
3. In the sprint planning meeting, when the team decides of which vertical to be focused on, the team will create those use cases only for the specific selected vertical for the particular sprint. For that sprint, the sprint should have tasks and enough space to complete the use cases. In this case sometimes we may have to go away from our usual 2 weeks sprints to 4 weeks sprint.

4. Once the team finishes the required use cases, they will sign in to development tasks. The QA will have tasks to create the test cases during the sprint. So now we have test cases too.
5. Once the iteration is done (At the end of the sprint), the development team delver the shippable product increment to the QA department. , One of the tradeoffs is that this will delay the customers immediate delivery at the end of the iteration by few days.. But as a company, we need to assure the quality of what we deliver to the customer by our focused QA unit. I think this is better , so in this way, customers product quality is basically assured 2 times. Which enable us to deliver a very good quality product to the customer.

6. This QA dept quality checking also can be time boxed to few days as there cannot be such a bottleneck for the product owner to test the vertical.

I can see we can eliminate few practical problems in Scrum model by using few extra steps. Because we all may not have that “Luxury of right context” for scrum in real world business.

Will Scrum scare away the PM .. I say BIG NO

Recent past this has been a very painful discussion in many organizations moving towards Agile.. What are we to do with our PM? Is he/she going to be a Product Owner, Scrum Master or will work as the developers of the team with his skills of development , testing etc. ? All that is fine.. But don’t forget about the Planning, Leadership, Risk Management and Project knowledge what your PM has gained over the years which is really helpful even in a scrum team for a medium to large scale projects. I understand there is no logic in converting PM to Scrum Master unless he understands and capable of playing this “servant based leadership” (they call it ) role.
Look at the following Scenario what we need to do when following a scrum project from top to bottom,

Product Vision -Themes -Values -Roadmap -Release plan -User stories -Product backlog - Sprint Backlog - Daily Scrum

Most the early stage work is the main responsibility of the product owner, however when you look at making release plans based on business values, budgets, stakeholder requirements, PO needs lots of support from the team as well as support from an experienced project manager would be invaluable. PM comes with lots of experience in foreseen risks, keeping team together with good spirit, protecting team from outside disturbances, being visionary about the project and specially some instincts about team skills J , So in that case I think a PM skills can be used in many ways as a very important role for scrum teams specially if there are many scrum teams involved in a project. One way to position him is to be outside of the team, acting a coaching role to help the PO in various scenarios throughout the project. But if the PM can be converted to a good scrum master who will serve this "Servant based leadership" the value he or she can provide is really good when compare with a techie who has no much experience of looking at the project perspectives becoming a scrum master.. I think its all about a mentality change which needs to play this new role by using your valuable skills. There are quite lot of opportunities for a skilled PM in agile environment either outside the team as a coach to work with PO or inside the team as a Scrum master.

SCRUM ... Issues.. ?

I had an interesting SCRUM discussion lately.. With one of the visitors who came to office. We had some point to discuss the PM frameworks and then we were discussing SCRUM in detail. He came up with some interesting point …
Will SCRUM kill the creativity of the development teams… ?
Developers produce piece of code.. in SCRUM we go up to the atomic level planning..so this specific task can be done in X number of hours.. true.. But if there is no such time boxes can they be much more creative…….I mean if we don’t look at the daily velocity of the graph… what would it be?
Hmmmmm… Hmmmm….. Hm…. I was stuck…. Yeah there is a point..
While going home I was thinking about this...
I think its like this .. In SCRUM we discuss what the customer wants in detail and in more detail at the Product backlog meeting as well as in Sprint planning meetings.. So we understand what our customers expectations are to a greater extend. So what we all do is producing what customer wants.
No matter what the methodology or framework we use, we design the architecture and we develop the code..With long planned frameworks what I see is that the developers have more time for creativity.. true.. But it enables more risk of over engineering.. Which result much more risk of sacrificing quality or delivery times at the latter stage of the project which results the project failures. May be soem most important part of the project ... who knows...Especially those long planed methodologies commit on specific strict deadlines.
In this case I think by using SCRUM one can eliminate those over engineering and risk of schedule overruns at the latter stage..In the same time it enables the “Defined creativity” :-)

if somebody needs to be much creative about a features or a piece of code, they can even discuss this at the daily scrum meeting.. making it transparent.. adjusting the calories of the sprint backlog. “Yeah I hear you techies.. That’s not the tech thingies work right ...LOL...!!! But unfortunately that’s the way the “bottom line” works :-) there are tradeoffs …
Now that I wrote about this, I need to explain few problems I see in SCRUM.. I see some of the practitioners believe scrum like a religion.. But thats not right.,.. As I say in my own words. SCRUM is not god given.. Its still evolving as a framework and still we see many issues.. Following are some of the issues I saw when practicing scrum.
Agile doesn’t fit for everybody . we have few left alone people when we introduce Agile Practice to corporate
The customer needs to be well educated.. Yeah .. they say “Think Agile” but never works that way.. need proper discussions and the understanding with the product owner before providing that much of transparency. Otherwise this will make your project and life miserable.
In the same time it’s a stress to commit to 8 hour work tasks everyday.. I know few guys who plan their sprints with 6, 7 hour tasks. May be that’s a solution.. but teams need to mature a bit to work with that.
Sometimes introducing gaps between sprints also helps and teams needs to be cared more when practicing scrum.