Monday, December 11, 2017

Proper Product Backlog Prioritization | Supreme Agile

תמונה קשורה
The backlog prioritization process is crucial for any agile project, during this process, the product owner will decide the importance of the user stories resides in the product backlog and prioritize them in a way that the most valuable stories are at the top of the list and the less important stories will be ranked at the end of the list. 

Without the prioritization process, there is a slim chance for the team on not delivering what the customer really needs, and that's not reflecting the agile spirit of delivering real value to the customers, By the agile manifesto:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

Now it makes sense that we want to deliver value to the customer (After all, he's the one the pay the money…), but in addition to that, the prioritization process will also help the scrum team to understand the customer expectation and basic guidelines for the work effort they will need to invest per iteration. 

Who's responsible to prioritize the product backlog?

As I mentioned in the beginning, it's the product owner's responsibility to ensure and validate that the product backlog is prioritized which make sense due to the fact that the PO is the one that has a direct approach to the customer. 

Now, can the product owner do the prioritization process without involving the team? No, like any other refactoring activities, the prioritization process must involve the entire scrum team, this is the only way to guarantee that the prioritization process will become more productive and effective.  

When to Prioritize?

The backlog prioritization process should be performed continuously throughout the project, there are no "Best Practices" for it, the prioritization will start once you create the initial product backlog and add the user stories, and continued prior to each iteration.

The prioritization factors

The product owner and the scrum team should prioritize the product backlog prior to the start of each sprint (Usually in the refinement meetings), but what are the main factors that they are using to decide which user stories are more important for the next iteration and which will be left in the product backlog?

The value to the customer

The first and most important factor that should be used in the prioritization process, is the Value that the user story adds to the customer, simple as that stories that have the bigger value should get the highest priority. In scrum, the team has iterations of 2-4 weeks, therefore the team must be focusing on delivering the highest value in relatively very short time.

A user story becomes more valuable based on the amount of contribution in bringing the project to life, if the user story has a low contribution in promoting the project deliverables than it becomes less valuable (These stories are Re-prioritized and placed in the bottom of the product backlog) than stories that contribute more in promoting to the future incremental releases.

Now, the "Functional" stories that add value to the customer are crucial, but that's only one side of the story, the second side is the "Non-Functional" stories that mostly added by the scrum team and does not add a direct value to the customer, these stories are added by the scrum team to improve productivity, handling external interruptions and another type of task that does not add a direct value to the incremental release but help to improve the team ROI.   


Risks and Uncertainty

The risk factor implies the amount of "uncertainty" that mostly caused by the team lack of knowledge. The less the team knows what to develop and how they should do it, the higher the risk and uncertainty. 

User stories with high risk and uncertainty have a major influence on the project and especially on the team commitments that must be delivered within a very narrow time frame, therefore those stories should be marked with high-priority to accelerate the generation of a new team knowledge in this area of expertise, Remove uncertainty and eventually to reduce risks early as possible.

Costs and ROI

Costs are a major factor in the product owner's (PO) ROI calculation. The main reason for that is that in some cases the most desirable stories might cost too much to develop, which resolve a negative ROI. 

The ROI calculation has a major value once the product owner needs to decide which stories should be delivered first, based on my experience, two equally important stories are often prioritized by costs; the story that has the lowest-Cost and positive ROI is given higher priority.

Dependencies

Dependencies in the product backlog are a fact, although we should aim to create standalone stories, there will always some dependencies among them, the dependency can be related to both "Functional" and "Non-Functional" stories. Dependencies must be taken under consideration once the product owner should decide how to prioritize the product backlog because, in some scenarios, high profile stories cannot be developed because of a dependency that must be removed prior the team can start to work on that story.


Monday, December 4, 2017

The Agile Manifesto - 4 Agile Values Explained | Supreme Agile


תוצאת תמונה עבור ‪agile values‬‏
The agile software development approach was created back then in 2001 with the publication of the Agile Manifesto, a document containing the principles and overall spirit of this new approach. The agile manifesto contains four main principles that are used to this day in any software development process that based on one of the agile methodologies (Scrum, Kanban, Extreme Programming (ET) Etc.).

The four principles are:
  1. Individuals and Interactions more than processes and tools
  2. Working Software more than comprehensive documentation
  3. Customer Collaboration more than contract negotiation
  4. Responding to Change more than following a plan
By creating these principles, the creators determined the although the values located on the right are very important, we still need to prefer the values from the left. Now, a very important thing that we must raise, is that this approach is relevant only in case of conflicts that may arise during the project. 

In this article, we will try to understand the logic behind each one of these principles:

Individuals and Interactions more than processes and tools


In order to promote a project, the stakeholders must use a dedicated and specific process and management/Development tools that will help them to accomplish the project goals. 

That's just a simple fact that we cannot deny.  However, the agile approach reminds us that there some aspects that even more important such as face to face communication, Trust among the relevant stakeholders, Self-Organized teams and more. 

Without these basic aspects, we will most likely fail to promote the project agenda that based on human resources, regarding the quality of the process and tools used on the way. 

Working Software more than Comprehensive Documentation


The traditional software development methodologies are built on the belief that there is a need in heavy detailed documentation process to handle each phase of the project. This could be fine and appreciated, but the biggest problem occurs once the documentation becomes the main goal of the team instead of focusing on delivering a working product.

The value of a "Working Software" is one of the most important concepts in agile, and therefore it gets a Hugh focus throughout the agile process. 

The main example that demonstrates this issue, is the concept of providing an increment software release in a very short development cycles (2-4 weeks) without the need to invest a major effort to document every step in the way that leads to it.

Customer Collaboration more than contract negotiation


To achieve success in almost any field, we first need to understand the expectations of the other side, this is the same thing in software development process, where we need to collect the customer requirements (Expectations) that are used as the baseline for the future development process. In traditional software development methodologies, those requirements are defined at the start of the project subject to the contract signed between the customer and the company. 

Sounds good, but what happens if the customer needs to change the preliminary requirements once he realizes that there is a gap between the original requirements and his current needs? Well, this is the problem! Due to the original contract signed between the two sides, each modification in requirements will resolve a contract modification, that in most cases will be denied by the company and will not allow the customer to get the product he really needs.

In agile, we still use contacts, but with one major difference, now the contracts are signed with the purpose to work with the customer and based on a collaborative communication that will allow the customer to modify the preliminary requirements without the restrictions as we saw in traditional models.


Responding to Change more than following a plan



In the traditional software development methodologies, we had clear phases that include a massive amount of planning that we will use for the entire lifecycle of the project. If we look at the "Waterfall" methodology that is probably the most commonly used in companies that are not using agile frameworks, we will see that there are five phases (Requirements -> Design -> Implementation -> Verification -> Maintenance), that are used during the SDLC.

Now, although each phase makes sense in the SDLC, there are some major problems that are driven by the nature of these models, Examples: 

1.   There is no option for to start a next without fully completing the previous one.
2.    There is a Hugh amount of planning per phase.
3.    There is almost zero tolerance to absorb modifications in project requirements.

So, what is so different in agile? The main thing is the understanding that ongoing changes in requirements are just another way to allow the customer to get the product that he really needs, therefore, the spirit of agile is to accept and embrace the ongoing requirements and the deep understanding that this is the best way to provide the best and most suitable product for the customer. 

The true agile spirit is based on the capability to flow with ongoing changes and not blocking them, by following this spirit, we will allow the organization to achieve some Hugh advantages that will provide a solid ground for greater collaboration with the customer.  

Saturday, December 2, 2017

Scrum at a Glance | Supreme Agile

תוצאת תמונה עבור ‪and that. gentleman, is scrum‬‏

The methodology of Scrum, is the world leading agile methodology for managing product development, especially because it's very lite, simple and flexible method to manage projects. The scrum framework provides a set of roles, ceremonies, and activities that based on the 4 values and 12 principles described in the agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

You can review the 12 principles as described in the Agile Manifesto: http://agilemanifesto.org/principles.html

Why it Called "Scrum?"

The origin of the term "Scrum" related to the world of rugby which is a team sport, the official definition is "Restarting play after a stoppage which has been caused by a minor infringement of the Laws".

So how it’s related to the world of software development? Well, there is one Hugh aspect that we can consider as crucial for the success of any team, and that's the "Human Spirit" that allow the team to rise above any barrier that can affect their success.

This factor can easily reflect the main idea of Scrum, of creating a cohesive team that will combine sets of individuals that will work with harmony and collaboration that will increase the efficiency of the team compared to a set of individuals that concentrates on their own success.  

Scrum Uses four Main Principles: 


Iterative Approach

Based on this methodology, the teams will now use short iterations that will include the same activities as we saw in traditional models, the main idea that similar to "Scrum" is that the team will start a new iteration (With new tasks) right after the previous sprint has finished.

Incremental Releases

After each iteration, the team will deliver an incremental working release of the product.

Building Team in scrum

The scrum team is built from sets of individuals that each one of them can perform tasks related to different areas, the team is self-organized and can handle tasks based on the iteration capacity.

Empirical Process control

Scrum uses an empirical process control that bases on the real-world progress of a project and not based on guesses or long forecast as used in traditional methodologies.

What differentiates Scrum from other methodologies?

The Scrum framework is differentiated from both agile and traditional models due to the following reasons:

Real Agility

The main advantage of scrum is that it allows the organization to manage projects with the ability to make adjustments based on the current progress and completed work.

The roles

Scrum has three core roles that are responsible for the main aspects of the projects, the roles are Product Owner (PO), Scrum Master (SM) and the Development Team. By using only three main roles, the framework provides a great simplicity that will reduce the bureaucracy and time to make project decisions.

Iterative Model

Both large and small projects are divided into small iterations (2-4 Weeks) that allowing both the team and the customer to make sure they deliver the product asked by the customer.

Communication and Collaboration

The scrum framework contains a few basic ceremonies that increase the close communication between the project stakeholders. The ceremonies are known as Daily meetings (Help to increase the communication among the team members and to make sure they all share the right goals), Planning Meeting (Determine the amount of work that need to be done to provide an incremental release of the product), Review meeting (Help the project stakeholders to review the work done by the team and to decide how to proceed ) and Retrospective (Help the team to achieve a continues improvement).

Continues Delivery

At the end of each iteration (A.K.A: Cycle), the team will deliver an incremental release of the product.

Increased Visibility

The scrum framework provides a great mechanism to allow an increasing visibility of all aspects of the project by using the built-in artifacts such as the Product Backlog, Velocity, and Burndown charts. 

When Scrum is Less Efficient?

There is no doubt that scrum is the leading agile framework used by most organizations, but scrum can still be less efficient in some cases, for example:  

  • The organization does not understand the meaning of the transformation.
  • Regression tests were done manually, which will increase the technical debt.
  • Development teams do not use continues integration (CI) method.
  • The organization does not ready to change its current structure.
  • The organization does not ready to change its culture.
  • There is no framework for an automatic build system.
  • The transition made without the relevant training.
  • There are expectations for instant results. 


Friday, November 24, 2017

Top Agile Myths & Misconceptions | Supreme Agile

Agile software development is probably the most common methodology used by organizations today, as such; many people have started to ask more and more questionד about this methodology that sometimes based on wrong assumptions.

In this article, I will review the most common Myths and Misconceptions that I encounter during agile training courses, hopefully, to help people to divide the truth from the assumptions. 
תמונה קשורה

Myth 1 - Agile is a New Force in the Software Industry

If we compare agile to the traditional methodologies like waterfall we can say that agile is new J, but the truth is that the agile manifesto was created in 2001, and therefore we can say that agile is certainly not new in the software industry.

Myth 2 -  Agile is better than Traditional Methodologies

Although more and more companies are using agile as the preferred methodology, this assumption is wrong! The type of which development methodology should be used should be determined per project and based on the environmental variables. 

For example, we can use the Waterfall methodology in any case that we have clear and informative requirements from day one of the project and stable environment that increase the predictability of the project in a matter of the relevant work that needed to be done.

Myth 3 – There is No Documentation in Agile

This misconception is most likely related to the misunderstanding of the Agile manifesto, where it describes the four principals:

  1. Individuals and interactions over processes and tools.
  2. Working software over comprehensive documentation.
  3. Customer collaboration over contract negotiation.
  4. Responding to change over following a plan.

Now, as you can see there is NO indication that Agile means no documentation or that documentation is not needed, what it says is that the FOCUS should be on delivering a working product instead of investing major time in creating a detailed documentation that may reduce the % of success to deliver the working product. 

There is some basic type of documentation that is very common during each iteration (STD’s, HLD Etc.), the only difference is the number of details and effort put by the team to create them

Myth 4 – Agile Projects are not limited by Deadlines

Similar to traditional methodologies, Agile is not a free ticket to abuse the project timelines, remember that in the end, there is a customer that pays for the software (And a company that needs to earn money…), there is no chance that this customer will agree to work with the company once he been told that there is no expected time for the project completion. 

The main thing in agile is that we can deliver incremental releases of the product in a way that will allow the customer to review the project progress and to use a basic set of functionalities that should be increased per iteration. 

Myth 5 – Agile Revoking the Need for Planning  

In agile, planning is everything! There is no a single project that does not involve a significant planning, the planning is started in the project roadmap, managing the work Prioritization and continues until the team chooses their commitments for the upcoming iteration.

The main difference between Agile and Traditional methodologies is that there is a less upfront planning in agile compared to traditional models that the entire planning is determined at the beginning of the project. In addition, in agile, the planning process performed per iteration (Usually two weeks of work) continually until the end of the project.

Myth 6 – Agile is only suitable for Software projects

The software development community first uses agile techniques and the agile manifesto describes agile in the context of software development. That’s the truth, but Agile is not restricted to software development projects, Think about agile as a framework that we can use to improve the quality and results of a project, this project may be related to software development, Marketing and for almost any project that is based on unpredictable environment. 


Myth 7 – Agile is the Cure for all Problems

Agile will not cure all problems that are part of a Software Development Lifecycle (SDLC), but it will help the organization to enjoy a few major benefits that will increase the % of project success, Examples:

  1. Reduce the Risks.
  2. Increase Visibility.
  3. Better tracking of the project progress.
  4. Better collaboration.
  5. Efficient communication.

Myth 8 – Agile is not suitable to handle large projects

Managing large projects is hard as itself, no matter what is the methodology that you use to manage it, the main difference between Agile and Traditional methodologies, is that in agile we take a large project and break it down to small pieces, which delivered in very short iterations.  

Myth 9 – Agile means No design

The main difference between agile and other traditional models is that in agile we perform design per iteration (Planning meeting) and not in one centralized phase like the one we have in the waterfall model. 
 

Monday, November 20, 2017

Daily Scrum Meeting - Pitfalls and Negative Patterns | Supreme Agile

תוצאת תמונה עבור ‪Meeting problems‬‏
The daily scrum meetings are the basic platform for the team to discuss and collaborate prior to starting the workday, it’s a daily 15 minutes (MAX) meeting, where the scrum members are asked to provide answers to three simple questions:
  1. What is accomplished since the last daily meeting?
  2. What is your plan for today?
  3. What is keeping you from succeeding to deliver?

Sounds like a very simple meeting agenda, right? However, you will be amazed to see how easy it is to turn a daily meeting into another useless and ineffective meeting.

In this article, I will make a short review of the most common pitfalls and negative patterns that affect the quality of the daily stand-up meeting.   

Mistake #1 - Team Members Not Showing Up On Time

The daily scrum meeting is limited for a MAX of 15 minutes, due to this narrow timeframe, there is a Hugh importance that the participants will arrive on time, although it may look simple to make sure that the team members are attending on time, many teams are still struggling with some of their team members that come late to the meeting due to personal discipline issues.

Suggestions for addressing this issue:
  1. Make sure that the meeting will occur early as possible, but pick the time that is the most comfortable to the team members, getting the team agreement is the first step to guarantee that they will arrive on time (and one less excuse for the team…).
  2. Make sure that there is enough time for the team members between meetings that occur prior the daily and the daily itself, if that the case, make sure that you provide the team members at least 15-20 minutes so they can arrive on time.
  3. Make sure that you do not wait to team members that come late; the rest of the team should not suffer from such behavior.
  4. In case of a team member delay, do not allow them to participate (Feedback is not taken/Given).

Mistake #2 – The Meeting Starts Too Late

The Daily standup is the first meeting that the team has throughout the iteration, as such, it’s a very important to start the meeting early as possible to allow all team members to synchronize and raise any issues that affect their progress.

Mistake #3 –NOT a Status Meeting  

The daily scrum meeting is time-boxed to 15 minutes, if the team members asked to report the work they did on the previous working day, they will most likely start to add technical information that is not relevant to the meeting, as a result, the meeting cannot end at the time scheduled and will become less effective.

The main goal to execute this meeting is to allow the team members to share information and sync about their progress (Based on the three basic questions that you all familiar with), there is no reason to discuss deep technical solutions that encounter the meeting agenda.

Mistake #4 – Too Much Detail

The meeting agenda is relatively simple; the team members are just asked to answer three simple questions, although, in some cases, the answers contains too much information than needed.  If that the case, the other members will lose their attention. To avoid this pitfall, the scrum master should keep the answers short, stop the talking once needed, and take it offline after the meeting. 


Mistake #5 – Keep the Meeting Agenda

To achieve the best results for this meeting, the team should follow the basic agenda of this meeting as it intends to be, one by one, each member of the team will provide an answer to the three basic questions :
  1. What did you do yesterday?
  2. What did you attend to do today?
  3. Any obstacles?

Any further discussion that is not relevant to these questions, should be addressed and resolved (By the SM) after the meeting.  

Mistake #6 – The Scrum Master show

The scrum master “Show” is any situation where the scrum master involvement reduced the effectiveness of the meeting, In many teams there is still a wrong conception that the daily scrum is meant for the scrum master, but this is far from being true, the daily scrum meeting is held for the team to discuss their progress based on the commitments they took at the start of the iteration.

Examples:
  1. Team members speaking to the scrum master instead of other team members.
  2. While team members are speaking, their eye contact is with the Scrum Master, which will resolve the loss of focus of all the other team members.
  3. The scrum master asks questions while the team members share their answers.
  4. The scrum master starts to plan a technical solution about a work that needed to do.
  5. The scrum master directly asks people to start speaking, the team knows what they supposed to do, so there is no real reason for the SM to interfere.
  6. The scrum master starts issuing instructions to the team members.
To avoid this wrong behavior, it’s the scrum master responsibility to educate the team members about the importance of this items, in addition to that, the scrum master should take one step back (During the meeting) to enforce the team to talk one with each other. 

Mistake #7 – Choose the Right Location

In most cases, the daily scrum meeting held in the team place of work, the main idea behind it is that we want to allow the team to start working as soon as the meeting completes.

Mistake #8 – Working with the Right Tools


Another major failure that can occur during this meeting is when the meeting executed without the relevant tools such as the Task Board and Burndown chart that shows the user stories and their status throughout of the iteration. To avoid this mistake, the meeting should be held with a visible scrum board that will allow the team members to talk about their work with the ability to use the board as a reference. 

Mistake #9 – Mixing of Different Meetings

There are five known meetings in Scrum, each one of them created to address a specific need in the process, in many situations, a common mistake occurs when the team starts to involve goals and process that must be addressed in meetings that specifically designed for that purpose.

Examples:
  1. The team discusses features that should be developed by the team during the iteration (Should be discussed in the planning and Refrainment meetings).
  2. The team discusses problems that do not relevant to their current commitments (Relevant to the Retrospective Meeting).
  3. The team starts to review their completed work and present it to the other team members (Relevant to the Review meeting).

Mistake #10 - Problem-solving

The third question that is asked during the meeting is “Is there any problem that affecting your ability to work?” a common problem that I frequently see in teams, is that team members and especially the scrum master, are using the meeting time to find a technical solutions for the problems raised instead of keeping the meeting agenda. To handle such problems, The scrum master should write down all issues raised by the team, and addressed them one by one as soon as the meeting completes.  


Saturday, November 11, 2017

Things to Avoid when Writing User Stories | Supreme Agile

תוצאת תמונה עבור ‪user stories‬‏
User stories used in scrum to manage the customer requirements in software development projects, the importance of writing a good user stories is crucial to the success of the projects and therefore they must be written correctly (Small, Informative, Spark conversation  Etc. ) to allow the scrum team to reduce misunderstandings and focusing on delivering value to the customer. 

Writing user stories may seem to be simple but believe me that they are not; there are many ways you can mess it up (Incomplete, inconsistent or missing valuable parts such ass acceptance criteria/DOD), to avoid this common mistakes, I created this list of the most common pitfalls you must avoid while creating your stories.

Large stories that increasing the work effort

Although the agile methodology provides some great process and tools to handle delays and bottlenecks that may arise during the iteration (Move it to the next iteration, rework and modify the story Etc.), we want avoid this scenarios by creating stories that will allow the team to take commitments that based on short units of work. Stories that created with the original scope that determined by the team during the planning meeting and modified during the iteration may increase the scope of the story in a way that will reduce the percentage of the team to meet their original commitments.

Stories that are changed throughout the iteration are more than welcome, this is agile all about (We embrace changes in requirements to satisfy the exact needs of the customer). However, there is a way to handle these requirements by splitting the original story into two (or more) stories that will allow the team to focus on their original commitments and then handling the new stories. 

Lack of Visibility

Stories that are not visible to the relevant stakeholders can lead to many problems such a lack of communication, failure to understand the “Big” picture and most importantly the ability to make an efficient prioritization.


Technical tasks that were written as user stories

There is a reason that user stories containing tasks and no the opposites, tasks should not be added to the product backlog in a makeup of user stories; this pitfall is mainly relevant to new teams that are not familiar with the different artifacts of Scrum.

 As a result, the team members add technical tasks as user stories, which may lead to confusion among the stakeholders once they need to prioritize the product backlog or determine which stories will be added to the next iteration.

The business value is not taking into consideration


We should always remember that the importance of the user story is mainly based on the value that it adds to the customer if the user story is written without the product owner really understand the business value that this story will add to the client, how can he make a real and effective prioritization process? To be able to make an effective prioritization process, the product owner must understand the business value of each user story and why it was originally requested by the customer. 

Stories that were written without collaboration

Collaboration among the relevant stakeholders is the main key to succeeding at writing great stories. Both the product owner and the team (Developers, Testers Etc.) should all collaborate prior to wring a user story. But making this collaboration, each role can contribute his own knowledge and experience that will most likely help to create improved and efficient stories.

Stories that do not provide answers

To write a great user story, the creator should provide answers to some basic questions:
  1. What should the team develop to meet the customer request?
  2. What is the business value of this story?
  3. What is the acceptance criteria that the team members should follow prior to starting the story?
  4. What is the Definition of Done that the team should accomplish prior to them to mark the story as “Done”?
Failure to provide answers to those basic questions will lead to confusions that will affect both the quality of the team deliverables and commitments.

Saturday, November 4, 2017

Scrum Team Roles & Responsibilities | Supreme Agile

תוצאת תמונה עבור ‪funny scrum team‬‏
The scrum team in scrum process is a collection of individuals with cross-functional capabilities (Developers, Testers, Designers Etc.) working as a single unit to deliver the work they collectively committed to accomplishing within an iteration.

The effectiveness of a scrum team is determined by their capability to work together as a special unit (Think about an elite army unit) that follows a common goal and vision determined by the product owner, this factors are critical for any methodology but particularly in scrum process that embraces collaboration and respect among the team individuals.
 

In addition, we need to keep in mind that it will take some time until the team will deliver with the highest possible standards right from the beginning (Based on my experience it normally takes about 4-6 months for a team to work at the highest performance), the improvement of the team depends mostly on the team itself, but also on the external stakeholders such as the scrum master and product owner.  

What should be the size of the scrum team?

Scrum teams are self-organized teams with an ideal size of 7+/- 2 members. If the team size will be larger than the Max suggested size (Nine team members), the team communication will become less efficient from what we expect. 

Now, if we need to add more resources to the team to handle the work effort, we will split the team into multiple independent scrum teams that will collaborate and synchronize with each other to achieve the project goal.

Characteristics of great scrum teams

For a scrum team to perform at the highest level, there are some basic guidelines and rules that each member of the team should follow:

  • The knowledge and technical skills within the scrum team are balanced.
  • Team members are dedicated to the team (work fulltime in the team).
  • Team members should follow the same rules, norms, and guidelines.
  • Each team member share is knowledge with another team member.
  • Motivated people that embrace the upcoming challenges. 
  • The team is empowered and Self-Organized
  • Should respect the other team members.
  • Should follow a common goal.
  • Should believe in the process.
  • Should work together.

The responsibilities of the scrum team 

The scrum team and each of the team members have a set of responsibilities which have to be fulfilled in order to achieve a common goal:   

  • They must report for any impediments that affecting their progress.
  • They should update their daily progress in the scrum board.
  • They have to work together to achieve each iteration goal.
  • They should add real action items in the retrospective meeting that will enforce the most important rule in Scrum of continues improvement. 
  • They should break-down the user stories into smaller tasks, estimate them and make sure they are delivered.
  • They have a responsibility to attend in different scrum ceremonies (Daily, review, retrospective Etc.).
  • They have the critical responsibility to deliver potentially shippable product at the end of each iteration.
  • They should make a real-time estimation regarding the work effort they should perform in a sprint.


Thursday, November 2, 2017

Principles of Agile Architecture | Supreme Agile

תוצאת תמונה עבור ‪Agile‬‏
I think that we all agree that the software industry is going towards agile, we can see it based on both a number of companies that already implemented this methodology and also on the large enterprises that going towards it. This major transition requires the implementation of agile practices in a way to support the complex incorporate system architectures with the remainder of following the spirit and principles of the agile manifesto.

As you all know, enterprise-class architectures will demand more than the theoretical guidelines as they presented in the agile manifesto, to help us reach the next level, I created this article proposing few of the most important principles for the development of enterprise architectures.

These principles are as follow:


Principle #1 – keep it Simple to Increase Success
Principle #2 – If you Build, you test IT!
Principle #3 – Collaboration is the Key to Success
Principle #4 – The Same Team Should Design and implement the System
Principle #5 – Continuous Improvement of the Process

We'll describe each of these principals in the sections that follow.

 

Principle #1 – keep it Simple to Increase Success

Agile software development is known for its focus on simplicity, if we review the agile manifesto (Principle #10):"Simplicitythe art of maximizing the amount of work not doneis essential".  
Simplicity is a major factor as the project/system complexity increases. The only way for agile teams to successfully managing large, complex architectures, is to make sure they keep things as simple as possible, how?
  1. By validating that they will use the simplest design that can work
  2. They remove any unnecessary dependencies in design that can increase complexity.
  3. They uncover any design hidden requirements that can affect the software.
  4. They use only the technology needed to overcome the problem.
Steve jobs: "Simple can be harder than complex: you have to work hard to get your thinking clean to make it simple. But It's worth it in the end because once you get there, you can move mountains"


Principle #2 – If you Build, you test IT!

Testing a system involves many validations and Verification (V&V) activities that will help the team to test the system ability to meet its functionality, Performance and user experience. To do this, teams must design a supported testing infrastructure (Manual/Automated) that provide ongoing testing support.  

The software quality is determined by many aspects, such as the quality of the requirements, Coding and especially testing (if you cannot test the software, you cannot assume it will work on customer environments). Now, that system architectures are more complex than before, there is a Hugh importance to make sure that the entire team will hold the responsibility of testing (Anything else would be just irresponsible enough).


Principle #3 – Collaboration is the Key to Success

Due to the fact that agile teams are self-organized by definition, it makes good economic and technical sense to use the those who have the knowledge, Experience, and skills to match the team goals and challenges.

"Business people and developer must work together daily throughout the project"
To achieve success, each stakeholder should have the power to contribute to the overall project, each technical input should be respected by others, and there is no need to be a specialist to share new ideas.


Principle #4 – The Same Team should code and Design the System

This principle is driven by the agile manifesto itself (Principle #11):"The best architectures, requirements, and designs emerge from self-organizing teams". This principle makes sense because in a real project effort were the agile teams are empowered to deliver software in some narrow time frames (Iterations of 2-4 Weeks at most), teams must have the power to make decisions that can affect their ability to meet the iteration goals including Design, Testing, and coding decisions.

A common pitfall of many agile projects is directed from ignoring this principle, think about a team that needs to be held accountable for design decisions made by others, and that's simply not effective for team performance (Especially when we want to motivate the team to execute plan not made by them).

In addition, we need to remember that these two phases (Design and Execution) are going together, therefore there is no sense to split it among more than one team, so in the optimal scenario these two phases should be made by one team that will take the entire responsibility for design and execution, Expected Benefits:

  • Increased motivation among the team members.
  • Lower chances of synchronization failures.
  • Better decision and execution making.
  • A Collective sense of ownership.


Principle #5 –Continues Improvement of the Process

Just like that, we want to see continues improvement in teamwork using retrospectives and other methods, we also need to continually aim to improve the agile process in our organization.

The motivation behind this principle is very obvious because if we succeed to continually Improve our process, we will make it more efficient, reduce unnecessary overhead, increase quality and reduce delivery time.  

Sunday, October 29, 2017

The “Starfish Method” for Useful Retrospectives | Supreme Agile

תוצאת תמונה עבור ‪starfish retrospective template‬‏

The starfish diagram is an excellent information gathering activity used to help the team members to reflect the things that they want to bring up throughout this short session, it’s based on an evolution of the historical three basic questions asked in this session:
  • What Went Well?
  • What went wrong?
  • What can be improved?
Now, instead of answering these three basic questions that categorize the participants' response to a "Black" and "Whit" criterion, the starfish diagram contains five areas for the team to choose:

Keep Doing (What the team should keep doing?)
A very good idea is to start the retrospective meeting with positive insights of the team members, the "Keep Doing" area will allow the team members to share their good insights and what they liked in the last iteration.

Less OF (What the team should do less of?)
This area will allow the team members to share their negative insights and the practices that they think that should be changed in order to promote the team process. In most cases, we will want to understand which are the processes that the team invest a major amount of effort and bring little benefit to the team/Customer.

More OF (What the team should do more of?)
This area will allow the team members to focus on the things that they should focus more such as tools/practices that will improve the process.

Stop Doing (What the team should stop doing?)
This area will allow team members to raise all things that are not promoting the team or Add value to the team/customer and therefore the team should stop using them.

Start Doing (What the team should start doing?)
This area will help the team members to suggest new ways to improve the process (New practices, Tools, Etc.) to increase the value per iteration.


The Starfish diagram and the maturity of the team

A frequently asked question about this technique is "Can we use this exercise on a new team?", Well, the answer is certainly Yes! The starfish technique is suitable for mature and un-matured teams as well.

The main reason for that is that this exercise is relatively simple and does not require any special demands or experience from the participants. In addition, the starfish exercise Provide an easy platform and criteria that will allow the team members to share their insights in a relatively simple way.

The Starfish exercise

The starfish exercise is executed with a few simple phases, starting from the preparation and continues with the data gathering, the basic phases are:

Phase 1 - Preparation 

Prior to setting up the meeting, make sure that you prepare a board with the picture of the starfish diagram, the board should allow the team members to use sticky notes to add their insights per criteria.

Phase 2 - Agenda

Once all team members are located in the room, start with a short description bout the meeting goals, and what do we want to achieve at the end.  

Phase 3 - Running the exercise 

  1. Start the exercise with a short brainstorming session with the team, in this session the team members are asked to write their insights about a specific category, but as I told before, start with the good things first, so you can start with one of the positive criteria ("More" or "Keep").
  2. After 4-5 minutes, ask the team members to stop and ask each one of them to read out load his insights.
  3. Once all team members are finished, take 2-3 minutes to review the main ideas and make sure that the team members are aligned.
  4. The main ideas should be copies to the board (Just use Sticky notes), and prioritized based on the amount of value they will add once they revoked. 

Phase 4 – Repeat phase 3 for each of the other sections


Phase 5 – Set owners and Goals

Once the board Is filled and prioritized based on the team insights, it’s now the time to set the owners for each action item that need to be mitigated in order to improve the process. 

My Presentations