Practical Scrum - Define Scrum Team

In this blog, I attempt to define a scrum team structure for a co-located team and how the common project roles fits within the scrum team. This is a guidance and actual team composition depends on the project. The guidance is based on my experience with several scrum projects and some common application of reading various agile / scrum books.

I suggest below team structure:

Role	Number	Comments
Scrum Master	1	100% as pure Scrum master, Or else, At least 50% pure scrum master and 50% can be any other role.
Tester (a Team member role)	At least 1 per 3 Developers	100% from starting of project
Developers (a Team member role)	Max 6	With more than 6 developers you should consider breaking the project in more streams and do Scrum of Scrum.
Product Owner	1	Coordinates requirements from n number of end-users / customers and prioritize requirements

Max 6 developers – Where does the magic number 6 comes from? – A team of six developers will mean total 6 dev + 2 testers + 1 scrum master + 1 product owner = 10 persons team. This is just an appropriate size to be fit in a single room or that can be easily managed with information flowing within all. Bigger the team size, it becomes difficult to self-manage and coordinate, information flow becomes too big a task requiring tools or formal processes. Scrum readings also suggests the scrum team size to be from 5 to 9 team members. There are several dedicated blogs which talks about issues with bigger team sizes.

The magic ratio – 1 Tester per 3 developers? – This is a guidance and depending on need you may have 1 Tester for 4 or more developers too. However, various text suggests that this is the magic de-facto ratio.

Can we have more than 1 Product Owner?  – Yes you can, as long as they coordinate and act as one face for developers.

Scrum master Role: Scrum master removes impediments faced by team members, eg. Coordination with other teams for any dependencies. Another major role of Scrum master is to help team adopt Scrum processes, eg. Ensure that daily stand-ups are happening properly and regularly, user stories quality is up-to-date, etc. I propose a 100% committed Scrum master to start with. Later based on scrum maturity of the team, keep it at 100% or less but never below 50%.

Product Owner Role: This is most important role, as a Product Owner (and not a scrum master) decides the priority of features to be implemented. The product owner represents the customers and end-users voice. This perspective is important. To repeat, the product owner is business centric role and not development team centric role.

Tester Role: Scrum or Agile team does analysis, design, development and testing at all times. Its important to have the tester role involved from the beginning i.e. from Iteration zero. Developers are the ones who writes unit tests, and testers are responsible for writing and executing functional tests (automation is desired and developers help can be sought here). Testers also assists Product Owners to come up with Acceptance tests and running the tests. Testers also performs test planning, and can also generate quality matrices if desired by Sr. Management. Main objective of Testers is not to break the system, and this is important. The objective of testers should be to help developers to prevent the defects.

Project / Team Lead: This is not a defined role in Scrum. Scrum teams are empowered, self-organizing, enabled to take team specific decisions and are self-managing. They do not need a lead. Also a Scrum master is not the Team Lead. Often Team Leads responsibility is to take decision in case of ambiguity which in Scrum is taken collectively by the entire team. In some setups, a Lead is a single point of communication with Customers, whereas in Scrum, all team members directly interact with the customer all the time. Leads are not required to assign tasks, in scrum, the team assigns tasks to themselves. Another responsibility of Lead is for management reporting which can be done by Scrum master or read the Project Manager Role description in this blog.

Project Manager Role: This is not a defined role in Scrum. In Scrum projects, you do not need a Project Manager. However, I feel a project manager is of great help. The role of Project Manager should be to prevent team from external disturbances. Eg. To generate reports for Sr. Management, for people management, assist in career growth / aspirations, etc. Moreover Project Manager is aware of this projects impact to organization and other projects within Organization likely to impact this project. This is not often the perspective of Scrum master nor the Product Owner. Project manager, from their project execution experience, gauge that something is not correct and can point the team of the possible issues. Project Manager however should not interfere with Team estimates or working style or any other aspect of project development. In Scrum, if used, the project manager role is to support and not a role with authority.

Architect Role: If you need an architect for entire duration of the project, then, one of the developers should be replaced with an architect (i.e. max 5 developers and 1 architect). If you do not need a full time architect, then consider adding an architect for few iterations or else bring architect as per need. In such partial allocations, keep max 6 developers and add additional architect for required duration. In case of on-need basis inclusion, make sure that you have stories that require architects intervention planned accordingly. Partial allocations are always tricky and involves thrashing but at times may be the only option available.

