Author: admin

What is the difference between a Scrum Master and a Project Manager?

 

A Scrum Master is

• An Influential Leader
• A change agent
• A role and not a designation
• Who do not use command and control
• A master facilitator of Scrum Ceremonies
• A servant leader – helps team to self-organize and insulates from distractions.
• A bulldozer of team impediments
• A mirror to the team
• One who promotes team work and collaboration
• A Scrum Champion and coach to the team.
• Who helps team members resolve their own conflicts
• Who think ahead of the team into the future coming work
• Who stay abreast of Agile developments in tools, technologies, and techniques the Team is using
• Who coordinates with external teams
• Who ask for management help when team needs it.
• A timekeeper of all Scrum Ceremonies.
• Who makes information radiators
• Who actively coordinates with all stakeholders of the project
• One who is a die-hard Agile learner
• One who gives frequent feedback to the team.
• One who engage constantly with other Scrum Masters through Community of Practice
• One who ensure the constant flow of business value to the customer.
• One who helps team in release planning
• One who keeps team metrics up to date.
• One who helps team to maintain their Scrum tools.

 

 

 

 

 

A Project Manager is

• An authoritative individual
• A formal hierarchical designation in an organization structure
• Who decides what work needs to be done
• Who assigns the work to the team
• Who counts on individual contribution
• Who keeps track of what everyone on the team is doing
• Who make commitments to management about how much Team can do by a certain date
• Who do a weekly/daily status meeting
• Who send weekly status report to the management
• Who plan training and other skills development for Team-members
• Who do active planning of resources, budgets, costs and schedules.
• Who do career-development and career planning for his/her direct reports
• Who do performance appraisals
• Who recruit, interview and hire new Team-members
• Who makes lay off decisions
• Who makes procurement decisions
• Who is responsible and accountable for the outcome of the project.
• Who keeps all the project related artifacts up to date.

Scrum Artifacts

 

Artifacts are perceived and recognized “Visual Aids”. In a co-located Scrum team, artifacts play a vital role for the team to reflect themselves on how they are doing with the sprint goal. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.

 

As per the latest Scrum guide, Scrum framework defines 3 essential artifacts.

 

 

Artifact #1: Product Backlog

 

 

• The Product backlog is a set of all baseline requirements prioritized in order which is made available by the Product Owner to the Scrum Team. The product backlog emerges and evolves over time and the Product Owner is responsible for its content and validity.
• The Product backlog is a living artifact that may be subjected to change, when there is a change in the external business environment, market conditions, regulatory changes or technology changes.
• Scrum teams work on the Product backlog and create a potentially shippable product increment which is demoed to the customer. The feedback from the customer is appended to the Product backlog.
• Product Backlog refinement, also popularly known as Backlog grooming, is an informal Scrum team ceremony that happens every sprint, in which everyone in the team, including Scrum Master and Product Owner get together to ensure that work items in the backlog are relevant and useful, and each items aligns to the overall product roadmap. It is indeed more of a working session than a typical closed door meeting.

 

Typical activities during the backlog refinement are

• Reviewing the highest priority stories on the top of the backlog
• Ask questions to product owner for more information.
• Deleting stories that are no longer needed
• Writing new user stories
• Re-prioritizing and force ranking the stories
• Re-define the acceptance criteria
• Creating new user stories when necessary
• Estimating or re-estimating stories
• Re-assessing the relative priority of stories
• Breaking the epics further into user stories
• Refining stories to prep for future sprints
• Understand the changing bigger picture of the product architecture as the backlog emerges.

 

Artifact #2: Sprint Backlog

 

