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