Business Analysts Role: This is not a defined role in Scrum. However, just like you need an architect for technical inputs, you may need a Business Analyst for requirements gathering / analysis. A business analyst should never act as a layer between Team and the Product Owner. A business analyst can assist the product owner to form user stories or run acceptance tests and can help developers with understanding business requirements. Organizations that are incapable of identifying a Product Owner, or organizations working in an offshore scenario, assumes a Business Analyst as a Product Owner. In such cases, a Business Analyst should act as a real Product Owner, the one who prioritizes the requirements and takes Business perspective and not developers view. Business Analyst is a specialized skillset and is not a substitute for a Product Owner and organizations who fail to employ a Product owner are in my view at a very high risk of developing a product which no one needs.  

UI Designer / Technical Writer / Database Specialist: Cross functional team does not mean that a developer is expected to be the UI designer or a technical writer. These are specialized roles. You need one, when you need one. Allocation of these specialized roles should be considered in the similar fashion as mentioned for Architect Role in this blog. Having said this, when you have a specialist working in team, have the knowledge shared to all team members such that in absence of the expert, team members can pick up the work. Pairing or explicit sessions can help here. When required, the team members will help Specialists to accomplish tasks. A team of generalists is the preferred approach in Scrum teams than Silos of Specialists.
 

To conclude the blog with an example: Let’s say you need a full time UI Designer and a full time Database Specialist and a Technical Writer on need basis then the team structure will be –  

• 1 – Scrum master
• 1 – Product Owner
• Permanent Team Members
• 4 – Developers (maximum)
• 1 or 2 – Testers (at least)
• 1 – Database Specialist
• 1 – UI Designer
• Technical Writer – On need basis

Hope this blog helps understand how a scrum team is structured. Consider this as a guidance which you will most likely refine based on the specific project needs.

What if the product is large and not possible with a team of this size. Check my blog on how to scale scrum teams via Scrum of Scrums.

Findings from Sprint Retrospective

In this blog I will mention several common issues encountered during Sprint execution and possible actions that can be taken to avoid these during software development.

This is obtained from my experience working on SCRUM in few projects in different organizations and is the result of brainstorming by different team members.

Knowledge of these will help address the common issues right from the beginning. Following issues are covered in more details in this blog:

1. Uncontrolled Changing Requirements
2. Majority of team members are not aware of overall functionality
3. Too many defects post release - Lack of Testing done by Developer pre-release
4. Too many defects post release - Unavailability of Test cases to developers
5. Lack of Reviews or Delayed reviews
6. Lack of Analysis during implementation or Bug fixing
7. Lack of Unit test cases
8. Not planning performance and concurrent test scenarios
9. Lack of separate Testing Environments
10. Sprint Retrospectives is done for namesake
11. Team not co-located
12. Developer skill set not up-to-date
13. Lack of knowledge on Newer unexplored technology

Issues and Prevention Mechanism: 

1.       Uncontrolled Changing Requirements:

• Uncontrolled changing Requirements results in frequent changes and missed implementations.
• Keep Sprints short (say 2-3 weeks). This way we can choose only a limited set of requirements to begin with. This gives time to Business Analysts / Product Owners to work without pressure to come up with detailed requirements for subsequent sprints.
• If a requirement within the current sprint changes, we must either take it as a new requirement which can then be taken in a subsequent sprint or if it is critical, we must re-estimate and then move some other requirement out of the sprint.
• Requirements must be tracked in some SCRUM tool, eg. TFS, rally, JIRA etc. This helps in identifying and shifting efforts, effortlessly. In my opinion Excel does not work in these situations.
• Changing a requirement means a lot as it involves re-analysis, re-design and re-implementation. It also means we need to cleanup previous implementation. This time must be estimated properly otherwise overall quality will suffer.

Note: I have another blog on Change is constant.

2.       Majority of team members are not aware of overall functionality