• Sprint Backlog is considered as the topmost subset of the Product Backlog that the team pulls into the sprint to work on. It is essentially the list of “To Do’s” a development team might be working during the current sprint.
• The work items in the Sprint Backlog are broken down further into tasks by the team. All items on the Sprint Backlog should be developed, tested, documented and integrated to fulfil the commitment.
• The Sprint backlog formation is usually guided by the Sprint Goal. It is a forecast by the development team on what functionality the team will have to work and deliver.
• The Product Owner helps the team to come up the sprint goal during the sprint planning meeting.
• The Sprint backlog can be changed by the Scrum team as it evolves. The development team may discuss the work in progress during the Daily Scrum and modify the Sprint Backlog throughout the Sprint, as the Sprint Backlog emerges during the Sprint.
• As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed.
• Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

 

 

Artifact #3: Product Increment

 

• The most important Scrum artifact is the Product Increment. Each Sprint the development team produces potentially shippable product increment. This product increment must align to the development team’s “Definition of Done” and this increment must be acceptable by the Product Owner.
• This product increment must be the sum of all the Product Backlog items completed during the current sprint and the value of the increments produced during all of the previous sprints. The Product increment must be in a usable condition regardless of when the Product Owner decides to actually release it.
• The Product increment is a piece of working software that creates transparency to all the stakeholders. The team may also create other optional additional artifacts like burn down charts and task boards

Definition of Done

When the Product Increment is delivered, it needs to meet “Definition of Done” which is a shared understanding document of the development team regarding of what “done” means. This definition is different for every Scrum Team, and as the team matures, the Definition of Done will expand and become more stringent

 

How to Write Good User Stories

A question that comes up a lot is how to write good user stories.  I can only assume because people have seen many examples of bad user stories out there.

“We can’t use ‘user stories’ for our type of work.  Its too complex and the user stories don’t contain enough detail”

“Why can’t you use user stories?”

“Because we cant build a system from 50 one-liners!”

Uh-oh.  Maybe you have seen this situation before, maybe you have been in this situation before either as an engineer or as a product owner.  Either way, its a tough spot to be in.  Here are some times on how to write good user stories.

Tip 1.  There is no story without a goal.  Start by outlining the goals of the users in the system.

Remember, user stories describe functionality in terms of the outcome, or the goal of the user.  Once you understand what the user is trying to achieve, it makes it much easier to create a good user story.

Tip 2.  Include metadata or other artifacts with the user story.

There is a misguided conception that a user story can ONLY include the user story, and not additional artifacts as needed.

Realistically, you are still able to use anything and everything valuable at your disposal to help with the communication process.  User stories are the beginning of the conversation, but not ALL communication.

Tip 3.  Make sure you have a set of cards with the different user personas described.  If you don’t have them, make some.

One of the reasons user stories do a poor job of communicating is because all users are treated the same.  How many times have you seen “as a user…” on a user story?  However, there is no system of a non-trivial size that does not have multiple types of users.  Understanding who those users are, what their pain points are, and how we can address those pain points goes a long way toward being able to write good user stories for those users.

Tip 4.  Involve the customer in writing the stories.

When we sit down to figure out what needs to be done for the user (aka the customer), we often shy away from involving the customer in those conversations.  This is because we think we should know everything.  While we should be aware of the customers needs and goals, the best way to get that information directly is to talk directly to the customers about their wants and needs.  Even better, if you can involve the customer in writing the user stories (at least the high level description), you stand a much better chance in delighting the customer with the product.

Tip 5.  Keep the stories short, remember, they’re just reminders to have the conversation.

User stories have 3 parts, the card, the conversation, and the confirmation.  The conversation is the most important part.  This could mean conversations with stakeholders and customers to outline what they want, AND it includes conversations with the team to articulate the business need.  There is no substitute for talking, and one of the positive aspects of Scrum is that it shifts the focus from documenting customer needs to actually talking about them.  As a product owner, part of your “secret sauce” is to be able to communicate a vision, in both the big sense and the small sense.

Some of the challenges teams have with writing and consuming user stories can be avoided by not having a rigid idea of what a user story is.  The user story is just a starting point for the all-important conversation.  Then you can flesh out and add details to reflect the shared understanding.  What kind of problems do you have with writing good user stories?

 

How to run a user story workshop?

