Sunday, April 29, 2018

The story of the chicken and the Pig | Supreme Agile


An agile team contains different stakeholders such as the development team, scrum master, and the product owner. Each one of the stakeholders that I just mentioned has an essential role to play in the creation of an effective successful team.

To be able to maximize their role as active contributors, these stakeholders need to know when it’s their turn to participate, listing and contribute to the overall feedback cycles that the team need to generate as part of their continuing growth.

To point out the difference between stakeholders that has a larger "Commitment" and those which just involve in different activities in agile, we can use the old story of the "Chicken and the Pig" that will provide a different angle about the commitments of the different stakeholders in agile teams.

So, the story goes like this: One day the chicken decides that the two should start a restaurant. The pig is intrigued by the idea and says, “That sounds great. I’m an entrepreneurial type of hog. I’m sick of working for the farmer.

But what are we going to call the restaurant?” The chicken thinks. Then she scratches and pecks at the dirt and suggests, “Ham and Eggs!” To which the pig replies, “No thanks, I’d be committed. You’d only be involved.”

You should think about this story when you start thinking about your agile team, and ask the basic question of "Who is the chicken and who is the Pig?"

A Chicken is a stakeholder that does not have a direct responsibility for the teamwork but still benefits from the pig's work. Chickens are listeners that do not contribute to the day to day effort to getting things done (They don’t participate in team activities).

Pigs roles are the core team members that are truly committed to the process, they participate in the day to day activities during the agile software development process and which have a direct responsibility on the deliverables.

Examples:
Let's take the daily standup as an example, which stakeholder is the pig? And which one is the chicken? In the case of the daily standup, the product owner is an "Observer" that does not expect to contribute to the meeting. They listen to the team while they share their progress and ensure that the team is working on the highest value stories (While the team owns the responsibility to perform the meeting, follow its goals and to keep its agenda).

Another example is the product backlog, although the entire team is responsible to maintain and keep the product backlog in a great shape, the product owner is the one that has the larger responsibility to ensure that the product backlog is prioritized and ready for the team development cycles. So, in that case, the product owner will be categorized as the "Pig" and the rest of the team as "Chickens".

The scrum master as the ZooKeeper
Now, in some organizations, the daily scrum meetings will attract different stakeholders (categorized as "Chickens") that will want to watch the daily standup which is a good way for them to check the team progress.

In that case, the scrum master should communicate to these "Chickens" that they shouldn’t participate and contribute (Unless they specifically asked) in the standup. Now, although these stakeholders can be senior management, manager of other teams and even customers, for this meeting they are all "Chickens".

Depending on the type of activity and the culture of the organization, your activities might be overwhelmed by chickens.  If that's the case, it’s the scrum master role to ensure that the chickens don’t take over your pig team (Remember that they have the higher commitment and therefore their words should get the higher priority).  