• Sprint planning session must involve all team members
• Sprint planning involves two parts, first involves analyzing user stories to be included in Sprint and second involves estimation and task break down. Involvement of entire SCRUM team helps all to be on same page.
• High level system design when done collectively by the team in a room helps all members to understand every part of current sprint implementation. In my opinion, this is highly recommended, as it makes up for issues like resource movement, resource unavailability, lack of analysis, lack of skill set.
• Demo of existing functionality and complete understanding of what team wanted to achieve must be clarified upfront to the entire team.
• Any changes to the items agreed upon (requirements / design) must be communicated during stand-ups. During stand-ups this should be communicated in 1-2 lines so that stand-up meeting does not exceed planned time.

3.       Too many defects post release - Lack of Testing done by Developer pre-release

• Yes, developer must test all positive scenarios that they are responsible for before delivering the code for testing. They do not perform tests like boundary conditions or impact on other developers code, but they must verify that whatever they promised to deliver must be in working condition when they handover for testing.
• At times this is not possible, as a developer might be implementing just a part of the overall functionality, so their work might not be testable. For this, we must keep a bucket to do developer testing once that functionality is complete (by all involved developers) and then any one developer can complete a round of scenario testing before handing it over for testing.
• Sprint done criteria must include developer testing and must be conveyed and agreed upon in Sprint planning.
• This eventually saves time because a defect identified at testing duration will involve fixing, build, deployment and re-testing, it’s better to fix it at the first step itself. Moreover developer knows the possible internal problems then the tester who does black-box testing. Using continuous builds, writing unit tests save some time, but nothing can beat a guarantee by developer. 

4.       Too many defects post release - Unavailability of Test cases to developers

• Test cases must be prepared by testers (as they have a different mindset towards software). These test cases must be provided to developers even before development begins, so that they will have fair idea of how their code fits in.
• Test cases must be reviewed by developers as they know the white box aspect of their code and can identify miss at testers end. Test case review must be added as done criteria for User story.
• For re-opened defect fixes, I have seen it helpful for a tester to test on developer’s machine to avoid re-re-opening of the defect as a re-open can mean a serious issue with analysis.

5.       Lack of Reviews or Delayed reviews

• Reviews must be done for everything, including Requirements, Design, Analysis, Code, Test cases, approaches, process and methodology. Lack of review and delay in review amounts to same sort of losses.
• Reviews must be given topmost priority
• If review needs to be done by someone outside team then it must be planned in advance and there must be at least one backup for the reviewer identified.

6.       Lack of Analysis during implementation or Bug fixing

• This is often the cause of defect induction and re-opening of other defects. Proper time must be allocated to analysis.
• Analysis must be reviewed by experienced developers before the fix is made to ensure that all related areas are getting covered.
• A mapping of test cases to application component helps in running test scenarios against the component being developed/fixed

7.       Lack of Unit test cases

• Many managers think that Unit testing is a time investment, however for a not throw away code, Unit tests saves time later during development/testing cycles.
• Unit testing helps to identify defects early in cycle and provides a safety net. You definitely won’t benefit from a safety net which has large holes, so unit testing must be planned from beginning or implemented incrementally to existing application.
• Code refactoring estimate must include fixing failing unit test cases estimate as well. In fact, code refactoring exercise must not begin with coding, but should begin with Unit testing
• Continuous build must include unit test cases run
• Developers must be made aware of importance of Unit testing

8.       Not planning performance and concurrent test scenarios

• Most applications today are used by hundreds and thousands of users. Test cases must include covering the concurrent situations for each such possible flow
• Time for performance testing of the application must be estimated as some functional issues which are not evident during normal testing are discovered during performance testing.
• The sooner the performance testing can be done, the better.  Identifying performance issues and fixing them may take time. Also detecting such issues requires extensive logging in system.

9.       Lack of separate Testing Environments

• The developer’s machines are well equipped with all necessary and extraneous components and are nowhere similar to the actual environment where the application will be finally deployed. Software that runs on developer machine will not necessarily run on a fresh machine. So, the testing environment must be different.
• Separating development and testing environments gives testers their own sweet time to complete and keep track of components that require testing and offers maximum available time to test.
• Performance testing environment should be as close to the actual production environment as possible.

10.   Sprint Retrospectives is done for namesake