I find lots of trainers have a hard time running a user story work. Moreover, these workshops do run with several slide shows instead of hands on exercises. I would like to get my dirty with lot of work to do in a workshop. There is a lot of value for teams writing the stories rather than, glancing through some theory examples.

I would prefer the following steps to run a User story workshop.

1. Form a group of 3-5 people who understand the purpose of the product. 3-5 seems to be the magic number. Any less and you might miss some ideas. If you add more people, it slows the process down and there are diminishing returns on the quality of ideas generated.

Let the team to come up with a vision of own dream product. Propose them to write high level features for the vision. Clearly explain what you mean by a feature. (Example: Login page for a portal is not a feature). Take each feature and identify the high level requirements on color sticky notes.

2. Introduce the phrase “EPIC” and tell teams to break features into epics in different color sticky notes. Make a wall map and help the teams to paste the epics exactly below the features. When teams establish features and epics relationship, I would work with them to make team write high level requirements for each epic. Introduce User Story with an example and its intent. Help teams understand various formats of User stories. Convey the importance of identifying User Personas at this stage. Show some examples of splitting user stories. Give few guidelines of dos and don’ts as well as pitfalls and traps when writing user stories.

 

3. Start the exercise by asking teams to write high level one liner as requirements for each epic in silence. Each person takes the same colored post-it and silently writes down one user story per post-it. Once everyone has finished writing their post-its, have each person read their post-its aloud. If anyone has duplicates they should be removed at this point.

Depending on the size of the epics it can take 3-10 minutes to get all the major user stories. You can watch the body language to see when team is done. You can observe that the group goes from huddled in at the beginning to standing/leaning back at the end. It is likely that each post-it starts with a verb. (eg. Compose E-mail, Create Contact, Add User, etc) which forms the walking skeleton” of the map. Ask teams to stick all user stories exactly under the related epics. This might be their first ‘aha’ moment for silent brainstorming.

4. Next ask the team to group the sticky notes in silence. Ask team to move similar things close to each other and dissimilar moved farther. Use silent grouping simply because it is faster than grouping them out loud. If duplicates are found, remove them. Groups will form naturally and fairly easily. Once again, body language will help you see when they are done – usually 2-5 minutes.

 

 

5. Introduce acceptance criteria with an example. Help teams write acceptance criteria for individual stories. Now talk about the non-functional requirements. Ask the team to come up with non-functional requirements for the same stories. Arrange all the stories on the wall, and help teams order them, ask them use slice the stories either by date or scope.

 

6. Explain sizing of stories using story points and help teams size all the stories. Please have someone role plays the Product Owner. Let the trainer himself act as a facilitator for story points sizing exercise using planning poker.

 

7. Finally, I like to take all the user stories in the first release. I recommend the team do some serious user story slicing to make sure that we have sliced the first release as thin as possible.

 

I see there is lot of value and motivation when team s to come up with their own vision and write down the stories.  The essence of the workshop may be lost when I give pre-cooked user stories to the team. What do you think?

How to groom, group, manage, and organize user stories

Very often, I observe team members conversing in retrospectives, “we have to wait for the requirements to be clarified by the Product Owner, and it is eating up a lot of time and delays our work in the Sprint. In good olden days we had requirements specification document which was easily manageable. ”   It is imperative that teams face an uphill task to manage hundreds of stories in their backlog.

I was pondering upon this problem for a while and understood that teams are missing a very important ceremony in the sprint called “Product Backlog Grooming” that would help in grooming, grouping, managing and organizing the user stories.

In short, the product backlog is the single source of requirements in agile, it is an ordered list of requirements, and the majority of the items in this list are the user stories. It needs to be continuously groomed whenever you see a need for it.

Here are few techniques for a team which can make their life easier when dealing with the user stories.

1. Groom the stories

