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 Agile is new J. But the truth is Agile Manifesto was created in 2001 and therefore it 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 development methodology used should be determined per project and based on the environmental variables. 

For example, we can use the Waterfall methodology if we have clear and informative requirements from day one of the projects. In addition, we have a stable environment that increases the predictability of the project with respect to the work that needs to be completed.

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. The 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 in the Software Development Lifecycle (SDLC), but it will help the organization to leverage a few major benefits that will increase the % of project success::
  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 it is, no matter what methodology used to manage it. The main difference between Agile and Traditional methodologies is that in Agile we take a large project and break it down into small manageable parts, 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.

  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.

  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.  

My Presentations