In some cases, the chickens are the highest rank in the organization (Directors, VP's Etc.) that will not take their status as "Chickens" which increase the challenge of the scrum master to keeping them from "Hijacking" the meeting. If you familiar with the different roles of scrum, you have the knowledge that says that the scrum master role is to protect the team and their ability to work in a safe environment.

For the scrum master, there are some basic ways to handle this situation:
  1. Sitting down with them and the team which will physically block their ability to access the team (In some cases it’s the only thing that can work).
  2. Free the time for the team to answer their questions once the meeting is finished (This will show respect and will make it easier for them to save their questions to the end of the meeting).
  3. Talking with these stakeholders and explain the expectations and why they are not allowed to interfere during the meeting.
Remember that the main focus is on the team, the scrum master should ensure that the team can focus on the meeting agenda by reducing all noises that come from the chickens.ns.

Sunday, April 22, 2018

Most Common Mistakes During the Transition to Agile (Part 1) | Supreme Agile

תוצאת תמונה עבור ‪agile transformation‬‏
When examining the last few years, we can see the extended amount of organizations that use Agile frameworks (Especially Scrum) as the preferred software development methodology. Some organizations had a massive success implementing and adopting Agile. While other organizations achieved partial success due to well-known problems that I will cover in this article.

Well, how can it be that organizations fail to adopt Agile? This is despite the fact that it is well known, there are many implementers, coaches and endless knowledge on the internet that is available for everyone. 

Well, the answer is not surprising and relatively simple. Agile is a document with a set of principles and values that are interpreted differently by different people. The direct result of this interpretation is the creation of too many ways to implement the method and the abandon of the real spirit of what this document really represents. 

This article will present some of the most common pitfalls made in organizations while implementing Agile. My recommendation for you is to pay attention to each one of the items described below and to ensure that you avoid them to achieve a successful transition process. 

Mistake #1 – Retrospectives without continues improvement

The main goal of the retrospective meeting is to allow the team to raise all issues that affect their progress and to suggest new ways to improve the process and their day-to-day work. Therefore, all action items must be prioritized and resolved quickly. If they are not, team members will have no respect for it and will not contribute to future meetings.

Keep in mind, that retrospectives are critical meetings during and after an Agile transition. Great trainers will use these meetings to show the team that they respect their problems and will do the necessary work to resolve them. This is one of the most important ways to start building the respect and trust between the team and the process. 

Mistake #2 – Agile as a Religion

This is one of the classic mistakes made by new Agile facilitators is using Agile as a religion. Therefore, they implement it without understanding the real needs of the customer. As a result, they fail to adjust his/her needs to resolve the true challenges raised by the customer.


Mistake #3 – Ignoring the Ceremonies

There is a reason to why we use ceremonies as part of the transition to Agile. These meetings allow both the organization and its teams to inspect and adapt the implementation. At a team level, ceremonies help the team to increase the collaboration, visibility, and efficiency from sprint to sprint. Below are some meeting types:
  • Daily meetings - Enables the team to synchronize and remain focused on the iteration goal.
  • Review meetings - enables the team to share their work.
  • Retrospectives - enables the team to grow using continues improvement.
  • Planning meetings – enables the team to understand the work prior to committing to it.

Mistake #4 – Poor Team Structure

When building Agile teams we should do our best to create teams that have all of the relevant skills to act as a truly cross-functional team. The main reason is to allow the team to make commitments at the start of the iteration (A.K.A: User Stories) and perform the necessary activities (Design, Coding Testing Etc.) to their completion.

Agile teams that do not have the correct mix of skills to act in this manner, will not be able to see the big picture of what it takes to complete a user story, or at worst deliver a poor quality implementation.

In addition to above, cross-functional teams have the ability to estimate the scope of work required to complete a story. However, should the team not have the relevant resources; they will most likely fail to make the correct estimations. This will result in resolve delays, increased pressure through the iteration and higher % completion failures. 

Mistake #5 – Not Enough Training

Once I was invited as a consultant to an organization that was in the middle of transitioning to Agile. The reason that they invited me was to analyze the current failures they had in the process that leads to increased frustration among their teams. The investigation results lead to a basic, but a crucial factor, there was a lack of training that was not part of the overall implementation strategy.

Making an Agile transition without providing the relevant training is like letting a person drive a car without experience. As part of an Agile transition, one must ensure that the implementation strategy includes providing relevant training to build the necessary foundations that will be used throughout the entire process. 

Mistake #6 – Automated Test Coverage  

The basic concept of Agile suggests a team should deliver an incremental release of the product at the end of each iteration. Well, automated testing is a critical factor in achieving this and can be the difference between a successful team and an unsuccessful one.

So why it is such a crucial factor?
  • Without automated testing, the team will create technical debt that will affect their progress in future iterations.
  • Automated testing helpד to increase the resilience of the code (Unit, Component and integration tests) and will help increase the quality of each delivery.
  • Automated testing will reduce the waste of time-related to regression testing. 


Mistake #7 –Product Owner is a JOB and not a Habit

The Product Owner is a critical role in the process and must be treated with the appropriate respect. It is easy to see why the Product Owner is a Key stakeholder in any Agile transition that uses Scrum as the chosen framework. From my years of experience, I have seen many teams that fail to perform their job due to chosen Product Owners (PO) for the role. A product owner without any knowledge, Experience, and skills cannot perform this function.

The product owner should be a person that understands the business and has the characteristics, time and expertise in the specific area. This is the only way to guarantee that the team will be able to prioritize the backlog, write good stories. These will ultimately increase the ROI of the team.

Mistake #8 – Start with a Management Tool

Another simple but costly mistake is an organization that starts with selecting the management tool prior to starting the Agile adoption. Sometimes it is justified to do it (Especially if the organization understands the needs that arise in a new Agile transition) but in many cases not. This is because the organization does not have the experience and therefore will try different tools that do not provide the necessary answers to manage an Agile transition process.

When starting a new transition, the organization must first gain a deeper understanding of the Agile Framework and the different concepts that come along with it.

Mistake #9 – Certification is not a guarantee of success  

I am not a great believer in certifications that you can get without real hands-on experience. In Agile there are many certifications such as CST, CSM, and CSPO that you can pass without any relation to the real practical world.

Because of the above, I have a major problem with organizations that start the process with Scrum Masters that do not have any experience or certified trainers who do not have a clue what it takes to transition the company to the new Framework

Trainers can assist, but one always needs to ask the right questions and not follow them blindly. Remember the trainer may not have any experience in your domain, organization culture, and the root problems that keep you from succeeding.

The exact same thing is relevant to the Product Owner and Scrum masters that are certified and no one trusts them to perform their job at the highest level. This can never happen without real experience (Simulating 1 or 2 situations during the course is just not good enough).


Mistake #10 – Ignore the Quality factor

Agile allows us to release an incremental release of the product and doing it fast. Many organization loves this approach due to many obvious reasons that we all familiar with. So what can go wrong here? Well, the answer related to a state of mind that delivering the product earlier and faster is enough to succeed, but it is not! Agile is not about delivering releases faster; it is about delivering quality releases in a way that will increase the trust between the customer and the team.

Using Agile is not a free license to provide fast releases of the software with poor quality that will affect the relationship with the customer. The team may release less functionality in a sprint, but once they do, the customer will know that it meets the quality standards he expects to see.

Mistake #11 – Customer as the Key Stakeholder

The Agile manifesto contains 4 values and 12 principles that state that the customer is the most important stakeholder and should be the center of any Agile project. Many Agile projects that fail related directly to this. The customer is left behind at critical junctions that have a major effect on the entire project. One must avoid this pitfall by ensuring the customer is involved throughout the sprints and his feedback is considered. This is the only way to ensure the team meets the customer vision and technical expectations. 


Mistake #12 – There is no Executives Support

Any transition should start with the support of the organization executives who will take a decisive role in the success of the implementation. Without their support, the new Scrum team will have more difficulties to adjust the new Agile approach. A

Wednesday, April 11, 2018

The Manager Role in Scrum Team | Supreme Agile


The scrum framework contains three mandatory roles that co-exist as scrum team, Development team, Scrum Master and Product owner (The general direction for the rest of the stakeholders such as management, architects Etc. is to support the team).

Because of this definition, we can now understand why the same question arises in almost any organization that is trying to make a transition to Scrum. “Where is the definition of team leader in scrum?”  Alternatively “Is there a necessity to keep them?” By asking these questions, we can understand that the organization is in the first phase of exploring scrum and what does it really means to implement it.  

If you are familiar with the Scrum framework, you are most probably aware that scrum teams are structurally different from traditional development teams.

In most cases, the traditional teams will follow a “Top-Down” approach where Management defines the project deliverables, schedule, and pace. While on the other hand, scrum teams will utilize a “Bottom-Up” approach, where they will determine their own pace and deliverables based on prioritization, Velocity, and capacity of the team (Under the restrictions of the organization boundaries of costs, Budget, declines etc. ).

The traditional role of a manager in the corporate world


The traditional role of a manager based on a well-known method of “Command and Control”. This method based on one single authority (Manager) that will control the major aspects of the project such as Team deliverables, Processes Schedules, and budget.

In this method the interaction between the manager and the employees is based on four simple phases:
  1. The Manager will identify the organizational “Needs” that based on budget, commitments and pre-defined plan.
  2. The Manager will provide to his employee a list of detailed instructions of demands, expectations, and goals (The employee should follow the instructions trusting the experience, judgment, and knowledge of the manager).
  3. The Manager will monitor the employee progress that based on specific instructions.
  4. The Manager will compare the employee deliverables based on the preliminary goals.
In the constantly changing software industry, this approach becomes less efficient and by far less productive than what we have in agile frameworks. There are many reasons that can explain this and why more and more organizations are now moving to agile. To clarify my point, I will focus on these three aspects:

Productivity – There is no way that a single manager can handle the current challenges that arise in almost any software development project (At least not in an effective way). Just think about the areas that this manager will have to handle in a single project starting from Understanding the organizational and technical requirements, Scheduling, Deliverables, and Quality.  

Centralized Management – We cannot throw this method just because we now have an alternative, but let us face it; centralized management comes with some major challenges starting from the need to issue list of technical instructions to the team (sometimes per employee), Handling internal/External dependencies and continuing with dealing with HR issues that may critically affect team performance.

Team Motivation – I think that we can all agree that this type of management (Depending on the manager and his leadership style) will not help to increase employee motivation. As followers, the employee role is to follow their manager instructions with the absence of freedom, decision making and trust that will not provide any sense of real ownership of their work.

Why agile can be scary for some managers? 


Prior to diving into the manager role in Scrum, I want to add more information about the “Bottom-Up” approach that used in Scrum. Scrum uses a more advanced approach to creating “Self-Organized, Cross-Functional” teams that can take full ownership of their work. This ownership is reflected in many aspects that were once fully managed by a single manager (described in the previous section) such as; determining the amount of work to deliver per iteration, Collective ownership of their work, Self-Management and the ability to decide how and who will perform which task to take. 

Now, as I mentioned at the beginning of this article, the Scrum Framework contains three main roles (Team, SM, and PO) that are critical to the success of the project. However, the Scrum Framework does not provide the same level of details regarding other main stakeholders that we expect to see in any SDLC project such as; Development manager, Project manager, product manager test manager or any other stakeholder that possess a management role.  

Therefore, those stakeholders who are involved in agile transition will struggle to find their role in the new agile teams. Especially when there are no criteria that specify their new responsibilities.  

The role of Managers in scrum team

In theory and based on my own interpretation of the Scrum Framework, the role of a manager in Scrum can be summarized as follows:

Re-Organization – I think that it is a classic for managers to help the organization to make the transition from a traditional way of working to scrum. Their work will focus on the “Re-Organization” and in the removal of any barriers that may affect this transition.

Servant leader – Similar to the role of the SM, managers should shift their state of mind from a single authority into servant leaders of their teams. Their new activities will focus on many aspects that will help their teams such as; creation of safe working environments to their teams, investigating for new tools that can improve efficiency and plan technical training that will improve areas where the team's skills could be improved.

Not interfere – It is simple, to allow Scrum teams to grow, the old fashion management must be removed and the team manager should take one-step back and not interfere with the Scrum implementation (It is a critical point for new teams that just started with scrum).

Change Agents  The organization TL’s should allow the organization to get the most from Agile, One way to achieve this, is to embrace the new agenda and state of mind that comes as mandatory part from this approach and to grow with it to help the organization to achieve better results.

Lead by Example – This is probably one of the most important keys to an Agile transition. Leaders that used to lead by “Authority” now must embrace the new culture and start to lead by “Example”. This is while at the same time allowing their teams to grow and take further ownership.  

Removing organizational Impediments – like we expect from the team Scrum Master to remove impediments that affecting their team capability to perform at the highest level, we can expect the same from the organizational TL’s to do the same. They need to reinforce the team with relevant resources, remove bureaucracy, and provide training as needed.

Feedback – Constructive feedback is another tool that managers can use to promote their agenda in their teams without enforcing it with authority as they used to do in the traditional style of management. Constructive feedback will assist the team to improve continuously.

Technical Assistance - Managers can use their knowledge, experience, and expertise to provide assistance whenever the team needs or ask for it.

Determine prioritization – This is a classic area for these managers to show their importance to their teams and especially in the process.  Using their knowledge, experience and broad perspective, they can allow the team to make a robust and more effective prioritization to increase their ROI.

Classic examples:
  • Assist team to prioritize technical debt affecting their ability to deliver real value. 
  • Assist team with the iteration planning and prioritization of their stories.
  • Assist Product Owner to prioritize the product backlog
  • Assist Product Owner and team to achieve the balance between “Functional” and “Non-Functional” stories.

Drop Their Ego – To be able to take part in the agile transition, managers will have to drop their ego and learn Agile from their Scrum Masters. Now’ it is easy to say it, but I have seen too many managers that fail to drop their ego and learn from someone that was under their direct management. This leads usually to unwanted results. 

Human Resources – Well, this aspect is still under the management responsibility. As part of his job, the TL will conduct regular 1:1 meetings with team members and provide assistance with different HR issues. In addition, they will recruit and hire new employees, integrate them into the team (With the collaboration of the SM) and remove any negative effect that may arise while integrates a new employee into the team.

The traditional manager as the new scrum master


A common approach to redefining the role of the traditional manager is to convert them into the new Scrum Masters of their old team. On the face of it, this seems to be good for the company, but believe me that it can be devastated for the team. When the manager plays the role of the SM, it is very unlikely that the team will gain a true confidence to begin to self-organize itself. The manager will most likely keep the hold management patterns and old habits that will make it almost impossible for him to release ownership to team members (an Agile fundamental concept).

Now, I have seen many team managers successfully transition, this is because they strongly believe in their team and in the Agile values. However, I always believe that the Scrum Master must be chosen and agreed by the team members and therefore should be one of them and not their old manager. 

Wrong Practices to avoid


Let us review some of the most common incorrect practices that I have seen in organizations in relation to this topic.

Assign the work for the team – one of the major cornerstones in Scrum, it the creation of “self-organized” teams that can determine for themselves the team member who will take ownership of the specific unit of work. Therefore, there is no need for using old management habits of assigning the work to the team.

Ensure work is completed – The team is responsible, therefore they need to follow the “Definition of Done” and “Acceptance” criteria.

Monitor what team members are doing – This responsibility belongs to the team, they need to provide answers during their daily scrum meeting. 

Work with your ego – Team leaders who fail to drop their ego and do not listen to their teams will become the team most critical impediment.

Prioritize the work – The team together with the product owner own the work. Therefore, the TL can assist and share his thoughts. He must not have the authority to delegate or priorities the work items. 

Decide what work needs to be delivered – It’s simple, the scrum framework provides two roles that are responsible to this issue, the PO that determines the features and requirements that need to be delivered and the development team that determines which tasks are necessary to achieve it.

Micro Management – I think that if you went this far in reading this article you have gained the knowledge to understand that Micro Management and Scrum are not linked to each other. 

My Presentations