The teams would have to spend at least ten percent of the time during their iteration, with the product owner to understand the existing stories in terms of clarity, feasibility and fitness in the iteration. If the story is big one, then they need work with the product owner to break it down into smaller chunks, manageable in iteration. Mark the stories as ready for sprint after this meeting, so that there is no back and forth during the iteration. Remove the stories from the backlog that are no longer needed. Make the stories more clear by elaboration the conditions of satisfaction as required. Estimate the stories with the best known facts at that time. Adjust the priority of the story with the permission of the Product Owner. The grooming activity is very much essential to maintaining the product backlog, else it would become unmanageable.

2. Group the stories

We can group related together under one umbrella that helps us visualize the progress of stories. For example have all reporting templates related stories under ‘reporting’ group, all user management related stories under “user management” group and so on. This grouping of stories is called as “Themes” in agile. Create high level groups when you start eliciting the requirements and try to group the stories accordingly as and when you add new stories to the backlog.  Some tools like Rally, support a Parent-Child relationship and successor-processor relationship that supports user stories grouping.

3. Manage the stories

Managing the stories is very simple. For each story in the backlog, the following attributes that would help in fetching the complete details of the origins of the story, that will make it very easy to track.

• User Story description
• Acceptance criteria
• Parent user story
• Priority
• Assumptions
• Dependencies
• Assigned to
• Estimate
• Team assigned to
• Group (if this story is grouped )
• Tasks associated
• Tests associated
• Status: Done, In-progress, completed, blocks etc…
• Impediments etc

Follow the DEEP model, as Mike Cohn calls it. DEEP is an acronym of

• Detailed

Appropriately Highest priority, more detail; lower priority, less, which are broken down into smaller stories for sprints/release.

• Emergent

Growing and evolving overtime; Re-prioritized when items are added /deleted.

• Estimated

The product backlog items are estimated. The estimates are coarse-grained and often expressed in story points.

• Prioritized

Items that are slated for the next couple of sprints

 

4. Organize the stories

Organizing the stories is easy, have team specific backlogs. Have the stories that are related to your team only in your backlog. Themes are also used to organize stories for releases.  Link your team stories on which you have dependency with other team, that way, you will come to know the status of other linked stories. Have frequent conversations with the Product Owner to prioritize and reprioritize stories.  Help your Product Owner to remove the stories that aren’t belonging to your team.

 

Imagine your lawn in the back yard, how do you maintain it? It has to be maintained regularly? If not at some point of time it becomes unmanageable, grows haphazardly in all directions, making it difficult to maintain. Similarly, backlog grooming is not a onetime effort.

Do you think you need to consciously water your lawn, trim and manure it, so that it looks healthy? Else, imagine what might happen!

How to decompose user stories into tasks?

Recently I was looking at the sprint backlog of a team, which just started their agile journey. When I looked at the task break down of the user stories, I noticed something like this.

User Story

• Coding
• Testing
• Check-in
• Build
• Demo

Looking at this task breakdown, I initially felt it as a sequential process steps defined as tasks for a story. I also noticed that every story had the same task break down with different effort estimates. I was looking at their done criteria of a story. I could not really relate their Definition of Done (DoD) and their task break down. Immediately, I asked one of the team members, “How do you make sure that you complete every task listed in the DoD? “  He stared at me with a confused smile, and said “We just do it! Sometimes there were tasks, we forget few of them and will get them done in the next sprint!”

Ah! Here is the catch…

I see that the task break down of the team just reflects a sequential process and doesn’t convey anything meaningful about what is happening with that story! Moreover, the task “Coding” doesn’t convey how much portion of coding completed for a specific story.

I also found a similar pattern of task splitting with other team’s sprint backlog too!

Somehow, I find that many teams are struggling to do an effective task down of a user story!

A task is simply a piece of activity that is required to get a story done. Here are some effective tips for breaking down a user story into tasks.

1. Pen Meaningful tasks
   Describe the tasks in such a way that they convey the actual intent. For example, instead of saying Coding, describe the tasks as  “Develop the login class”, “Develop the scripting part for login functionality”, “Develop the password encryption for the login functionality”, “Create user table and save the login data to DB” etc.. Such tasks are more meaningful rather than just saying coding and testing.