• Sprint retrospective is feedback check on the SCRUM process. It must be done seriously
• Action items identified must be assigned owners and a time to accomplish issues identified must be agreed to
• Action items in previous retrospective meetings must be discussed so that the findings are not lost.

11.   Team not co-located

• Team co-location is utmost important for swift communication within team. Testers / Architects / Developers / Managers all must be at the same area or same room if can be arranged for.
• If cannot be achieved due to distributed teams, using phone or video conferencing should be preferred over emails

12.   Developer skill set not up-to-date

• Maintaining a competency matrix and training team members on newer technologies is a win-win situation
• Knowledge of newer technologies equips team members to think in efficient and unique ways to achieve faster or informed results
• Continuous relevant trainings keeps staff motivated, offers job satisfaction to many and employee retention increases.

13.   Lack of knowledge on Newer unexplored technology

• Hiring a consultant for the required period can help achieve mastery in unexplored areas and staff can gain that knowledge.

With time, I will try and update this list and possible resolutions. I would like to know any other issues that you would have identified during Sprint retrospectives and what steps you took to counter them. Please leave them as comments and I would like to add it to the above list.

TagLo on Android

Tag Location - anything, anywhere, anytime

(Android GPS application)

About TagLo :-

TagLo enables you to tag any 'OBJECT' and search its location on Map. Eg. You can tag a ATM location, your favorite coffee shop, a picturesque location, a good hotel in your trip, a house looking for rent, ... You can Tag anything you can see or feel and view it on Map at a later time.

Windows Mobile Development in .Net

For windows mobile development we have 4 choices in .Net:


a) ASP.Net Mobile – Browser based access to the application which is not hosted on Mobile. Application is hosted on a webserver. The advantage is that it supports wide variety of mobile devices as all we access is webserver and it renders HTML ultimately. Drawback is that it cannot use any phone specific features and runs in browser. From VS2008 onwards, there is no explicit template available for ASP.Net Mobile development. Any ASP.Net web application developed, runs on modern mobile web browsers. Some considerations must be taken like not using huge images and large scrollable data. Here is a blog that provides some more information: http://roopeshreddy.wordpress.com/2010/10/25/developing-web-applications-for-blackberry-mobiles-using-microsoft-asp-net/

b) .Net Compact Framework – To develop standalone Windows Mobile application. This is most matured framework so far but UI render engine is old Winform based so UI experience is not great. But the platform is powerful and is directly hosted on mobile device.

c) Silverlight for mobile – This has advantage of rich UI development as with Silverlight apps we see. It has advantage of accessing Phone features but the drawback is that it needs a host like web browser to run and thus cannot run as a standalone application. However, the experience is not at all bad - I would like you to have a look at this 6 mins silverlight video: http://www.youtube.com/watch?v=81MyyagOIog&NR=1
Also, Silverlight is supported from Windows Phone 7 onwards. Windows mobile 6.5 does not have support for this.


d) .Net Micro Framework – This is relatively very new and looks promising. It will allow creation of rich WPF applications on Windows Mobile. The drawback is that as of now it does not have tooling support for development. So even to add a button, we need to do that via code.


For now, I will recommend Silverlight for mobile as it has Rich UI support and Microsoft roadmap looks promising on Silverlight support going forward.

Where is the Requirement Document?

This blog is on an obvious topic. But for those who are still using a Requirement Specification document it can be an interesting read.

When I started with my first project in year 2001 we had a 200+ pages SRS - System Requirements Specifications document. Till year 2007 I worked on several large projects/products and each had a fairly huge Requirement document.

Few months back during a conversation I realized that I have not seen a SRS document from year 2007. These projects were much larger and were Enterprise scale with geographically distributed teams. So, then what happened to the Requirement Document? What led to collapse of Requirement document and what replaced it?

Giving it a thought I think a shift to agile methodology provided clients the flexibility to change the requirements. Maintaining requirement documents along with code with short iterations is a tough job and often the effort would go waste when requirements would evolve or change in subsequent iterations. Following drawbacks of keeping requirements in a document were evident:

• Frequent changes require revisiting entire related requirements. Relating requirements in a document was not an easy task either.
• Changes in Requirement would affect not only code, but Technical design document, test cases document, etc. and keeping traceability between Requirements and these artifacts is not again an easy task that can be accomplished via documents.
• Change to Requirements also affects Project plan and getting a real time report for this required a lot of efforts

Clearly, evolved the need for a tool sophisticated enough to accomplish above tasks. There are several tools available in market that would capture the requirements in form of User Stories and then link test cases to these along with any technical design and could also link code committed to a particular user story. Requirements could be categorized, prioritized; defects could be associated with Requirements. These tools would also integrate the estimates to accomplish the change and provide on-demand and live reporting with most features entailing entire Software Development Lifecycle. When required, the tools will filter the data as desired and export it in many different formats.

  

This tool completely replaced the need for a requirement document.

But does it mean that requirement capturing techniques like conducting workshop, interviewing clients, use case diagrams are also out of picture. Answer to this is a big NO. Requirement capturing is THE most important aspect of the project as this is the way you define and redefine what the end user actually need. Only that you document the requirements in a tool which allows traceability and visibility than using a stale document which will become obsolete by the next iteration.

Closing this blog, I also recall that I have not seen a Technical Design document from Year 2007 onwards. Few important very complex things where various components are interacting did require some sort of technical design document, but then I did not see a Tech design for many complex functionalities. A self-organizing strong team would infer the design from the code. So, code is the only documentation we had from a long time now. Do you also work in similar pattern these days? Do you like it? Probably this will need another blog to talk about this.

 

Agile Development – Change is constant!

Often I see that whenever there is a change in requirements from the client, the developers tends to get de-motivated.. unwilling to change the codebase.. I hear comments like: 

• They are not clear on what they want 
• They should first define their requirements and then move forward with this 
• Our marketing team would accept just everything that client wants without pushback 
• Frequent changes will destroy the design

.. all pointing that we developers are unhappy and someone there is not doing the job correctly.

Times have changed and we are agile. Change is reality; business is changing every second. Think as if you have your own business - would you not like to make changes as you go, may be your vision changes with market, may be you want to do something different based on your competitors or based on some new innovative ideas and so on.. When your customer is asking for a change, it means a lot to them. It means a lot to the value to end-users that will be offered by the product you are eventually helping them to create. By buying into this change you are helping a wider community.

Agile methodology is all about accepting the fact that - change is constant. Agile helps to manage change. Does agile then mean that we keep changing things? I guess no. We should definitely reason and demand that why there is a change. We should evaluate and suggest the client if the change is not for good or if there are better alternatives. However, we should also understand that why someone wants to change and if this is genuine change, then we should embrace it.

Ten tips for Clients and developers involved:  

1. Reasons for change should be conveyed. People should buy into the idea. It also will help you validate and understand implications of the change and also invite other cheaper/better ways to have that incorporated. 
2. Frequent changes means that something could be going wrong. May be vision has a problem. May be execution strategy is not concrete, may be this is not the right time to start... And yes, implementing a change does costs something. 
3. A change control board (CCB) consisting of client stakeholder (Product owner and others) and vendor management/arch/lead responsible for change management should be trusted.
4. Change needs time to implement, this should be scoped well and included in the plan.
5. Developer’s can fix a problem as a hack or can provide proper desirable fix. If time will not be provided to implement the changes, changes can still be done but will involve hacks. Hacks will deteriorate the overall quality making system costlier and difficult to change as month’s passes by.
6. Design a flexible architecture which meets the current spec out requirements. Don’t overdesign and do accept the fact that design will change.
7. You can minimize the efforts by using appropriate design patterns, by following design principles.
8. Follow agile, follow refactoring, follow TDD... They will ease changing code.
9. Enjoy changing code, see how your design handles the change, you will definitely learn new ways of refactoring and also newer ways to design your next system.
10. Refactoring is fun. Once you achieve it and then when you see cleaner code you feel happy about it. And once change is delivered and it’s making difference in end-users life, that’s the real reward you get.

Next time you are facing a change, do question it and once answered, embrace it with affection. Change is good.

 

AOP using Unity2.0

AOP using Unity 2.0: http://www.codeproject.com/KB/architecture/aopusingunity2.aspx