2. Use Definition of Done as a checklist.
   Let us see what a DOD is very quickly. DOD defines the completeness criteria of a story. It includes all items that have to be completed to claim that the story is done by the development team. A simple example:

• Acceptance criteria is verified during testing
• Coding tasks completed.
• Exploratory Testing completed and signed.
• Regression test reviewed and passed.
• Unit testing – written and passed.
• Code reviews conducted.
• Defects are in an “acceptable” state to the Product Owner.
• User story accepted by the product owner.
• Regression tests run and passed
• Smoke / automation tests run (if applicable)
• Check for memory leaks
• Automated unit tests are checked in

  Now how do you ensure that all items of DOD are done by the team? One way is to use the DOD as a checklist to come up with tasks for the user story so that the team can take each one of them and complete without forgetting.

3. Do not have too small tasks, it is an overhead
   Another syndrome I have seen is tasks which are very small, broken down to a minute level like, 10 min, 30 min, 5 min tasks, for example: Write Accept User Name Password, Validate Login, and Give Error Messages. Breaking the user stories with too many details is an overhead. What is the ideal size of the tasks?

One guideline is to have tasks that span less than 8 hours so that each one of them can be completed in at least a day.

4. Avoid explicit testing task at unit testing level as far as possible
   If possible, prefer unit testing not to be a separate task and be part of the implementation task itself to encourage people to practice TDD approach. However, this practice may not be ideally suitable for new Scrum teams.

5. Do not have very big tasks
   Do not have too big tasks that span across days together as we really do not know the actual progress.

In, some mature teams, I have seen, they do not do the task break down at all. They just pull in the user stories and complete them, but it is journey for new Scrum teams to get there.

So, how often do you think, as a team, you have to revisit the DoD, so that your task breakdown may change?

How to create user stories from traditional requirements? 

When I coach teams, many times, I see the requirement analysts; often feel uncomfortable to understand the difference between a user story and traditional requirements.

I was talking to a requirements analyst last week, and he was saying

“My company started to go the agile way, and was told to write requirements in User Stories. I have no idea on how to write user stories. Do we still need requirement documents or not at all?

I see the concern expressed is one of the most common one that makes people nervous.

It is hard to figure out how to break the big requirement specifications into smaller chunks of work doable in iteration.  Here are few tips and tricks that help to slice the big requirements documents to user stories.

Traditional requirement documents have features specified by each module or milestone.

Tip1: Pick one feature at a time and prioritize

Take each module or big feature from the traditional document, and understand

• Who is the user of that functionality
• What is the purpose of that requirement
• Why does he need that functionality

The “Why” in the last point will tell you the actual business value the end user gets from the feature. It also helps you to assess whether the end user really needs that feature. If you see that there is no real business value in building feature, then push it to the bottom of the stack.  The aim is to identify the most important big rocks that are useful for the end user to build his system.

 Tip 2: Break the big feature into small chunks

Now this big rock cannot be obviously built in a 2 weeks or 4 week iteration. Obviously it needs to be broken down into smaller pieces.

Start splitting down the requirements into smaller pieces. As you identify each smaller requirement, try to come up with the functionality aka the acceptance criteria that tell us whether we are building the right feature.

Tip 3: Support it with other artifacts

One myth that many had in their minds is, a user story and acceptance criteria is just a bulleted list of sentences.  However that is not true!

While writing the user story and acceptance criteria, it is Okay to support it with all additional artefacts that are needed. For example: any wire frame, business rule document, any architecture diagram etc. but ensure you attach the bare minimum things without investing lot of time and the developer understand the intent of the story.

Tip 3: Make sure the requirements are clear

• Ensure that conditions of satisfaction for each story is identified aka the acceptance criteria that helps build the right functionality.
  • Write down the tests that can be run verify whether the right functionality is really implemented, aka the acceptance tests that confirm the acceptance criteria is met. Running these acceptance tests would qualify the story as a DONE and accepted story by the end-user.
  • Dependencies cross the stories and have them specified in the same user story for reference. Example, Send email story is dependent on Create email story.
  • Parent user story i.e the big rock, so that we know what would be finally built once these smaller rocks are done.
  • Any assumptions like how will you demonstrate the small rock to the end user, example any test container that you may want to use till the actual test environment is ready.

Tip 5: Repeat and rinse

Repeat all the above steps until a feature in your traditional document is covered.

Repeat the same again and again!

To summarise, take the a big requirement specification document, break it down into feature, break it down into smaller requirements, prioritize them, take the most important ones from top of the stack, capture enough details in the form of acceptance criteria aka the condition of satisfaction. This way you are nailing down on the most important requirements, releasing them to team early to build them, so that ROI can be realized faster.

Do you think this way of breaking the big rock into smaller ones, and building them is better than building the bigger rock at one go? Of course I agree that, there is a need to integrate back all the smaller pieces.

How should I assign resources to my Agile team ?

The waterfall teams known for built in component teams. These component teams are separate specialized teams for requirement analysis, design, coding and testing. These teams produce bigger chunk of work at a stretch and do the handover of the work to the subsequent specialized team. This kind of behavior produces lot of latency and delay in the process and reduces the ownership mistakes that surfaces during the later period of development. Moreover, the specialized component teams often involves in “throwing it over the wall” behaviors. The recommendation is that Agile teams try forming feature teams being cross functional in nature to fix the problems that arise out of component teams.

Agile feature team comprises of the requirement analysis, design, and coding, testing responsibilities within the same team. This team will work on whole end-to-end customer feature focus. Planning, coordinating and doing work are greatly simplified in feature teams. Handoff and delay wastages are dramatically reduced leading to faster cycle time. Learning increases and organization can focus on delivering high priority business value features.  So an Agile team must contain everyone like developers, testers, designers, data architects etc. This team requires working on a specific product feature end to end. The Agile team includes cross functional team members plus Product Owner and Scrum Master

Some of the important traits of Agile feature teams are

• Small teams with full time team members five to nine in one team
• Stable teams may stay together for several years and jell well to achieve high performance
• Self-Organizing teams that do not require the overhead of managers, since they coordinate among themselves a lot, which is quite simple.
• Empowered: the team make their own decisions
• Cross Functional teams that contain everyone on the team to work on end-to-end functionality
• Interdependent on other teams for information and on senior management for support
• Continuous Collaboration exists between them to achieve the goal
• Shared and collective ownership and accountability as a team towards the goal.
• Everyone in the team are generalized specialists
• Accept change in requirements as a routine part of their job
• Have their own set of working agreements on how they want to work as a team
• Have distributed leadership across the organization
• Cross competent and preferably collocated
• Have complete autonomy of the work they want to do and constantly engaged in innovating something new that delights the customer

It is recommended that the Agile feature teams work with one product Owner and one Product Backlog. The Product Owner is the customer representative of the team. A Product Owner with high product knowledge and business analysis experience may be hired and put into the team. In the same way, the Scrum Master is a facilitator and servant leader of the team who should be assigned to the team, during the initial phases of the team. Avoid someone dual role, the Scrum Master and Product Owner for the same team. Avoid having a part time Scrum Master or the Product Owner for the team, since the value from the roles is not fully utilized by the scrum team.

In waterfall each phase has a group of specialists. For instance, requirement specialists in the requirements phase, design specialists in the design phase, and developers in the implementation phase. The requirement   specialist would be only being on the release in the beginning-she was only allocated in the requirements phase. Since Scrum is not waterfall and there are no phases. The same team members allocated in the beginning will balance the resource need till the end of the release. Hence no phase wise resource allocation in Agile.

How do I coordinate multiple Scrum Teams on the same project?

In a Scrum team there are multiple roles and personas that work together to complete the set of work items that they have committed to accomplish within the sprint. These Scrum team members develop the feeling of togetherness and collective ownership towards the sprint goal. A typical scrum team consists of 7 people plus or minus 2, including Scrum Master.  Often, complex projects with multiple dependencies scale through having Scrum teams of teams. These roles created required for top down monitoring and integration of product increments. There are some projects which can scale up to 500 people using number of multiple scrum teams to achieve one common bigger goal.

In this article, I would like to present 3 different frameworks that are popularly used to coordinate between multiple scrum teams on the same project.

 

Scrum of Scrums (SoS)

It is an important and well known technique in scaling Scrum to large project teams. It is also known as Meta Scrum. These meetings allow teams to discuss their work, focusing on areas of overlap and integration. In this approach, each team identifies one person or two persons to represent their team to attend Scrum of Scrums meeting.  The representatives from each team coordinate the work with multiple scrum teams. These meetings are much like daily standups, but they may happen less frequently as the project execution proceeds in a smooth manner. Everyone answers the following three questions:

• What changes did my team just make that will affect you?
• What changes will my team make next that will affect you?
• What blockers do we have or foresee for you?

In some project teams, this meeting happens 2-3 times in a week. It may start with a 30 minute time box initially and later reduce as the release progress. It is important to note that it is not a status meeting; in fact it is differences only meeting to understand the other team’s progress. The members who take part in this meeting are self-organizing and self-managing. Managers are welcome to this meeting and they may offer their helping hand in removing bigger impediments. This meeting is a working session to resolve the issues. Use simple spread sheet or any other tool to track issues, owners and due dates. This meeting focuses on inter-team dependencies that effect process and people.

Scaled Agile Framework (SAFe)

It is one framework that focuses on adapting Lean-Agile framework that is built on the top of Scrum teams. The framework could be successfully applied for projects with 50-125 people at a stretch and supports large enterprise scaling of Scrum. The big picture graphic of SAFe highlights individual roles, teams, activities and artifacts that are applies the framework at team level, Program level and Portfolio level. The core values of SAFe are Program Execution, Code Quality, Alignment and Transparency. SAFe uses Agile Release Train (ART) to coordinate between multiple Scrum teams, which advocate the concept of “Develop on Cadence and Release on Demand”.  SAFe supports agile frameworks like Scrum, XP and Kanban. It supports more centralized top down large enterprises that highly resonates with Process and Product evolution. It also proposes an architectural runway that multiple scrum teams need to build to have high quality product increment.

 

Large Scale Scrum (Less):

This framework is into existence by Craig Larman and Vodde. LESS proposes 2 frameworks for coordinating with multiple Scrum Teams. Framework 1 almost works similar to operation of Scrum of Scrums meeting for 10 teams. The number 10 being not a magic number, but it is the tipping point beyond which a Product Owner no longer can have a big picture view and have no time to spend with multiple teams. Apart from Scrum of Scrum style, the team representatives from all Scrum teams will do all the scrum ceremonies together.

Beyond 10 teams, the framework 2 which comes into being that states that the Product Owner role needs to be more top down to have holistic big picture view. The Product backlogs are split into area backlogs and the Product Owner role is divided into Area product Owner (APO) and the Product Owner Team.

These two frameworks actively support Scrum teams in large enterprises. They have systems thinking view in Agile and scale the PO structure.

 

 

How can Agile work in FDA regulated Software environments?

Some of the biggest myths of Agile software development are:

• Only one specific way of working
• Working without documentation
• Doing iterations with daily standups
• Working without a plan

The companies which conduct clinical trials maintain standard procedures to the overall Software Development Life Cycle (SDLC) process that will be used in the design, development, testing and operation of software systems developed. For each core product software system, all planned SDLC deliverables and their scaling will be documented in the Validation Plan. Project teams shall document Software change process and applicable deliverables for the system maintenance cycle. For each of the phase prescribed by FDA, we will see how the same applies to Agile way of working. The waterfall style of working can be tweaked to work for agile, the documentation may be maintained in appropriately for the auditors to perform the validation audit.

 

1. Planning Phase
   Once a software system project has been approved, the planning phase may be initiated. Management shall ensure that all team members have all of the appropriate qualifications and training required to be assigned work on the project. Each software system project shall prepare a Validation Plan. Software systems that are to be released in a phased approach shall be documented as such in the Validation Plan. Each software system requirement shall be detailed in a Requirements Specifications document. The Requirements Specifications should be created using an authorized template. The signature of all project team members shall be documented.

 

In Agile:

• The Validation plan is a part of sprint level definition of done, and the plan will be produced every sprint
• The Requirement Specifications document is created by the Product Owner before beginning of every release

 

2. Development Phase
   The Requirements Specifications may be iteratively reviewed and updated during software system Development Phase. Each product shall document Test Strategy and Test Plan.

   All software source code developed shall be placed under configuration management control.

   The Technical Specifications should be developed during the software system Development Phase. Unit Testing shall be conducted as outlined in the Validation Plan. Code Reviews shall be conducted as outlined in the Validation Plan. A Software Build of the source code shall be delivered to the validation/test team. Test Scripts, reflecting the functionality outlined in the Requirements Specifications shall be written in such a way that they facilitate tracing to the appropriate requirements and shall identify the capturing of objective evidence, when appropriate. Issues, defects & enhancements shall be documented and managed by the project team using a defect tracking system. The project team shall document all decisions

   about all issues, defects and enhancements. A Requirements Traceability Matrix shall be prepared to trace requirements as outlined in the Requirements Specifications to the associated testing.

 

In Agile:

• Updating requirements specifications iteratively is a part of Sprint level definition of done
• Test Strategy and Test plan is part of Sprint level definition of done and the same is done every sprint
• The technical specifications document is produced as a part Sprint level definition of done
• Unit testing is User Story level definition of done
• Code reviews are part of Sprint level definition of done
• Defects are logged in the defect tracking tool as a part of sprint level definition of done
• Requirements traceability is prepared and updated every sprint as a part of definition of done

 

 

3. Controlled Testing Phase
   A “Final Feature Complete” Software Build of the source code, with all required functionality implemented, shall be delivered to the validation/test team for Controlled Testing. This software build shall be appropriately labeled. When this software build is deployed to the Controlled Test environment, a code freeze shall go into effect. The Validation Plan, Test Strategy/ Test Plan, Requirements Specifications and Technical Specifications shall be approved prior to the start of Controlled Testing. Unit testing and Code Review documentation shall be completed prior to the start of Controlled Testing. Prior to formal execution in the Controlled Test environment, test scripts shall be reviewed and approved by a Validation Designee different from the Validation Designee who authored these Test Scripts. During Controlled Testing phase, the Test Scripts shall be formally executed in the Controlled Test environment. These Executed Test Scripts shall be accompanied by applicable objective evidence, when required by the test step. All defects shall be communicated and managed by the project team. The project team should document an Impact Assessment to determine the scope of Regression Testing. This Impact Assessment should be documented. When User Acceptance Testing (UAT) is to be conducted for a core product, the UAT may be executed, as outlined in the Validation Plan. The UAT is formally documented by the internal customer(s) and/or user representative(s) prior to release. The results of Controlled Testing shall be documented in a Test Summary Report. At a minimum, the report must account for each planned activity as outlined in the Test Strategy and Test Plan and any deviations or additions to that plan. The report shall be completed at the conclusion of testing or at the conclusion of the validation effort. Test Summary Report may be included/combined within the Validation Summary report. A Release Memo shall be completed prior to formally releasing the software system. The results of validation efforts shall be documented in a Validation Summary Report. At a minimum, the Validation Summary Report must account for each planned activity and/or deliverable as outlined in the Validation Plan and any deviations or additions to that plan.

 

In Agile:

• Controlled testing is a separate sprint by itself
• Controlled testing is a part of Release level definition of done
• All the documents are reviewed and printed out.
• Automated test scripts can be run as a part of release level definition of done and the report is published.
• Regression test reports are published
• UAT may be conducted as a part of release level definition of done
• Test Summary report, release Memo are published in Control testing sprint.
• Validation Summary report may also be published in control testing sprint